SDL slowdown?

Started by
7 comments, last by taby 18 years ago
I have been programming for about 10 years, but mostly school projects and data processing, and have only just tried my hand at anything like sdl. With that being said, i have written a pong game, to see if i had gotten the hang of everything. So far, it works well, but, the drawing is kinda jittery, and i was wondering if there is a way that i can smooth it out at all. The code is kinda of long, so i won't post it all unless its requested. John
Advertisement
Use double buffering (look at the SDL_SetVideoMode flags), avoid use of alpha in sprites (try colorkeys and couple it with the RLE accel flag when blitting). Also try to delete only the prior frame's sprite rectangles when refreshing, instead of blanking the whole screen surface.

Guess there are more ways to optimize your game, but those are the more general ones I can remember.
here, check it out
http://flashingchicken.is-a-geek.org/wiki/index.php/Pong
Use either float or double types for position and velocity data. Only convert to integers when you are about to draw the object.BTW- your links to pong-draw.cpp and pong-main.cpp seem to point to the same file.
0xa0000000
oops, fixed that
but, i would think that with the precision that each pixel offers (whole numbers), using decimals for position woudnt really matter
when i say jitter, i mean, on the order of 20 or so pixels at a time, when the fastest thing should be moving no more than 5
Are you using time based movement in your update loop? What I mean is, do you just do

position += 10;

or

position += 10*someTimeDelta;


If you are using the former, that may well be your problem. As your PC will update your main loop at a different speed each frame, in some cases you may be calling Update 300 times a second, and then only 100 frames per second.

This would give you a jittery motion.

If you need more information, this thread has a lot of information, and the lists the pro's and con's of different methods.

But the idea of the method is as follows:
* Calculate how long it took you to update the last frame - this is your frame delta
* Multiply all speed dependant code by the frame delta
* Movement will now be smoothed out of the course of multiple frames.

Its not perfect, and still gets effected by big changes in the frame rate.

Hope this helps
Spree
Converting to reals would just be a first step. Jittering is usually caused by differences in time between updates. You can use interpolation to smooth out these differences which is easier using real numbers. Sub-pixel 2D rendering is also simple to implement using floats. As SpreeTree mention, to make your game frame-rate independent, a delta multiplier is needed. This value is often a real number. So to keep the values precision , it's a good practice to use reals all the way through. [position = position + (velocity * deltaTimeMultiplier)]

The use of real numbers isn't an absolute necessity(see fixed-point numbers), but benefits are essentially free given the resources of todays computers.

I'am sure these forums have a lot of topics on these subjects.
Good Luck.
0xa0000000
So, if i did something like xpos=xpos + xspeed * delta_t/16.7 [assuming 60 frames/s to be 1], that should make it move more consistenly?
A great resource for implementing a fixed-step timer is "Fix Your Time-Step!" by Gaffer.

This topic is closed to new replies.

Advertisement