Stuck trying to get parallax working

[8bit-Dude]

Hey Guys! I need some advice on implementation of parallax.

 

I took inspiration from section 6.1 of https://playermissile.com/dli_tutorial/

 

In my case, I have a pattern that repeats every 4 chars, so I have generated screen data that is 44 bytes wide, and scroll only with HSCROL (from 0 to 15). Here is what I did:

 

1) I tested full screen scrolling with a VBI, and it works as expected (see scroll-vbi.xex).

 

2) Next, I setup a vector of scroll values for each line, and updated all values simulataneously with the VBI. Again, it works as expected (see scroll-dli.xex)

 

3) Finally, I tried to only update the values of top 8 rows with the VBI. It works, but the screen gets corrupted on certain HSCROL values (I think 2,3,6,7,10,11,14,15). This is weird (see parallax-dli.xex).

 

I wonder if anyone can spot a mistake I might have made?

(In DLI parallax-dli.xex, _scrollX start at $24E0)

 

The DLI/VBI code of parallax-dli.xex looks as follows:

_scrollX: .byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
_scrollTemp: .res  1

DLI:    
    ; Backup A & X
    pha
    txa
    pha
    
    ; Load line counter
    ldx _countDLI
        
    ; Update parallax
    lda _scrollX,x
    sta hscrol   

    ... multiplexed sprites ....

    ; increment line counter
    inc _countDLI
        
    ; Restore A & X
    pla
    tax
    pla
    rti

VBI:
    ; Reset atract (screen saver timer) and DLI counter
    lda #0
    sta atract
    sta _countDLI
	
    inc _scrollTemp
    lda _scrollTemp
    lsr A
    lsr A
    lsr A
    lsr A
    ldx #0
loopLine:
    sta _scrollX,x
    inx
    cpx #8
    bne loopLine

    ... multiplexed sprites ....

    ; Exit VBI
    jmp XITVBV

 

 

 

scroll-vbi.atr scroll-dli.atr parallax-dli.atr

Edited August 26, 2021 by 8bit-Dude

[Rybags]

You seem to be populating that scrollX array with the same value in the VBI.

Wouldn't you want the array to have different values each one moving at a slightly faster rate?

 

A tip for scrolling when used in conjunction with LMS - rather than maintaining 2 different counts you can keep them as one, then just use masks, bitshifts etc to extract the HSCROL value you need.

Of course with HScrolling, larger values in LMS means moving the graphics to the left but larger HSCROL values move data to the right.  So what you cam do is subtract the HSCROL value from 3 if just using 2 bits for the scroll value (or just XOR with 3).

With VScrolling the scroll value is in reverse so you don't need to do the extra operation.

 

[8bit-Dude]

4 minutes ago, Rybags said:

You seem to be populating that scrollX array with the same value in the VBI.

Wouldn't you want the array to have different values each one moving at a slightly faster rate?

 

That is what I do with scroll-dli.xex and it works fine.
But in parallax-dli.xex, I only populate the first 8 values of scrollX, and the screen gets corrupted for some values of the scroll.

Edited August 26, 2021 by 8bit-Dude

[Rybags]

I should also have mentioned - when storing HSCROL it's best to STA WSYNC first - you can get unwanted glitches if you change it during the graphics part of a scanline.

Though that said you can get glitching due to other things as well.

[8bit-Dude]

10 hours ago, Rybags said:

I should also have mentioned - when storing HSCROL it's best to STA WSYNC first - you can get unwanted glitches if you change it during the graphics part of a scanline. Though that said you can get glitching due to other things as well.

Thanks for the tip. Adding STA WSYNC before STA HSCROL fixed half of the glitches (see attached).
Do you have more info on what "other things" could be causing the remaining glitches?

 

Note: the glitch seems to appear only when HSCROL switches from a value in range $08-$0f back to $00.
Could it be something to do with the WSYNC not working correctly because of the delay on previous scanline?

 

parallax-dli-wsync.atr

Edited August 27, 2021 by 8bit-Dude

[8bit-Dude]

It worked after I included a few extra cycles after WSYNC before updating HSCROL:

 

    ; Update parallax
    lda _scrollX,x
    sta wsync
    sta _delay
    sta hscrol
 

Weird!

[rensoup]

1 hour ago, 8bit-Dude said:

It worked after I included a few extra cycles after WSYNC before updating HSCROL:

Well you've already found the problem but I made a similar test a while back and ran into the same issues, some people posted explanations:

 

 

Has the source, so may be of interest

[8bit-Dude]

I got something working almost correctly now. It not completely glitch free, as the DLI fires-off between 1 and 2 line late...

I am probably going to need offset the chars by 1 or 2 pixels to get something seamless. 

 

 

Edited August 27, 2021 by 8bit-Dude

[8bit-Dude]

Here is the final result, after a little bit more work!! ?

 

I am working on a new lightgun game by the way, with mechanics inspired from Battle Clash (SNES game).

 

parallax-goblin.atr

Edited August 27, 2021 by 8bit-Dude

[Rybags]

If things are happening late it can be due to the WSYNC store occurring after the first scanline of the DLI.

Also with HScrolling enabled there's more DMA cycles lost as well as it being a variable thing depending on HSCROL value.

 

The single-step debug in Altirra can help out here, you can determine if your DLI is taking too long.