SDL_FLip Argument

Hi,

SDL_Flip currently takes one argument: A pointer to the display
surface. I find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Why does SDL_Flip need this argument? There’s only 1 thing you can pass.
Why not just:

SDL_Flip();

Just curious, especially since SDL_Flip already knows the display
surface through the SDL_(Video|Shadow)Surface pointers.

Thanks,

  • Roy Wellington IV

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called screen onto the video hardware. before I do this frames can pass all they want without update. Does that make sense?----------------------------------------

---- Roy Wellington IV <cactus_hugged at yahoo.com> wrote:

=============
Hi,

SDL_Flip currently takes one argument: A pointer to the display
surface. I find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Why does SDL_Flip need this argument? There’s only 1 thing you can pass.
Why not just:

SDL_Flip();

Just curious, especially since SDL_Flip already knows the display
surface through the SDL_(Video|Shadow)Surface pointers.

Thanks,

  • Roy Wellington IV

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Let me add to the questions: Does flipping a non-display surface do
anything useful? Is the argument important in SDL 1.3 with its multiple
windows?

Jonny DOn Sun, Mar 22, 2009 at 4:39 AM, wrote:

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called screen
onto the video hardware. before I do this frames can pass all they want
without update. Does that make sense?



---- Roy Wellington IV <cactus_hugged at yahoo.com> wrote:

=============
Hi,

SDL_Flip currently takes one argument: A pointer to the display
surface. I find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Why does SDL_Flip need this argument? There’s only 1 thing you can pass.
Why not just:

SDL_Flip();

Just curious, especially since SDL_Flip already knows the display
surface through the SDL_(Video|Shadow)Surface pointers.

Thanks,

  • Roy Wellington IV

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called screen
onto the video hardware. before I do this frames can pass all they want
without update. Does that make sense?

This is incorrect.

2009/3/22 Jonathan Dearborn :

Let me add to the questions:? Does flipping a non-display surface do
anything useful?? Is the argument important in SDL 1.3 with its multiple
windows?

I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.On Sun, Mar 22, 2009 at 4:39 AM, wrote:

On Sat, Mar 21, 2009 at 10:25 PM, Roy Wellington IV <cactus_hugged at yahoo.com> wrote:

Hi,

SDL_Flip currently takes one argument: A pointer to the display surface. I
find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Just store the result of SDL_SetVideoMode() and use that instead.
SDL_GetVideoSurface() is deprecated.


http://codebad.com/

Hiyya, Donny’s on the right track but one stop shy of the station. What he says does not contradict me. You can even triple buffer if you want.

http://en.wikipedia.org/wiki/Triple_buffering-------------------------------

---- Donny Viszneki <donny.viszneki at gmail.com> wrote:

=============
On Sun, Mar 22, 2009 at 4:39 AM, <@necron> wrote:

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called screen
onto the video hardware. before I do this frames can pass all they want
without update. Does that make sense?

This is incorrect.

2009/3/22 Jonathan Dearborn :

Let me add to the questions:? Does flipping a non-display surface do
anything useful?? Is the argument important in SDL 1.3 with its multiple
windows?

I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.

On Sat, Mar 21, 2009 at 10:25 PM, Roy Wellington IV <cactus_hugged at yahoo.com> wrote:

Hi,

SDL_Flip currently takes one argument: A pointer to the display surface. I
find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Just store the result of SDL_SetVideoMode() and use that instead.
SDL_GetVideoSurface() is deprecated.


http://codebad.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What you said, for the most part, made no sense, esp:
"before I do this frames can pass all they want without update"
What I think you mean is:
“You can blit all you want to the back buffer, but the screen won’t
actually update until you call SDL_Flip()”
… something I am aware of. I know how to use SDL_Flip() - my question
is why do you have to pass an argument to it? The /only/ valid thing to
pass SDL_Flip is a SDL_Surface * to a screen (or a buffer of a screen,
if you’re doing double buffer.) If you look at the source code, you’ll
see that regardless of what you’re doing, there is only 1 valid input to
the function: The result of SDL_SetVideoMode(), which is the same as
SDL_GetVideoSurface(), meaning that the only valid way to call
SDL_Flip() is:
SDL_Flip(SDL_GetVideoSurface())
…or something that equates to that. If you take a look in the code,
you’ll see that if you pass any other surface, the function becomes a no-op.

