Sdl_anyformat

Matthijs_Hollemans · October 10, 2002, 2:25am

Hi all,

When setting up the video mode for my game I want to accomplish the
following: if I can get a HWSURFACE with DOUBLEBUF, in any
bits-per-pixel mode, I’ll take it. Otherwise, I want to use a
SWSURFACE, not a HWSURFACE without DOUBLEBUF. The reason for this is
that all of my testing shows that a hardware surface without page
flipping tears like crazy, but for a software surface it isn’t even
all that bad (probably because the contents of the software surface
are blitted to the framebuffer in one go).

Is there any way I can specify this in the call to SDL_SetVideoMode?
AFAIK, SetVideoMode will first try HWSURFACE | DOUBLEBUF, and if
that fails, it will automatically try HWSURFACE, followed by
SWSURFACE. (This is independent of the SDL_ANYFORMAT flag, which I
believe only means “do not emulate the requested bits-per-pixel
mode” – it doesn’t have anything to do with the hardware/software
surface decision.)

My code currently first checks to see if the request video mode is
available with SDL_VideoModeOK. It is unclear to me if this has the
same semantics as SetVideoMode. In other words, does it
automatically fall back to a HWSURFACE if the DOUBLEBUF is not
available, and to a SWSURFACE if no HWSURFACE is available? I hope
not…

Thanks,–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

Paulo_Vinicius_Wolsk · October 10, 2002, 10:01am

that all of my testing shows that a hardware surface without
page

flipping tears like crazy, but for a software surface it isn’t even
all that bad (probably because the contents of the software
surface
are blitted to the framebuffer in one go).

As far as I have tested, this happens because when in a
hardware surface with double buffer a flip will wait for the vertical
retrace, which avoids tearing.

On the software surface it won’t happen because what causes
the bad tearing on harwdare mode is the simple fact that things
are being drawed on the screen while the video card is drawing
the image on the monitor also, so if you render someting on the
upper portion of the screen after that portion was updated during
a vertical retrace, it won’t be visible until the next vertical retrace
(I mean, if the problem doesn’t happen again).

Using a software surface helps on this problem because when
you tell SDL to update the dirty rects, it will copy them OVER the
image on on your video card. If it hapens during a vertical
retrace, there will be information from the previous frame which
helps to hide the tear. There may be tearing on this method, but
much better than if you do it straight on a single buffer hardware
surface.

Paulo

Matthijs_Hollemans · October 10, 2002, 10:26am

As far as I have tested, this happens because when in a
hardware surface with double buffer a flip will wait for the
vertical
retrace, which avoids tearing. […]

Well, thanks for the additional explanation, but I already knew that
In fact, wanting to avoid a single buffered HWSURFACE was the
reason why I asked my question in the first place (although it
appears I picked a totally inappropriate subject line Thanks for
your response anyway.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

Paulo_Vinicius_Wolsk · October 10, 2002, 2:41pm

Well, thanks for the additional explanation, but I already knew
that

Perhaps someone can get something useful from that anyway
^_-.

In fact, wanting to avoid a single buffered HWSURFACE
was the
reason why I asked my question in the first place (although it
appears I picked a totally inappropriate subject line Thanks
for
your response anyway.

Maybe (MAYBE) SDL_ListModes with the apropriate flags
AND SDL_DOUBLEBUFFER and a NULL pixel format will do the
trick. Tell us if it works later :).

Paulo

slouken · October 10, 2002, 5:08pm

Maybe (MAYBE) SDL_ListModes with the apropriate flags
AND SDL_DOUBLEBUFFER and a NULL pixel format will do the
trick. Tell us if it works later :).

I don’t think it does. I think you have to try to set a double-buffered
video mode, and if you don’t get SDL_DOUBLEBUF in the returned surface’s
flags, re-set the video mode with SDL_SWSURFACE.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Stephan_Goetter · October 11, 2002, 3:02am

Hmm, I don’t like games switching video mode at startup more than one time.
This is ugly loud and destroys the virtual reality right at the beginning.
Diablo 2 is a bad example (2 modes for intro and game here).
BG2 is a good one and has almost the best startup I’ve ever seen.
Player is never waiting in front of a black screen and intro starts with sound
right after mode switching.

StephanAm Freitag 11 Oktober 2002 02:07 schrieb Sam Lantinga:

Maybe (MAYBE) SDL_ListModes with the apropriate flags
AND SDL_DOUBLEBUFFER and a NULL pixel format will do the
trick. Tell us if it works later :).

I don’t think it does. I think you have to try to set a double-buffered
video mode, and if you don’t get SDL_DOUBLEBUF in the returned surface’s
flags, re-set the video mode with SDL_SWSURFACE.

–
if [ $[echo $FROM | wc -w<3] = 1 ]; then exit; fi

David_Olofson · October 11, 2002, 5:09am

Maybe (MAYBE) SDL_ListModes with the apropriate flags
AND SDL_DOUBLEBUFFER and a NULL pixel format will do the
trick. Tell us if it works later :).

I don’t think it does. I think you have to try to set a
double-buffered video mode, and if you don’t get SDL_DOUBLEBUF in the
returned surface’s flags, re-set the video mode with SDL_SWSURFACE.

Hmm, I don’t like games switching video mode at startup more than one
time. This is ugly loud and destroys the virtual reality right at the
beginning.

Yeah - but you can’t avoid switching once anyway, and most monitors
won’t resync faster than that you have time to switch mode several times
before the monitor’s even realized anything’s going on… (I assume it
doesn’t take several seconds to conclude that “no, we didn’t get
SDL_DOUBLEBUF”.

Anyway, if it’s really that annoying to wait another fem tens of a second
for the monitor to resync, how about doing the test only during the first
startup, and then storing it in the config? (Oh, don’t forget to deal
with fullscreen and windowed modes separately! They can be different…)

Diablo 2 is a bad example (2 modes for intro and game here).

Yeah, but that’s another thing. The game actually uses two modes; it’s
not just trying one or two during initialization. And I agree; using
several video modes in a game is a bad idea. (If you want the config
menues to work without OpenGL, that should only be a “safe mode”, that
isn’t used once OpenGL is configured and working.)

BG2 is a good one and has almost the best startup I’ve ever seen.
Player is never waiting in front of a black screen and intro starts
with sound right after mode switching.

Never waiting in front of a black screen? Are they using a fullscreen
size window on the desktop, or what?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc…------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL…|
-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture |----------------------------> http://www.linuxdj.com/maia -’
— http://olofson.net — http://www.reologica.se —On Friday 11 October 2002 11:56, Stephan Goetter wrote:

Am Freitag 11 Oktober 2002 02:07 schrieb Sam Lantinga:

Julien_Clement1 · August 7, 2008, 1:31pm

Hi,

I’ve often used the option “SDL_ANYFORMAT”, but never really investigated
what it was really for.
Can someone explain ? (answer only if you really know what’s going on … I want to avoid a big controversy :))

Thanks !

Julien_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Julien_Clement1 · August 7, 2008, 1:43pm

I’m not sure the previous email was sent correctly:

I was wondering what was the effect of “SDL_ANYFORMAT” passed to the video surface.

Is there a “good way” to make an SDL application portable, knowing that not all platforms may support some flags or some specific depths ?
Is SDL_SetVideoMode smart enough to return a video surface which is the closest to what we wanted, even if it is not as optimized as expected ?

My opinion is that what you want is a resolution of WxH, with some optimization flags, but if a platform cannot support this optimized mode, it is expected that we get WxH video surface anyway. (except if the resolution is not supported at all, in that case report the error and exit…)

Hope I make my question clear …

Many thanks

Julien_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr