Compress TileMap tiles in level file

[Vankata453]

TileMap tiles are now saved with the help of negative integers, the absolute value of each one being a multiplier for the next value (ex. "0 0 0 0 0 5 5 5" -> "-5 0 -3 5").

Newline separation for tiles in file based on TileMap width is no longer supported to save off additional file size.

Examples:

• 0 0 0 0 0 0 45 1 1 1 1 3 3 3 3 3 0 0 -> -6 0 45 -4 1 -5 3 -2 0
• 0 0 0 0 0 43 12 12 12 12 12 1 1 1 5 -> -5 0 43 -5 12 -3 1 5

Results from re-saving some levels from "The Crystal Catacombs":

• Worldmap: 1.5MiB -> 74.9KiB
• "The Journey Begins Again": 409.2KiB -> 27.7KiB
• "Fjord of Fortitude": 319.1KiB -> 48.9KiB
• "A Light in the Darkness": 613.3KiB -> 183.9KiB
• "Light and Magic": 456KiB -> 163.0KiB

[weluvgoatz]

Tested the first 4 levels of #3121:
all_that_glistens.stl: 437KB -> 194KB
another_cold_day.stl: 918KB -> 167KB
area_42.stl: 838KB -> 454KB
bonus_dias.stl: 337KB -> 107KB
And they all seem to work just fine!

[swagtoy]

@Vankata453 Is there a possibility you could implement a unit test for this?

[swagtoy]

Can you try breaking your test now? Primarily, we already know it works, but try breaking it, Try reading nothing at the end of the tiles and seeing if it breaks. Assume the level designer would maliciously put a negative at the end to break stuff and see if an exception throws or something.

[Vankata453]

I already ensured it throws exception if two negative integers are next to each other and if the array ends with a negative value.

[swagtoy]

Oh my apologies, i only read the first test function and missed that (i skimmed that as you "adding the test cases"). Moving on then. If the logic works then it looks good :) Sent some suggestions I think

[swagtoy]

LGTM. It look great son lets merge it

[swagtoy]

Actually, wait no, I do think we could maybe throw a dart and maybe align on a single Vector::reserve() size, just so for example all those 32 4 5 5 5 5 5 5 5 5 5 42 5 cases where a tile repeats maybe 10 or 15 times to create a wall won't result in needless reallocations. We could even do step scaling (i.e. for a step of 5, if 6 elements are pushed, then it allocates to 10)... EFL can do this but I see nothing in C++ that can easily let us do a step. We'd have to implement that logic ourselves, though I actually question if that'd help. At this point we would be micro-optimizing to very OS dependent tasks. So at a minimum, lets just reserve and clear for now on a vector so we can very slightly speed up those few cases. Maybe a value of 24 seems generous. Up to you here; once you decide on that you can then merge.

[swagtoy]

lgtm

[swagtoy]

heh