However, Donny’s answer of:
“I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.”
…would be a perfectly valid reason to have that SDL_Surface* argument
to SDL_Flip(), and more or less answers my question. Additionally, if
SDL_GetVideoSurface() is deprecated, then I should stop using it…

I feel I should ask… why? SDL_GetVideoSurface() is a darn useful
function. My other choices are to pass a SDL_Surface * all the way down
the call stack (annoying) or declare a global (ew, esp since SDL already
has it - that’s what SDL_GetVideoSurface() returns!)

necronology at cox.net wrote:> Hiyya, Donny’s on the right track but one stop shy of the station. What he says does not contradict me. You can even triple buffer if you want.

http://en.wikipedia.org/wiki/Triple_buffering



---- Donny Viszneki <donny.viszneki at gmail.com> wrote:

=============
On Sun, Mar 22, 2009 at 4:39 AM, wrote:

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called screen
onto the video hardware. before I do this frames can pass all they want
without update. Does that make sense?

This is incorrect.

2009/3/22 Jonathan Dearborn :

Let me add to the questions: Does flipping a non-display surface do
anything useful? Is the argument important in SDL 1.3 with its multiple
windows?

I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.

On Sat, Mar 21, 2009 at 10:25 PM, Roy Wellington IV <@Roy_Wellington> wrote:

Hi,

SDL_Flip currently takes one argument: A pointer to the display surface. I
find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());

Just store the result of SDL_SetVideoMode() and use that instead.
SDL_GetVideoSurface() is deprecated.

Wouldn’t it be usefull if you could also flip other surfaces? We have
some internal buffers in our game where we more or less implemented
something similar than double buffering, whereby the code would have
been much easier if we would be able to have double buffering for some
surfaces. I wondered at the time when I implemented that, if the
hardware can do that already (or if the hardware can do that only for
the screen surface). Anyway, our implementation is also very fast as
the flip is just a swap of two pointers.Am 27.03.2009 um 04:11 schrieb Roy Wellington IV:

What you said, for the most part, made no sense, esp:
"before I do this frames can pass all they want without update"
What I think you mean is:
“You can blit all you want to the back buffer, but the screen won’t
actually update until you call SDL_Flip()”
… something I am aware of. I know how to use SDL_Flip() - my
question is why do you have to pass an argument to it? The /only/
valid thing to pass SDL_Flip is a SDL_Surface * to a screen (or a
buffer of a screen, if you’re doing double buffer.) If you look at
the source code, you’ll see that regardless of what you’re doing,
there is only 1 valid input to the function: The result of
SDL_SetVideoMode(), which is the same as SDL_GetVideoSurface(),
meaning that the only valid way to call SDL_Flip() is:
SDL_Flip(SDL_GetVideoSurface())
…or something that equates to that. If you take a look in the
code, you’ll see that if you pass any other surface, the function
becomes a no-op.

However, Donny’s answer of:
“I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.”
…would be a perfectly valid reason to have that SDL_Surface*
argument to SDL_Flip(), and more or less answers my question.
Additionally, if SDL_GetVideoSurface() is deprecated, then I should
stop using it…

I feel I should ask… why? SDL_GetVideoSurface() is a darn useful
function. My other choices are to pass a SDL_Surface * all the way
down the call stack (annoying) or declare a global (ew, esp since
SDL already has it - that’s what SDL_GetVideoSurface() returns!)

necronology at cox.net wrote:

Hiyya, Donny’s on the right track but one stop shy of the station.
What he says does not contradict me. You can even triple buffer if
you want.
http://en.wikipedia.org/wiki/Triple_buffering


---- Donny Viszneki <donny.viszneki at gmail.com> wrote: =============
On Sun, Mar 22, 2009 at 4:39 AM, wrote:

Hiyya, I think it’s use is just

SDL_Flip(screen);

It shows that I want to dump what I have in the sdl surface called
screen
onto the video hardware. before I do this frames can pass all they
want
without update. Does that make sense?
This is incorrect.
2009/3/22 Jonathan Dearborn :
Let me add to the questions: Does flipping a non-display surface do
anything useful? Is the argument important in SDL 1.3 with its
multiple
windows?
I believe it has always been the case that the API accepts an
SDL_Surface* argument so that when multiple buffered displays were
implemented, the SDL_Flip() API wouldn’t change.
On Sat, Mar 21, 2009 at 10:25 PM, Roy Wellington IV <cactus_hugged at yahoo.com> wrote:
Hi,

