Sdl Program Slow?


reiboul

Peace sells... but who's buying?
Joined
Jul 16, 2006
Messages
587
Age
36
Location
France
Website
Visit site
Hello!

I am learning C++ fos some time now, and have a problem with speed :(

No matter what FPS I set, the program is to slow! Even if a deactivate the FPS limiter, the game is still slow!
Without FPS limitation, I have the same speed @50Mhz than 250Mhz :ph34r:

I have no problem on PC : if I turn the frame limiter off, it takes less than a microsecond to complete the game loop!

So does anybody know what is slowing it on the GP2X??

*edit* Mhhh... I remember someone telling about the LCD adjustment affecting the LCD refresh rate, so I just slided the bar from the extreme right to the left, and now the program runs OK!

Why the f*** did they implement such a laamme feature??? It is supposed to help with scanlines, not to slow down games! and the FPS counter still indicated more than 1000fps, with the game being slow as a snail!
 
the slider adjusts the refresh rate, so if you use a high devider(bar right, low refresh rate) you get low fps if you use vsync.
And i dont see why you would turn it totaly tot he right anyway, most people i know have it on the far left to avoid it...
Do you have a mk2?
 
the slider adjusts the refresh rate, so if you use a high devider(bar right, low refresh rate) you get low fps if you use vsync.
And i dont see why you would turn it totaly tot he right anyway, most people i know have it on the far left to avoid it...
Do you have a mk2?


I have mk2 & FW2.1.2
How do you disable vsync in SDL, so that my game no longer waits for the screen to refresh? That's quite annoying, since the release I did must be to fast for normal human players :)




(bonus question : can anybody tell me how I should pass many parameters to a thread, using SDL_threads? B) )
 
Last edited by a moderator:
hm, as long as you dont intentionaly call vsync it shouldn't be there, but i could be wrong sdl does lot of stuff for you.
At an mk2 the slider does have next to no effect, you should always have it on the far left position.
 
hm, as long as you dont intentionaly call vsync it shouldn't be there, but i could be wrong sdl does lot of stuff for you.
At an mk2 the slider does have next to no effect, you should always have it on the far left position.

My experience shows exactly the opposite :) on my MK2, the slide bar make the game from too slow to wayto fast!
 
Last edited by a moderator:
When you call SDL_SetVideoMode, make sure you aren't using SDL_DOUBLEBUF, and it won't wait for vsync.
 
The bar doesnt make adifference on _how it looks_ on mk2, of course it still changes the refresh rate.
However at default its fairly to the left, so nothing bad using vsync as long as the user doesnt mess it up :)
 
(bonus question : can anybody tell me how I should pass many parameters to a thread, using SDL_threads? B) )

These routines usually accept a "void" pointer that you can set up to be a pointer to a structure that contains the data you want.

In the code that starts the thread you can allocate the data to hold things on the heap (if you do it statically the structure needs to be global or static in this code so a return from the function does not deallocate the memory) then in you thread code cast the void pointer to a pointer of your structure type and get your values. You can then deallocate the data if you want or just have the process cleanup deallocate it.

If you start and exit this thread a lot during your code then the cleanup when you have your data is recommended. If the thread runs as long as your other code does it is not as critical but if you don't clean it up there is data on the heap that might just be taking up space. You local variables come from the stack and the new/malloc/calloc stuff comes from the heap. Since we are running on a memory constrained system I would free it as soon as I was done with it.
 
Last edited by a moderator:
When you call SDL_SetVideoMode, make sure you aren't using SDL_DOUBLEBUF, and it won't wait for vsync.

Too bad i'm setting DOUBLEBUF, I should either switch to single buf or explicitely advise to set the LCD bar on the left

For the thread problem, I created a class (but I should use a struct) containing all game data, but I thought this was a poor solution. On the other hand, it's working and it means much of a revolution in my code, since objects moves is no longer handled in the main loop (depending on the framerate) but in the thread using a timer!

It's always cool and productive to talk with skilled programmers :) (i mean, more skilled than me!)
 
Last edited by a moderator:
A high refresh rate is also good for your eyes, because a low refresh rate (slider on the right) produces a lot of flickering.

Also, if you don't set SDL_DOUBLEBUF and use HW surfaces, the screen will flicker a lot regardless of refresh rate...

- Alex
 
Been testing some simple SDL stuff on my PC vs GP2X.

Framerate on PC 1000+ FPS

GP2X 62 FPS

If you are using SDL_Flip() it is waiting for vsync.

However if you are getting a framerate WAY lower than this it is something else.
 
Been testing some simple SDL stuff on my PC vs GP2X.

Framerate on PC 1000+ FPS

GP2X 62 FPS

If you are using SDL_Flip() it is waiting for vsync.

However if you are getting a framerate WAY lower than this it is something else.

I measured the time for SDL_Flip on my PC, it is between 2,5 and 3,5ms, is there a way to gain speed there? because basic functions take about 1000 times less processing speed :( but 60 FPS should be enough for me ;)
 
Last edited by a moderator:
you have to use the functions to convert the surface to the same format as the display buffer.
 
Back
Top