[Game]Armageddon

2 posts were merged into an existing topic: [Troubleshooting] Battery issues

well…its only a little higher but still counts ?

3 Likes

Yeah, it counts! I added a highscore list to the first post. I probably should have done so earlier but at least I have enough scores now that I can have 5.

I noticed that you also encountered the bug with the highscore table where the loader overwrites data over Armageddon’s highscore table. I should have chosen a different EEPROM location other than starting from zero. I would have preferred the loader data to be at the end of EEPROM but that’s just a personal preference.

I probably should update the game to save at a different place in EEPROM, but nobody has complained about it so it was low priority. I’m pretty busy for the next two weeks or so, but if anybody finds it bothersome I can patch it easily after that, or they could patch it themselves! Open source!

2 Likes

We could do with a ‘save/load EEPROM to/from SD file’ program.

The reason for picking a different spot isn’t just to avoid overwriting other game’s saves, it’s also because if everyone writes to the start then the early areas of EEPROM wear out faster than the rest (depending on how good the wear levelling is).

(It would be neat if chip manufacturers took that into account and gave earlier areas a better lifespan.)

the max write cycles is something like >100k.

If you wear out EEPROM by playing Armageddon, I will bring a new Pokitto to your door! :wink:

Edit:1M cycles at 25C (source: Microchip)

1 Like

Why would you use a Microchip specification for an NXP part?

From the NXP LPC11U6x datasheet section 12.1 table 11:
EEPROM endurance: 100000 min, 1000000 typical cycles
(Tamb = -40℃ to +85℃; VDD = 2.7 V to 3.6 V. Based on JEDEC NVM qualification. Failure rate < 10 ppm)

Lazyness. I guessed they’d be similar, both being ARM Cortex-M0’s

1 Like

Laziness is a a virtue.

1 Like

Here a new Highscore (Nr… 3)

4 Likes

Fear not, for I have appeased the angry noodles.

(Ignore the weird top score, that was there when I started. Obviously two games writing to the same block of EEPROM.)

3 Likes

:open_mouth: insane

1 Like

@Rakkachi still has the highest score though - 10695.

2 Likes

Highscore table updated! Keep the scores coming. If we get enough I may expand the table to 10 slots.

I really need to fix the EEPROM issue by saving the highscores at a different place from any other game, but I really have other things I need to be working on… Maybe I can make an update this weekend.

Maybe we also need the loader to start saving and restoring EEPROM from the SD card to prevent conflicting saves from corrupting EEPROM, but that would only work when games are loaded by the loader. Data would still be corrupted if games are loaded directly from a computer. Would such an addition still be useful if flashing directly would still cause problems?

2 Likes

A better fix would be to use a checksum algorithm to verify the data.
That helps you know if another game has overwritten anything.

Then if it doesn’t match up warn the user “either the current save data is corrupted or there is no game save for this game, would you like to make a new save?” and then wipe the data if they say yes.

Not necessarily.

If we built a function into the library that could handle that so that there was a common interface for it then every game could voluntarily offer the ability to store the previous EEPROM to SD or create a backup of the game.

The difficult part is finding an arrangement that suits everyone and does what’s intended.
This also ties in with the idea of coming up with an SD arrangement that gives each game or author their own folder.

Yes, because people would be aware of the issue and chose when to backup their EEPROM.

(Also my suggestion of a function/class in the API helps to mitigate that.)

1 Like

3 posts were merged into an existing topic: Saving user data on EEPROM & SD - development discussion

Armageddon is the first game ever to use the PokittoCookie highscore / data save system

I have updated the bin, and added this to EmBitz examples. I will update the mbed version also.

Example of how the savegame works in Armageddon:

1.Add “PokittoCookie.h” to the includes

#include "PokittoCore.h"
#include "PokittoCookie.h"

2.Create your own child class of Cookie

