Nintendo 3DS
An extra devlog today, to keep you informed on the 3DS progress.
The soccer match was cancelled, so I had some extra time.
Which was pretty neat as I could pour some more time into the game.
However in the end I only have worked on the 3DS version.
Though it was pretty fun and informative!
First I downloaded 4coder to try it out. It’s somewhat nice to use so far. I do miss some important features. So I want to look into implementing those. However 4coder being cross platform as well as very customizable is very interesting. Running the build commands from within 4coder is one of the main advantages to me currently.
After that I had to implement the file loading code. Which didn’t take too long before it worked actually. However after that I stumbled upon a very important detail. This took me until into the night, when somebody helped me out. I try to keep the explanation short and simple.
Memory Alignment
The 3DS CPU is a 32-bit ARM CPU.
It can read memory misaligned, which means it can read a 8-bit variable and not complain.
Though on PC your program will have an 8-bit variable converted into a 32-bit value.
Which means it is aligned and only then the PC won’t complain.
So in the 3DS version of the code I did not bother with aligning the variables. As on PC it happens automatically through the compiler and on 3DS the ARM CPU should be able to handle it. Turns out though, that the Floating Point Unit(FPU) is actually not happy with misaligned variables. That means that the address of a float variable should always be aligned, but as we now know, that doesn’t happen automatically on 3DS.
Luckily once I learned about this, it was very easy to add padding to one of the variables that was causing crashes. With all the variables aligned to 32-bits, the program ran fine again. So as long as I align the variables to 32-bit the program should be able to be executed. Though for doubles it needs to be aligned to 64-bit. I am not bothering with that at the moment though, until it crashes on it.
World Simulation
At this point the game ran, but the world was not simulated.
It was just the test intro I created that ran.
For the actual level to not crash, I had to properly set the memory sizes for each memory area.
As the tilemap was overwriting some other memory for example.
How could this happen so easily? Well I forgot to properly turn on assertions haha.
But with all the correct memory sizes set, the game now actually runs.
No you can’t see much on the screen. But behind a dark blue screen the whole game is actually running! That is such an exciting idea! 😀 I can’t wait to get the rendering and sound working. To then finally implement the input to be able to drive around in the world. So even though the image here shows you just a 2DS with a blue screen. Remember that behind that blue screen the game is running without crashing!
