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 folowing article tries to describe this format.
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.
This image format is Copyright 2000,2007 by Bogdan Ontanu and Eugen Brasoveanu, All right are reserved.
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_loopWe have asked ourselfes what can we do to speed up this routine at the expenses of complicating things a little.
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.
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.
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.
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 [...]