Scribd
Upload
27 views

Doublebuffering Access To Front and Backbuffer - SDL Development - Simple Directmedia Layer

The document discusses options for directly writing to the front buffer in SDL. It explains that SDL does not currently have an API for this, but suggests hacking the SDL source code to add this functionality and sharing the changes. It also discusses techniques like drawing to both the back and front buffers to achieve higher framerates.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
27 views

Doublebuffering Access To Front and Backbuffer - SDL Development - Simple Directmedia Layer

The document discusses options for directly writing to the front buffer in SDL. It explains that SDL does not currently have an API for this, but suggests hacking the SDL source code to add this functionality and sharing the changes. It also discusses techniques like drawing to both the back and front buffers to achieve higher framerates.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Doublebuffering access to front and backbuffer?

M_Egmond 1 December 31, 2002, 5:44pm

Hi all,

I am currently converting a game I wrote from Windows/DirectX to Linux/SDL.


In my game most graphics are written to the backbuffer and then flipped
onto the ‘visible’ screen. I have found this not to be a problem with SDL,
since I can use SDL_BlitSurface(source,rect,screen,rect) to blit from a
’source’ surface to the screen (backbuffer), and then use SDL_Flip() to
make it visible.

However, there are cases where I want to write a simple line or other
graphics onto the front buffer directly (to avoid having to flip again). I
set up double buffering (and SDL_HWSURFACE) in the call to SDL_SetVideoMode
(which works), but I can find no way to get a pointer to the frontbuffer
(as SDL_Surface). The SDL_GetVideoSurface() gives me the same pointer as
returned from the SDL_SetVideoMode, which is the backbuffer. Also after
flipping the SDL_GetVideoSurface still returns the same pointer.

The docs for SDL_GetVideoSurface say something about getting a ‘publicly


visible surface’ instead of the ‘real’ video surface if SDL does
conversion. I think SDL is not doing any conversions for me (is there a way
to find out for certain though? I use SDL_VideoModeOK() with 640x480 and it
returns 32bit mode as closest possible, so I use that - SDL shouldn’t do
any conversions then?).

I also couldn’t find any relevant info in the last two months of the
mailinglist-archive or the FAQ.

So is it possible to get a pointer to the front buffer (which is easy in


DirectX) or write (blit) to the front buffer directly? For simplicity
assume that I will set a video mode for which SDL does not have to do any
conversion so the ‘publicly visible’ vs ‘real’ surface isn’t an issue.

Thanks, Maarten.

Ney_Andre_de_Mello_Z 2 January 2, 2003, 6:50pm

M. Egmond wrote:

[…]

So is it possible to get a pointer to the front buffer (which is easy in


DirectX) or write (blit) to the front buffer directly?

I might me missing something, but why not just blit to the back buffer
before flipping?
Regards,–
Ney Andr? de Mello Zunino

Micah_Lee 3 January 2, 2003, 7:24pm

I think he probably has already written to the backbuffer and flipped


and doesn’t want to redraw everything again and flip again just to draw
a single line on the screen.

Micah> ----- Original Message -----

From: [email protected] [mailto:sdl-admin at libsdl.org] On Behalf Of


Ney Andr? de Mello Zunino
Sent: Wednesday, January 01, 2003 2:10 AM
To: sdl at libsdl.org
Subject: [SDL] Re: Doublebuffering access to front and backbuffer?

M. Egmond wrote:

[…]

So is it possible to get a pointer to the front buffer (which is easy


in
DirectX) or write (blit) to the front buffer directly?

I might me missing something, but why not just blit to the back buffer
before flipping?

Regards,

–
Ney Andr? de Mello Zunino

SDL mailing list


SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Daniel_Phillips 4 January 3, 2003, 7:29am

Unless you are always able to run well over 30 fps, the difference between
drawing into the buffer and drawing directly on the screen for things like
text and cursors is very easy to feel, i.e., 33 ms is too much for cursor
movement or keyboard feedback, whereas it is perfectly acceptable for 3D
object rendering.

Combining drawing a sprite, say, into the buffer and drawing the same sprite
directly to the screen at a higher framerate (don’t forget to draw it into
the back buffer first, or it will rip) is a technique I’ve used with success,
and which I consider essential for achieving that smooth, professional feel
for a 3D app, especially an editor.

Run a slow animation, and you will notice that the X cursor already works
this way, though I doubt that’s explicitly part of SDL.

A quick tour of the source suggest SDL doesn’t have an API for this yet.
Technically, it’s not hard, but getting it totally generic and convenient is
hard. My recommendation to the orignal poster: just get the SDL source,
hack it in the way that works for you in your configuration, then post your
hack for discussion.

DanielOn Wednesday 01 January 2003 08:09, Ney Andr? de Mello Zunino wrote:

M. Egmond wrote:

[…]

So is it possible to get a pointer to the front buffer (which is easy in


DirectX) or write (blit) to the front buffer directly?

I might me missing something, but why not just blit to the back buffer
before flipping?

M_Egmond 5 January 3, 2003, 12:03pm

At 2003-01-03 16:30, you wrote:

A quick tour of the source suggest SDL doesn’t have an API for this yet.
Technically, it’s not hard, but getting it totally generic and convenient is
hard. My recommendation to the orignal poster: just get the SDL source,
hack it in the way that works for you in your configuration, then post your
hack for discussion.

Thanks for the suggestion. The question about why I didn’t write to the
backbuffer and flip was indeed answered correctly by the other poster: I
don’t want to spend the same time again drawing the complete screen in the
backbuffer. It’s also a bit pragmatic as the current code I have uses
direct frontbuffer writes and it would be a lot of work to get them out.

I’m not sure I’m comfortable enough yet with Linux and X to hack (and
compile) the source code, but I’ll definately have a look as time permits.

Bob_Pendleton 6 January 4, 2003, 5:32pm

Combining drawing a sprite, say, into the buffer and drawing the same sprite
directly to the screen at a higher framerate (don’t forget to draw it into
the back buffer first, or it will rip) is a technique I’ve used with success,
and which I consider essential for achieving that smooth, professional feel
for a 3D app, especially an editor.

Run a slow animation, and you will notice that the X cursor already works
this way, though I doubt that’s explicitly part of SDL.

There are at least three different ways that the X cursor is drawn. Most
of the time (these days) there is hardware cursor support that inserts
the curors pixels into the video output in the video hardware. Sometimes
it is drawn using a real overlay plane. And, a lot of the time it is
drawn using “save unders”. Which means that the pixels under the cursor
are saved and the cursor is drawn directly into the frame buffer. Before
any drawing is done the server puts the pixels back does the drawing,
and then redraws the cursor. It gets more complicated in mulitibuffered
X servers, but I haven’t seen one of those for a long time.

I spent 5 years of my life porting X servers to high performance 3D


workstations. I’d almost give up a body part to find a job like that
again.

Bob PendletonOn Fri, 2003-01-03 at 09:30, Daniel Phillips wrote:

–
±-----------------------------------+

Bob Pendleton, consultant for hire +


Resume: http://www.jump.net/~bobp +
Email: @Bob_Pendleton +
±-----------------------------------+

You might also like