MazeRider [PreRelease]

(Pharap) #41

Originally I was going to wait until tomorrow to try to fix this,
but I decided to have a quick shot at it and this is the result:

I decided to do a bit of drastic redecorating, but the code is now both simpler and smaller,
in terms of both source code and progmem.

Think of eeprom_read_block and eeprom_update_block as special kinds of eeprom-to-ram and ram-to-eeprom memcpys.
The memcpy_P found in <avr/pgmspace.h> ought to have been called progmem_read_block.

It would be a single entity to worry about saving (i.e. a simple EEPROM.get and EEEPROM.put) rather than having multiple arrays to save.

The only downside is that it forces you to save the entire state at once,

but that’s not a particularly big downside unless you really need to save only part of the state.
The use of ‘update’ will avoid unnecessary wear on the chip.

The system I invented for Minesweeper has both backwards and forwards compatibility as well as better protection from corruption than a simple 2-byte id.

(If I were to write a program that saved data at EEPROM_STORAGE_SPACE_START + 375 at the moment then it would mess with your game’s save data and you’d never know a thing about it.)

However it’s a lot more complicated and still has one thing I need to fix.
(The variable length array allocated on the stack is non-standard behaviour, I ought to swap it for a new/malloc.)

I could adapt my Minesweeper system if you’re interested,
but frankly it’s probably a bit overkill for your needs.


So the _block part is taking the sizeof(array) and using it to write the whole array to EEPROM?

Kind of like how I originally thought I could put the array in with put?

(Pharap) #43

Pretty much. The passed object gets interpreted as a block of bytes.
It doesn’t work with all objects though,
I believe the rule is that it only works on types that are ‘standard layout types’.

I still need to double check if put will write a whole array or not.
Either way I prefer using the avr-libc functions.
I’ve found that in some circumstances they work out smaller.
(Probably because EEPROMClass uses too much indirection.)

I did mention _block very briefly earlier:

(Simon) #44

Definitely … I recall you and I swapping them out in Mini Rogue and saving hundreds of bytes.


I’ll confirm that fixed the Issue later when I have my device on hand. After that I should be good for another release.

(Pharap) #46

I checked earlier and it seems I did determine whether get and put can do whole arrays,
but I completely forgot that I had because I was juggling multiple things again.

The answer is yes, but the real question is which is cheaper.

(That’s a question for another time though.)


I gave it a test and it looks like EEPROM functionality is now in place, thanks @Pharap.

I’ve decided to push another release now as the game is fully feature complete.
Right now there are 3 introduction levels to introduce the mechanics and 5 additional levels

I’ve decided to keep the dead ends in some levels. If you get stuck, you can enter the pause menu with A and then return to level selected by pushing A+B at the same time.

I still want to add more levels since I’ve used almost no PROGMEM but I will try and release them in packs instead of only one at a time.

Oh and if someone could show me how to play a bytebeat loop that would be cool since I don’t think im going to be able to make any other music besides that method

(Pharap) #48

The only example I can think of for bytebeat being used on the Arduboy is @filmote, @Vampirics and @uXe’s work on MiniRogue.

(From this comment.)

I developed a tune for it myself, but my tune didn’t get used because they found a tune they liked better.
If you want to use it for your game I’d be happy to donate it.