Surfaces in Double-Buffering (A bit urgent...)

SDL Development
1

Hi List!
I was working the whole weekend to get my stuff working on a system
with real double duffering and everything works fine, even if I had to
perform some crude steps. Now I have the problem, that the mousepointer
is not visible in the regular updated regions. No big problem, I thought, I
wanted a colored mousepointer, so this is the time to write. But to do this,
I need a surface pointer to the FRONT surface. As far as I understand the
SDL_GetVideoSurface function, this recieves only the back buffer. Is there
any way to get the front surface? If not, is it possible to integrate it into the
next CVS snapshot, as far as there are already some big steps ahead?
It would be nice, if anyone could find time to answer, because I want to
implement the mouse pointer this weekend…

Thanks in advance,
Andreas Podgurski

2

Couldn’t you just draw the cursor last, before the page flip?

-Darrell

3

Hi List!
I was working the whole weekend to get my stuff working on a system
with real double duffering and everything works fine, even if I had to
perform some crude steps. Now I have the problem, that the mousepointer
is not visible in the regular updated regions. No big problem, I thought, I
wanted a colored mousepointer, so this is the time to write. But to do this,
I need a surface pointer to the FRONT surface. As far as I understand the
SDL_GetVideoSurface function, this recieves only the back buffer. Is there
any way to get the front surface?

Well, you really want to write the mouse pointer on the back buffer right
before you flip, since otherwise you lose the mouse pointer as soon as you
perform the flip. :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

4

Well, you really want to write the mouse pointer on the back buffer right
before you flip, since otherwise you lose the mouse pointer as soon as you
perform the flip. :slight_smile:
No, I don’t want. I want to implement the same system I had on my old 486 to
do a mouse pointer. In this case, I’m moving the mouse pointer around on the
front surface, just like in a single buffer app, while the application is drawing the
other buffer. This system is still suitable while running on slow systems.
Shurly, the pointer is drawn into the back buffer before flipping just as it is erased
in the back buffer after flipping, but most drawing is done on the front screen. On
some (old) systems page flipping is not hardware accellerated an you can get max
10-12 frames, which is still enough for my application but too slow for a good mouse
pointer. Trust me, I know what I’m doing ;-).
Another thing, why I really need access to the front buffer is creating a GUI system
which works under double buffering. It is a roleplaying game I am writing, so I need
heavy db graphics AND heavy gui uses as well. Currently, I have an extra offsceen
buffer where the changes are stored, but accessing the front buffer directly would
make it much more easy and even faster…
In fact, there is a reason, why both buffers are accessable under DX…

Regards,
Andreas Podgurski

5

Wed, 13 Dec 2000 Andreas Podgurski wrote:

Well, you really want to write the mouse pointer on the back buffer right
before you flip, since otherwise you lose the mouse pointer as soon as you
perform the flip. :slight_smile:
No, I don’t want. I want to implement the same system I had on my old 486 to
do a mouse pointer. In this case, I’m moving the mouse pointer around on the
front surface, just like in a single buffer app, while the application is drawing the
other buffer. This system is still suitable while running on slow systems.

Ok, I get the point! (And I’m feeling right at home, as this is very similar to
what that old DOS game I’ve been tolking about is doing. :slight_smile:

The really nice way to do this is by using tripple buffering. And that’s not
the way DirectX usually does it (circulating the buffers), but treating the
third buffer as an off-line rendering target, that replaces one of the other
buffers when it’s ready.

Obviously, in your case, you’ll actually need quadruple buffering, as you need
to have two buffers ready before you can do the switch. (Unless the machine
is fast enough at copying full buffers…)

Shurly, the pointer is drawn into the back buffer before flipping just as it is erased
in the back buffer after flipping, but most drawing is done on the front screen. On
some (old) systems page flipping is not hardware accellerated an you can get max
10-12 frames, which is still enough for my application but too slow for a good mouse
pointer. Trust me, I know what I’m doing ;-).

This is very important if the pointer is to be usable. On the Amiga (full
frame rate, raster synced mouse pointer), I used to draw free-hand, but that
just won’t work with PC mice using the standard 20-30 Hz Win95/98 drivers.
(Many mice can be tuned up to 200 Hz, but Win95/98 drivers usually don’t
support that - probably just to make sure serious users switch to some other
OS…)

