pouët.net

hi sceners,

can anybody tell me what the principle behind the twisty scroller in this intro is?
it seems to me that you would be out of cycles if you had to map/plot it pixel by pixel using the cpu..

thanks

The principle? It's mathematics actuially ;-)

texture distortion?

It's probably "bobbified", i.e. the position if each cell in the scroller is precalculated, and then there's a dedicated bob routine to plot it, which can be quite fast since the position is static. For some of the effects there's a bit of hardware FPP or what they call it on Amiga to add some waving.

What cruzer wrote. I find it helps looking at the scroller data as a texture, mapped statically texel by texel to the screen. Then the data is simply scrolled normally within the texture, while the texel-to-screen mapping is handled separately (preferably unrolled).

EOR scroller: As cruzer said, the position of each "cell" is precalc'ed, you only need to plot a few in EOR per frame to get the characters scrolling along the path of precalc'ed cells.

Yes, excatly as Cruzer, and p01 says. But i am quite sure that the "EOR" is "bobbified" (1bpl bobs) as Cruzer says, and their datasources are their predrawn "polys" for each text-cell.
This effect is a combination of "circleplot" and bobs.. Hey I am almost getting sentimenal by this now.. those memories :)

iow. one big lookup-table.

The good ol' sayin':
Precalc as much as you can :D

on a sidenote: the music in this cracktro is just wonderful and reminds me ALOT of the jazz jackrabbit soundtrack.. :)

EOR = ? Not familiar with that term...

trixter: eor == xor (Excusive OR)

it's also the sound a donkey makes, which I'd like to think is what p01 was saying.

Nice scroller too.

It's just a youtube video, dummy.

ok.. so each cell/texel shape and position is precalculated, and for each time you scroll, you update them (possibly using unrolled generated code).. using the eor idea, you eor using a mask that only affects the cell/texel you're updating and leaves neighbouring pixels alone? which also has the effect, that the eor toggles the cell on/off for each update, so you can skip the cells that don't need updating during the current frame (and you also don't need a "clear whole frame" sweep by the cpu or blitter).

yep.

oO yeah one thing is sure, that's killer blittering. These kinds of scrolls effects usually are verticals and just need some copper's palette changing. I'm Completely digging that cracktro and this thread ! I'm not sure to understand 100% actually,
1 pixel of the scroll original bitmap correspond to some mask once deformed ?

... but cpu eor'ing the video memory ( the only memory available) on a500 usually gives shitty low results, even for one plane. not mentioning this technique would touch the same bytes many times , lowering the bus uselessly.
There must be more evil blliter use behind this, ... I can sense it.

There's a similar effect in this c64 demo. Smaller but still oneframed. So with the Amiga having 7 times the clockspeed, a 16/32 bits CPU and a blitter, it should be doable.

But I don't think I would xor the "bobs". The Amiga's bitplanes makes it possible to avoid having adjecant bobs in the same bytes, so both setting and clearing a bob could be done by pure storing.

cruzer said:

I think this is more like it: massive blitter, no cpu, and erasing the whole thing, no delta-with-previous frame. ( blitter use ->double/triple buffer implied -> modifying previous frame is prohibed) ... or what the fuck, it may be a paleo-c2p.
... got to read the amiga blitter's specs ...

oops didn't read previous post

... can't help thinking about it... Here is another theory: It could simply have been done using usual blitter polygon filling: drawing letter horizontal borders, then filling with the horizontal stop/continue filling... But the W in the text looks bitmap-defined, so must not be that ( but it is not a bad idea )

I was by mistake quoting the word "EOR"... ofcourse the blitter "OR"' s the bobs together.
This scroll is generated as a long vector-band made by small polys(squares) rotated/bended. And that "vector-routine" precalc eac poly's position and its polygon-image, which is blitted on as a 16x16 bob. Then the scroll-lookup decides which ones to draw or not.

HOHOHO SHIt SHIT SHIT

!!!!!!!!!!!!!!!
!sq
*fdsq
r
dqbdqbd


III got it !!! DON'T MOVE DON'T MOVE DON'T MOVE DON'T MOVE DON'T MOVE !!

-> Each letter is defined with only 5 pixels height !!! and they are 0 or 1 so when you look at a "vertical column of pixel", you can only have 32 different values !
BINGO: you just have to define 32 different image of the whole text tunnel, AND JUST DO THE BOB BLITTING PER FUCKING COLUMMMNNZZZ!!!


f,kqfd,nlqdlk,qdmld ! ! ! !! ! ! ! !
1111111111111111111111111111111111111111111111111 !

rlz

(plus , no blitting if column is zero, aka the space between letters)
I WANT MY CODE AWARD NOW ! GIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMMEGIMME !