Sine scroller

[bobbybearing]

lsl and add are quicker than mulu. But you can also precalc your sintab if you have to mul *40 each time...

[pmc]

Thanks for the confirmation. Yeah - I thought about precalculating the sine table values before but I didn't cos it seemed like cheating!

Instead I sat down with my calculator this morning and worked out a way to multiply by 40 using shifts and adds.

Definitely going to keep precalcs in mind though - might edge me closer to getting a one pixel sine copy working...

[pmc]

Erm... Just checked out the two pixel version at home and it's not right - there's a glitch in the top right hand corner of the sine scroller. I didn't notice this on my laptop at work but I do notice it on my PC at home.

I even tried the two pixel version with a pre calc'd sine table but the glitch is still there! Aaaarrrghhh! I just can't seem to make the routine fast enough so that it looks right with anything other than a four pixel sine copy.

Think it's gonna have to be double buffering or bust!

[musashi5150]

Originally Posted by pmc

Think it's gonna have to be double buffering or bust!

Dude, double buffering always! Even triple buffering sometimes if your routine flops over a frame

[bobbybearing]

yep, it's that I had said : all 1 or 2 pixels sinuscroll works with double or triple buffering

[AGN]

Originally Posted by pmc

I even tried the two pixel version with a pre calc'd sine table but the glitch is still there! Aaaarrrghhh! I just can't seem to make the routine fast enough so that it looks right with anything other than a four pixel sine copy.

Maybe it's fast enough but interrupt starts at vbl instead of particular line.

@@ -330,6 +330,7 @@
        and.w   #%0000000000010000,intreqr(a5)          ;did the copper cause the interrupt?
        beq     interrupt_done                  ;nope, jump back out of my interrupt code
        move.w  #%0000000000010000,intreq(a5)           ;yep, clear the copper interrupt bit and continue with the interrupt code
+       move.w  #$00f0,cust_regs+color00

 clear_dis_scrn:
        btst    #6,dmaconr(a5)                  ;blitter ready?
@@ -547,6 +548,8 @@
        rts

 interrupt_done:
+       move.w  #$0f00,cust_regs+color00
+
        movem.l (sp)+,d0-d7/a0-a6                       ;end of interrupt, restore registers
        move.l  cop_int_address,-(sp)           ;stick the return address on the stack
        rts                             ;and return to it
@@ -1087,6 +1090,7 @@
        dc.w    $9d01,$ff00,color01,$0fa0
        dc.w    $9e01,$ff00,color01,$0fa0
        dc.w    $9f01,$ff00,color01,$0fa0
+       dc.w    intreq,$8010            ;triggers the copper interrupt
        dc.w    $a001,$ff00,color01,$0f90
        dc.w    $a101,$ff00,color01,$0f90
        dc.w    $a201,$ff00,color01,$0f90
@@ -1129,7 +1133,8 @@
        dc.w    $c701,$ff00,color01,$0f00
        dc.w    $c801,$ff00,color00,$000f               ;start of the second copper bar
        dc.w    $ca01,$ff00,color00,$0000               ;end of the second copper bar
-       dc.w    $ffdf,$fffe,intreq,$8010                ;triggers the copper interrupt
+       dc.w    $ffdf,$fffe
+       dc.w    $3001,$ff00,color00,$0fff               ;end of the second copper bar
        dc.w    $ffff,$fffe

 credits:       dc.b    "$VER: Sinescroll V2.12 with UltraEdit32 V13.00, assembled with Devpac V3.02 under WinUAE 1.4.1.0 April 2007)"

[AGN]

Originally Posted by pmc

Yeah - I thought about precalculating the sine table values before but I didn't cos it seemed like cheating!

Data at 'sin_table' is a precalc itself. You should use system/math libs to create these values. :P

[musashi5150]