Now, speaking pointers, there is another problem with modern mice; they’re not
raster synced. This basically means that they won’t move smoothly even if you
speed them up to several times the frame rate! Same problem as the
interference phenomena you get with a decoupled game loop without
interpolating coordinates. I’d like to see a mouse driver where that’s
fixed… (Perhaps an XFree86 hack?)

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

6

Now, speaking pointers, there is another problem with modern mice; they’re not
raster synced. This basically means that they won’t move smoothly even if you
speed them up to several times the frame rate! Same problem as the
interference phenomena you get with a decoupled game loop without
interpolating coordinates. I’d like to see a mouse driver where that’s
fixed… (Perhaps an XFree86 hack?)
In fact, doing the mouse pointer worked perfect on my old 486 and should do that
on more modern machines, too, and definitly I had no need for triple or quadro buffering,
just because drawing and erasing a mouse pointer is even on that old machines fast
enough, especially because I did erasing and redrawing in one step using a special
region code to this. And I simply don’t see the problem you mentioned up here, because
I recieve the original mouse coordinates and not some delta values… And even if it
is so, the coordinates can be interpolated, not that hard to write, as far as my motion jpeg
decoder and several other parts, like scrolling and fadings are interpolated, too… Runs
quiet smooth… The only thing I really need to implement that stuff is to have access to the
front buffer just like in a single buffered app. In fact, it would be exactly that code, adding
some treatment of the flipping.

Regards,
Andreas Podgurski

7

Just use a separate thread to draw the mouse cursor.–
“and all the present leagues with all the past
and all the future to make war on me” — Petrarch, “Life Hurries On”

8

quiet smooth… The only thing I really need to implement that stuff is to have access to the
front buffer just like in a single buffered app. In fact, it would be exactly that code, adding
some treatment of the flipping.

Well, I’ll work up a quick hack for you (not advertised in the API), and
you can show me what you mean. I’d love to see a demo of this, and if it
works out well we can figure out the best way to expose this in the API.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

9

quiet smooth… The only thing I really need to implement that stuff is to have access to the
front buffer just like in a single buffered app. In fact, it would be exactly that code, adding
some treatment of the flipping.
Well, I’ll work up a quick hack for you (not advertised in the API), and
you can show me what you mean. I’d love to see a demo of this, and if it
works out well we can figure out the best way to expose this in the API.
Thanks! I’m trying to put a simple demo together as soon as possible. I hope to get the mouse
pointer running till then, at least the GUI refresh thing will be included, because this is finished.

Thanks again,
Andreas Podgurski

10

Wed, 13 Dec 2000 Andreas Podgurski wrote:

Now, speaking pointers, there is another problem with modern mice; they’re not
raster synced. This basically means that they won’t move smoothly even if you
speed them up to several times the frame rate! Same problem as the
interference phenomena you get with a decoupled game loop without
interpolating coordinates. I’d like to see a mouse driver where that’s
fixed… (Perhaps an XFree86 hack?)
In fact, doing the mouse pointer worked perfect on my old 486 and should do that
on more modern machines, too, and definitly I had no need for triple or quadro buffering,
just because drawing and erasing a mouse pointer is even on that old machines fast
enough, especially because I did erasing and redrawing in one step using a special
region code to this.

No, extra buffers are really overkill in this case, but more or less required
if you want to make sure there is no tearing, especially since you don’t have
an RTOS or even an RT ISR to do the pointer updating.

And I simply don’t see the problem you mentioned up here, because
I recieve the original mouse coordinates and not some delta values…

Well, the problem is when you receive and use the coordinates, in relation
to when they were actually captured (actually received - PC mice aren’t using
polling) from the mouse. If this isn’t a constant time, you’ll get unsmooth
movements (interference patterns), which is a problem if you’re doing serious
free-hand drawing.

And even if it
is so, the coordinates can be interpolated, not that hard to write,

Exactly. All you need is sufficiently accurate timestamps on the events in
relation to the video refresh rate…

as far as my motion jpeg
decoder and several other parts, like scrolling and fadings are interpolated, too… Runs
quiet smooth… The only thing I really need to implement that stuff is to have access to the
front buffer just like in a single buffered app. In fact, it would be exactly that code, adding
some treatment of the flipping.

Yes, indeed.

I’m not really arguing against front buffer access or something; just thinking
out loud. :slight_smile:

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

11

Wed, 13 Dec 2000 QuoteMstr wrote:

Just use a separate thread to draw the mouse cursor.

That only solves half of the problem. You still need access to the front
buffer, or you might as well throw the pointer in just before flipping.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’