PT0

This article (or part thereof) is obsolete. It may have made sense in the past, but it does not make sense now. It is kept here only for historic curiosity and/or posterity.

Lumps with .PT_ extensions are 4-bit sprite lumps. They have been replaced with RGFX starting with Fufluns.

The types of sprite lumps are:

Lump	Type of Sprite	Dimensions	Size (bytes)	Used by
.PT0	Hero graphics	32 x 40 x 8	640 x 8 = 5120	Heros
.PT1	Small Enemies	34 x 34 x 1	578 x 1 = 578	Enemies
.PT2	Medium Enemies	50 x 50 x 1	1250 x 1 = 1250	Enemies
.PT3	Large Enemies	80 x 80 x 1	3200 x 1 = 3200	Enemies
.PT4	Walkabouts	20 x 20 x 8	200 x 8 = 1600	Heros, NPCs
.PT5	Weapons	24 x 24 x 2	288 x 2 = 576	Items
.PT6	Attacks	50 x 50 x 3	1250 x 3 = 3750	Attacks
.PT7	Box Borders	16 x 16 x 16	128 x 16 = 2048	UI colors & box styles
.PT8	Character portraits	50 x 50 x 1	1250 x 1 = 1250	Textboxes,Heros

(NOTE: All types of sprites can be used by slicetree_n_n.reld lumps)

A sprite lump is made of fixed width binary records with no header. The total number of records is stored in the .GEN lump. The size of each record is (((width * height) / 2) * frames). Data is stored two-pixels per byte, one in the low nibble, one in the high nibble (in sane bit ordering). For instance, if one reads the byte 0xA7, the next two colors will be 0xA and 0x7, respectively. (Note that sprites are 16-color images; see PAL for information about 16-color palettes.)

Pixels are stored in blocks called frames, and then in vertical columns from top to bottom, and rows which go from left to right. There are no delimiters between columns, you just have to know the height of the sprite beforehand.

Here's an example to clarify. Walkabouts have eight frames per sprite. The walkabouts for wandering hamster might look something like:

...where "f1" means "the first frame". Now, let's look at f1, which depicts Bob placing his left foot down:

...where the first pixel (0) is in the top-left corner of the frame. This means that if you're reading the following stream of pixels: F0123DA6... then F would be the top-left pixel, 0 would be the one below it, and so forth. After height number of pixels, the next column begins to fill.

In other words, though the way you might think about the graphics is like "x * y * frames", the actual layout of the bytes making them up is "frames * x * y", with each byte encoding 2 consecutive pixels of the current column.

Pseudocode for loading the entire PT4 lump might look something like:

for N walkabouts:
    for 8 frames:
        for WIDTH columns:
            for HEIGHT/2 rows:
                'Read a byte from the lump
                'Set the next two pixels
            next
        next
    next
next

Because of the two-pixel-per byte thing, the bottom right pixel of an image with an odd number of pixels is lost-- luckily the OHRRPGCE does not use any images with odd-numbered pixel totals (the sane thing to do would have been to waste an extra nibble in the data, rather than cropping the last pixel... oh well)

PT0

Navigation menu

Search