SDL_Flip currently takes one argument: A pointer to the display
surface. I
find myself doing some form of this all day:

SDL_Flip(SDL_GetVideoSurface());
Just store the result of SDL_SetVideoMode() and use that instead.
SDL_GetVideoSurface() is deprecated.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I feel I should ask… why? SDL_GetVideoSurface() is a darn useful function.
My other choices are to pass a SDL_Surface * all the way down the call stack
(annoying) or declare a global (ew, esp since SDL already has it - that’s
what SDL_GetVideoSurface() returns!)

SDL 1.3 gets multiple windows, which are multiple video surfaces.
Which one should SDL_GetVideoSurface return? This is also,
incidentally, why SDL_Flip takes a parameter, to know which one to
push to the screen.On Thu, Mar 26, 2009 at 11:11 PM, Roy Wellington IV <cactus_hugged at yahoo.com> wrote:


http://pphaneuf.livejournal.com/

Wouldn’t it be usefull if you could also flip other surfaces? We have some
internal buffers in our game where we more or less implemented something
similar than double buffering, whereby the code would have been much easier
if we would be able to have double buffering for some surfaces. I wondered
at the time when I implemented that, if the hardware can do that already (or
if the hardware can do that only for the screen surface). Anyway, our
implementation is also very fast as the flip is just a swap of two pointers.

You might find the actual implementation of SDL_Flip very interesting
and enlightening, search for it in this file:

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/SDL_compat.c?view=markup

Note the name of the file. This is pretty much left in the name of not
breaking older programs when we could still fake it easily. Also, you
could be more clever and update just the part you need updated instead
of the whole thing (and as you can see, it hasn’t been a real hardware
page flip for a really long time).

I didn’t inspect all the code paths, but for most platforms (at least
Mac OS X, X11 and the WinDIB driver, I think), you’re already
effectively getting double buffering, so if you’re doing double
buffering in your program, it’s become triple buffering at that point,
and you’re spending a lot of time moving pixels around…On Thu, Mar 26, 2009 at 11:22 PM, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:


http://pphaneuf.livejournal.com/

Hiyya, Answers come easy, it’s asking the right questions that’s hard. I’ll ask a question myself.

Why was SDL_flip needed in old sdl and it’s not needed in the new sdl?

I’m too lazy to delete the rest…

You might find the actual implementation of SDL_Flip very interesting
and enlightening(new sdl)

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/SDL_compat.c?view=markup

you could be more clever and update just the part you need updated instead of the whole thing (and as you can see, it hasn’t been a real hardware page flip for a really long time). See the term frame buffer.

I didn’t inspect all the code paths, but for most platforms (at least
Mac OS X, X11 and the WinDIB driver, I think), you’re already
effectively getting double buffering, so if you’re doing double
buffering in your program, it’s become triple buffering at that point,
and you’re spending a lot of time moving pixels around…

Wouldn’t it be usefull if you could also flip other surfaces? We
have some
internal buffers in our game where we more or less implemented
something
similar than double buffering, whereby the code would have been
much easier
if we would be able to have double buffering for some surfaces. I
wondered
at the time when I implemented that, if the hardware can do that
already (or
if the hardware can do that only for the screen surface). Anyway, our
implementation is also very fast as the flip is just a swap of two
pointers.

You might find the actual implementation of SDL_Flip very interesting
and enlightening, search for it in this file:

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/SDL_compat.c?view=markup

That’s indeed interesting. Here for reference the SDL 1.2 version:
http://www.libsdl.org/cgi/viewvc.cgi/branches/SDL-1.2/src/video/SDL_video.c?view=markup

Note the name of the file. This is pretty much left in the name of not
breaking older programs when we could still fake it easily. Also, you
could be more clever and update just the part you need updated instead
of the whole thing (and as you can see, it hasn’t been a real hardware
page flip for a really long time).

What do you mean? It seems that in SDL 1.2, it is a hardware page flip
(or do I missinterpret the source there?).

I didn’t inspect all the code paths, but for most platforms (at least
Mac OS X, X11 and the WinDIB driver, I think), you’re already
effectively getting double buffering, so if you’re doing double
buffering in your program, it’s become triple buffering at that point,
and you’re spending a lot of time moving pixels around…

