[SDL] Quick question about Marius' tutorial. Setting the video mode
Author
Hi all!
I'm following this tutorial for GFX with SDL:
http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/tut3
In that tutorial, he does the following for setting the video mode:
screen=SDL_SetVideoMode(640,480,32,SDL_SWSURFACE|SDL_FULLSCREEN|SDL_HWPALETTE);
I would like to use a hw surface instead, so I did this:
screen=SDL_SetVideoMode(800,600,32,SDL_HWSURFACE|SDL_DOUBLEBUF);
That works great. However, if I try to run it in full screen by doing
screen=SDL_SetVideoMode(800,600,32,SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN);
Everything flickers a lot.
Do you guys know how I can resolve that problem? I have tried with different parameters but I haven't had any luck.
One more thing, do I really need to add SDL_DOUBLEBUF for hw surfaces? If I don't do it, evertythings runs much faster, but it still flickers.
Thanks a lot for your help.
Typically, flickering occurs when double buffering is not done properly. When you're updating the screen directly (moving rectangles one at a time), you get this funny flicker effect. Try posting some code, maybe there's something obvious.
Also, you can call SDL_VideoModeOK to check whether the combination you're asking for is supported... but there's really no reason for 800x600x32 doublebuf/fullscreen not to be supported :).
EDIT: you can also check SDL_GetVideoInfo to see if your hardware supports various types of blits and whatnot... still, those things don't really relate to flickering, unless we define the term differently.
Also, you can call SDL_VideoModeOK to check whether the combination you're asking for is supported... but there's really no reason for 800x600x32 doublebuf/fullscreen not to be supported :).
EDIT: you can also check SDL_GetVideoInfo to see if your hardware supports various types of blits and whatnot... still, those things don't really relate to flickering, unless we define the term differently.
Author
Thanks for your answer, Replicon. I tried the functions that you mentioned and it seems that video mode is correct.
The source code has been taken from here:
Source Code
I still cannot figure out what is wrong...
The source code has been taken from here:
Source Code
I still cannot figure out what is wrong...
Ah, I'm assuming the cone3d stuff hasn't changed. I remember going through that same tutorial about 2-3 years ago or so, when I first played around with it. It worked perfectly fine for me.
Did you try downloading the source from his link and building that directly? It might work... and then you can diff the two.
Did you try downloading the source from his link and building that directly? It might work... and then you can diff the two.
Author
Yes, that source code works fine.
What I'm trying to do is to use a hw surface instead of a sw surface like he uses in that source code.
What I'm trying to do is to use a hw surface instead of a sw surface like he uses in that source code.
I'll give it a whirl when I get home. In the mean time, have a look at the comments section, the word 'flicker' shows up a lot, but they seem to be talking more about the thing not executing at all.
Author
hey, thanks for that.
I found the solution there.
However, let me ask you something. If I am using a hw surface, do I really need to add SDL_DOUBLEBUF to the video mode?. If I don´t use it, everything runs much much faster but it flickers. On the other hand, I don´t need SDL_DOUBLEBUF for sw surfaces.
I found the solution there.
However, let me ask you something. If I am using a hw surface, do I really need to add SDL_DOUBLEBUF to the video mode?. If I don´t use it, everything runs much much faster but it flickers. On the other hand, I don´t need SDL_DOUBLEBUF for sw surfaces.
Double buffering draws everything to an offscreen surface and then flips it to the visual surface all at once instead of drawing each thing on the visual screen as you call SDL_BlitSurface.
When you don't buffer your drawing you will see flicker or tearing because although it is happening quickly you still pick up the drawing order of things to the screen (especially the 2nd layer of sprites).
Conversely the "flipping" done with buffering is more like a movie of frames and eliminates the "flicker" by doing the drawing in the background and just showing you the new image all at once instead of a piece at a time.
Sorry, that sounds repetetive and all, kind of tired. I will try to revise it later.
When you don't buffer your drawing you will see flicker or tearing because although it is happening quickly you still pick up the drawing order of things to the screen (especially the 2nd layer of sprites).
Conversely the "flipping" done with buffering is more like a movie of frames and eliminates the "flicker" by doing the drawing in the background and just showing you the new image all at once instead of a piece at a time.
Sorry, that sounds repetetive and all, kind of tired. I will try to revise it later.
And if you're NOT double buffering, then to get rid of the flicker, you'd have to draw everything to anb off-screen, screen-size surface, and blit the whole thing to the screen... which is basically double buffering, but with an extra screen blit :-).
The only disadvantage of double buffering is that if you're updating the off-screen buffer by means of "dirty rectangle updates", you will have to keep track of dirty rectangles/backgrounds for 2 frames back instead of just one (since you update a given buffer once every other frame).
The only disadvantage of double buffering is that if you're updating the off-screen buffer by means of "dirty rectangle updates", you will have to keep track of dirty rectangles/backgrounds for 2 frames back instead of just one (since you update a given buffer once every other frame).
Author
Thanks for the information guys.
I think I understand double-buffering much better now.
Regards
I think I understand double-buffering much better now.
Regards
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
