Super Mario Bros. X Forums

Supposedly SMBX runs at 65 frames per second, at least according to the FPS counter. However, I'm trying to sync the timing of events in a particular section of my level to music, and noticed that 65 ticks per second isn't really that accurate.

Using this code: I get about 64.1 ticks per second, not 65. I'd like to know what other people get on other systems.

...But that doesn't matter too much to most people. What really matters (at least when you're not using LunaLua) is the timing on moving layers.

I measured the number of ticks between a pair of events triggering each other on a given delay, causing a block to move up and down. As expected, at speed 1 the block moved the same distance as the number of ticks (speed being measured in pixels per tick, where a block length = 32 pixels). The number of ticks, however, turned out strange:
No wonder it's so hard to prevent cycling layers from getting farther and farther off if you don't use the same speed and delay both ways. A 2 second delay isn't even the same as two 1-second delays!

Natsu said in this thread that, effectively, the distance moved is speed*time*65. This is pretty close, but you can't have a fraction of a tick. The number of ticks for a given number of seconds appears to be:

(seconds*65)+1, rounded to the nearest ODD number if it ends in .5

Normally .5 is rounded to the nearest even number, but presumably it's rounded before the 1 is added, resulting in it rounding towards odd numbers instead.

In that case the distance moved is:

speed*((seconds*65)+1, rounded to the nearest ODD number if it ends in .5)

The extra 1 is what tends to throw off the timing of layers. For example, a speed of -1 for 2 seconds and a speed of 2 for 1 second moves the layer -131 and then +132, causing it to go further off by 1 each cycle.

However, moving it by -1 for 1 second and +2 for 0.5 seconds does work because the number of ticks for 1 second is twice the number for 0.5 seconds. Another solution is to split up the first delay, so you have the layer moving -1 for 1 second, then -1 for 1 second again, then +2 for 1 second.

It's all in how the ticks add up. I hope this is helpful!

SMBX frames per second are about 64.14. I have noticed that the calculation is off after a while, too. What I usually do is just test out numbers until I get something that works.

I actually figured out that Natsu's formula didn't quite work for looping movements shortly before you made this thread, but never got around to posting about it. While the chart has been helpful for me, I have a complaint about this:

Quantumenace wrote:The number of ticks for a given number of seconds appears to be:

(seconds/65)+1, with a .5 rounded to the nearest ODD number

I can't figure out how you expect people to be able to use that formula. You give an example, but never properly walk people through how to use it. For example, let's use a 1 second delay, like you did in the example. 1/65= ~0.015. Then the formula says to add 1 to it, giving us 1.015. Then there's that last part: a .5 rounded to the nearest odd number. I assume you mean to add this to the number we already have, which would give us 1.515. However, the nearest odd number to that would be 1, an entire 65 ticks too low. Either you left out a step or didn't explain your formula well. I'd appreciate if you would clarify this.

*facepalm* I meant to say you need to multiply the seconds by 65, not divide. I edited the post to fix it. Sorry about that.

So, multiply the number of seconds by 65, add 1, and round to the nearest odd number if the result ends in a .5.

Ah, that makes way more sense! Thanks for the clarification; this will be really helpful for me.

The exact FPS of SMBX is 1/0.0156 = 64.1025 641025 641025...