pouët.net

I've just remember - I don't know why - the term "supersprites". It is a very very oldschool thing, probably from the time of 286s.

It was for software sprites, instead of using the common mask with AND and paint with OR method, the sprite was painted directly, pixel by pixel from the code. The movs contained the color information directly. Afaik, it was faster in old days computers, I think from 386 and up it was slower...

The thing is that I've been trying to find information about it, but I've found nothing about it. Do you know if there is any other name for that? Do you know games/demos where it was used?

sounds like the code table sprites on ST. it depends primarily on how big the gaps are in the sprite. depending on this you can gain a lot. also, it depends on your screen layout. on VGA you have 8 bpp mode whereas, which sounds easy enough (i hope you don't need 'port' instructions, tho). on Amiga / ST it's bitplane mode (in this case you need at least 16 empty sprite pixels in a row for a speedup).

another factor would be if the generated / custom-made code will fit in instruction cache. this could be a limiting factor on 486 (or 386 w cache).

never heard the term, but the technique was widely used. T

here's also an issue with dword writes and aligns, if you were drawing directly to screen memory, byte-by-byte writing was not that great idea. But to get dword writes and smooth movement for sprites, you had to create 4 different versions (I wrote a routine which generated the code in runtime). And you still had to have a regular sprite drawing routine for clipping :)

Sounds like how we do software sprites (bobs) on C64. It's definitely faster, but uses a lot of memory, since you typically also need specialized routines for different starting points.

jmagic: I never did clipping... I just used an smaller screen resolution and deleted the borders - borders in the size of a sprite-1 pixels.

can someone describe the trick with OR and AND painting ?
whats the advantage? dont need to repaint background? (like selection on WINDOWS which is done by xoring the stuff)

i think it is also called "compiled sprites".

Tigrou: http://en.wikipedia.org/wiki/Mask_(computing)#Image_masks

Tigrou: I don't know if there is any other way to do sprites than the compiled and the and/or one. About the and/or, the good thing is that you don't need ifs. It is the same as alpha transparency, the AND is a multiplication and the OR is the same as the sum, but I believe the OR was faster than a sum in old computers. The AND might be faster nowadays... but I suppose there is little need for dicothomic alpha by the current standars...

Oh, well... also I suppose the AND/OR was much better if the graphic mode was not byte by byte as mode13h in pcs...

yes, there is another way.. RLE sprites (like in wolf/doom). nice for chunky layouts

clipping with RLE can be a bitch, tho (like with code table sprite routs)..

I used to code my sprites with if's when I didn't know it's done with masking :P

I think what you describe is usually called compiled sprites. As jmagic says they are a bit problematic on 486+, but they don't make even that much sense on a 80286.

First, a real 286 is likely to have an EGA (later 386-era 286's are fakes combining elements from different times:). Bye bye chunks. With planes you likely need that anding and oring stuff.
Second, with 8-bit io it makes sense to use the graphics controller. Poke it right and it moves stuff around simultaneously in all 4 planes, at the same time anding/oring it with your value of choice. Since the data needs to come from the display memory you can't really compile it into code.

Of course you can try some really sick hybrid technique. Post me the results when you get them :)

Using masks: 3 reads, 1 AND, 1 OR, 1 write, 3 incs, several pixels can be done at once depending on CPU register size (although extra overhead for odd widths and memory alignment and such, clipping is harder)
Using ifs and 0 as transparent colour: 1 read, 1 conditional branch, 0-1 writes, 2 incs, only one pixel at a time (clipping always straightforward)
"Compiled sprites": 1 write per pixel (or less), 1 inc (or less), but worst possible use of instruction and data caches, clipping is very complicated, harder to inline

All three can use RLE, and the first two can be unrolled. In many cases clipping large sprites against one another is worthwhile if it reduces overdraw. What works best depends completely on the platform and the number and size of the sprites.

For chunky Amiga (8-bit) stuff I've preferred a format that stores four copies of the image (shifted 0, 1, 2 and 3 bytes, respectively), divides the sprite into transparent regions (skipped RLE style), opaque regions that are simply copied, and regions that contain both transparent and opaque pixels. It works quite well.

Command Cyborg: Why to do software sprites on Amiga?

I mean, Amiga have hardware sprites, isn't it!?

Doom is talking about 256 colour chunky overlays in c2p amiga demos. Amiga sprites are limited in horizontal resolution and colour depth.

or

ITS UP TO YOU!