pouët.net

Go to bottom

Supersprites

category: general [glöplog]
 
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?
added on the 2008-12-13 10:11:32 by texel texel
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).



added on the 2008-12-13 10:33:29 by earx earx
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 :)
added on the 2008-12-13 10:44:15 by jmagic jmagic
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.
added on the 2008-12-13 10:53:28 by cruzer cruzer
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.
added on the 2008-12-13 10:55:08 by texel texel
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)
added on the 2008-12-13 13:12:39 by Tigrou Tigrou
i think it is also called "compiled sprites".
added on the 2008-12-13 13:25:25 by rac rac
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...
added on the 2008-12-13 13:34:36 by texel texel
Oh, well... also I suppose the AND/OR was much better if the graphic mode was not byte by byte as mode13h in pcs...
added on the 2008-12-13 13:36:19 by texel texel
yes, there is another way.. RLE sprites (like in wolf/doom). nice for chunky layouts
added on the 2008-12-13 13:40:59 by earx earx
clipping with RLE can be a bitch, tho (like with code table sprite routs)..
added on the 2008-12-13 13:41:41 by earx earx
I used to code my sprites with if's when I didn't know it's done with masking :P
added on the 2008-12-13 17:35:32 by Optimus Optimus
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 :)
added on the 2008-12-13 18:07:33 by 216 216
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.
added on the 2008-12-13 18:12:55 by doomdoom doomdoom
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.
added on the 2008-12-13 18:24:11 by doomdoom doomdoom
Command Cyborg: Why to do software sprites on Amiga?
added on the 2008-12-13 18:26:32 by texel texel
I mean, Amiga have hardware sprites, isn't it!?
added on the 2008-12-13 18:26:54 by texel texel
Doom is talking about 256 colour chunky overlays in c2p amiga demos. Amiga sprites are limited in horizontal resolution and colour depth.
added on the 2008-12-13 18:46:56 by xeron xeron
BB Image

or

BB Image
added on the 2008-12-13 19:12:39 by bdk bdk
ITS UP TO YOU!
BB Image
added on the 2008-12-14 00:46:37 by Optimus Optimus

login

Go to top