When we used SDL_Flip in the beginning, I thought of it as a very fast
function because a surface flip seemed to be something very fast,
should be done almost immediatly. I think the name of the function
leads to such a thought.

For some systems (don’t remember anymore the settings; I think
hardware surfaces was a requirement), this was also true.

For some others though, it was not. When we did some profiling, it
seemed that about 30% of the whole runtime of the program was spent
in SDL_Flip!

That was when we introduced another layer, because I thought I can
make a swap of two SDL_Surface pointers much faster. Now, we have kind
of Video post processor which has two SDL_Surfaces and a pointer two
one of those. We always draw to the pointed surface in our main loop.
The video post processor has an own thread where it blits the
(back-)surface to the actual video surface and where it does the
SDL_Flip(). (Optionally, it can do also some post processing, we have
different post processors you can use, e.g. some resampling, or
scaling up, or whatever.) Then there is a flip() function, which just
swaps the pointer to the other surface.

By this way, we have the slow SDL_Flip() mostly parallel to the main
loop and we can also do some post processing, also in parallel to the
main loop.Am 27.03.2009 um 04:28 schrieb Pierre Phaneuf:

On Thu, Mar 26, 2009 at 11:22 PM, Albert Zeyer <@Albert_Zeyer> wrote:

Why was SDL_flip needed in old sdl and it’s not needed in the new sdl?

It is needed. It’s a shame that we don’t have a real buffer swap for
the OpenGL back-end.

Wouldn’t it be usefull if you could also flip other surfaces?

This is kind of a corner case and doesn’t reflect any real underlying
functionality provided by computers. It’s easy enough to implement
yourself.

I didn’t inspect all the code paths, but for most platforms (at least
Mac OS X, X11 and the WinDIB driver, I think), you’re already
effectively getting double buffering, so if you’re doing double
buffering in your program, it’s become triple buffering at that point,
and you’re spending a lot of time moving pixels around…

Yes, there are there potentially three intervening buffers between the
program and the user, but that isn’t necessarily the same as double
buffering at all. I believe if you ask for a single buffer in OpenGL
on Mac OS X with its hardware accelerated window compositing, yes
there is an extra intervening buffer, but you don’t get to explicitly
tell that buffer when to update, it will just update every time Mac OS
X decides to do so, won’t it? Hopefully that’s as often as possible,
since if you asked for a single buffer from OpenGL, you should know
why you asked for it.

When we used SDL_Flip in the beginning, I thought of it as a very fast
function because a surface flip seemed to be something very fast, should be
done almost immediatly. I think the name of the function leads to such a
thought.

Well, if the back-end supports a fast double buffering, it is. Almost
every display adapter works by constantly reading the frame buffer and
outputting some kind of video signal based on that data (combined with
some other settings, probably gamma function for one.) Switching it to
a different framebuffer (when it supports this) is, then, usually very
fast. With a compositing layer between you and the actual video
hardware, though, I don’t know what happens. SDL_FULLSCREEN FTW

For some systems (don’t remember anymore the settings; I think hardware
surfaces was a requirement), this was also true.

For some others though, it was not. When we did some profiling, it seemed
that about 30% of the whole runtime of the program was spent in SDL_Flip!

That was when we introduced another layer, because I thought I can make a
swap of two SDL_Surface pointers much faster. Now, we have kind of Video
post processor which has two SDL_Surfaces and a pointer two one of those. We
always draw to the pointed surface in our main loop. The video post
processor has an own thread where it blits the (back-)surface to the actual
video surface and where it does the SDL_Flip(). (Optionally, it can do also
some post processing, we have different post processors you can use, e.g.
some resampling, or scaling up, or whatever.) Then there is a flip()
function, which just swaps the pointer to the other surface.

By this way, we have the slow SDL_Flip() mostly parallel to the main loop
and we can also do some post processing, also in parallel to the main loop.

Ah, so you overcame a throughput bottleneck by letting your main
thread skip over the lock condition of emulating double buffering? I
suppose for systems without real double buffering, it might be a good
idea to have an option to do the buffer swap in its own thread? A lot
of SDL games do their game processing in the same thread as their
drawing, this would probably be a cheap (as in SDL hacking time) way
to give a performance boost to most of them. Although it would just
require a lock on the display surface, I guess.On Fri, Mar 27, 2009 at 3:32 AM, wrote:
On Fri, Mar 27, 2009 at 6:54 AM, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:

