Static SAT
The first milestone has been reached. Or perhaps it’s the second.
What matters is that the SAT is in again, but in the very basic way.
So yes, we can detect if there is a collision.
However we don’t know how far we are inside the other collider yet.
We need that info to properly resolve the collision.
At least the basis has been laid out. Though I realise the next part is one of the hardest bits of this. I did implement the possibility to draw a rotated rectangle. This helped me visually see that the SAT was indeed working with rotated collision shapes. But it also will help me in the next phase, as I can draw lines with those rotated rectangles as well. This way I can visualise how far a collider is inside of another. Making debugging this system way easier than before!
BONUS:
I’ve been doing some work in the weekend.
No, not on the collision system.
Instead I went back to the 3DS port.
Trying to implement the asset loading.
Since it turned out that the assets weren’t even getting loaded.
So after fixing the file reading I discovered some other parts that aren’t working correctly. One of them being the tilemap getting loaded. Which doesn’t surprise me to be honest. But that is hopefully something I can look at this evening.
Apart from that I have been tinkering with a Wii example as well. I was surprised how easy it was to get stuff working there. Though I probably won’t look much further in that platform for now. Figuring out how to handle memory and everything in a different platform has been proven to be a bit hard. Though once it is working, like on the 3DS. It seems to be usable just like normal without too many hassles. It’s mostly my stupid mistakes which keep the game from working properly, at least on 3DS at this point.
UPDATE:
Well this felt like a very productive evening.
As I said above, I wanted to work on the 3DS port a bit.
Found another problem with the file loading.
This time it was specific to the track files.
After that was fixed I stumbled upon the thing I was afraid of. The 3DS has 128MB RAM according to Wikipedia. However turns out you can not use all that memory. So I allocated as much as I could. After that I still did not have enough memory. When I calculated how big the tilemap was, as it was trying to load that thing into memory. Well, let’s just say it was big… around 64MB big. That’s way too much. So I decided to make a start with an idea I had for a long time.
The idea is to only have a tile type ID and a shape ID for a given tile. That would reduce the tile memory footprint from 28 bytes to just 4 bytes(-86%). That should be enough to get the game up and running. This involves changing a lot of different systems. I also need to regenerate the track from the GPS data. This is all not ideal and the editor is also crashing currently. However a little proof-of-concept was already working and that got me excited. Hopefully I can think of more ways to reduce the memory footprint. 9MB still feels a bit on the large size if you ask me. But tomorrow we will shift the focus back to the collision algorithm.
