gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Timers - which ones are safe to use? [SOLVED]

#150989 - Ultima2876 - Sat Feb 16, 2008 1:44 pm

I'm trying to implement a time-based movement system in my game engine, and this would mean using a timer as far as I know. My problem is, I also want to use dsWifi and Noda's advanced sound system. I've heard talk in the topic for the advanced sound system that it uses 2 timers and that dsWifi uses the others. Are there any timers safe to use in this situation?

Last edited by Ultima2876 on Mon Feb 18, 2008 12:30 pm; edited 1 time in total

#150990 - tepples - Sat Feb 16, 2008 2:41 pm

Ultima2876 wrote:
I'm trying to implement a time-based movement system in my game engine

Does the DS's built-in movement timer (Vblank, which ticks at close to 60 times per second) not work for you?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#151036 - Ultima2876 - Sun Feb 17, 2008 4:19 pm

I was hoping for more like 1024 or 1000 ticks per second. That way if I start getting slowdown I can still have my sprites moving the same distance in the same amount of time as if the game was running full speed, it would just look "frame skipped".

Or do you think this would work using the vblank interrupt to increment my timer?

#151040 - tepples - Sun Feb 17, 2008 5:19 pm

Ultima2876 wrote:
Or do you think this would work using the vblank interrupt to increment my timer?

Soytainly. LOCKJAW does something similar: if the front-end detects that it is falling behind the number of vertical blanks since the irq handler was installed, it runs the game engine multiple times and only runs the graphics afterward.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#151050 - Dwedit - Sun Feb 17, 2008 7:08 pm

Ultima2876 wrote:
I was hoping for more like 1024 or 1000 ticks per second. That way if I start getting slowdown I can still have my sprites moving the same distance in the same amount of time as if the game was running full speed, it would just look "frame skipped".

Or do you think this would work using the vblank interrupt to increment my timer?


If you have game logic run 1000 times per second, you'll be causing slowdown instead of mitigating it.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#151062 - M3d10n - Mon Feb 18, 2008 12:09 am

If you're using v-sync you'll always miss 1 frame if you take more than 16 ms in your loop, dropping to 30fps, and miss 2 frames if you take more than 32ms (dropping to 20fps). You'd only need multiply your movement speed by 2 or 3, respectively (or 4, if your framerate drops to 15fps by missing 3 frames).

So the vblank could work well for you. You only need a little extra math involved if you want your speeds defined as units/second.

#151075 - Ultima2876 - Mon Feb 18, 2008 12:30 pm

Dwedit:

Of course, but I meant increasing a timer, and using the time since last update to move my sprites (similar to how it's done in most PC games).

M3d10n:

Thanks for the suggestion; I see what you mean, but I already went ahead and implemented a timers class. What it does is uses Timer2 as a master timer, then implements software timers layed over it so I can have as many timers as I like. I've got a timer counting at 1000 ticks per second now, so I'm using that for movement and FPS calculation.

Thanks guys, consider this solved :P

#151096 - tepples - Mon Feb 18, 2008 10:44 pm

Ultima2876 wrote:
Of course, but I meant increasing a timer, and using the time since last update to move my sprites (similar to how it's done in most PC games).

Caution: If you have distance moved depend on the time since last update, that tends to decrease the stability of the physics. For example, a bullet might go past a wall or a character without colliding.

Example from an actual product: One of the Quake games allows slightly higher jumps at certain frame rates than at others because the frame rate changes the shape of the arc.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#151118 - nipil - Tue Feb 19, 2008 11:33 am

tepples wrote:
Example from an actual product: One of the Quake games allows slightly higher jumps at certain frame rates than at others because the frame rate changes the shape of the arc.

More info about this here and the "interesting" quote itself :
Quote:
Matching our conditions with the table, we predict that the best frame rates would be about 29, 41, 83, 92, 120, 140, and 170. Notice that these numbers are very near the values that people have found experimentally. This match between theory and experience lends credence to the model used.

_________________
NDS Lite Gold/Silver, MK5/R4DS, MSI PC54G2, D-Link DI-624