I guess if you only needed a few more rasters you could get the Copper to trigger a Level3 INT before the VBlank... (As long as the display isn't still being drawn by the CPU).

[korruptor]

pmc: I've dropped my source into the zone. It's not double buffered and the sine is pre-calced but it might be worth a read. It took me a while to get it working so there're probably bugs.

[pmc]

@mushashi5150 & bobbybearing - As you can read below, it actually turns out that the routine not being double buffered isn't the problem. However, your advice has always been good advice so who am I to go against it? Double buffered it now is!

@AGN - Hmmm... good idea and something I hadn't thought of - if I need to, I can shift the start of the interrupt somewhere else other then the VBL... Regarding the sine table itself being a precalc - gimme a break, most of my hair's fallen out just getting this far!!

@korruptor - thanks for posting your source, nice one. Bugs? Who's routines don't have bugs? As you can read below, certainly not mine! You got it working, that's the main thing...

I lifted the double buffering code out of the sinescroller source on flashtro.com and implemented it into my routine.

Double buffering isn't the problem. With or without the double buffering, there's still the glitch in the top right hand corner of the sinescroll display. Something else is wrong.

Also, there's now a mismatch between the master and temporary sine pointers. If I disable sine, as per AGN's suggestion of sticking a 255 in at the second position in the sine table, weird things happen. I get a flat scroller for half of the screen and then it breaks into a random sine pattern for the other half. As far as I can tell, these problems have only occurred since the routine was converted to a two pixel sine copy.

[musashi5150]

Originally Posted by pmc

With or without the double buffering, there's still the glitch in the top right hand corner of the sinescroll display

I had a glitchy scroller once and the problem was the Blitter masks not being set correctly - scratched my head for quite a while on that one. And of course be sure to WaitBlit() before poking any registers (but I'm sure you're probably already doing that).

[pmc]

Also, there's now a mismatch between the master and temporary sine pointers. If I disable sine, as per AGN's suggestion of sticking a 255 in at the second position in the sine table, weird things happen. I get a flat scroller for half of the screen and then it breaks into a random sine pattern for the other half.

Scratch the above, that was happening on the four pixel version too.

I went right back to my original working four pixel routine. Then I added or changed everything that I've added or changed between that routine and the two pixel version, assembling and running after each change, including new things like adding double buffering. Everything works fine up to this point.

The top right graphics glitch problem *only* happens when I then increase from four sine blits to eight for the two pixel copy in the sine blit loop... Very odd...

[AGN]

Originally Posted by pmc

Regarding the sine table itself being a precalc - gimme a break, most of my hair's fallen out just getting this far!!

Which means that having *40 values in table is not cheating.

Originally Posted by pmc

Double buffering isn't the problem. With or without the double buffering, there's still the glitch in the top right hand corner of the sinescroll display. Something else is wrong.

My bet: broken logic in frame flipping.

Originally Posted by pmc

Also, there's now a mismatch between the master and temporary sine pointers. If I disable sine, as per AGN's suggestion of sticking a 255 in at the second position in the sine table, weird things happen.

You don't need 2 pointers for sine table in d.buffer mode.

Put code in zone.

[AGN]

Originally Posted by korruptor

pmc: I've dropped my source into the zone. It's not double buffered and the sine is pre-calced but it might be worth a read. It took me a while to get it working so there're probably bugs.

It works on 68000@7MHz?

[bobbybearing]

without double buf, with winuae, perhaps check Immediate Blitter or cycle exact cpu-blitter

[pmc]

Originally Posted by AGN

You don't need 2 pointers for sine table in d.buffer mode.

Yes, you're right - I've gradually realised that I don't need two sine pointers - I'm changing my code to only use one. Once I've got the sine code changed I'll post an updated source.

[pmc]

Sine code has been changed now. Only one sine pointer is used. Instead, an offset value is added each iteration. Still not sure if this is *the* proper way to do it but it seems to work. Still got the top right graphics glitch. Anyways, new version posted to the zone...

[bobbybearing]

have no time atm, but great work!

[pmc]

@bobbybearing - no worries, man - and thanks.

@korruptor - had some time so checked out your source just now. Looks like it needs to be double buffered for running on 68000 - I get some flickering running it as if it's on an ECS A500+ under WinUAE - but with that amendment done it'll look great. Top man. Only other prob I had was that it didn't quit properly for me after I pressed the left mouse button...

[AGN]

Originally Posted by pmc

Sine code has been changed now.

I don't like You.

@@ -235,12 +235,12 @@
 ** Equates - Library offsets **

 execbase       equ      4
-openlibrary:   equ     -552
-closelibrary:  equ     -414
-forbid:        equ     -132
-permit:        equ     -138
-sys_cop_offset:        equ      38
-cop_int_vect:  equ     $6c
+openlibrary    equ     -552
+closelibrary   equ     -414
+forbid equ     -132
+permit equ     -138
+sys_cop_offset equ      38
+cop_int_vect   equ     $6c

 ** Code **

@@ -431,7 +431,7 @@
 sin_copy_setup:
        lea     scroll_screen,a0                        ;first word of the scrollplane as the source
        suba.w  #2600,a6                        ;first word of the displayed screen as the destination
-       moveq.b #19,d2                  ;display is 320 bits wide, which is 40 bytes which, is 20 words. 20 words need to be blitted to complete one display. Set counter to number required minus one cos this is a dbra loop
+       moveq   #19,d2                  ;display is 320 bits wide, which is 40 bytes which, is 20 words. 20 words need to be blitted to complete one display. Set counter to number required minus one cos this is a dbra loop

 sin_blits:
        bsr     get_offset                      ;first we need to use a sin value to offset where we start copying into the displayed screen

Originally Posted by pmc

Still got the top right graphics glitch.

Race condition. Your code is not able to update copper list before its execution.

@@ -1035,6 +1035,7 @@
        dc.w    ddfstrt,$0038,ddfstop,$00d0
        dc.w    bpl1mod,$0000,bpl2mod,$0000
        dc.w    color00,$0000,color01,$0fff
+       dc.w    $0101,$ff00
        dc.w    bpl1pth
 plane1_h:      dc.w    0                       ;where the screen bitmap address gets put
        dc.w    bpl1ptl