Sprite

From CleanPosts

Jump to: navigation, search

Everything in GEM is configurable, from the menus and colors to the icons to the symbols for "Stop Don't Do That!" and the mouse cursor. And because GEM is a graphical environment, the configurations are changed in a graphical way, with mouse clicks. GEM Paint has a control panel with patterns encoded as sprites which are used when spray painting or filling a region. This is great, because you can mix several of the sixteen available colors in a checkerboard pattern, as shown below, to create a completely new "color". This results in a huge set of possibilities, and some interesting textures. I can spend hours playing with it.

The GEM icon editor has a cut-and-paste feature so you can copy other icons and change them, but this is not the case with the Paint sprite editor. So if you need to make a checkerboard pattern, you end up doing it yourself, click after click, and it's a 16 x 16 square. That leads to Mouse Finger and screams for a hack.


The patterns are stored as a .PAT file. I imported it into the DEBUG program in DOS, which loads it starting at address CS:0100. The CX register contains the size of the file, 0A80H, which equals the 2,688 bytes reported by the DIR command. There are 21 available positions for sprites, with 128 bytes per sprite. These are arranged in four planes of color information which can be combined in a binary way to produce up to sixteen colors, sort of like musical notes forming chords:


1 -Red 2 -Green 3 -Blue 4 - Intensity

The first sprite was set up to be a blue and white checkerboard. Each row of the 16 x 16 square takes two bytes, and there are sixteen rows, or 32 bytes for the whole square in that color plane. In binary, one color plane looks like this:

10101010 (AA) 10101010 (AA) 01010101 (55) 01010101 (55) 10101010 (AA) 10101010 (AA) 01010101 (55) 01010101 (55) 10101010 (AA) 10101010 (AA) 01010101 (55) 01010101 (55) 10101010 (AA) 10101010 (AA) 01010101 (55) 01010101 (55)

For the first sprite, all of these alternating 1's are in the blue plane, where the rest is zeros all the way:

RED { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 } RED { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 }

GRN { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 } GRN { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 }

BLU { AA AA 55 55 AA AA 55 55 - AA AA 55 55 AA AA 55 55 } BLU { AA AA 55 55 AA AA 55 55 - AA AA 55 55 AA AA 55 55 }

INT { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 } INT { 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 }

Zero is white, and a 1 bit in all planes equals black. Adding to the confusion, the data is big-endian, so a white dot on the very lower right hand corner of a black field would have the last two bytes set to FE-FF (1110 -1111) instead of FF FE (1111-1110). Each one of the 21 sprite selection fields in the Paint program (seven rows of three) are the corresponding 16 x 16 sprites tiled about 2 and a half times horizontally and vertically.


I wanted to duplicate this pattern, but use the red color plane instead of blue. In Debug I named my new file using the command "nRUBY3.PAT". Then I went to address CS:0180 and typed in that 32 byte pattern, going 55 [SPACE] AA [SPACE] etc., which was a lot easier than clicking one at a time on the little squares. When I was all done I wrote it to disk with "w" and quit to DOS. In Paint I loaded my new PAT file, and Voila! The next sprite over from the blue-and-white one was now red-and-white. Now that I understand the layout of the PAT file, I can automate the process and build a program that spits them out on cue.

Personal tools