[SDL] Update the screen issue

CrazyLegs EasyTo breakdance_programming at hotmail.com
Mon May 3 10:27:48 PDT 2004


ello again, and thank you so much


>From: David Olofson <david at olofson.net>
>Reply-To: sdl at libsdl.org
>To: sdl at libsdl.org
>Subject: Re: [SDL] Update the screen issue
>Date: Mon, 3 May 2004 11:42:19 +0200
>
>On Monday 03 May 2004 10.10, CrazyLegs EasyTo wrote:
>[...]
> > >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.
>
back-buffering ,and page flipping
>
>[...]
> > >(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.
>
yea i noticed it too, thanx anyway
>
>[...]
> > >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.
>
>
the 2nd in fact is more interesting, how can i do it(my pseudo code plz), 
i've never used SDL_WaitEvent() before
> > >(Now, some people would suggest that you should also insert an
> > >SDL_Delay(<some value>) 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. :-D
i agree =D, but when you're debugging it's just the rescue.
>
>[...]
> > 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(TM).

yes it should overwrite the whole screen(it's a 3d engine)
that's weird SDL_Flip get called but it doesn't act as expected!
would you please accept my code( i removed all the 3d engine code and keept 
it resonably small)
if so plz give me your email, icq,aim or whatever

thanx in advance!
>
>//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 ---
>
>
>_______________________________________________
>SDL mailing list
>SDL at libsdl.org
>http://www.libsdl.org/mailman/listinfo/sdl

_________________________________________________________________
Dialoguez en direct et gratuitement avec vos amis sur 
http://g.msn.fr/FR1001/866 MSN Messenger !





More information about the SDL mailing list