Rayne the Rogue

I’ve modified the game to use Arduboy2 and ArduboyTones, however:

The EEPROM storage system used with this game isn’t very Arduboy friendly (although, admittedly, there currently isn’t a standard for EEPROM use).

It assumes that EEPROM is cleared to 0 but an erased area in EEPROM will be set to 0xFF. It also assumes that all games will use the same system as this one, so it can have problems if a previously loaded game used a different system.

I’ve tried to change the EEPROM system to use 0xFF as the value for an erased EEPROM byte, as well as other changes to make it more suited for the Arduboy, but pressing the B key does nothing when prompted with “PRESS B TO START”.

I don’t want to spend any more time on it, but if anyone is interested, my fork with the changes can be found here.

So there’s no way around the “press b” issue?

I’m sure there is. I personally don’t have the time or inclination to look into it any further.

1 Like

I have updated Rayne the Rogue and re-released it here
Game is available in both arduboy format and source.

2 Likes

I found a bug. After 100 lvl the game is REALLY slow. But i can’t figure out why Arduboy have problems with framerates above 226. This is your code:

 //set frame rate
  uint8_t tcave = (cave>100) ? 100 : cave;
  arduboy.setFrameRate(28+tcave*2);

The Arduboy2 library has 2 ways of setting the frame rate:

void setFrameRate(uint8_t rate); // rate in frames per second
void setFrameDuration(uint8_t duration); // frame duration in milliseconds

Using setFrameRate() the maximum rate allowed would be 255 frames per second. (The maximum value that can be stored in a uint8_t)

Using setFrameDuration() the fastest rate would be setting a duration of 1ms, which would be 1000 fps. However, the display() function takes something over 1.2ms to update the display, so you would have to set the frame duration to 2 and get 500 fps.

It looks like the above code would limit the frame rate to 228 maximum, which would be within the maximum 255 allowed by setFrameRate().

Note that the due to order of operations, the frame rate math will be evaluated as
28 + (tcave * 2)
With tcave limited to maximum 100, this gives the maximum of 228.
It’s possible the author didn’t take precedence into account and expected
(28 + tcave) * 2
With tcave at maximum 100 this would give 256, which would have been a problem.

Edit: From the following post by @PineappleComputer, I realised that this game uses the original Arduboy library, not Arduboy2. Without examining the Arduboy library’s nextFrame() code, it’s possible that there could be problems with high frame rates in this code.

1 Like

Maybe it was a problem with hex file. I downloaded latest version from Github. After i changed reference from Arduboy.h to Arduboy2.h and recompiled the code the problem has gone.