Copper swing effect

[LeCaravage]

Hi,

Amiga 500 OCS/ECS KS1.3 512/512Ko. Non sytem programming.

Been struggling on a copper effect. The effect constists of vertical copper bars using 2 colors changes all along the line.

This is the closest effect I'd like to reach :



And this what I get :



At each line I use a wait copper instruction + $dff102 delay + several moves for colors changes ($dff184 and $dff186).

The WAIT x position is changed in sinus wave each line + $102 changed accordingly.


I use 2 bitplans and they look like these :

First bpl pattern (44 bytes large) : $ff00,$ff00,$ff00...

Second bpl pattern (44 bytes large) : $ffff,$ffff,$ffff,....

Any hint ? It supposed to be a very easy effect to code in therory, but I'm starting to go blank.

[DanScott]

seems you need to wait 8 pixels earlier, that's all

[LeCaravage]

@Dan : You answer so fast, pretty sure this kind of effect was already coded a lot of time in Anarchy

More seriously, I'm using a 1 pixel sin table (-44,44) range, and I convert it to a WAIT abscissa (-11,11) by ASR.B #2 . May be it's there the pb. And also I make a OR.B #1 at second byte of copper instruction so the copper knows it's a WAIT and not a MOVE.

[LeCaravage]

Well, it's not so easy in fact. I did a fast test, with the bitplan pattern I displayed upper and a fixed X WAIT there's not a lot of fitting $102 positions.
I'm not even sure I'd not have to set one of the $102 (odd planes) fixed to 0 all along lines.
So my method is all wrong I guess, need to rework it.
Before entering in this dark room and switching light on, I didn't expect to find this.

[a/b]

Not sure what the problem is, I couldn't entirely understand your explanation. In any case, the effect in the first picture looks like this to me:
1. bitmap with only one bitplane, used as a static mask (e.g. $ffff,0,0,0,...,$ffff, so the first&last word is set and the rest is transparent), with color1 ($182) set to 0 to hide the plasma edges
2. copper list, for example:
wait $40/$51, $180 color, $180 color, ... $180 0
wait $41/$51, $180 color, $180 color, ... $180 0
...
wait $c0/$51, $180 color, $180 color, ... $180 0
Then you modify $51 (horizontal wait position) in each line based on a sine or some other curve, and the bitplane mask takes care of the first&last few pixels, so both left&right edge are straight lines.

[defor]

Originally Posted by a/b

Not sure what the problem is, I couldn't entirely understand your explanation. In any case, the effect in the first picture looks like this to me: ..........

It's a long time since I've programmed anything like that.... So ignore my comment if totally wrong.
Isn't Copper's horizontal position in fact an index of the DMA slot? Two pixels are drawn per a DMA slot. So even in the best scenario, one could not move just one pixel horizontally. I see that the sinus pattern on the first image has the one pixel difference. So I don't think it's done the way you described.
P.S.: I see that only 16 (or so) colors are unique per line. My guess is the trick is in pre-computed image (one line only in fact) of 16 bars which is hscrolled (BPLCON1) per line and COLORxy registers are modified in the borders (or even earlier when image is displayed, racing the beam).

[LeCaravage]

Sorry, I read again my upper posts and it's not clear. I'd like to have columns of copper colors moving in horizontal 1 pixel precision, so I could simulate a horizontal "wavy" swing effect for each line. The effect the closest is this one : [ Show youtube player ]


This coding pb makes me think (in a far less complex way) of this demo effect, ie combination and synchronisation with x wait(y,x) and bitplan $102 delay :

Here's a sample dump of my copper tests. The delays of $102 are not follinwg a sinus curve but linear progression, $102.B=+$11 at each line for test purpose only (->hence the diagonals).

line #0
5031fffe 01020000 01840000 01860000 01840000 01860000 01840000 01860000 etc...until end of bitmap line.
line #
5131fffe 01020011 01840000 01860000 01840000 01860000 01840000 01860000 etc...until end of bitmap line.
line #
5231fffe 01020022 01840000 01860000 01840000 01860000 01840000 01860000 etc...until end of bitmap line.
line #
5331fffe 01020033 01840000 01860000 01840000 01860000 01840000 01860000 etc...until end of bitmap line.

etc...
As you can see, there's not a lot of positions where X WAIT(y,x) and $102 values are perfectly synchronised.


@a/b : If I understand your method, this will not allow pixel precise movement ?

@defor : "So even in the best scenario, one could not move just one pixel horizontally."
You could if you add copper instruction $010200xx and 1 or 2 (or more ?) bitplans at each line.


This is the result for :

bpl#0 pattern as $ffff,$0000
bpl#1 pattern as $ffff,$ffff

bpl#0 pattern as $ff00,$ff00
bpl#1 pattern as $ffff,$ffff

[LeCaravage]

Ok, may be I understand. May be...

In fact there's half of $102 successive values which could fit one X WAIT position. So I need to move +2 or -2 X WAIT in certain values. The hardest now is to find these values. In other words, Dan was right but I didn't understand what he meant.
I hope I'm right, because I'm almost at the end of the road.

[paraj]

The BBS intro in the video is this one.

It runs in 3BPL dual play field mode (BPL2 can be ignored, it's used for the BBS name and number), BPL1/3 contain a regular pattern with (if I'm counting correctly) 16 pixel wide blocks resulting color 1, color 2, color 3, color 1, .... color 0 is used for the "border effect".

Then on each scanline it uses the copper to scroll PF1 and the changes the 3 colors as fast as possible.

[LeCaravage]

Mangage at last to make it. The cause was more a lack of understanding than a bug.
As stated it Dan at the beginning, it was a gap between WAIT and $102 delay.
Thanks @all for help.