Great stuff!
Quote:
Originally Posted by Jerrythabest
EDIT: Something just popped into my mind. JCS also saves which layer you're looking at. In the J2L format specification in the ERE, I can't find where this is stored (though there are JCS Focus positions). I think this is known but just not documented, just like the layer properties flag bits? Anyway, I suspect the 'char Unknown' I found missing in UR's EDIT block is actually the layer number that MLLE was focussed on upon saving, 0-based. It's 3 in many levels (which means they were editing the Sprite Layer). This is just a random thought though, I don't have any proof. Also, if this is correct, we should probably also find some MLLE Focus positions somewhere.
|
The current layer in .j2l is something I've never personally gone looking for, so it's not on the ERE even though it is probably "known" to some other people. I can't imagine it would be at all hard to find.
Anyway, that makes a lot of sense for that byte, given that it's in the EDIT section. Here's something a fair bit closer to proof: it's 03 in most places, but it's 02 in TUBE3, and when you open tube3.j2l in JCS then it's viewing layer 3 there as well. I guess they cleared layer 4 before clearing layer 3, and that was all they ever did with it before converting it to .j2l and then never touching it again. Looks like you're right. Certainly I don't notice any effect ingame of changing that byte, not that I'd expect one from anything in the EDIT section.
(I didn't check every single .LEV; there might be others, but TUBE3 struck me as a pretty likely candidate.)
Quote:
Originally Posted by Jerrythabest
EDIT #2: (EDI2 haha) About the INFO block: on the ERE it is stated that it contains no byte for the first tile since it's always blank. However, this does not seem to be the case: the length of the block (excluding the fourCC and the two longs in the beginning) is always [numberOfTiles]; it's even always a multiple of 10.
|
Oooh, whoops, my bad. That was supposed to be about DATA, not INFO.
Quote:
|
EDIT #3: I've uploaded program output about Castle1, Battle1 and Labrat1. Output begins with "TILE INFO", then all tiles with nonzero INFO bytes (tile# : value) are listed, then "EMSK", followed by a black-and-white visualisation of the EMSK block. Black parts are unset bits, white are set. (NOTE: it's not really an image, but actually a rather large (~4 MB) HTML table. It renders cleanly in Firefox but it's anything but standards complient so it may look buggy in other browsers.)
|
Cool! I think you have an off by one error in your INFO tile#s, though. I looked into COLON1 and LABRAT1, and it looks like the transparent color used for translucent tiles is always the second color in the palette. Here's the effects of various values for INFO before I lost interest:
00: normal tile
01: Transparent, used in COLON1
02: Transparent, used in LABRAT1
03: Transparent
04: Access Violation
05: Caption (in the .j2l version of the level), and tile does not display ingame. This explains why in so many levels the caption tiles are copies of other tiles and placed near the bottom of the tileset.
06: Access Violation
07: Access Violation
Quote:
Originally Posted by Jerrythabest
I just tried something in TMAP: changing the 01 01 bytes into 00 00 in the beginning of Castle1's TMAP gives me a very informative crash: "TMAP section version unrecognised". So if those shorts that are defnied 'Version; //maybe?' on the ERE are really section version numbers it shouldn't be difficult to have JJ2 confirm this!
|
The relevant text from JAZZ2.EXE:
Code:
LINF Chunk version unrecognised by GetLevelName LINF TMAP Chunk version unrecognised TMAP CMAP EVNT LAYR Chunk version unrecognised LAYR HSTR LINF Chunk version unrecognised FLIP Too many animating tiles ANIM MASK EMSK DATA Too many tiles in level INFO TILE Chunk version unrecognised TILE
It looks like you're right. LINF, LAYR, and TILE are the three sections with those constant version-looking shorts, and that is the constant section of TMAP, whatever the rest is for. Good thinking!
ETA: Here's a list of, as far as I can tell,
everything we don't yet understand.- An unknown byte in EDIT
- Two unknown strings in LINF (probably Secret Level and Bonus Level, though which is which?)
- An unknown byte per layer in [LAYR]INFO
- Another unknown byte per layer, created by bit0 in the SpeedSettings long and only used in one layer in two levels
- An unknown short in [LAYR]DATA
- An unknown byte in CMAP
Other than that, as far as I can tell, we have arrived at a
complete specification for .lev files in just over two weeks time. High fives!
or more like a decade's time, depending on how you want to look at it.