Am 27.03.2009 um 04:28 schrieb Pierre Phaneuf:

On Thu, Mar 26, 2009 at 11:22 PM, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:


http://codebad.com/

That’s indeed interesting. Here for reference the SDL 1.2 version:
http://www.libsdl.org/cgi/viewvc.cgi/branches/SDL-1.2/src/video/SDL_video.c?view=markup

Where it calls video->FlipHWSurface if it has the SDL_DOUBLEBUF flag…

What do you mean? It seems that in SDL 1.2, it is a hardware page flip (or
do I missinterpret the source there?).

… but the windib driver doesn’t have a FlipHWSurface at all (it’s
NULL, I expect it just doesn’t apply the SDL_DOUBLEBUF flag to any
surface it creates), the x11 implementation is “return(0)” (and
probably doesn’t apply the flag either), and the Quartz driver (on Mac
OS X) seems to have some sort of emulation set up, not really doing
anything in hardware…

Page flipping is a rather ancient method, at this point in time, and
even when it’s available (I think the windx5 SDL driver has it?), it’s
strictly fullscreen, for obvious reasons. This was useful in the era
of DOS games, where all you had was basic VGA register twiddling,
which only included setting the video mode, setting the display offset
(a full screen down, and you have page flipping), and querying whether
we were vblanked (the cathode ray being on and drawing down the
screen, or off and going back up to the top). Oh, and changing the
video memory page, for those cards with more than 64K of video memory
(WOO!!!)…

Since the mid to late 90’s, video cards have had 2D accelerators which
could at least do solid block copies within the video memory, some of
them even with a bit to automatically vsync the command (so you send
the command whenever, and the video card will take care of waiting
until the vblank is on before doing it, and the CPU is free to keep
going with other stuff). So you just draw offscreen, maybe even in a
smaller than fullscreen buffer (for windowed mode), and have
accelerated blits that effectively take zero CPU to move it to the
screen. I’m pretty sure that resolution and 2D accelerator performance
went hand-in-hand well enough that you could pretty much always copy a
full screen from off-screen to on-screen within a vblank cycle, so
this was, for all intends and purpose, as fast as page flipping.

Now, graphics APIs don’t even let us access the video memory at all,
so not only is page flipping rarely useful, it’s rarely available to
us at all.

I didn’t inspect all the code paths, but for most platforms (at least
Mac OS X, X11 and the WinDIB driver, I think), you’re already
effectively getting double buffering, so if you’re doing double
buffering in your program, it’s become triple buffering at that point,
and you’re spending a lot of time moving pixels around…

When we used SDL_Flip in the beginning, I thought of it as a very fast
function because a surface flip seemed to be something very fast, should be
done almost immediatly. I think the name of the function leads to such a
thought.

For some systems (don’t remember anymore the settings; I think hardware
surfaces was a requirement), this was also true.

If “in the beginning” was on Windows at the time SDL has the windx5
driver at higher priority than the windib one, then with fullscreen
and hardware surfaces, you could indeed get correctly working page
flipping.

For some others though, it was not. When we did some profiling, it seemed
that about 30% of the whole runtime of the program was spent in SDL_Flip!

For all those other cases (which are now most of the cases that you
probably care about in SDL 1.2, and all the time in 1.3), this is
now what happens. SDL_UpdateRect takes an amount of time proportional
to the area of the rectangle, so that’s why you can be clever and try
to update a smaller area than the whole screen (which is what the
SDL_Flip fallback does), and save significant amount of time. A
tile-based scheme is fairly common, but there’s also a (minimal)
overhead per call to SDL_UpdateRect, so you don’t want 1x1 pixel tiles
either, there’s diminishing returns, until the per-call overhead
becomes more than you save.

That was when we introduced another layer, because I thought I can make a
swap of two SDL_Surface pointers much faster. Now, we have kind of Video
post processor which has two SDL_Surfaces and a pointer two one of those. We
always draw to the pointed surface in our main loop. The video post
processor has an own thread where it blits the (back-)surface to the actual
video surface and where it does the SDL_Flip(). (Optionally, it can do also
some post processing, we have different post processors you can use, e.g.
some resampling, or scaling up, or whatever.) Then there is a flip()
function, which just swaps the pointer to the other surface.

By this way, we have the slow SDL_Flip() mostly parallel to the main loop
and we can also do some post processing, also in parallel to the main loop.

If the SDL_UpdateRect (hidden in SDL_Flip) is done in software (like
in many of the useful drivers now, unfortunately), then your strategy
is pretty good. That’s also what the SDL_ASYNCBLIT flag was created,
which does something along the lines of what you’re doing, using
another thread for the memory copy, but that wasn’t so popular, and
has a few drawbacks… For single CPU/core machines, you still lose
that 30% of CPU time (and it actually probably increases to something
like 40%, because of cache misses and context switches), but instead
of it being spent all in one chunk, it’s automatically intermixed with
the rest of your code (the CPU will blit a little bit, then run a bit
of your game logic, then blit a little bit more, and so on).

For top-notch performance, you want to go with the new “renderer” SDL
1.3 API (stay clear of the SDL_compat.h file!), that uses "textures"
instead of surfaces (they’re the same kind of thing, really, not much
to do with 3D or anything, it’s just a name for “the new fancypants
surfaces”), and use the SDL_TEXTUREACCESS_STATIC flag on as many
textures as possible (you can’t access the pixels, but the accelerator
has a lot more flexibility to do whatever it takes to put it in video
memory and use hardware acceleration, like encode it in a special
format or whatever). This will have more variability than the SDL 1.2
API (or the “compat” API in 1.3), where it could give you 500 fps on
one machine and only 30 on another, but in any case, it should not be
worse than the 1.2 API performance, which did its best to emulate a
crummy old DOS-era state of things that didn’t really map all that
well and usually ended up doing things in software…On Fri, Mar 27, 2009 at 6:54 AM, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:


http://pphaneuf.livejournal.com/

Why don’t modern systems have the old Display List concept that systems
like the Atari 8-bit and Amiga (I think?) had.

On the Atari, you had the ability to, at any point down the length of
the screen, tell it to start reading display data from somewhere else
in memory.

Apply this to rectangular areas, and you’ve got very fast access to
arbitrary blocks of memory. (I think the Atari 7800 or Lynx could do
something like this?)

Ugh, anyway. Haven’t had coffee yet… can’t stop thinking about
Ataris. I’ll shut up now. :slight_smile:

-bill!On Fri, Mar 27, 2009 at 02:01:27PM -0400, Pierre Phaneuf wrote:

Page flipping is a rather ancient method, at this point in time, and
even when it’s available (I think the windx5 SDL driver has it?), it’s
strictly fullscreen, for obvious reasons. This was useful in the era
of DOS games, where all you had was basic VGA register twiddling,
which only included setting the video mode, setting the display offset
(a full screen down, and you have page flipping), and querying whether
we were vblanked (the cathode ray being on and drawing down the
screen, or off and going back up to the top). Oh, and changing the
video memory page, for those cards with more than 64K of video memory
(WOO!!!)…

Well, if the back-end supports a fast double buffering, it is. Almost
every display adapter works by constantly reading the frame buffer and
outputting some kind of video signal based on that data (combined with
some other settings, probably gamma function for one.) Switching it to
a different framebuffer (when it supports this) is, then, usually very
fast. With a compositing layer between you and the actual video
hardware, though, I don’t know what happens. SDL_FULLSCREEN FTW

The thing is, just about none of the modern APIs let you play with
switching the framebuffer that’s used. OpenGL (and I’m hoping Direct3D
too?) still has flags to do similar things, with things similar to SDL
happening when you’re in windowed mode (instead of getting page
flipping, it actually copies from an off-screen surface, or it just
fails when you try to set the option, I’m not sure).

With compositing, it usually works with “damage”, the display server
(be it X11 or Mac OS X’s Display Server) keeps track of all you do to
the surface, and tries to update the screen as soon as possible,
usually with vsync so that it looks good (it also does nothing if
there’s no damage, so it’s not too sucky).

Ah, so you overcame a throughput bottleneck by letting your main
thread skip over the lock condition of emulating double buffering? I
suppose for systems without real double buffering, it might be a good
idea to have an option to do the buffer swap in its own thread? A lot
of SDL games do their game processing in the same thread as their
drawing, this would probably be a cheap (as in SDL hacking time) way
to give a performance boost to most of them. Although it would just
require a lock on the display surface, I guess.

Sam is way ahead: SDL_ASYNCBLIT. :slight_smile:

But like I said, it doesn’t actually do anything with a lot of
drivers… And I expect that with the SDL 1.3 API actually getting the
hardware accelerators to do their fair share of work a lot more of the
time, it won’t matter again…On Fri, Mar 27, 2009 at 12:59 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:


http://pphaneuf.livejournal.com/

Why don’t modern systems have the old Display List concept that systems
like the Atari 8-bit and Amiga (I think?) had.

On the Atari, you had the ability to, at any point down the length of
the screen, tell it to start reading display data from somewhere else
in memory.

Man, that’s old school! Wasn’t that how some adventure games (King
Quest style, with graphics and a command prompt at the bottom)
combined graphics and text, by basically switching video “mode” at
some line? Couldn’t do that on my Apple II (but there was a built-in
variant)… :stuck_out_tongue:

Apply this to rectangular areas, and you’ve got very fast access to
arbitrary blocks of memory. ?(I think the Atari 7800 or Lynx could do
something like this?)

There’s a variant of that in common usage nowadays, for YUV video… :slight_smile:

Ugh, anyway. ?Haven’t had coffee yet… can’t stop thinking about
Ataris. ?I’ll shut up now. :slight_smile:

Hehe!On Fri, Mar 27, 2009 at 2:16 PM, Bill Kendrick wrote:


http://pphaneuf.livejournal.com/

In modern graphics vernacular, “display lists” are lists of graphics
instructions abstracted away form the procedural APIs of OpenGL et al.
It can be used to save your CPU and bus from having to repeat the same
operations as often.On Fri, Mar 27, 2009 at 2:16 PM, Bill Kendrick wrote:

Why don’t modern systems have the old Display List concept that systems
like the Atari 8-bit and Amiga (I think?) had.


http://codebad.com/

Man, that’s old school! Wasn’t that how some adventure games (King
Quest style, with graphics and a command prompt at the bottom)
combined graphics and text, by basically switching video “mode” at
some line? Couldn’t do that on my Apple II (but there was a built-in
variant)… :stuck_out_tongue:

Yeah, fire up an Atari emulator (like Atari800) with BASIC, then type:

GRAPHICS 7

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.

But you could mix-n-match all you wanted. “Star Raiders” had a
status display near the top of the screen. It was a 20-char-wide, 8-scan-hi
text mode. But it’d go away when there wasn’t a message, allowing
the starfield to get drawn there again.

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.)

Apply this to rectangular areas, and you’ve got very fast access to
arbitrary blocks of memory. ?(I think the Atari 7800 or Lynx could do
something like this?)

There’s a variant of that in common usage nowadays, for YUV video… :slight_smile:

I knew there was SOMEthing. This sometimes appears as a strangely
unsynched blue box when you move a video player around, sometimes, right?
(It almost looks like a chroma-key effect, like for TV special effects
and weather reports.)

-bill!
(who is running a ‘party’ with 12 Atari systems, spanning all platforms,
tomorrow… so I’ve been thinking about my heritage a LOT lately :wink:
http://www.newbreedsoftware.com/atariparty/ )On Fri, Mar 27, 2009 at 02:35:08PM -0400, Pierre Phaneuf wrote:

Yeah, in the old day, it was really just a way to tell the video chip
where to start accessing memory via DMA. :)On Fri, Mar 27, 2009 at 03:37:54PM -0400, Donny Viszneki wrote:

In modern graphics vernacular, “display lists” are lists of graphics
instructions abstracted away form the procedural APIs of OpenGL et al.


-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

There’s a variant of that in common usage nowadays, for YUV video… :slight_smile:

I knew there was SOMEthing. ?This sometimes appears as a strangely
unsynched blue box when you move a video player around, sometimes, right?
(It almost looks like a chroma-key effect, like for TV special effects
and weather reports.)

On some cards, it’s implemented with a chroma key, and sometimes
somewhat sloppily. I think there’s a whole other framebuffer, and the
chroma key says to go get the pixels from that other framebuffer (and
it could be any shape, but it’s normally filled with pixels of the
chroma key color, so no one is the wiser), so when you move the
window, the color keyed main framebuffer window gets moved, but the
video app has to blast a frame to the new location on the secondary
framebuffer…On Fri, Mar 27, 2009 at 3:49 PM, Bill Kendrick wrote:


http://pphaneuf.livejournal.com/