[…]
Then, how do you know that it’s working fine? 
well everything is drawing well, but the screen doesn’t update,
(the content of the previous frames remains there)
Ah… I see. Unless you completely cover the screen with new graphics
every frame, you have to clear the screen one way or another.
SDL_Flip() either copies your shadow buffer to the display surface,
or swaps the visible page with the one you just rendered into. These
cases are different, but they have one thing in common: Old stuff is
left around until you draw over it.
[…]
(Suggestion: I’d make this “while(SDL_PollEvent(&event)”. Saves
one level of indentation by avoiding the “else” case, and more
importantly; you know that the outer loop essentially runs once
per frame, and nothing else.)
hmm, can you please gimme a simple exemple?! use my pseudo code if
it’s possible.
while(!Quit) {
while(SDL_PollEvent(&event)) {
if ( event.key.keysym.sym == SDLK_ESCAPE ) {
Quit = true;
}
switch(event.type) {
case SDL_QUIT:
Quit = true;
break;
default:
break;
}
}
if(SDL_GetAppState() & SDL_APPACTIVE){
// draw everything
this->draw();
/* ..And calculate the fps */
calcFrameRate();
/* now flip the back buffer to the front.. */
int er = SDL_Flip(_MainScreen);
}
}
Just noticed another thing: The if(event.key.keysym…) statement may
react at random on various events, since the event.key part is
invalid unless the event really is a keyboard event. Always check the
event before touching any other part of the event union.
[…]
To avoid hogging the CPU (100% load) when the app isn’t active,
add something like:
else
SDL_Delay(100);
here, or (better) do something that turns that SDL_PollEvent() at
the top into as SDL_WaitEvent(), so you don’t have to spin around
that loop at insane speed just to read events.
Can you ellaborate(simple exemple would be appreciated)?!
What happens in your version is that if the application isn’t active,
it’ll spin through the main loop, polling events as fast as the CPU
allows. That is, while your application is in the background, not
really doing anything, it consumes all CPU power it can get by,
potentially making the whole system slow and unresponsive for no
reason.
On a multiuser OS, or on a battery powered machine, this is obviously
considered a criminal offense. 
So, either
* just go to sleep for a moment (SDL_Delay(100) -
one tenth of a second), to nicely hand over the
CPU to the OS and any processes that might actually
have real work to do,
or
* if possible (that is, if you're just waiting for SDL
events, as in this case), do it the proper way and
use SDL_WaitEvent(). As opposed to SDL_PollEvent(),
SDL_WaitEvent() will block until something actually
happens. So, if your app is inactive and there's no
even for it in say, ten seconds, it won't use a
single CPU cycle during those ten seconds.
(Now, some people would suggest that you should also insert an
SDL_Delay() after SDL_Flip(). I say “yes, but make it
a user option”. It will effectively restrict your frame rate to
100 Hz on most operating systems, which will, in some cases,
result in less smooth animation than you may get otherwise.)
well i can lock the frame rate to some value and stick out!
Actually, no you can’t, really. You can make the engine render at any
frame rate you like as long as it doesn’t try to display anything.
However, SDL_Flip() (on a proper target with retrace sync) will lock
the frame rate to the monitor refresh rate.
Also, since SDL_Delay() and the SDL timers generally have a
granularity of 10 ms, you can’t use those to accurately control the
frame rate on targets without retrace sync. As long as you want a
frame rate below 100 Hz, you can “throttle” the game using a mix of
SDL_Delay() calls and busy-waiting on SDL_GetTicks().
but i’m using SDL to write(port) a 3D software engine.
That’s not really relevant, provided the game is designed to deal with
whatever frame rate it gets. (Old 2D games are generally not
designed to deal with that, so you get some extra work if you want to
port one of those.)
[…]
i tried to isolate the problem, and i can tell you the the code
from directdraw doesn’t cause the problem since it’s just some
maths classes.
Oh, you really wish coding was that simple, don’t you? ;-D
Don’t you, huh?!
Naah… That would be pretty boring in the long run. 
[…]
i removed all the code from the draw method
i just print a pixel with a random postion and color,
and the problem still there : the screen is filled with dots from
the previous frames instead of only one dot.
Yes, as expected… (See above.)
Is the game supposed to overwrite the whole screen? (I’d guess so, if
it’s a 3D engine…) If so, I’d guess some part of the graphics went
missing in action. If you really repaint the whole screen every
frame, you can’t go wrong; SDL_Flip() should Just Work™.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 03 May 2004 10.10, CrazyLegs EasyTo wrote: