Top chunk of the screen is 160 pixels wide, two scanlines tall,
pixels in one of 4 paletted colors. ?Bottom chunk of the screen is
four lines of 40 character wide, 8 scanlines tall text. ?The OS has
routines to construct basic Display Lists for various useful modes,
like this one.
A “scanline” is just a line just one pixel tall. The electron gun
“scans” from left to right, firing electrons at those mean phosphors
Then you’ve got Display List Interrupts, that allow you to change more
than just the mode; e.g., change the color palette, change the
horizontal scroll value, and change the horiz. position of sprites.
(Player/Missile Graphics on the 8-bit Atari; they were as tall as the screen,
so you could split them up by scanline.)
The NES hardware supported an overscanned tilemap with an offset value
and a number of arbitrary sprites also keyed to a four-color palette.
Super Mario Bros 3 was one of the first games (the first perhaps?)
that would use the hsync interrupt to swap out the values of the
sprite registers so that it could load up more sprites on the screen.
If you ever got too many sprites sharing the same scanline, they would
flicker!On Fri, Mar 27, 2009 at 3:49 PM, Bill Kendrick wrote:
A “scanline” is just a line just one pixel tall. The electron gun
“scans” from left to right, firing electrons at those mean phosphors
On the Atari, some pixels were more than 1 scanline tall.
(e.g., fullscreen graphics mode with 40x24 pixels vs.
fullscreen graphics mode with 320x192 pixels. In the former case,
pixels were 8 scanlines tall. In the later, they were 1 scanline tall.)
> If you ever got too many sprites sharing the same scanline, they would
> flicker!
Multiplexing, I think is the term. Some games, on some platforms, do it
pretty well. Other games do it pretty terribly.On Fri, Mar 27, 2009 at 04:23:25PM -0400, Donny Viszneki wrote:
–
-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/
Hiyya, …question… This is how I double buff. Does the new 1.3 code do this too? And if so or not ,why? (so there is little chance for confusion)
//done with sending vertices to the pipeline so need to signal the
//hardware to flip context surfaces, sending the back buffer to the display
void ScreenRenderer::flipDevice()
{
glFlush(); //flush any commands leftover in th OpenGL pipeline
SDL_GL_SwapBuffers(); //swap our buffers
}
---- Donny Viszneki <donny.viszneki at gmail.com> wrote:=============
On Fri, Mar 27, 2009 at 3:49 PM, Bill Kendrick wrote:
Top chunk of the screen is 160 pixels wide, two scanlines tall,
pixels in one of 4 paletted colors. ?Bottom chunk of the screen is
four lines of 40 character wide, 8 scanlines tall text. ?The OS has
routines to construct basic Display Lists for various useful modes,
like this one.
A “scanline” is just a line just one pixel tall. The electron gun
“scans” from left to right, firing electrons at those mean phosphors
Then you’ve got Display List Interrupts, that allow you to change more
than just the mode; e.g., change the color palette, change the
horizontal scroll value, and change the horiz. position of sprites.
(Player/Missile Graphics on the 8-bit Atari; they were as tall as the screen,
so you could split them up by scanline.)
The NES hardware supported an overscanned tilemap with an offset value
and a number of arbitrary sprites also keyed to a four-color palette.
Super Mario Bros 3 was one of the first games (the first perhaps?)
that would use the hsync interrupt to swap out the values of the
sprite registers so that it could load up more sprites on the screen.
If you ever got too many sprites sharing the same scanline, they would
flicker!
You could, of course, ask anyone else on the list who could then tell
you to just look in the header file SDL_video.h on the ViewVC, which
is available via www.libsdl.org. If the API (or one with a similar
name) is still there, then the functionality is still there.
As to whether the OpenGL backend supports double buffering… check
the docs for it or I dunno… write a nody program that asks for a DB
context, and then check to see if you actually got a DB context…
SDL_GL_SwapBuffers() is a wrapper around the plaform-specific way of
flipping buffers in the context. It’s fundamental to being able to use
OpenGL in a platform-independent way, so I doubt it’s been removed
entirely.
Eddy
2009/3/28 :> Hiyya, …question… This is how I double buff. Does the new 1.3 code do this too? And if so or not ,why? (so there is little chance for confusion)
//done with sending vertices to the pipeline so need to signal the
//hardware to flip context surfaces, sending the back buffer to the display
void ScreenRenderer::flipDevice()
{
glFlush(); //flush any commands leftover in th OpenGL pipeline
SDL_GL_SwapBuffers(); //swap our buffers
}
---- Donny Viszneki <donny.viszneki at gmail.com> wrote:
=============
On Fri, Mar 27, 2009 at 3:49 PM, Bill Kendrick wrote:
Top chunk of the screen is 160 pixels wide, two scanlines tall,
pixels in one of 4 paletted colors. ?Bottom chunk of the screen is
four lines of 40 character wide, 8 scanlines tall text. ?The OS has
routines to construct basic Display Lists for various useful modes,
like this one.
A “scanline” is just a line just one pixel tall. The electron gun
“scans” from left to right, firing electrons at those mean phosphors
Then you’ve got Display List Interrupts, that allow you to change more
than just the mode; e.g., change the color palette, change the
horizontal scroll value, and change the horiz. position of sprites.
(Player/Missile Graphics on the 8-bit Atari; they were as tall as the screen,
so you could split them up by scanline.)
The NES hardware supported an overscanned tilemap with an offset value
and a number of arbitrary sprites also keyed to a four-color palette.
Super Mario Bros 3 was one of the first games (the first perhaps?)
that would use the hsync interrupt to swap out the values of the
sprite registers so that it could load up more sprites on the screen.
If you ever got too many sprites sharing the same scanline, they would
flicker!
I don’t know if the SDL_DOUBLEBUF flag actually enables double
buffering when combined with the SDL_OPENGL flag. Use this:
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);On Mon, Mar 30, 2009 at 12:57 PM, Edward Cullen wrote:
As to whether the OpenGL backend supports double buffering… check
the docs for it or I dunno… write a nody program that asks for a DB
context, and then check to see if you actually got a DB context…
SDL_GL_SwapBuffers() is a wrapper around the plaform-specific way of
flipping buffers in the context. It’s fundamental to being able to use
OpenGL in a platform-independent way, so I doubt it’s been removed
entirely.
2009/3/30 Donny Viszneki <donny.viszneki at gmail.com>:
As to whether the OpenGL backend supports double buffering… check
the docs for it or I dunno… write a nody program that asks for a DB
context, and then check to see if you actually got a DB context…
SDL_GL_SwapBuffers() is a wrapper around the plaform-specific way of
flipping buffers in the context. It’s fundamental to being able to use
OpenGL in a platform-independent way, so I doubt it’s been removed
entirely.
I don’t know if the SDL_DOUBLEBUF flag actually enables double
buffering when combined with the SDL_OPENGL flag. Use this:
I do know; it does NOT. What I was referring to when I said ‘back
end’, is that, I believe, that the ‘normal’ 2D SDL functionality has
been implemented (in 1.3, as an option) in OpenGL, which gives
performance improvement in some applications. There is an important
distinction between the ‘hidden’ GL backend for the 2D stuff and the
‘public’ 3D GL.
The question wasn’t exactly clear. The point of my answer was that
the overwhelming majority of the answers can be found by reading the
documentation, exploring the code and experimentation… funnily
enough, these are the 3 things professional programmers do as a matter
of course… scarry that, don’t you think?
Also, giving someone an answer holds them back. IF someone discovers
an answer for themselves, they will own the answer, this leads to
improved confidence and also and most importantly, they will remember
it better.
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
Which you have to do before you create the context… as documented on
the doc wiki.> On Mon, Mar 30, 2009 at 12:57 PM, Edward Cullen <@Edward_Cullen> wrote:
