First time visiting the jcsref website? Check out the welcome
page for information.
Browse through the latest news
to see what's going on with JCS and level editing in general.
Take a look at this month's feature
articles for some of our best content.
Been a while since your last visit? Find out what's new in the latest updates
What have people been talking about on the site? Find out in the latest comments
Get to know the staff
members of jcsref and find out how to contact us.
section is full of great JCS resources. If you can't find it here, you'll find it on one of the links.
Not really sure what you're looking for?
Want to see what all jcsref has to offer?
Check out our topics listing
You can use the link above, the book icon up top, or the topics tab to the left.
Do you know exactly what you're looking for?
Are you trying to get information on several topics?
Give our archive search
Use the link above, the magnifying glass icon up top, or the search tab on the left.
Not sure on the spelling of your topic?
Need to browse through some keywords to find what you want?
Our site index
is just what you're looking for!
To go there now, use the link above, the papers icon up top, or the index tab to the left.
Jazz 2 Level files (.j2l) do not store the tile data for each level on a tile by tile basis, meaning that if you have a layer of 256x64 tiles, it is not represented by an (encrypted) string of 16384 values.
For whatever reason, such an obvious tile-recording system was rejected by the .j2l file developers - probably to conserve space - and instead something that JCS refers to as a Tile Cache was created. The Tile Cache holds four-tile-long blocks of data which are later referenced by the main layer mapping section of the .j2l, resulting in map data approximately one quarter the size they would be on a tile by tile basis. .j2l files can still get big if a lot of layers are used - I think a layer isn't recorded at all if it's entirely free of tiles and events, thus saving a whole lot of room - with a huge variety of eyecandy and thus a large number of different four-tile-long blocks, but for the most part the files stay quite small.
Each of the four individual blocks shown in the picture above would be recorded as a series of four values corresponding to their tile number in the Tile Cache section of the .j2l, and then later be referred to in the layer 4 section. Note that the top and bottom blocks are duplicates, so it need only be documented in the Tile Cache once, and it then may be referred to multiple times in layer maps. This is particularly useful for the blank-blank-blank-blank block which shows up a great number of times in most levels, especially if there are layers like layer 3 which only have a few tiles in them here and there.
An important thing to note is that the blocks are aligned on a grid in which each unit is, naturally, four tiles wide and one tile high. A tile which JCS says is at X position 6 will be in a block with tiles at X positions 5, 7, and 8. You cannot create a block from tiles 3, 4, 5, and 6; that will result in two blocks, each with two blank tiles and two other tiles.
A .j2t file contains four images: the tileset itself; the mask for the tileset; how the tileset would be masked if it were automasked; and the tileset again, horizontally flipped. This fourth image is used for the placement of flipped tiles. (Note: Adding the ability to vertically flip tiles to JCS/JJ2 would require the recompilation of every .j2t file and a potentially dramatic increase in their filesize... not really a good idea.) For the purposes of the Tile Cache, a flipped tile is a different tile number from its unflipped version, and so requires another block.
An animation is obviously not a standard tile. A block containing an animated tile essentially contains a reference to a single external copy of that animation which at whatever speed moves from frame to frame. The current frame for that particular animation is then displayed as part of that block. Different animations are different references, and a one-frame long animation is not the same as the tile used by that one frame. They are separate breeds.
Also, as you might imagine, a flipped version of an animation counts as different than an unflipped version of the same animation.
Events - and their parameters, but that's another story - are for the most part entirely separate from the tiles they are placed upon, and generally don't affect the blocks they're inside, as event mapping is stored elsewhere in the .j2l. You can stick almost every event in the world on the tiles of a block and it will remain the same block.
There is an exception to this rule. Sticking an event onto an animated tile - flipped or unflipped - will generally cause a new block type to be recognized. That event does not, however, differentiate that copy of the block from later copies that do not have that event on them. Continue on...
Each of the gray star tiles represents a three-frame animation - star, blank, star - with speed 0. The first star-blank-blank-wall block detected - that is, the one closest to the upper left corner of layer 4, block 1,1-4,1 - creates the definition for that block, including in this case the destruct scenery event on top of the star tile. Most of the other blocks see no reason to differentiate themselves from the prototype, except for the one with the second destruct scenery event, which is its own block.
When a destruct scenery event (or other such) is destroyed or incremented, this changes the actual tile at that position. Because( as we have spent so much time going over) JCS and JJ2 store tiles in four-by-one blocks, what is actually changed is the block that contained that tile. When the top destruct scenery event is shot, JJ2's concept of block 2 is altered to contain a blank tile on its far left. That means that all of the star tiles in all copies of block 2 instantly disappear. (Shrapnel only falls from the actual destruct scenery event.)
However, if the prototypical copy of block 2 did not have a destruct scenery event on it, there would be no reason for block 2's far left tile ever to change, and the star in block 3 would be the only removable tile. All copies of block 2 is connected to their original
In the above image, as long as the row of destruct scenery events are the first time that block (or possibly two blocks) appears as the level, each destroyed destruct scenery event will remove the corresponding three wall tiles in the passageway below. Until that time they will function as perfectly ordinary indestructible walls.
JJ2 creates its layers in numerical order; first layer 1, then 2, 3, 4, 5, 6, 7, and finally 8. Therefore a block in layer 2 will serve as its prototypical copy for layers 3 and up, as well as elsewhere in layer 2, but would be superseded by copies of that block in layer 1, which comes first. Why this is practical knowledge is as follows. If the prototypical copy of block x appears in layer 4, then all copies of that block in layers 5, 6, 7 and 8 will be based on that. Thus, altering a block in layer 4 can cause identical alterations (minus shrapnel) to occur in other layers as well as elsewhere in layer 4.
When a trigger crate or trigger zone for this triggerID is executed, all copies of these twelve blocks (which could be only six blocks were the structure moved two tiles to the left or right) in layers 5, 6, 7, and 8 will have those animated tiles be affected by the triggering. If the structure is animated to disappear when triggered, then a copy of the structure in a background layer, appropriately positioned, will also disappear. There can be as many copies of a block in a background layer as you want.
Ordinarily, if a block extends off the edge of a layer, the remaining tiles in it are considered blank.
An exception to this rule occurs when the Tile Width checkbox of a layer is on. At that point the block continues with the tiles from the far left of that y position, and so on. This works all right if the layer width is a multiple of 4, which I recommend doing at all times, but it can get a little confusing with other numbers. I present this illustration to hopefully give you an idea of how to handle other layer sizes... if you can't figure it out, stick with multiples of 4.
A combination of all three confusing factors - animated tiles, flipping, and an event such as destruct scenery - will result in an access violation. It is simply too much referencing to ask JJ2 to handle.
In single player, block copies are affected by the original only if the original is within the 64x64ish square of active memory surrounding the player character. A block containing trigger scenery will not update itself until that trigger scenery enters into the active memory square. Moreover, if an event such as trigger scenery is artificially keeping an animation's speed at 0 in all copies of a block, moving the original copy of the block out of the active memory square will cause all copies of the animation to resume animating. To handle this, make sure all triggering is done while the trigger scenery is within active memory and keep animations at speed 0. Obviously you are free to ignore either of those recommendations if desired for some particular effect.
An event such as destruct scenery on an unanimated tile will cause that tile to vanish in all copies of that block throughout the level, regardless of whether the block copy containing the event was the prototype or not.
(Discovery, research, contemplation and documentation performed by LAbRaTkId, BlurredD, Neobeo, and Violet CLM.)
Added on: 18 July 2006 20:57. Made by Violet CLM.