Could you zip up the flash image you downloaded and post here? I’m curious if there is a download error or something else
@angelbolanose can you try again. I have recompiled the Hex.
@Mr.Blinky it was the image itself as I had the same issue.
Thank you my friend, it worked like a charm! Game work flawless again (:
Im sorry my friend, but I don’t know why the game again stop working…with exactly the same problem… after a couple of games, It appears to be blank again and it just stays the background alone… could it be on my end? I already re-install the cardbuilder but sadly no luck I don’t know if I may be the only one that have this problem.
The way I noticed that it wasn’t working again even before starting the game is because on the main menu the little checkmark to choose the “1P Survival” is not there anymore.
And again I apologize for all this hassle again man, but is just I’ve been really digging this game a lot. Is the best for all my 5-10 mins. breaks around the day.
Will do it… this is the last flash image I downloaded, game wasnt working before, and after it still didn’t work.
flashcart-image.zip (2.6 MB)
Good to hear. Let me look at it again - must be a little bug no one has picked up before.
Why don’t you give OBS a go while I am fixing this!
I had a look at the game in your image and it is identical to the one on the cartbuilder site and the github repo. So it’s the game.
I already been playing it lol, very challenging but still pretty good as well !!
I assume it is the game but I am unsure what is happening.
My best guess is that it is something in my code corrupting the values in the EEPROM. As your score goes over 80 and then 160, it unlocks the next levels (and sets a value in the EEPROM to indicate this). But what I can see in the video is the highscore has been reset to 0.
To help me narrow it down, are you always playing 1 player survival mode?
Also are you playing landscape or portrait mode - you video shows landscape?
I wanna send you a longer video to show you more but it only lets me send 7.0 mb…
but let me tell you exactly how it goes. I play mostly in vertical, couple of minutes… I don’t think I’ve gone over 80 yet, but then after a couple of games, later I play horizontal mode… the high score keeps recorded. Then, suddenly later in the day when I come back, the checkmark for play “1P survival” is gone (is the only mode I play), then if I click up and down arrows, or left and right, I get some random high scores, like “0025”, “4300”, “5852” , probably my older scores… and once I click to start the game, it just starts, but no spaceship either mine or enemy, just the background, and if I click “B” it takes me back to the menu. Pretty much hehe
OK … that helps a little.
Is it possible you played anything else between the two sessions?
And another question … has it ever failed when you complete one game and immediately try to start another?
yes. I did played other games between the two sessions, and, it has never failed when I complete a game, both times that has failed is been that i turn the device off, then maybe play a couple of other games, and then go back to this game is when I get that error
I managed to reduce the video file. Here it is
OK … so you have discovered an ongoing issue with the Arduboy. I am not sure how much you know about the device but there is some ‘permanent’ memory (called EEPROM) which is used to store high scores and other settings between games.
When you play 1nvader I use certain memory locations to store the rotate and previous game chosen. When you played some other game, it might use the some of the same memory locations. You come back to 1nvader and it tries to read the levels and so forth but instead reads garbage. I have some basic checking in my code to see if the memory locations have been corrupted but it can only go so far.
I have changed the code to look for the mode and rotation and make sure they are valid. If not it resets the EEPROM memory so you can play again. Unfortunately this will clear your high scores. Please create another cart and try again - sorry for the inconvenience.
It is a real problem with games overwriting each others EEPROM memory. Luckily a lot of games have no clashes or do not use this memory.
BTW what other games have you played in between. I am curious to see how they are handling the memory.
@pharap had a method for adding a checksum to the EEPROM routines - I might have to look at this in future. The FX makes EEPROM issues so much more likely as players swap games rapidly.
Sounds like other games you play corrupt this games data.
@filmote I noticed you can still kill the invader when it’s pushing you of the screen. Is this intended?
When I shoot the invader when it has almost pushed me off screen the player is pushed offscreen but you can continue playing. moving right will get me back on screen
Great minds think alike!
No … that doesn’t make much sense does it. I might have to change this.
thank you very much for all this hard work. I really appreciate you guys what you do for this community. I do have very little knowledge, but I do understand what you said. Game works again, ill do some testing but it seems to be working good.
The games I played between are Sirene, Hollow Seeker, Hooper and Space Cab.
Yes, I did that as an experiment in Minesweeper.
The save system used is also designed in such a way that it’s possible to add new fields to the save data at a later date, making it fully forwards and backwards compatible.
(At the time I thought this was over-engineered, but maybe now it’s not?)
The relevant files are here, here and here. If you need more of an explanation of what they’re doing I’ll explain later, but I think the only part that’s likely to trip you up is the use of templates.
(I templated the checksum code and save system code to make them flexible enough to work with any hash function/checksum function - ‘compile time polymorphism’ as it’s known.)
As I said previously, the FX makes EEPROM issues so much more likely as players swap games rapidly.
I wish the bootloader saved and restored the EEPROM as it flashed games (@Mr.Blinky is this even possible?)
I was thinking of just accumulating all the memory locations into a uint16_t then writing that out. I would put a call to the function in a the same functions where I write data. The checksum formula can be game specific and actually very simple.
The issue is likely to be Space Cab … more of my dodgy code!
The bootloader actually has serial commands for reading and writing EEPROM (even the old Cathy bootloader before @Mr.Blinky modified it - see AVR109, pages 8 and 9), so yes, it’s almost certainly possible.
Personally I’d want it to be optional, but I’d probably struggle to update the bootloader anyway.
(For that matter, I think most non-programmer/non-hardware-dev users would too, so perhaps it would take a while for this feature to propagate? Or maybe the side-chip would make it easier?)
16 bits gives you a theoretical 1 in 65536 chance of collision, but in actuality it’s less because addition is commutative. So you’d get the same checksum for 1,2 as you would for 2,1 (because
(1 + 2 == 3) && (2 + 1 == 3)).
I went for 32 bits because for only 2 extra bytes it gives orders of magnitude more range, and used a hash function because this is exactly the sort of scenario that hash functions are intended to be used for, the way I’ve done it might be flawed (I’m no mathematician).
Really it’s no different to implementing
GetHashCode in C# or
hashCode in Java.