AMAZE - 8 - Format Changes

Due to unforseen issues, this post(and possibly the next) might be a bit boring and dry. Just a heads up.

After last Friday's post, some good and bad things happened. The good thing is that I tested out some basic movement controls for the player as a proof of concept, and they worked great. This means that we're going in the right direction with this engine. Unfortunately, the bad thing was really bad: I accidentally broke the engine somehow.
Here's how it happened:

1. I decided to upgrade my compiler to the latest version, so that I could take advantage of some neat new features that would make my life a hell of alot easier.
2. After this, things started to go wrong. Specifically, the game was crashing immediately.
3. With a good bit of testing, I realized that my program was trying to load tiles with huge nonexistent ids for some reason. The problem was coming from my file loading code, but I haven't the slightest clue why.
4. Regardless, I can't seem to fix it. That means that I have to either hard-code my levels, or rewrite my loading code entirely. I'm going with the second option, which is why I posted that I was skipping Ludum Dare.

Before I talk about this rewrite, let me explain how my asset files tend to work right now, and why they're stupid and badly designed. Assets files need to hold all kinds of numbers, like the width of a sprite or the tile ids in some level. Currently, they are stored in an unwieldy but human-readable way. If we have a 150 by 46 pixel sprite, a section of the file might look like this:
150
46This might seem like a great way of doing things to a layperson, but it's a nightmare for computers to read. They have to do it like this:
0*10+1 = 1
1*10+5 = 15
15*10 + 0 = 150
New line here, next number:
0*10+4 = 4
4*10+6 = 46
New line here, next.....
I've actually simplified the process a bit, since the computer also has to figure out that how much every number symbol is actually worth. There's obviously many places that this could go wrong. In my case, the computer was somehow occasionally adding more numbers at the end, throwing the count off by 1 or more decimal places! It's also a bit unstable. What if the computer never runs into a new line somehow, and just keeps making the first number bigger? Everything breaks very quickly.

My solution is to store the data in a more computer friendly format, binary. You probably also know that binary is just 0s and 1s, but you might not know that bytes(8 digit binary numbers) correspond nicely to characters. This is why(I think) so many binary 'formats' tend to be based on a multiple of 8: it's easy to add, subtract, and manipulate sets of characters. These numbers can hold much more information as well, because bytes are in fact base-256: A single digit can hold over 25 times as much information! For me, I'll be sticking with 16 bit(2 byte) numbers. They can hold values of 65,000+ which is more than enough. Here's what reading them looks like:
(0*256)+150 = 150
(0*256)+46 = 46
That's it. That's all. with a set size like this, you know exactly what to read ahead of time, and the math is that much simpler. It also doesn't have to convert anything; it just takes the values given. This leads to a smaller, faster loading script-not to mention that there will be much less room for error here.

Anyway, so far I've rewritten the export functions for tilesets and sprites. The room code holds more varied and less predictable info, though, so I'm still working on it. After that's done, I just need to rewrite the import code and fix any serious bugs that show up as a result of this change. I think I can finish this in the next week or so.