Talk:Jill of the Jungle Map Format
Tile mapping table
Man, JotJ is confusing... According to the article, JILL.DMA contains this:
| Data type | Description |
|---|---|
| UINT16 iMapCode | ID used in map file |
| UINT16 iTileset | Index of tileset containing this tile's image |
| UINT16 iTile | Index into the tileset |
| UINT16 iFlags | Flags for this tile |
| UINT8 iLength | Length of tile name |
| char cName[iLength] | iLength characters for the tile name. |
For the first entry, it starts like this: 00 00 / 00 47 / 01 02 / 01 30 / 14. This would mean the tile name is 0x14 = 20 bytes long. This does not look correct, because the next entry would be: 00 09 / 42 41 / 53 45 / 53 48 / 4F. Not only would this mean a name of 79 characters, but "coincidently" the bytes 42-41-53-45-53-48-4F correspond to the word BASESHO, which looks more like the name of a tile. If the first length would be 14 instead of 20, it makes more sense because then the first name would be BASETREE. However, when you assume that is correct, the next entry only has 6 bytes instead of 8 before the length of the tile name.
Just look at the file in a hex editor and it will probably be clearer than what I'm trying to say.
Does anyone have experience with this file who can maybe point out what is going on here? -- Spinal 17:10, 15 March 2008 (GMT)
- Hey Spinal,
- I think I also had some trouble with this initially. I believe Malvineous wrote the inital notes on the Jill of the Jungle Map Format notes, based on his work from Xargon. But I had found Jill to be a little different to what was documented. However, I never got around to updating the notes.
- I found that the first entry starts at byte 9th. I could never work out what the first 8 bytes are for. I also found that the data structure seems to be as follows:
Data type Description UINT16 iMapCode ID used in map file. UINT8 iTile Index into the tileset. UINT8 iTileset Index of tileset containing this tile's image. UINT8 iType The type of tile, e.g. Solid, Background, Climbable, etc. UINT8 iSomething I have no idea what this byte refers to. UINT8 iLength Length of tile name. char cName[iLength] iLength characters for the tile name.
- So your first entry goes 14 00 / 00 / 5B / 31 / 00 / 08 / 42 / 41 / 53 / 45 / 54 / 52 / 45 / 45. So its basically Map code 0x0014, tile at index 0 in set 0x5B, of type 0x31, and the name string goes for 8 bytes, resulting in BASETREE. I hope this helps.
- - Daniel 04:35, 16 March 2008 (GMT)
- Ah, cool, that makes much more sense. Thanks a lot! -- Sander 13:23, 16 March 2008 (GMT)
- I know it's been three years... but hey, I'm retro. Anyway, I'm not sure I got everything here, but I do not believe in exceptions (the first entry starting at byte 9th)... I think EACH AND EVERY entry is "7 bytes + a filename", it works from the beginning to the end; I suspect the first entry to be named "0", here's what I'm thinking about:
Data type Description UINT16 iMapCode ID used in map file UINT8 iTile Index into the tileset UINT8 iTileset Index of tileset containing this tile's image UINT16 iFlags Flags for this tile UINT8 iLength Length of tile name char cName[iLength] iLength characters for the tile name.
- If the Jill map format requires 16bits for tile indexing, then it makes sens to use 16bits for the "ID used in map file". Still according to what's explained about SHA format, we can have up to 128 tilesets per .SHA (and 128 items per tilesets). So we can store each info on a single byte (one byte for iTileset, one byte for iTile) -- and 8bits is already too much ^^ (note that for some reason, iTileSet-64 is the exact tile set value). Maybe the engine needs all those flags, the 16bit integer seems quite possible (for instance, entry 0 is 513: 512 -back- & 1 -non solid-, it seems to be correct and require more than 8bits). Until now, I was unsure about the use of the DMA file. I mean, they could have skipped this file already if it wasn't for tile definition.
- Also, the file ends with two nice string: the first is certainly the music filename to play and the second represent the next map to be opened, both are null terminated and follows a single byte stating the string length of each. I have no idea if it is part of the entity table or something else.
Object Data
Upon reading the information given for the object data, it seems the method by which I had worked out what I believed to be the values for all (or most) of the objects was entirely incorrect. I had been working under the assumption that the first byte in each object entry determined which actual object and object was, rather than which category of object it belonged to. That does seem like it could explain some errors I had when recently attempting to figure out object data again (since I had lost my previous work). If I have the time, at some point I may try to figure out the values for the objects with the benefit of the information on this page. Eric Mushroom Wilson 09:04, 2 November 2008 (GMT)
- Hi, I'm quite sure the object data description as shown on the wiki is exact -- except most of the values are signed (iXD, iYD, iState, iSubState, iStateCount, iCounter -yes, even this one-, iInfo1 and I suspect iZapHold also -- although I've never seen any object using this variable so it's certainly a save game specific stuff) -- anyway, the few objectID that might be confusing are 41 (the bouncing ball has different look depending on its iCounter), 42 (the huge "M" "E" "G" "A" "S" letters, defined by its iCounter) and 28 (the given object is defined by iCounter and matches to the inventory number). --Ilovemyq3map2 19:54, 16 May 2010 (GMT)