Hey I installed this and now my arduboy won’t flash another game. Anyone else experience this?
Yes sorry, to flash another game after flashing this one you simply have to put the Arduboy in flashlight mode, which is holding the UP key while turning ON the Arduboy. When in flashlight mode you should be able to flash another game.
Yes … its surprising that we are having an issue with this game as it hasn’t gone above the 75% RAM ‘danger’ mark.
This is such a polished perfect game! Very responsive and well made, thanks! Few observations:
- The intro screen is brilliant as it teaches the controls, but what is the point of the taxi stop changing number from 2 to 1 if you kill the passenger? (just a silly question)
- Why UP/DOWN does not do A/B functions too?
- Dialog bubbles sometimes appear off screen or covered
It has to do with the program storage space. If you comment the boot logo it does not generate issues when uploading a new game.
So I can never have my Asteroid game to be flashed on-the-go.
But if I make some of my
float local (should NEVER do that) then I can flash it…
Just don’t mind the last bit…
The percentage of RAM that the compiler gives is just for global variables. A sketch could also allocate a lot of local variables on the stack or heap, in an often used loop, which could also cause the problem.
Thanks for the compliment!
To answer your questions…
the intro screen looked really cluttered with two signs on the screen at one time and it was a little confusing for the player to understand what to do. Obviously, you are not supposed to squash the passenger so if you picked them up properly the first time, you would never see the second sign!
I guess it could but they you would have to press multiple directional keys simultaneously. Maybe a mod for Version 2?
Yes, this is a known bug and will definitely be addressed in Version 2.
One of the things I need to do for Version 2 in addition to the previous is free up some PROGMEM space for some additional levels.
Right, at the point where the game is sitting idle (on the splash screen) and a user would be able to flash the device there should be very little local variables allocated or stack / heap use due to looping. Of course its just my inclination but I have been wrong before.
Is there any way to really measure or calculate the dynamically allocated memory use the game?
I haven’t tried it with Arduino but something I’ve done with other systems is add a small piece of code at the start of the program that fills the stack and heap areas with a simple pattern, such as all 0xFF or all 0x55 or incrementing values 0x01, 0x02, 0x03, …
You then use your program as usual and then at some point dump the stack/heap area and look for the area(s) where the pattern has been overwritten.
With the Arduboy you could use the global variable use reported after a compile to calculate the area to be filled with the pattern. The code to set the pattern would go at the very start of setup().
Assuming resetting to the bootloader doesn’t clear the RAM, you could press the reset button and then use avrdude to dump and examine the RAM.
Interesting … my only concern with this is that I then need to include the serial.print code into the sketch. I guess that’s predominately PROGMEM so it shouldn’t affect the RAM readings. I did have an issue where I could not connect via the serial monitor - probably for the exact same reason I couln’t flash the board without intervention.
@MLXXXp’s solution is probably more appropriate if you cannot connect the serial monitor.
Actually, I could use the
freeMemory routine and write it to the the eeprom for later retrieval. Some sort of ‘if freeMemory() < last recorded value then update eeprom with freeMemory()’.
The problem with freeMemory() is that is just tells you the amount of free RAM at the point that it’s called. If you want to know the maximum amount of dynamic RAM ever used by the program, you would have to call freeMemory() at the point in the program where this maximum use occurs. This point may be difficult to determine with a complex program. And, it might occur during execution of a function in an external library that you aren’t intimately familiar with and/or don’t want to “patch” with freeMemory() calls.
With my method, you don’t have to worry about this. You just use the program normally, hopefully at some point executing the code that will use the most dynamic RAM. Then sometime later you examine the RAM to see how much of it has been “clobbered” based on the amount of the pre-set pattern that has been disrupted.
Right … I had assumed that it would be my code causing the problem but of course its most likely my code calling something in another library that causes the issue.
I like your approach but with both scenarios I wonder how you go about pinpointing what is causing the problem. I think I can take it for granted that something is consuming the memory, but what?
Hmm, I already tried that and it didn’t work. Let me try a different PC.
Worse case, click the reset button just as its about to upload.
What problem? The need to use flashlight mode to load another sketch?
First, I’d rule out it being a global variable that’s causing it. For this, I use objdump to find out what, if any, global variable has the same address as the bootloader “magic key”.
If instead it turns out to be a local variable or the stack, then yes, it could be difficult to find.
In any case, it’s not really worth trying to fix because any later changes to your code or the libraries that you use, or even the compiler itself, could alter the memory layout and cause the problem to reoccur.
Yes … I really meant what library call or stack issue is causing the problem.
True. But if it is ever ‘finalised’ (when is a game ever finished?) then you can thump out a HEX with the problem gone. If you recompile it after this, you may introduce new issues due to library updates and the like.
Actually, this one doesn’t seem to work as it is telling my all my memory is free. Those defines must exclude the Arduino.
This one gives a ‘realistic’ answer > https://github.com/McNeight/MemoryFree
Or you can use Project ABE and see the RAM there…
ProjectABE shows the global variable RAM usage but doesn’t show you at runtime the dynamically allocated RAM and stack use. I just spoke to @FManga and he is going to look at whether this might be possible but he is concerned about the performance problems it might create
make the variable in the homescreen non-local, and basically check complier output (or project ABE)
Did I try out your cab on my Arduboy? Hmm… still can’t remember doing so.