SOLAR OS - API

Solar OS Technology Articles

Sprites might have gaps inside...
Or was it spirits?

SOLAR OS Icons/Sprites Format

Solar OS uses a special kind of image format for its ICONS:

This is the so called "Sprite Format" or .PZE or "pictures with zero eliminated"

This folowing article tries to describe this format.

Credits and License

The design of the format was made by: Bogdan Ontanu and Eugen Brasoveanu. The HE coding was done by Eugen Brasoveanu. The Solar OS coding was done by Bogdan Ontanu. We used no other external references in our design.

Copyright

History and the problem description

The roots of this format come from the Hostile Encounter Game.

HE Game was the first application to use this format AFAIK. It originated from our tests for obtaining the greatest speed in drawing a sprite on screen or in a memory buffer.

The sprite was simply defined as a sequence of animated bitmaps that had to be drawn with color keying. The problem here was that we had to remove the unwanted color key pixels. The simple inner loop looked like this:


@@line_loop:
	mov 	eax,[esi]
	cmp	eax,color_key 			;usually black
	jz	@@do_not_draw_this

	mov	[edi],eax

@@do_not_draw_this

	add	esi,4
	add	edi,4
	dec	ecx
	jnz	@@line_loop

We have asked ourselfes what can we do to speed up this routine at the expenses of complicating things a little.

There are some problems in this simple algorithm:

1)The compare for color key made at every pixel
2)We had to read every pixel from the original image even if we would NOT draw it on screen
3)The image stored contains unused color_key pixels and is bigger that needed

Please note that this discussion is valid ONLY IF the image has some gaps in it, this is true for games sprites. And guess what? It is also true for most icons and mouse cursors.

Continouse rectangular images will not benefit from this format at all.

Compiled Sprites

Our test shows that the greatest speed increase in sprites drawing would be obtained if we used compiled sprites. In HE compiled sprites showed an astonishing 10x speed increase. Unfortunately compiled sprites also use up 8x more space in RAM since they contain some code sequence for every pixel in the image. For some simple and small images this could work, but in HE we also needed alpha blended sprites and cloaked sprites and other effects and this would mean duplicating the per pixel code for each effect. So we needed another solution.

The solution

For avoiding the compare at every pixel we did stored only the relevant pixels for each sprite. This needs some additional information like where a sequence of pixel starts and how many pixels it contains. We soon realized that there are actually "formations" of pixels inside a line. Again whole lines may be absent from the image so we also needed information about where each line will start. Since we used animations a lot we also added the info needed to store a sequence of images inside a single "sprite" We did named his format ".PZE" as an abreviation for romaian word "poze" that actually means "pictures". Out tests showed speed increase of 2x up to 4x using this format.

PZE Format description

General description

A sprite is formed by a sequence of images

Each image is formed by a sequence of lines. Lines starts at a certaing Y offset from image start.

Each line is formed by a numer of pixel "formations".

Each formation starts at a ceratin X offset from previous formation and contains an DX number of pixels. Since formations contain only non color key pixels no compare test is done or needed when drawing. Also this adds some level of compression by removing the not needed pixels in the image. To our great surprise this "compression" turns out to be important for the sprite size not for speed only.

Detailed description

True Color Format


File_Size		dd	?

Image_Pointers		dd	IMAGES_NR dup(?)

[...]

Lines_Count		dd	?

Line_Y			dd	?

Formations_Count	dd	?

Formation_X		dd	?
Pixel_Count		dd	?
Pixels			db	3*Pixel_Count dup(?) ; color format is RGB 8:8:8
[...]