Sprites in my game are Shaking and Sprite Animation is Chopp |
Re: Sprites in my game are Shaking and Sprite Animation is C |
stevo5800
|
Might want to read this for some proper timing http://hdrlab.org.nz/articles/amiga-os-articles/minigl-templates/frame-rate-independent-animation-using-sdl-and-opengl-with-frame-rate-limiting/ I found this timing to be pretty good. You should show us the rest of the code or at least show how you are updating the players position, or any other animation you have. Just curious to know what platform you are working on also?
|
|||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
Jonny D
|
You should probably use SDL_Delay() in there to give time back to the system instead of burning it all in a while loop. It might not fix your jitter issue, but it's worth doing anyhow.
Jonny D On Sat, Sep 8, 2012 at 3:38 AM, axt32 wrote:
|
|||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
Jonny D
|
Also, there's a lot missing from your example code. One thing in particular is the integration of your simulation (i.e. what happens each time step to move your sprites). I can't tell if you're doing that right or if you're even using the right data types for position data (use floating points, not integers to hold x and y).
Jonny D |
|||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
Andreas Schiffler
Guest
|
Try the SDL_gfx framerate manager which is designed to attempt to maintain a constant framerate.
http://www.ferzkopp.net/Software/SDL_gfx-2.0/Docs/html/_s_d_l__framerate_8h.html #include "SDL/SDL_framerate.h" FPSmanager fpsm; Uint32 rate = 30; SDL_initFramerate(&fpsm); SDL_setFramerate(&fpsm,rate); while (drawing) { ... /* Delay to fix rate */ Uint32 time_passed = SDL_framerateDelay(&fpsm); if (time_passed > 0) { printf("Desired rate %i / Delay was %i ms / Actual framerate %i Hz ...", rate, time_passed, 1000 / time_passed); } } On 9/8/2012 12:38 AM, axt32 wrote:
|
|||||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
David Olofson
Guest
|
On Saturday 08 September 2012, at 09.38.35, axt32 wrote:
Short answer: Don't do that! It's a last resort "solution" that you use to save power on battery powered devices and the like. What you should preferably do is synchronize rendering to the display refresh rate, which is typically - but not always - 60 Hz. You do this by enabling retrace (or vblank) synchronization. In SDL 1.2, IIRC, a double buffered hardware surfare will enable this, if available. The actual synchronization happens in SDL_Flip(). You should probably still use a framerate regulator, but only as a cap, so you don't get hundreds or thousands of fps when retrace sync isn't working, as that (apart from wasting power) can cause all sorts of other issues. Note that you can't (reliably) chose a suitable display refresh rate on most platforms, so you have to adapt your code to deal with varying delta times, or run the game logic at a fixed "virtual" frame rate and then interpolate (or extrapolate) graphical coordinates as needed.
Yes, sort of. Unless you actually synchronize with the display refresh, you'll sometimes move an object right before it's draw on the screen - and sometimes right after it was already drawn, in which case what you'll actually see is the last frame repeated. [...]
This will potentially cause another problem: When your main loop is constantly burning CPU cycles, never sleeping or blocking on anything, the operating system (pretty much regardless of which on it is) will respond by lowering your dynamic priority - and as a result, you're going to lose the CPU, sometimes for extended periods of time, to just about any random background task that wants it. You probably want to put an SDL_Delay(10) in that loop. A smaller value would be preferable, but that might not work on some platforms. The scheduling granularity of older Linux systems and some other platforms is 10 ms, so if you go below that, you're effectively still busy-waiting, burning CPU cycles. One option is to use sched_yield() (Un*x) or Sleep(0) (Windows; SDL_Delay(0) also works on Win32 in the SDL versions I've checked), which essentially just calls the OS, saying "Hey, now would be a good time to grab the CPU for a moment if you have work queued!" It's not particularly nice (still burns CPU cycles doing nothing useful), but it tends to work if you're not certain that you can sleep with ms granularity... -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '---------------------------------------------------------------------' _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
Mason Wheeler
Guest
|
Yes, this is important. Any worthwhile game will have a "game timer" available that
works something like this: Declare a timestamp variable that gets updated at the start of each frame. Each frame, check the timestamp and see how many milliseconds have passed, then update the timestamp. Calculate movement distances based on how many ms it's been since the last frame, and update all screen objects. Render. Note that on-screen movement is tied *to the elapsed time* and NOT TO THE FRAME RATE. This means that your frame rate can go up or down and things will still move at a consistent speed. From: David Olofson Subject: Re: [SDL] Sprites in my game are Shaking and Sprite Animation is Choppy! Note that you can't (reliably) chose a suitable display refresh rate on most platforms, so you have to adapt your code to deal with varying delta times, or run the game logic at a fixed "virtual" frame rate and then interpolate (or extrapolate) graphical coordinates as needed. |
|||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
gormlai
|
The problem could be that your game is just switching between 2 frame rates, like say jumping between 30 and 60 fps. This can give a sense of choppiness, as an unstable frame rate can look worse than a consistent frame rate ( depending on implementation, a constant 30 fps can look better than one switching between 30 and 60 fps).
I would use a solution like the following, where you use a fixed rate: const double desiredMillisecondsPrFrame = 1000.0 / 60.0; double accumulatedTime = 0.0; void gameloop(double deltaTimeSinceLastFrame) { accumulatedTime += deltaTimeSinceLastFrame; while( accumulatedTime >= desiredMillisecondsPrFrame ) { accumulatedTime -= desiredMillisecondsPrFrame; DoTheActualUpdateOfGameLogic( desiredMillisecondsPrFrame ); } } On Saturday, September 8, 2012 at 11:46 PM, Mason Wheeler wrote:
|
|||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
MrOzBarry
|
Yeah, Listen to Mason on this one, just be sure to make sure you compensate for game pause-states.
On Sun, Sep 9, 2012 at 2:06 PM, Gorm Lai wrote:
|
|||||||||||||||
|
Sprites in my game are Shaking and Sprite Animation is Chopp |
Ian Norton
Guest
|
I seem to remember that there is a frame rate manager in SDL_gfx. You should use that rather than rolling your own. Remember, not just rendering needs this, your position calculation needs to be smooth over time too,
Ian On 9 Sep 2012 21:30, "Alex Barry" wrote:
|
|||||||||||||||||
|