I’m writing a tile-based game using SDL. It runs at 800x600x16-32bpp.
Under Win32 and X there are some graphic corruptions (artifacts?) that
appear to be the result of SDL updating the screen before the vertical
retrace, Is there a way around this? (My code basically just blits a
ton of rectangles on the screen and calls update.)
I’m writing a tile-based game using SDL. It runs at 800x600x16-32bpp.
Under Win32 and X there are some graphic corruptions (artifacts?) that
appear to be the result of SDL updating the screen before the vertical
retrace, Is there a way around this? (My code basically just blits a
ton of rectangles on the screen and calls update.)
This is a problem under Win32 and X which I don’t think has a solution.
The problem is that the window systems don’t sync to vertical retrace,
and control when to actually update the screen themselves.
The best way to minimize these artifacts is to keep a list of update
rectangles, and update them all at the same time, using SDL_UpdateRects().
See the screenlib example library for a sample implementation of this.
If you are using DirectX or X11 DGA, you can get access to the vertical
retrace, but I haven’t exposed it in the SDL API because of the problem
under windowing systems.
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
Sam Lantinga wrote:
This is a problem under Win32 and X which I don’t think has a solution.
The problem is that the window systems don’t sync to vertical retrace,
and control when to actually update the screen themselves.The best way to minimize these artifacts is to keep a list of update
rectangles, and update them all at the same time, using SDL_UpdateRects().
See the screenlib example library for a sample implementation of this.
Unfortunately I am updating the entire screen every frame, everything has to
be redrawn from scratch.
If you are using DirectX or X11 DGA, you can get access to the vertical
retrace, but I haven’t exposed it in the SDL API because of the problem
under windowing systems.
So why not just have to funtion return immediately if the function is not
useable in the current environment?
This is a problem under Win32 and X which I don’t think has a solution.
The problem is that the window systems don’t sync to vertical retrace,
and control when to actually update the screen themselves.
Usually this is solved by using two in-video buffers that are
flipped (double buffering). You blit to the non-visible surface
and after you finished you tell the video-hardware (or DirectX)
to swap the surfaces. This is done by setting the video-start-address to
this video-buffer; therefore the final
swap will occur after the next vertical blank and the glitches
that have been mentioned disappear.
I used that method with direct VGA-access but DirectX supports
that, too.
Bye,
Markus–
Dipl. Informatiker (FH) Markus Gietzen
@Markus_Gietzen
Author of XGenEm - SEGA Genesis/Mega Drive Emulator
Usually this is solved by using two in-video buffers that are
flipped (double buffering). You blit to the non-visible surface
and after you finished you tell the video-hardware (or DirectX)
to swap the surfaces. This is done by setting the video-start-address to
this video-buffer; therefore the final swap will occur after the next
vertical blank and the glitches
It sounds like page flipping is a feature that should appear in the next
version of SDL. 
I’ve been meaning to implement it for a while now.
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
It sounds like page flipping is a feature that should appear in the next
version of SDL.I’ve been meaning to implement it for a while now.
Mmmmmm… Page flipping (drool drool)
I want it too!!!
Josef Wells_
Program (pro’gram), n. A magical spell cast over a computer that turns
one’s input into error messages. v. To engage in an activity similar to
banging one’s head into a wall, but with less opportunity for reward.
Wise words from Josef Wells .aka. Scrub .aka. MadMan, for more, write
jwells at ece.utexas.edu
Josef Wells <josef.wells at analog.com> writes:
It sounds like page flipping is a feature that should appear in the next
version of SDL.I’ve been meaning to implement it for a while now.
Mmmmmm… Page flipping (drool drool)
I want it too!!!
it’s called double buffering, you draw to one section of memory while
the other one transfers to the video card memory…or if both
buffers can fit in the card’s memory then just swap which one the card
draws…
j
Jeff wrote:
it’s called double buffering, you draw to one section of memory while
the other one transfers to the video card memory…or if both
buffers can fit in the card’s memory then just swap which one the card
draws…j
Yeah, but I thought SDL did that already with SDL_UpdateRect(screen,0,0,0,0);
which would then flip the buffers, hmmm.
Yeah, but I thought SDL did that already with SDL_UpdateRect(screen,0,0,0,0);
which would then flip the buffers, hmmm.
It actually copies the buffers. The advantage of SDL_Flip() would be
that on hardware that supports it, the video display base address would
change, eliminating the need for an extra copy. In addition, if vertical
retrace waiting is enabled, it would also eliminate “tearing” artifacts.
It’s pretty nice.
(but not yet implemented)
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
emblem writes:
Jeff wrote:
it’s called double buffering, you draw to one section of memory while
the other one transfers to the video card memory…or if both
buffers can fit in the card’s memory then just swap which one the card
draws…j
Yeah, but I thought SDL did that already with SDL_UpdateRect(screen,0,0,0,0);
which would then flip the buffers, hmmm.
well, I am emulating it (which isn’t really ‘emulating’, it is doing)
by having two buffers in system ram and just flip flopping them (just
when i am in speed sensitive spots, some other times i simply single
buffer).
j