A89: Re: Re: Sprite Formats
[Prev][Next][Index][Thread]
A89: Re: Re: Sprite Formats
Hi Niklas!
Thanks for the information. This will a really flexible editor, then.
| The "sprites" on the calcs are nothing more than bit patterns representing
the
| raw graphics (and possibly the mask) of the figures in them... afaik there
is no
| standard format. Some use a fixed size (8x8, 16x16), others use dynamic
sizes
| (and data that tells how big the sprite is). Some put the graphics
separate from
| the mask, others put them in two or more blocks following each other. Some
| separate the greyscale planes of the gfx, others interleave them, and some
even
| interleave the mask with the gfx.
Yeah, I know. The only thing is whether the most significant bit is left or
right. But with a scripting language, this wouldn't be a problem.
| My own favourite (because I currently use it) is a fixed-width,
variable-height
| interleaved sprite:
|
| typedef struct {
| int Height,HotspotX,HotspotY;
| WORD data[0];
| } SPRITE_DATA;
|
| ...or in asm:
| mysprite:
| dc.w height, hotspotX, hotspotY
| dc.w row0_mask, row0_plane0, row0_plane1
| dc.w row1_mask, row1_plane0, row1_plane1
| ... etc.
OK, I'll put that in.
| The most *common* one would probably be formats used by the sprite
functions in
| DoorsOS and compatibles, since they are directly available, finished and
| documented (I think - never used them myself).
I know about the C formats available, but I don't know anything about ASM.
The user would have to do that himself.
| The coolest would be if you could make a simple script language to
describe the
| sprite data format, making it very dynamic.
That's a great idea! That's exactly what I'll do.
| As for graphic file formats, a very quick look in altavista gave me this
(going
| through the tree is so much easier than blindly searching when you know
exactly
| what you're looking for):
| http://www.dcs.ed.ac.uk/home/mxr/gfx/
Thanks a lot! I didn't think about looking it up on the internet.
Bye,
Sebastian Reichelt
References: