pouët.net

Go to bottom

how does this twisty scroller work?

category: general [glöplog]
FWIW there was similar scrollers in the prods of the Atari group Holocaust, with gigantic letters flying across the whole screen and shit. It's a precalc party but who cares it looks cool and runs in 1 frame in fullscreen.
added on the 2010-11-22 16:46:09 by p01 p01
Some discussion about it in here too

http://flashtro.com/page.php?id=127
added on the 2010-11-22 16:47:20 by Serpent Serpent
yeah, but this thread doesn't answer more that what has been said here, ...
to me, all that is theorically too slow for an a500 - you just don't cpu on screen like that on a500, and mask-blitting for each displaced pixels is already too much blitting. I remain on my blitting-per-column idea, which makes sense to me ... anyway, the fact letters are defined on 6x5 bitmaps is the key to finding the trick.
... ah shit,
added on the 2010-11-22 16:55:42 by krabob krabob
hi gfbtm and krabob ;)

I also spent/wasted some time today figuring out the effect ;)

(most of the time reading old HW manuals since it's been 14 years since I last programmed on the miggy;))

the OR'd BOB theory is correct

if you d/l the intro from here, then run it on a 512k chip/512k fakefast kick1.3 a500, you might want to take a look at the following addresses:

4fdfc : VBI handler (calls effect code at 50422)

50550: effect loop: DMA setup
miniterm=FC (OR) (try 3C for XOR)
bltsize is 0x302 (fixed size for all blits, 32x12 pixels ?!)
505a0: main blit loop setup
the word at 514ae holds the number of "columns"
(~200, changing it to smaller values makes the scrolly shorter)
505b0: main blit loop (precalc'd blitter setup)
font is 5 cells high (another inner loop).
-a1 points to "texture" data (updated each frame),
a0+ points to precalc'd blitter setup.

51cc2: sound replay

=) really a nice wicked effect MMM did there ~20 years ago =)
added on the 2010-11-22 19:27:37 by xyz xyz
oO
Ace and fast crack ! Never been so much in monitoring other's code, but the data makes sense.

yeah, one little blit per "letter pixel" of course, I was wrong with my blit-per-column theory, It would have taken 32 screens, so 256kb and a lot more memory for the masks. And I skipped the fact that you (of course) do nothing for the letters "hole".

... amiga blitter ... !!!, I'm pretty sure we could still invent a lot of never-been-done effect with that. So bad I started coding in 1996, I had my attention on copperlists and 68030 thingies at the time. I'm frustrated to not have played much with that part :(
added on the 2010-11-22 20:08:58 by krabob krabob
nice.. still, ~1000 bobs, even if they're small, sounds like a lot..

what you call "texture data" is the plain old horizontal scroller behind the scenes, I guess!?
the "texture data" is one byte for each glyph column. only the lower 5 bits are used and the innermost loop tests each bit and blits a prerendered bob if it is set, or skips on to the next "texel" if the bit is cleared.
so yes, 1000 bobs maximum but at lot less in practice because of spaces/transparent texels. it was really fun disassembling this thing :)

I think I also saw a copper list that did some x/y wobbling (fgcolor+scroll register+modulo reg. writes per scanline) but I do not think that is used all the time / on all screens.
added on the 2010-11-22 21:51:23 by xyz xyz
and the bobs can't move => faster than regular bobs
added on the 2010-11-22 22:35:18 by cruzer cruzer
@cruzer: as in shifting is not needed and therefore your bobs can be 16 pixels narrower? (if i remember the inner workings of the blitter correctly - it's been over 10 years since i coded amiga hardware regularly).

login

Go to top