PT0

From OHRRPGCE-Wiki

Lumps with .PT_ extensions are sprite lumps. The types of sprite lumps are:

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

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.

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-- luckly 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)