fastest way to code an one pixel sinus scroller

[Antiriad_UK]

Originally Posted by ross

Gha... I've a déjà vu

Give up the goods, give it up, give it!!!!

[LaBodilsen]

Originally Posted by Antiriad_UK

Give up the goods, give it up, give it!!!!

He might be referring to this old thread :
https://eab.abime.net/showthread.php...ht=sine+scroll

[morbid]

So to summarize the methods from this and other threads:

- Copy slices
Photon has a nice write up here: http://www.coppershade.org/articles/..._of_the_Snake/

- Use line drawing
A write up can be found here: https://www.stashofcode.com/how-to-c...ll-on-amiga-3/

- Animated font
Example here: [ Show youtube player ]

- Plot pixels and do an XOR fill
Example here: [ Show youtube player ]

- Pre-generate an animation
Have not found an example of this, so maybe it is not feasible

- As posted by ross: https://eab.abime.net/showpost.php?p...1&postcount=10

- The method used by Photon: [ Show youtube player ]


Have I missed anything or did I get something wrong?

[Int42]

Thank you all for collecting the common methods to create this effect.

[Menthos]

Originally Posted by Antiriad_UK

The sine scroller from Sax Offender code is here:
https://github.com/jonathanbennett73...Offender/Miami

Isn't this a little risky as the add result could overflow the word size depending to where in memory the screen buffer is found?

add.w (a0,d6.w),a5 ;add sine 1 (premult)
add.w (a0,d7.w),a5 ;add sine 2 (premult)

[phx]

When operating on address registers the word-operand is always 32-bit sign extended first.

[Menthos]

Originally Posted by phx

When operating on address registers the word-operand is always 32-bit sign extended first.

Ok. Good to know. Thanks!

[ross]

Originally Posted by Antiriad_UK

Give up the goods, give it up, give it!!!!

I have no idea if what Photon actually calls "C2P-shift type sine scroller" is similar to what I did (I haven't found a detailed explanation).
My blitter mask constantly adapts to the curvature of the wave, so at different slope I have different slices (precisely for this reason in the old thread I was unable to indicate exactly how many blittings I do each column of 16 pixels; it seemed to me that in Photon's code it constantly does 4 blits/columns but I've not dissected the demo so I could be totally wrong!).

But I don't see it as a C2P algorithm, instead as a "sliced binary deferred summation".
It is no coincidence that it uses the same minterm of blitter MFM encoding and it is in effect a multi-masked blitter feedback effect.
(yes, I'm using strange words on purpose , I would like to use that routine sooner or later, and explain it well)
And I'm sure someone else thought it before me.. maybe only a little different.

[REMOVED]

Version with huge sine. Of course in the 'live' version it is silk fluid.
As you can see there is not much time left in the frame (don't look at the garbage and the fact that there is no double buffering and scrolling )

it is probably more suitable for many medium height scrolls, where you can use other kinds of tricks.

Looking at it, Photon is right when he says that in his demo it is close to the available physical bandwidth limit.
But perhaps I could beat him, even if only slightly

[Jobbo]

Ross, I don't really follow what you are saying.

Would be curious to see the code or an executable to fiddle with.

Never the less it seems like it'd be possible to reduce the number of blits by noticing that shallow angle 16pixel chunks only need as many blits as they have vertical steps. You could even mask the left and right side for the peak or base of a hump.

And then it also seems pretty likely that you can just apply blits iteratively so you're just making incremental changes to the existing buffer.

Anyway not sure what you're doing or what Photon did, but it looks like fun!

[Jobbo]

With the incremental approach it seems like you could just run a wave of 16 or maybe 8 pixel wide blits through there if that makes sense.

You could do the even columns first with no need to combine with the background. Then the odd columns second, combining with the even columns.

Not sure if that makes senses, it's all hard to describe but seems like something along these lines would work.

[ross]

Joboo, what you're saying might work.
But it is probably slower than the "deferred summation" method
(I don't know what to call it! but in practice this is what happens if you use the blitter in 'feedback mode' on the same column at different 'heights').

EDIT: https://eab.abime.net/showpost.php?p...4&postcount=20
Probably at the time I had done a precise count and with that wave I had an average of 3 blits each 16px column, which is not bad at all!
Obviously, if the slope changes, the average of the blits done changes
(however my routine supports a maximum of 4 per column which guarantees me a maximum slope of 45 degrees, in a block of 16x16).

EDIT2: damn I couldn't resist, you have a PM

[Jobbo]

I think that is starting to make sense.

"Feedback" is sort of what I meant by "incremental".

I'm still fuzzy on how you are applying it, but maybe one day I'll have a go.

[ross]

Originally Posted by Jobbo

"Feedback" is sort of what I meant by "incremental".

Yep.

I'm still fuzzy on how you are applying it, but maybe one day I'll have a go.

I'm applying a "deferred summation", just because I don't have a name for the method, but I think it's called that way

[DanScott]

I have no idea what's going on there Ross!! But looks great!!!

So i know you can do less blits (only need 1 pixel blits where the slope of the sine needs it).. but can't work out what else you're doing Is the source image just a regular linear bitmap ? or is there some jiggery pokery going on with the source image too ?

[ross]

Originally Posted by DanScott

I have no idea what's going on there Ross!! But looks great!!!

So i know you can do less blits (only need 1 pixel blits where the slope of the sine needs it).. but can't work out what else you're doing Is the source image just a regular linear bitmap ? or is there some jiggery pokery going on with the source image too ?

Absolutely linear:

	move.w	d1,bltamod-2(a6)
	move.w	d1,bltbmod-2(a6)
	move.w	d1,bltdmod-2(a6)

;a6=$dff002

I don't touch the module throughout the main routine and work column by column (16px*height, with a variable number of blits, from 1 to 4, usually 2+).

[ross]

Aaahh, now i know why Photon call it C2P! Basically what I do to calculate the mask applied to the column to select the slice is similar to what a C2P routine do.

But I don't think this is enough to define it a "C2P-shift type sine scroller", the basic concept is different and that is just a pre-calculation method.
But in fact with the names I gave to the routines I certainly can't blame him

This however means that the two routines are similar.

[DanScott]

I had a look at the code snippet you posted before... the "odd" minterms using C channel, and the BLTCDAT being set to a mask will need to think about this some more... because right now I still have no idea

[a/b]

Is this incremental, like you lower/raise the whole 16-pix column (or 2 halves, as you can use d=a+b) and then adjust individual columns or groups of columns up/down by 1 row from the previous frame, as needed?
I did a 3D bitmap rotation around y axis in a similar way. Basically, I precalculated delta blits needed to morph a frame into the next one, and then merged individual colums that needed shifting for the same amount horizontally, as long as they had the same height (3D perspective stretch/shrink), into groups that were then processed as a single blit. And then blitted in new colums that had a different height.
So a bunch of blit masks...

[Jobbo]

a/b

Where can I see that effect, it sounds awesome!!!

I always loved those rare rotation effects like in Brian the Lion that used an iterative vertical skew.

Actually, yours sounds like the rotating skull in Sanity Interference.

[a/b]

Not to derail this thread... Coming (not so ) soon (TM) when I finally finish my trackmo. It looks ok, it's just a transitional effect. Yeah, you could compare it to the skull in Interference. But I'm using it as a "64x200 sliding window" on 320x200 picture while preparing something else in the background. And I'm also doing vertical scaling of parts of the picture in real-time because there wouldn't be enough room to prescale the whole picture. So while it's pretty optimized (50 fps and it only does ~8% of blits that a copy 1 by 1 approach would do) there's still enough room do to other stuff, it's not a main effect.