A.D.A. Amiga Demoscene Archive

Hi,
Does anyone know if the Shadebob demos of old (A500 day) were done using the blitter or the CPU? I can see how to do them easily (albeit slowly) with the CPU as they are essentially additive. However, I cannot think of a way of combining blitter operations to get the same effect though i believe its possible.

Thanks

I never did this effect but funnily enough thought about this not so long ago. I think on A500 you would use 6 bitplanes. Anyway to draw 1 shadebob you start with the top bitplane and you use your bob mask data to copy the area on the bitplane below it to the bitplane above it. Then repeat this for each bitplane. When you get to the first bitplane you can just draw your bob mask in.

So the first time you plot a shade bob you would get just the 1 bitplane bob mask. Then the blitter sucks up the data through the bitplanes as you go round the screen. So it's like a blitter hoover ;0) Once you have hit the maximum colour you really want it to set to zero the next time round though.

Am I right anyone was this how it was done ?

I've never done shadebobs, but here comes my theory about how it's done. I think you would use the blitter since addition can be simplified using logic.

For one bit addition using operands A and B with carry in C it looks like this:
RESULT = A'BC + A'BC' + A'B'C + ABC
CARRY OUT = ABC' + AB'C + A'BC + ABC

It's possible to simplify these expression but the blitter doesn't really care about that =) Also you could save cycles on the first bitplane by assuming carry in equal to zero and using only two data sources.

Hi,
That would work but if the bob wasn't moving you would only get 6 frames between black and full colour (0,1,3,7,15,31). I was wondering if there was a way of incrementing the pixel colour. With CPU code this would be a case of getting a colour value by bit masking and combining all planes, then incrementing, then masking and writing back out to planes. It could be sped up somewhat given the bob is only 16/16 but it would be nice to find a way of doing this with the blitter.

Maybe the demos worked as you guessed - after all the bobs were never stationary! :)

Edit: Ignore this post.

Hi Dalton,
Could you elaborate a little on your method - what would you have in each channel - how many blitter operations/passes would you need? My blitter knowledge is a bit rusty - my interest has only been rekindled last week or so and its been about 12 years since I coded stuff on Amiga. :)

Thanks

well.. it's probably a bit of a hassle to get this to work. But the idea is that you start with the lower bitplane and "blit your way up" saving the carry between planes to get proper addition.

The letter notation (ABC) I used above is actually the same as the one commodore uses in blitter documentation (what a coincidense!).

You'll need to use one (or maybe) two "carry buffers" the size of your bob.

You'll need two passes for each bitplane and you'll need all blitter channels for all passes.. but you should be able to blit a descent number of bobs even on a500.

Thanks Dalton, what I meant was what would you have in each source channel for each of the two passes? A=Mask B=bitplane C=?

C would be the carry from lower bitplane (earlier pass)

Thanks, to divert a little from the posts title :) Could I ask a question regarding filled vector optimization from the same era as Shade Bobs? I used to be into demos at around the time when A500's ruled and Crionics were top - way before C2P. At that time folks had only just started making blitter filled convex vector graphics at 50hz. For some reason the Crionics could render bigger objects with way more faces than anyone else and still run at 50hz. Do you have any idea what tricks they pulled? I assume they did.

Precalc rotations? Not checking blitter waits? Or something more elaborate.

begin off-topic

@retrocoder: welcome (back) :o) Any particular reason why you refound interest in coding after 12 years? Did you code demos at that time? Would be fab if you picked up coding again and release something!

In any case, ask all questions here in the forums. There are some mighty skilled coders lurking about.

end off-topic

I did not read the entire thread ;)

But this just came to my mind: One could not use normal addition, but some galois field operations. For example a simple 1 tap lfsr can be done mostly with two source and one target and would still cycle through all colors. You would just have to resort the color table. Doing normal adds would require three sources and almost twice the number of passes..

Ok, translation:

You need one blitter pass with two sources for most bitplanes and one with three sources for one bitplane => 50% blittertime saved.

'@retrocoder: welcome (back) :o) Any particular reason why you refound interest in coding after 12 years? Did you code demos at that time? Would be fab if you picked up coding again and release something! '

Hi, I guess I never really lost interest but moved into game coding where i've been ever since. I've always had fond memories of coding demos and games on my dusty A500 which is got me into this career in the first place. At the time I left the scene I knew how to do all the current effects with the exception of shadebobs and confusion over how Crionics vector routines were so darn fast. Those questions have always been in my mind and finding this forum was great.
I would love to knock up a demo in my spare time but don't have an A500 any more ( shock horror! :) ). Do any of you guys code with devpac via UAE (which i've never used)? If so is Devpac easy to locate and how accurate is the emulation? Even after this long I still remember K-Seka is not an option i'd ever follow! ;o)

I guess, shadebobs were relatively easy with blitter. It was just setting up a correct palette, then just blit the bobs on each bitplane, but each bob should go to a different bitplane. If the palette is well suited, it should look like an additive effect.
What I mean is, that if you put bobs on each plane, they should be the same colour. if two bobs overlap, any bitplane with any, then it's the next colour, and so on.

I think this is just a matter of a tricky palette.

Since it's just a wild guess, I think I'll have to test it :)

