So far we have read the main details of a room and extracted the background items, came across the FF byte and we now know the remaining bytes are room objects (such as blocks, pick up items, etc).

The first room object for Knight Lore in Room zero is set as a 7 (the first byte after the FFh byte). As shown to the right this is split into two parts.

Block is the block being placed (e.g. a table, a brick block) and Count shows how many are being put in this room. As you can see, a very concise way of placing multiple items. The count starts from 0, therefore add 1 to the value you get for the actual value.

The more observant may have realised that you can only place 8 blocks at any one time; to add more than 8, simply place multiple bytes.

Also, this means that a limit of 32 different game objects can exist. Which is more than enough in Knight Lore.

What follows after this 'object descriptor' byte is a series of 'object location' bytes (the number is determined by the count) and describes the location of the block. These locations are grid cells.

Repeat this sequence of object descriptor byte/object location bytes until the end of the room data, i.e. get a block and determine its type, then get the count from the byte and the following count bytes, extract the x, y, z location and place the object there.

Don't worry, a worked example will be shown!

All is not as simple as this though. Alien 8 has more than 32 game objects and so cannot fit into the 5 bits allowed.

In Alien 8, whenever the block type is shown to be 0x1Fh, skip this byte and the following then move on to the next, this next byte is the block type/count block. The reason is quite simple, when you come across this special block (called a control block) add 0x20h to every subsequent block type. For example, if the block byte was 7 this signifies 8 block type 0's. With the control block active it becomes 8 block type 20h. Control blocks are always last in the data so do not have a 'revert' mode. Each new room starts with the Control Block off and there are no location offsets (detailed below).

One other thing you may have been wondering is if we have 2 bits for Z location how are items placed above this when a room can have 8 objects in height?

Another simple yet concise solution and similar to the control block. In Alien 8 whenever a block type 0 is found it means that the z location for the remainder of the objects are offset. The next byte is read, bits 0 and 1 are the x/y offsets and the remainder are the z offsets. A 1 in the x/y signifies a half block shift and the z is in pixels offset from the ground (multiplied by 4). Note, z offsets are really only of use for Knight Lore. Remember in filmation games the size of blocks are measured as x and y are 8 pixels for one block and z is 12 pixels for one block.

I guess to keep things simple because this control block uses two blocks (one for the control block and one for the offset) this is the reason why the control block for block extensions (1F) skips two bytes.

In Knight Lore this method is not used, instead the offset is stored in the block data lookup table (6C0B) - refer to above for what the offsets mean. What this effectively means is that Knight Lore required two blocks for every block that could be in the upper half of the screen, whereas Alien 8 required just one, but the drawback is that an extra byte per block placed is required.

In other words in Knight Lore to have one block high and low requires two block types (even though they are the same) with the offset in its block details; whereas in Alien 8 you just need one but embed the offset in the data. There are pros and cons with both methods.

also, it is implicit that all Control Blocks do not have an offset.

Again, there is no need to extract all the information from the block data, instead refer to the map file (see to the side). The same reason applies - more information is required to make the data useful.

Finally, you may be wondering (well, probably won't be) why the sprites have the numbers they have. The sprite number is how the graphic is located. Visit the download section and open up any of the game sprite graphics. If you look at the map file for Knight Lore you will see that the sprite number (second number) for the Clockwork Mouse is 0x74h. Now, look at the bitmap and count the rows and columns to find the Clockwork Mouse. I don't know about you, but when I first saw these graphics I wondered why they were like this :)

Each room object has a lookup table of values similar to the background items that describe details about the block, such as its rotation (a bit like how the doors are done), its offset from the x/y/z cell stored in the byte.

I haven't mentioned Pentagram yet. Pentagram uses the Control Block byte as with Alien 8, however it is not used as the graphic count is less than 32.

Also, it does not make use of the offset block in Alien 8 for putting items higher in the Z axis; instead it reverts back to the way Knight Lore did it. However, Pentagram does not actually have any room objects high enough to use this facility (except high doors).