That was fast

I figured out what the issue was with the memory manager. Sometimes the amount of data being stored is just short of what is possible. With one of the memory blocks, it had a total sie of 68 bytes that it could store and after alignment, trying to store 41 bytes became 69 bytes. The way the total was being calcualted meant that it ended up trying to subtract 69 from 68. Nothing wrong from the standpoint that it should be possible. It doens’t meant it’s correct. Before the adjusted amount of memory available is returned, I check to see if the aligned size is enough to fit in the wanted size. After alignment the wanted bytes becomes 72 and the memory block isn’t considered for trying to hold the data.

The linked list issue has also been fixed. It’s first item’s previous and next pointers weren’t set to null in the first place. Luckily it was that simple and I didn’t end up losing that many sanity points.

Unfortunately there’s still an issue with the release build running on retail kits which is that the debug cubes I’m rendering appear as thick horiontal lines and don’t seem to move. It’s baffling me as there’s no reason I can think of that it would do this. I’m going to comment out the game state management in the main loop, trying to render the cubes, and go from there.

Next; I’m going to properly write the client and server networking code. It’s been a catastrophe for a long time and is held together by duct tape at this point. There are a bunch of game objects that are all the same, there’s no data compression for the network messages though I don’t think that will be tackled with this rewrite at the moment. Being able to cleanly create, update, and destroy game objects while also informing the clients is the goal.