🔒 Locked

Timing issues

Started by etftw Jun 11, 2009 at 8:41 AM 1 reply 850+ views

Original Post

Jun 11, 2009 at 8:41 AM

Hey, I have been working on a prototype for a couple of weeks now in XNA which is similar in style to Guitar Hero in which you have sprites moving down the screen and the user must press them once they reach their destination. The problem however is that while the sprites are reaching their destination initially on time it slowly goes out of time as time goes on, I believe this could be due to the odd frame being lost (it only sees a 1fps drop every now and again) in the process possibly as the positioning does assume that the sprites will move 60 times per second. I am currently using the fixed timestep mode at the moment to limit the FPS to 60 and from what I have read using this also trys to recover lost frames. Can anyone recommend some online reading material that may help me overcome this problem? Thanks

Adam_42

267

Adam_42

Jun 11, 2009 at 9:05 AM

What I'd suggest to fix it is instead of calculating the position of the sprites based on the frame number, calculate them from the time elapsed since starting the song. That can either be retrieved from the audio playback system, or with a standard timer.

For example, assuming horizontal scrolling, you want something like:

MySprite.x = (SpriteSpeedInPixelsPerSecond * (TimeOfSprtiteInSong - TimeSinceSongStarted)) / TimerFrequency;

etftw

Author

etftw

Jun 11, 2009 at 9:30 AM

Quote:
Original post by Adam_42
What I'd suggest to fix it is instead of calculating the position of the sprites based on the frame number, calculate them from the time elapsed since starting the song. That can either be retrieved from the audio playback system, or with a standard timer.

For example, assuming horizontal scrolling, you want something like:

MySprite.x = (SpriteSpeedInPixelsPerSecond * (TimeOfSprtiteInSong - TimeSinceSongStarted)) / TimerFrequency;

Hey,

Thanks for the reply, I am actually doing something similar to that at the moment except instead of specifying the speed in pixels per second I am specifying how much it moves every frame and then multiplying by 60 like this:

sprite.y = destination.y + ( ( speedPerFrame * 60 ) * ( timeTheSpriteShouldReachDestination - theTotalAmountOfSecondsElapsedInGame ) )

If I'm correct wouldn't using the algorithm you suggested result in the same thing?

The strange thing is when testing on the PC it works but on the 360 it seems to gradually go out of time.

I threw in a method to synchronise it every second as well so that all the sprites are where they should be just incase they have fallen behind with any loss of frames.

This really is one I just can't get my head around, I have spent days on end trying to figure it out.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.