Misc User Apps - Text-based LVL editor (lol) Samapico - Thu Sep 04, 2008 11:17 pm Post subject: Text-based LVL editor (lol)
Small thing I made... mainly for L.C. and Snrrrub who seemed interested in the effects of having tiles outside the 1024x1024 boundary. So here is a small program to make .lvl based on simple text input.
Syntax:
X,Y,tile
Example:
1,2,3 will put tileID 3 at coordinate (1,2)
One tiledef per line
Limit (as per lvl format) is 4095,4095 for coordinates, and tile id can't be > 255
have fun
My predictions if Continuum encounters a tile outside the 0,0 - 1023,1023 area:
-Either a crash
-Some warning about an invalid LVL file
-These tiles would be completly ignored
I'm also curious about WORMHOLES outside the map... if it doesn't crash the game, there is a slight chance the wormholes would still be registered, without the tile being there (i.e. the tile is ignored, but it still adds the wormhole in its list of wormholes)
Cause wormholes are definitly put in a separate array, with their own x,y struct, so these are not limited to 1023,1023. Unlike tiles, which are most likely put in a large 1024x1024 array, and putting anything outside that = BOOM.
Hakaku - Fri Sep 05, 2008 12:31 am Post subject:
Well I tried putting a tile at 0,0; 700,700; and 1025,1025. The result was the following: 0,0; 700,700; and 1,1. So I then tried to place tile 1 at 0,0; and tile 2 at 1024,1024 and the result seemed that the tiles overlapped (Continuum was showing tile 2).
So the result wasn't quite one of your three theories.
Samapico - Fri Sep 05, 2008 1:08 am Post subject:
nice
and if you do like...
a wormhole at 0,0
and some other tile at 1024,1024
will the wormhole still be there?
I'm also guessing that whatever tile is written last will be the one on top, so if you put
1024,1024,1
0,0,2
tile 2 will still be the one shown?
Snrrrub - Fri Sep 05, 2008 1:53 am Post subject:
I think the only really interesting question is if the extra 4 bits per tile are used by Continuum. The x and y coordinates are in the range [0, 1023] and the tile value is in the range [0, 255]. That's 10 bits for x, 10 bits for y, and 8 bits for the tile value = 28 used bits. All of that information is encoded in a 32-bit field on disk so that leaves 4 unused bits. That begs the question: are they really unused or does Continuum do anything special if those bits are set?
Clients generally read the map data into a large array like so:
for each field f in mapFile:
x = f & 0x3FF
y = (f >> 12) & 0x3FF
tile = (f >> 24) & 0xFF
mapData[x, y] = tile
This kind of code has 3 implications:
1) The x and y fields cannot be outside [0, 1023] because the upper 2 extra bits are masked out.
2) If you try to write out of bounds, you'll set the "unused" bits but your coordinates will still be modulo 1024.
3) If two or more fields refer to the same (x, y) location, only the last one will be used.
Samapico, I haven't seen your code but I'm assuming you're not masking the top 2 bits of the x, y coordinates? Your code should resemble:
x = readInt() & 0xFFF
y = readInt() & 0xFFF
tile = readInt() & 0xFF
write(x | (y << 12) | (tile << 8))
-Snrrrub
Samapico - Tue Sep 09, 2008 9:48 pm Post subject:
Yeah of course I'm not masking these bits in this program, that was the whole point
Also, since Continuum ignores these bits, I thought of a use for them in DCME.
Basically, I'd use these bits to save the information about walltiles... basically, which walltile set does this tile belongs to. This would make it so it wouldn't require any extra data in other files, or in eLVL. (Such data in eLVL chunks would almost double the filesize; +3bytes for each walltile)
It would allow for 14 walltile sets, which is more than enough to cover the whole tileset, especially since the walltile patterns would include diagonals, and pretty much any shape (8 surrounding tiles => 256 patterns)
And 14 because there would be the possibility of a tile that is on the map, but that was just a consequence of an adjacent walltile, so DCME would have to ignore it on loading... or it could load it and overwrite that tile... that will be to determine whenever I jump in this.
Anyway, the result of this will be selections that can be flipped / rotated, and the walls would stay intact
