[SDL] Perfomance problem with SDL+OpenGL

[Jonathan Dearborn]

Hey, I don't know if this helps, but you can try running the program without calling SDL_Flip() (or whatever screen update function you're using, whether for SDL or OpenGL) and check the fps and compare this to the fps without the stuff you put in (drawing routine?) and without SDL_Flip().  This will avoid SDL_Flip()'s vsync at least.  You won't be able to see what's happening, of course, so output the fps to a text file.


Date: Mon, 4 Dec 2006 13:46:54 +0100From: thephantomlord at gmail.comTo: cal at splitreflection.com; sdl at libsdl.orgSubject: Re: [SDL] Perfomance problem with SDL+OpenGL
Thx for all guys, I'd just though that more frame rate (more than vertical refresh) would be better! :rolleyes:
 
So, theres no trouble with getting that fps...
 
C Ya! 
Sun, 3 Dec 2006 16:12:7, cal at splitreflection.com <cal at splitreflection.com>: 
"Simon Roby" <simon.roby at gmail.com> wrote:> This is not a performance problem! Vertical retrace syncing (aka. > vsync) prevents your program from updating the screen more often than > it isrefreshed on your display.---I've seen claims that pushing frame rate to hundreds of frames/second makes a game more responsive.  For a simplistic algorithm this can be the case.  But if the input processing properly accounts for the possability for a 'button' being pressed and released during a frame, 20-30 frames/second can be suprisingly responsive.  I agree that there's no point in a frame rate faster than vertical refresh. _______________________________________________SDL mailing listSDL at libsdl.orghttp://www.libsdl.org/mailman/listinfo/sdl -- Phantom LordCaelis Studios ---> From Gods Hands To Yours 
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today!
http://get.live.com/toolbar/overview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20061204/a4c45442/attachment.htm>