Displayscroll

[Coagulus]

I'm trying to get my logo in JetHunt to weave like it does on the PC version. The Blit command after separating the logo into lines works but it's a little slow. I did try the scroll command but couldn't get it to do it right.

However there is DisplayScroll which is supposed to use the copper. This would be great if I could understand the manual entry.

Does anyone know how to use this command in Blitz?

Coagulus

[Cylon]

Try this, doesn't work with more bplanes, as far as i know; but, what do i know

obsolete.

[leathered]

Just fantastic mate! Rob and I had a quick bash at this last winter, figured out some basics with a rough example and AFAIK Rob got it working really sweet for his title screen. We never did get around to putting an example here though, and I'm sure your example will help in the future. If I'm not wrong this effect should be one of the means of getting that copper floor working in racing games and the scaling floor in one on one beat em ups.

[Coagulus]

Awesome, (I thought I'd replied ages ago!) I've used some of the code from Leathered and my own efforts to knock up an AGA "outrun" attached with source.

I wonder if there's a way of using displayscroll on just one playfield (of a dual playfield) though... otherwise everything on top has to be a hardware sprite...

[idrougge]

Originally Posted by Coagulus

I wonder if there's a way of using displayscroll on just one playfield (of a dual playfield) though... otherwise everything on top has to be a hardware sprite...

As usual, Blitz's documentation is to no help. According to an old Usenet post, DisplayScroll uses two arrays because one works with the odd bitplanes and one with the even ones. That should help your dual playfield endeavours, and might also explain why Cylon can't get it to work with more than one bitplane.

BTW: This thread should be moved to Blitz area…

[Retro1234]

I think I want to throw the manual out the window

[Cylon]

Finally got the time to nail the b*tch down.

I always knew there was a strange offset between the odd and the even planes, but never took the time to investigate further.
Well, until now.

I narrowed it down to <1> subpixel (hires pixel in lowres) i believe. The rest is up to the real coders.

First i tried to use the offset parameter in displayscroll cmd, this doesn't seem to work.
Then i constantly tried to get closer to the offset by using a very small step per line tracing downwards without the wobbling, of course.
Finally got the number 13 (well: 12.x to 13.x) as the offset for this very 8 colour bitmap. This offset can be placed anywhere, depending on the effects you want to create. Best is at (0) position in the even-array.

I hope this is usefull. Src below.
Remember: Cylon did it.

;display scroll adapted by cylon

DEFTYPE.w
BitMap1,320,256,3

LoadBitMap1,"face8.iff",1  ;3planes 8 cols

VWait50
BLITZ

BitMapOutput1    ;print onto bmap

Locate 2,28:Print "THIS IS AGA DISPLAYSCROLL"
Locate 2,30:Print "<<<<< Move Mouse >>>>>"
Use BitMap1

;For a=7To1 Step -1
;  b=1-b
;  Circlef160,128,10*a,10*a,b
;Next

InitCopList1,44,256,$10003,8,8,-$10

CreateDisplay1

DisplayBitMap1,1

DisplayPalette1,1

For y=0 To7                           ;debug colour boxes

  Boxf 0,y*16,7,y*16+15,y

  Locate2,y*2+0.5:Colour1:Print y

Next y

Dim xpo.q(256),xpe.q(256)

a=0
VWait150
Mouse On

tpi.q=2*Pi  ;precalc

xpe(0)=-13  ;offset for even planes start at ypos=0
;not quite accurate! sub-pixel fetch or what the hell....

While Joyb(0)=0

 For a=1 To 253
   d.q+Pi/18:If d>tpi Then d=0.0

   c.q=Sin(d)+(MouseX-160)/160

   xpo(a)=c

   xpe(a)=c  ;same as odd, but with offset

 Next
 VWait

 DisplayScroll1,&xpo(0),&xpe(0);,-13 offset does not work here?

 VWait
Wend

VWait25
QAMIGA
End

NoCli:CloseEd

You can create strange effects if you arrange your colour registers wisely. Like a counter-wobbling of odd/even bplanes.
Or, avoid all even planes in a pictures back but use only those even planes to scroll or wobble on top.

[Shatterhand]

Can someone help me with this command?

I understand I should do 2 arrays with the same size as the number of lines of my display, one for even bitplanes and the other one for odd bitplanes (great for dual playfield, yay!) Each value will be the difference in the horizontal position related to the previous line. This should make possible to make weave effects or "single layer" parallax scroll (the "fake" one achieved usually with raster effects instead of one layer on top of the other)

But

A) What is the offset? Why I get an "not enough copper space" error when its positive or zero, it shows something when it's -1 and just shows black screen with anything else?

B) Why when all the values on my array are 0 I get just garbage on screen?

I just can't understand how this works!

[Cobe]

As i remeber offset is 3. And add it to initcoplist. Not at the end of displayscroll command.
In case you would already have lets say for example some aga copper gradient than you would add 4 at the end of displayscroll command.
And displayscroll works better if its right after displaybitmap.

[E-Penguin]

After a bit of fiddling, the "magic bitplane offset" is exactly:

xpe(0)=-13 + 0.00788

At least, on an A1200 and A500 under winuae!

[Shatterhand]

Originally Posted by Cobe

As i remeber offset is 3. And add it to initcoplist. Not at the end of displayscroll command.
In case you would already have lets say for example some aga copper gradient than you would add 4 at the end of displayscroll command.
And displayscroll works better if its right after displaybitmap.

I must say this doesn't help me at all understanding how this command works.

[Cobe]

This is how I have it set up in my current aga dual playfield project:

[E-Penguin]

Based on my limited understanding...

Horizontal scrolling on the Amiga is achieved through two mechanisms:
1. Setting the "MODULO" registers, one per bitplane BPL1MOD and BPL2MOD, which tells the playfield where to start each line, in blocks of 16
2. Setting the "data start" DDFSTRT register gives a per-pixel offset, up to 15 pixels.

These three registers are why the Copper list needs three entries per line.

So, to scroll a display by 20 pixels, you'd set the MODULO registers to 1 (ie, 16) and the data start register to 4.

This command takes two arrays, which represent the offsets, in terms of pixels, per bitfield (odd and even) per row. Presumably Blitz then works out the three register values to set and creates the copper list accordingly.

The "offset" for the command itself I have no idea, I think it's related to building the overall copper list rather than to do with pixel offsets.

Why does the odd line have to be delayed by -13(ish) compared to the even? I assume that's to account for the fetch delay, so that both end up in the same place.

[Cobe]

I think we're talking about different offsets.
I've only used displayscroll twice, successfully, but only on one playfield so I wouldn't know that odd lines would have XOffset -13. It'll come useful if I ever want to displayscroll both playfields. Thanks for finding that out.

But if Shatterhand is getting "not enough copper space" that means that he got CopOffset/customs wrong.

So from my findings
'DisplayScroll CopList#,&xpos.q(n),&xpos.q(n)[,CopOffset] ;(size=-3)'
when using displayscroll you need -3 set in initcoplit customs.

Optional [,CopOffset] is used only if you already have some other custom copper command that uses custom copper space.
Like for example if you already used
DisplayRGB CopList#,Register,line,r,g,b[,CopOffset] ;(ecs=-1 aga=-4)
then everything should look like this

InitCopList CopList#,ypos,height, type,sprites,colors,-7 ;-4(aga)-3(displayscroll)
'DisplayScroll CopList#,&xpos.q(n),&xpos.q(n),4 ; 4 cause displayrgb already use first 4 custom copper spaces

[E-Penguin]

It works but it's slow. I can't get it to build a new coplist in a single frame on an A500 and barely on an A1200, and that's with using various lookup tables to avoid doing anything more than

xpo(i) = mouseOffs(MouseX)
xpe(i) = xpo(i)

in the loop.

I'll fiddle around with the RiCopperFx library when I get a chance and see if this can be done faster directly.

[Cobe]

Ah..thats bad news. I noticed its slow but i hoped that once i make lookout tables it would be better...

[E-Penguin]

I tried pre-calculating a table per line per offset, but that didn't work; presumably it's something to do with how Blitz handles multi-dimensional arrays.

[E-Penguin]

Originally Posted by Coagulus

Awesome, (I thought I'd replied ages ago!) I've used some of the code from Leathered and my own efforts to knock up an AGA "outrun" attached with source..

My daughter had demanded I write her a game for Christmas - any objection if I use this as the basis for something? As it'll be written in 24 hours don't expect miracles...

[Havie]

Originally Posted by E-Penguin

My daughter had demanded I write her a game for Christmas - any objection if I use this as the basis for something? As it'll be written in 24 hours don't expect miracles...

Looking forward to this!!! Finally, a great Outrun on the Amiga...or will it be Santa Run 3D?

[E-Penguin]

It'll be whatever I can cludge together out of bits and pieces in a couple of hours to please a 5 year old... Don't set your expectations too high! It'll probably involve dinosaurs to keep my son happy too.