/* This is how you do it with the PokittoCookie class !!!*/
class gdata : public Pokitto::Cookie {
    public:
    uint32_t highscores[NUM_HIGHSCORES];
    char names[NUM_HIGHSCORES][NAME_SIZE+1];
    int check_number;
    gdata() {
    }
};

3.Make an instance of your class that you will use to handle the savegame data

gdata gamedata;

4.Replace direct EEPROM reads writes with a logic that uses the Cookie instead, this is the loadHighscores that runs when the game start

void loadHighscores(){

  uint32_t defdata[] = {10000,7000,5000,4000,2000};
  char defnames[NUM_HIGHSCORES][NAME_SIZE+1] = {"Crack Shot", "Defender", "Gunner", "We Tried", "No Hope"};
  // Initialize the cookie
  gamedata.begin("ArmageDD",gamedata);

  uint32_t allscores=0;
  for (int i=0;i<NUM_HIGHSCORES;i++) allscores += gamedata.highscores[i];

  if (gamedata.check_number != 12345) {
        //checknumber indicates that no highscores saved yet, so put in "defaults"
        for (int i=0;i<NUM_HIGHSCORES;i++) gamedata.highscores[i]=defdata[i];
        for (int i=0;i<NUM_HIGHSCORES;i++) strcpy(gamedata.names[i],defnames[i]);
        gamedata.check_number = 12345; // put the checking number
        gamedata.saveCookie();//save the default values
  }
  /*
  for( uint8_t entry = 0; entry < NUM_HIGHSCORES; entry++ ){
    for( uint8_t offset = 0; offset < ENTRY_SIZE; offset++ ){
      if( offset < NAME_SIZE ){
        names[entry][offset] = EEPROM.read( ENTRY_SIZE * entry + offset );
      }else{
        uint8_t* addr = (uint8_t*) &highscores[entry];
        addr+=offset-NAME_SIZE;
        *addr = EEPROM.read( ENTRY_SIZE * entry + offset );
      }
    }
  }
  */
}

5.Handle variables inside the Cookie just like you would handle any other variables. When you are done, just call the saveCookie() function!!

void saveHighscore(uint32_t score, char* who){
  uint8_t found = 0;
  uint32_t tmp_score = 0;
  char tmp_name[10];
  for( uint8_t entry = 0; entry < NUM_HIGHSCORES; entry++ ){
    if( score > gamedata.highscores[entry] ){
      found = 1;
    }
    if( found ){
      tmp_score = gamedata.highscores[entry];
      strcpy(tmp_name,gamedata.names[entry]);

      gamedata.highscores[entry] = score;
      strcpy(gamedata.names[entry], who);

      score = tmp_score;
      strcpy(who, tmp_name);
    }
  }
  gamedata.saveCookie();
/*Writing to EEPROM directly is deprecated and not necessary
  for( uint8_t entry = 0; entry < NUM_HIGHSCORES; entry++ ){
    for( uint8_t offset = 0; offset < ENTRY_SIZE; offset++ ){
      if( offset < NAME_SIZE ){
        EEPROM.write( ENTRY_SIZE * entry + offset, names[entry][offset] );
      }else{
        uint8_t* addr = (uint8_t*) &highscores[entry];
        addr+=offset-NAME_SIZE;
        EEPROM.write( ENTRY_SIZE * entry + offset, *addr );
      }
    }
  }
  */
}
2 Likes

@wuuff Take a look at the above!

1 Like

PokittoLib updated in mbed online compiler, this can now be compiled & runs from there as well

1 Like

Awesome! I’m glad you chose Armageddon to demonstrate PokittoCookie. I never got around to addressing the issues with the previous highscore code, so this should be a good improvement.

I unfortunately have not been in the same place as my Pokitto, and I won’t be for over another month, which is part of why I haven’t been posting. I’m excited to try out this newer version on my pokitto when I get the chance though!

1 Like

Armageddon is now also playable in Simulator AND EEPROM saving works exactly like on the hardware.

Now you can see with a hex editor exactly how the PokittoCookie system works

3 Likes