Restoring lost posts from old hosting provider 
Quote:
Originally Posted by Jerrythabest
Quote:
Originally Posted by zapS
The fourcc's identifying a section are (afaik) always followed by a 4-byte length-value representing the size of the section minus the fourcc and the length value(8 bytes total).
So this:
long Unknown; // always 196?
is the size of the "EDIT"-section.
|
This appears to be true, except for the first (DDCF) block in the file, which is always 8 bytes ("DDCF" + a long).
The file can be quickly skipped through by:
Code:
skipBytes(8);
while(bytesLeft()){
skipBytes(4);
skipBytes(readLong());
}
And thus, a particular block can be reached easily by:
Code:
skipBytes(8);
while(bytesLeft()){
if(readBytes(4) == "TMAP") //To reach the TMAP block
break;
skipBytes(readLong());
}
Also, I'm missing something in UR's EDIT block. (A char is a one-byte value, right?)
Code:
char Section1[4] = "EDIT";
long SectionLength;
char Unknown; // I see this byte in my Battle1.lev file?
char LengthOfTilesetFilename;
char TilesetFilename[LengthOfTilesetFilename];
char Unknown;
long Unknown; // always 2?
|
Quote:
Originally Posted by Unknown Rabbit
Just to reply quickly without considering the rest of your post, the DDCF section actually contains all the other sections within it, so the long is the length of the whole file minus eight. It's something like this:
- DDCF
- EDIT
- EDI2
- LINF
- HSTR
- TILE
- FLIP
- LAYR
- INFO
- DATA
- EVNT
- TMAP
- CMAP
|
Quote:
Originally Posted by Jerrythabest
Ah, that's indeed a better way to put it. Also, the LAYR block contains the second INFO/DATA blocks... so it's actually like this:
- DDCF
- EDIT
- EDI2
- LINF
- HSTR
- TILE
- LAYR
- TMAP
- CMAP
|
Quote:
Originally Posted by Jerrythabest
I've began working on the LAYR blocks.
Code:
char BlockHeader[4] = "LAYR";
long BlockLength; // Total length of the following INFO, DATA and EVNT blocks + 4
long Unknown;
char InfoHeader[4] = "INFO";
long InfoLength; // Length of this block, excluding InfoHeader and InfoLength (as usual)
LayerInfo LayerProperties[8]; // As specified below
char DataHeader[4] = "DATA";
long DataLength;
(layer data follows, I haven't figured it out yet)
The LayerInfo structure mentioned above (assuming you're using the name 'short' for a 2-byte value?):
Code:
long LayerFlags; // Only the lower 5 or so bits appear to be in use:
// bit0: Tile X
// bit1: Tile Y
// bit2: ? (either 2 or 3 is Limit
// bit3: ? Visible Region)
// bit4: Texture mode
short LayerWidth;
short LayerHeight;
char Unknown[7]; // Still need to look into these bytes
short LayerXSpeedMarginal; // See discussion below!
short LayerXSpeed;
short LayerYSpeedMarginal;
short LayerYSpeed;
Some notes about the layer speeds:
-They appear to be missing entirely for Layer 8 (so the LayerInfo structure is actually 8 bytes shorter for the last layer!)
-The LayerXSpeed/LayerYSpeed fields seem to be the 'integer' part of the layer speeds ('1' syncs with player movement, '2' goes twice as fast etc.), whereas the LayerXSpeedMarginal/LayerYSpeedMarginal values seem to be fractional (even set to the maximum value it's very slightly less than 1). I'm not an expert in floating point representations, so if this is in complience with any standards feel free to teach me about it |
Quote:
Originally Posted by Unknown Rabbit
What you're calling LayerFlags looks to have the same structure as LayerMiscProperties on the wiki, which... isn't documented. Whoops. Assuming they are the same, though, the bits are in order Tile Width, Tile Height, Limit Visible Region, Texture Mode, and Parallax Stars. The same goes for the X and Y speeds: just like in .j2l files they're stored in longs as multiples of 65536.
(So layer 8 in .lev files is completely incapable of having its speeds even set, let alone used? That's brilliant.)
|
Quote:
Originally Posted by Jerrythabest
Ah, multiples of 65536, that's a funny way of describing it  JCS simply divides by 65536 when reading the values into those Layer Properties boxes and multiplies by 65536 again upon saving... so that's how.
I'm not sure about Parallax Stars being bit4, if I turn it off in Carrot1 the texured background returns to a plain one? Or have I been screwing up some bits here?
About Layer 8's immobility:
This image is a screenshot of Castle1's LAYR-INFO block, with one layer on each row.
EDIT: Another thing I noticed and that might be interesting... many of these layer properties are stored in .j2l on a per-property basis (as opposed to the per-layer basis in .lev files). But after scanning for, for example, layer speeds in the game's memory I actually found them listed one after the other in memory. Just like they are in .j2l files.
I don't know much about the differences between 1.00g and 1.00h, but for the record: I've seen this in 1.00h. |
Quote:
Originally Posted by Unknown Rabbit
Okay, did some actual tinkering instead of just looking at the wiki, and you're right. Limit Visible Region is bit3, and bit2 is HasTiles, that is, whether or not the layer is drawn at all. Parallax stars hadn't been implemented yet in 1.00g; if you turn off texture mode in the levels that do seem to have it, you see that the dots are simply drawn on the textured background manually.
I would be hesitant at best about paying too much attention to the memory layout for anything but save files.
Concerning your mystery bytes, the fourth controls the (storage of the) layer speeds. If the second bit(2) is set, then the seven unknown bytes are followed by two longs storing X Speed and Y Speed. If the third bit (4) is set, then there are two longs storing Auto X Speed and Auto Y Speed. (If both are set, speed precedes auto speed.) Haven't found any examples of the first bit (1) being set yet, but it definitely has some effect, unlike the fourth (8).
Since the last three of the mystery bytes seem always to be zero and don't seem to change anything, I'm guessing that layer speed byte is actually a long, similar to the LayerFlags long. The first two bytes of the seven are a short indicating what the wiki calls Z-Axis (-300, -200, -100, 0, 100, 200, 300, 400), but just like in 1.23, altering them has no effect. Not sure about the third byte yet...
|
Quote:
Originally Posted by Jerrythabest
Aha, so that's why I couldn't find any auto speed settings in the levels I looked at
Layer 8 can be made to move automatically, but it won't obey 'normal' speed settings. |
__________________
Last edited by Jerrythabest; Aug 12, 2011 at 01:22 PM.
|