I’m going to advise against it.
I’ve recently been helping out/advising someone else with a game project that has a bit of overlap with this project (in terms of physics and using tile-based rendering) and something I found with the
everyXFrame trick is that it can cause problems because of the timing.
everyXFrame trick is supposed to do is to simulate decimal numbers/fractions, but instead of accumulating the fractional part of the distance you’re just delaying until you can add a whole part.
I.e. if you had a ship travelling at 4 pixels per second (1 pixel every 1/4 of a second) then your movement is going to look like this:
|Method \ Frames||1||2||…||14||15|
I’m doubtful that it will be a problem, and I’ll explain why…
The error depends on the format.
Whether it’s going to affect you or not depends on what the smallest fraction speed you’ll have to represent is.
The smallest fractional value that a floating or fixed point type can repsresent is called its ‘epsilon’.
(The epsilon is also the smallest value larger than zero that the type can represent.)
float's epsilon on the Arduboy is:
Which I think it’s safe to say is pretty tiny.
SQ7x8 have an epsilon of 0.00390625 (1 / pow(2, 8)).
It’s significantly larger than
float's (more specifically ‘orders of magnitude’ larger),
but it might not be that much of an issue.
SQ15x16 have an epsilon of 0.000015258878 (1 / pow(2, 16)).
That’s still comfortably small.
What you have to ask is what sorts of values are you going to be handling.
If you wanted to move 1 pixel per second at 60 fps then you need to move 0.01666… pixels per second.
0.01666… is still over 4 times
UQ8x8's epsilon and over 1092 times
UQ8x8, theoretically you could go as slow as 1 pixel every 4 seconds before you’d encounter problems.
I’m not sure what you’ve done so far.
That was all a bit too much for me to process.
I’ll wait until I know that your GitHub is up to date and then I’ll have a peek.
Before I sink too much time into it, I think I need to know a bit more about what you want.
What’s your intention for the background?
Are you going to have the same 64x64 block repeated infinitely?
Are you just going to have stars in the background?
Stars and planets?
How much variation do you want in the star patterns?
While thinking about it I’ve had an idea that I think you might like, but I need a bit of time to test it.
Whne I have a better idea of what your intention is and how the background is going to be drawn, I’ll start discussing the movement of the background with you.
When it comes to tile games there are two approaches:
- Move the camera and keep the world static
- Keep the camera static and move the world
I think you might be better off with a static world and a moving camera, but we’ll see.