[SOLVED] Testing 1.2-alpha and getting weird frameCount causing everyXFrames to stop working right

Hi all,

I’m trying, just for fun, to create a Space Invaders like game. I also wanted to try out the new faster nextFrame implementation in the 1.2-alpha version of the library and just give the next version general testing through use. :slight_smile:

However something odd happens. If you take this project and clone it perhaps you can see it too: https://bitbucket.org/AMcBain/invaderz/src In case I check in stuff after this, use the first commit: 8ab6a7cc15f772f073a269c22be63532f5807070

What happens:
The aliens eventually stop moving and any missiles also get stuck and stop moving. This is due to everyXFrames returning false for 4 and 120. However since the ship you control isn’t tied to an Xth frame, it updates all it wants. This is how I know my code to paint the screen is still being called. I also logged the time between "next frame"s and it was consistently 4-6ms.

I instrumented the core library with Serial.print calls and noticed something odd about the numbers. It could be due to having to send it back across the serial connection, but I don’t think so given the previous. This is what I get after things go wonky:

frameCount   Xth    result
717        % 120  = 117
719        % 120  = 119
721        % 120  = 1
723        % 120  = 3
725        % 120  = 5

I removed duplicate logs where it logs the same number multiple times because it’s not time to run the Xth frame yet. (120 in this case; Though shouldn’t it always increment by the time everyXFrames is called? I do use the nextFrame() frame guard.)

I get data like:

116 % 120 116
118 % 120 118
122 % 120 2

before things stop moving and going weird. It seems almost like it’s skipping numbers and only counting even numbers. (may just be the serial connection and trying to log that fast, etc.) Eventually the rare odd number get logged but nothing bad until it’s mostly odd numbers and the modulo of 120 or 4 is always false. Now I know the code only does frameCount++ (increment by one) so I find it quite hard to believe it’s skipping numbers somehow.

I also know this isn’t due to frameCount wrapping since as it is logged too, I can see what number it is. With 16 bits for it I calculated (perhaps wrongly) it would take around 18.5 minutes before it wrapped, which would cause some values fed to everyXFrames to execute early. This odd behavior also didn’t fix itself after it wrapped. I waited.

What should happen:
From the outside perspective everyXFrames should never return false if the frameCount is perfectly monotonic and continuous for any value that fits into a uint8_t (0:255).

What I’ve tried:
Well I did the obvious: switched back to 1.1 and tried it again. Aside from things rendering more slowly (as was expected) I couldn’t get it to “hang” in the same way after a few tries.

This happens regardless of whether I am logging through the serial connection or not. I noticed it first without any logging. Also yes I know that that’s now how you do missiles for Space Invaders. I’m changing that. :wink:

If you guys, or the core developers, have any thoughts I’d appreciate it!

Life is unfair sometimes. I went back after posting the above to make double check I had a frame guard and I noticed the bug right away! I had forgotten a bang. Thus my code only ran for the times in between the valid times to run the next frame. This fixes all issues I had so far with updates and everything.

This thread can be closed.

1 Like