TopicsSearchIndexQuickTipHelp


Index

16 bit to 8 bit
3D Tileset Objects
Ambient sounds (Howto JCS)
Automask
Background Music
Bouncy things
Buttstomp Scenery
Compiling a tileset
Cool layer tricks
Creating the Palette
Destruct Scenery
Detached Starfields
Event Theory
Events moved by belts
Gradients
Important phrases (Howto JCS)
JCS Hotkeys
Layers (Howto JCS)
Links and Resources
Making a simple level (Howto JCS)
Masking in general
MCE's - why and how
Motion Blur
Mystery of the Pacman Ghost
Palette Swap Animations
Remembering Triggers
Text
Textured Backgrounds
Tile Cache
Trigger Scenery in background layers
Triggers
Underwater Ambient Lighting
Warps
Welcome to JCSref

 Viewing node Tile Cache


Tile Cache

Tile Cache


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.


Flipped 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.


Animated Tiles


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


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.

Other Layers


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.

Layer Width


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.


Errors


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 19:57. Made by Violet CLM.