In a game I was making, I wanted to calculate the movement of a character several times per frame in order to have extremely accurate platforming. I discovered that something around 5 times per frame could work nicely on the original model 3DS, but something bothered me. Firstly, the new 3DS would be capable of more calculations per frame, and my game would be overclocked to a point of unplayability. Secondly, I wasn't sure if it were possible to count tiny increments of time without using a FOR loop, which would also be overclocked. I've tried using MAINCNT, but it seems to count how many frames have passed.
So, I was wondering if there is any way to count fractions of a frame in order to equally space high speed calculations. Let me emphasize that I want equally spaced calculations. I don't want 5 calculations, and then an unspecified wait time where the user waits for the next frame to input.
I need something that is universal on all systems, or else cross platform compatibility will be based on guesstimations of the system's processing power.
If I have to settle for calculating gravity each frame, it wouldn't be the end of the world, but I love being anal about this sort of thing.
Don't.
In any game, one round of calculations per frame is more than enough. Unless, perhaps, your target audience includes nonhumans.
Such a dogged pursuit of imperceptible, ineffectual 'accuracy' is more likely to harm your game than benefit it.
The focus isn't hyper fast controls, it's hyper accurate collision detection while maintaining controls that function the same as a normal speed game.
Here's a pseudocode representation of what I imagine:
@Start
calculate gravity
recieve input from user
change the character's coordinates based on gravity and user input
LOTS AND LOTS OF FLOATING PLATFORM COLLISION DETECTION
if maincount indicates a frame has passed
Render changes that have occurred
end if
wait a fraction of a frame (whatever is deemed possible)
goto @Start
My goal is to be able to detect platform collision with pixel-perfect accuracy while maintaining a fun game speed (not too slow) I decided multiple calculations per frame would be a solution to this. Unfortunately, I don't know if such time accurate calculations are possible in SmilebASIC, and I also wanted to make it so that the controls functioned at the same speed as the rest of the game.
But we're talking about 1/300th of a second here... So you may have a point.
If I were to put the control aspects in the maincount if statement, thus sacrificing perfect controls in exchange for still great controls, I wouldn't have to worry about equally spacing the 5 or so calculations...
However, I would still like to know if there is a way to do what I planned. Perhaps for a future project, or maybe for my current one.
Input and output is granular on the level of frames. In 1/60th of a second, it makes no difference if you schedule (1/1200th second calculating then 1/1200th second waiting) ten times, or (1/1200th second calculating) ten times then 1/120th second waiting. There will be absolutely no difference to the user experience.
But.... every game you've ever played has probably run at a maximum of 60fps (every single console platformer is capped at 60fps and nearly all PC platformers will cap themselves at the same speed). You can't tell me that these games aren't good because they aren't running at 300fps. Just use VSYNC to cap it to 60fps and calculate collision once per frame, that way you don't have to worry about things like the New 3DS.
It doesn't make much sense to do this. The state of your game stays consistent between user inputs, and as SquareFingers said, input only happens at 60 fps. You know how everything is going to move, just use trig.
That said, SmileBasic 3.3 will be introducing MILLI to get the current millisecond time. This will do what you expect MAINCNT to do.
You might be able to pull this off if you carefully structure your vsyncs and run at a lower fps like 30.
The only way the new 3DS makes a difference is if you set the system variable "hardware" to 1. Don't even trip bro.
to jump on the repeating information bandwagon, but hopefully single out the only truly important factor: user input is only polled once per frame, so it won't give any extra accuracy to your players. If you're thinking about mid-frame collision, then SPHIT already does this if you use SPCOLVEC correctly.