You need to do the blitter-addition thing if you want more than 5-6 bobs to be able to overlap each other. Also, the blitter-addition thing allows you to have a long 'trail' of bobs by waiting a couple of frames before you erase (= subtract) the old bob.

@Azure: I had never heard of an lfsr before, is it really that simple? how would you select the tap? is the process reversable?

azure: Interesting concept. That should work quite well!

dalton: http://homepage.mac.com/afj/lfsr.html describes LFSRs.
LFSRs are shift registers with a well-designed feedback operation that make the pattern inside the shift register cycle through all possible states (except 0) until the starting state is reached again.
(so a 4-bit LFSR will go through 15 different states until it repeats)

You can find a 'reverse' LFSR through a magic permutation (look further down along the page) so yes, subtraction is possible as well.

The final code could be something like this for a 4-bit LFSR shadebob implementation:
1) backup the contents of bpl3 beneath the sprite
2) copy the contents of bpl2 to bpl3, masked against the sprite
3) copy the contents of bpl1 to bpl2, masked against the sprite
4) copy the contents of bpl0 to bpl1, masked against the sprite
5) copy the contents of backup to bpl0, masked against the sprite
6) XOR the contents of bpl1 to bpl0, masked against the sprite

(here you end up with 3 sources in all blits except the first, and N bitplanes takes N+2 blits. Perhaps someone else can trim off a few plane operations?)

I wonder if Dweezil was doing something like this in Darkroom...? :)

Some more optimization:

When you use interleaved bitplanes you can save some blitterstarts.

If the shape is small or not very complex and it be manually written to the dma input register, requiring fewer dma channels.

Here is how you do it with two blitterstarts:

Use interleaved bitmaps + 1 dummy bitmap.

1) shift all bitplanes up (bpl0->1, 1->2,... n->dummy)
2) dummy xor bpl1 -> bpl0

Do this either with an additional source for the shape or by loading dma reg manually.

Makes me almost want to dig out my a500 ;) I wonder whether this has already been done before?

What is a blitter start? I'm not familiar with that terminology.

I had a think about this over the weekend and addition seems pretty straight forward using two blits per plane. 3 bitplane example:

p1c(carry) = p1&Mask
p1 = !p1&Mask
p2c = p2&p1c
p2 = p2&!p2c : !p2&p2c
p3c = p3&p2c
p3 = p3&!p3c : !p3&p3c

& = and, : = or, ! = not

blitter start == starting the blitter. By arranging the data properly Azure was able to make one single blit which would do the bitplane-shifting for all planes in a long go (assuming that the shifting operation is to be performed over the entire screen). This would not reduce the amount of blitter work, but would cut down on the number of CPU interrupts (if the blitter is being fed by the CPU through a blit-queue).

I've done a lot of blitter-addition stuff. And yes, it's easy, two passes per bitplane (though 1 for the highest), 3 sources per blit (except 2 for the first two). I wonder why this wasn't used more in OCS demos, for lensflares etc. I mean, shadebobs are ugly no matter what. If they'd only tried clearing the screen between frames.

If anyone's interested I can dig up some copper managed blitter add code tonight. IIRC it can do about 40 4-bpl addbobs in one frame. Or maybe I just made those numbers up. We'll see.

Hi Kalms,
Shifting the bit planes up wouldn't work (unless i'm missing something) e.g:

BPL 0 1 2 3 4
0 0 0 1 0 colour 8

would become:
0 0 0 0 1 colour 16

Doom, i'd love to see the code. :)

retrocoder, you have to scramble the order of the colors in the palette.

This sequence will be generated for 4bpl if you are using the shift/feedback function me & azure are describing above, and starting with 0 0 0 1 in the bitplanes:

BPL 3 2 1 0

0 0 0 1
0 0 1 1
0 1 1 1
1 1 1 1
1 1 1 0
1 1 0 1
1 0 1 0
0 1 0 1
1 0 1 1
0 1 1 0
1 1 0 0
1 0 0 1
0 0 1 0
0 1 0 0
1 0 0 0
0 0 0 1 (the cycle repeats here)

and thus you should assign a gradient to the palette colors, ordered like the above list. Also notice that color 0 is not included in the sequence.

Gotcha - missed the scrambling part. Interesting approach. :)

http://doom.untergrund.net/lightbobs.s

And! I just noticed that the routine is old, ugly and horribly coded. :D But it does work. It does saturated addition of a 3-bpl bob to a 3-bpl picture, with a bit in the 4th bitplane representing a fully saturated pixel. Ie. cols 8-15 should all be the same as col 7.

I haven't considered if interleaved bitplanes could help somehow, they probably could.

I should note that the CPU is totally freed up this way, it doesn't even get interrupted by blitter-finished. So you can use it for something cool like clearing one of the off-screen buffers. ;)

http://doom.untergrund.net/amiga/oldintroshit.amig aexe <- some veeery old discarded intro using the routine

http://doom.untergrund.net/amiga/twister.amigaexe <- a very old discarded twister effect, also with some lightbobs on top of it

Not really wanting to test it, they should both run oneframe on an A500.

That is really cool - thanks Doom.

I never thought of initiating blitter operations from a copper list. How does the blitter wait work with the copper?