English Amiga Board - HELP with blitter vertical shift

English Amiga Board (https://eab.abime.net/index.php)

- Coders. Asm / Hardware (https://eab.abime.net/forumdisplay.php?f=112)

- - HELP with blitter vertical shift (https://eab.abime.net/showthread.php?t=108188)

HELP with blitter vertical shift

I'm trying to scroll a portion of a plane vertically using blitter, so far I have no problem going up but as soon as I change direction I'm getting some unexplicable (for me!) results.

This routine is executed at every frame. Source and destination match, the shift is obtained by adding the size of a line to the source (A3) so the image moves up 1px every frame. 1 is also subtracted from H so the size of operation don't mess with next bitplane.

As long as SCROLL_DIR_Y=0 the scroll works OK and when it's 1 the size of a line is added to the destination (A4) instead, to obtain the opposite direction. But as soon as this is triggered the result of the blit is as in second image, without any scrolling in-between.

Using modulos of 0 and scrolling the whole area have the same results.

I'm obviously missing something, maybe an expert eye can give me a hint? :help

Code:

__SCROLL_BG_Y:

    MOVEM.L    D0-A6,-(SP)    ; SAVE TO STACK

    BTST.B    #6,DMACONR    ; for compatibility

    MOVE.W    #%0000100111110000,BLTCON0



    ; ## MAIN BLIT ####

    MOVE.L    BGPLANE0,A3

    MOVE.L    BGPLANE0,A4



    MOVE.B    SCROLL_DIR_Y,D5

    TST.B    D5

    BEQ.S    .goUp

    ADD.L    #336/16*2,A4        ; POSITION Y

    BRA.S    .goBlit

    .goUp:

    ADD.L    #336/16*2,A3        ; POSITION Y

    .goBlit:



    bsr    WaitBlitter

    MOVE.W    #$FFFF,BLTAFWM        ; BLTAFWM

    MOVE.W    #$FFFF,BLTALWM        ; BLTALWM

    MOVE.W    #%0000000000000000,BLTCON1    ; BLTCON1

    MOVE.W    #bpl-wblit,BLTAMOD        ; BLTAMOD

    MOVE.W    #bpl-wblit,BLTDMOD        ; BLTDMOD



    MOVE.L    A3,BLTAPTH        ; BLTAPT SRC

    MOVE.L    A4,BLTDPTH        ; DESC

    MOVE.W    #(h-1)*64+160/16,BLTSIZE    ; BLTSIZE

    ; ## MAIN BLIT ####



    MOVEM.L    (SP)+,D0-A6    ; FETCH FROM STACK

     RTS

Going up OK:
http://eab.abime.net/attachment.php?...1&d=1631036592

Going down:
http://eab.abime.net/attachment.php?...1&d=1631036642

Are you using descending mode for the appropriate blit?

http://amigadev.elowar.com/read/ADCD.../node0120.html

Should I? I'm not using the blitter shift.

OH maybe i see now, source is overwritten! Thanks I'll give a try with decending mode!

It's unrelated to shifting.

If you're moving memory forward into an overlapping region then you need to use descending mode.

Otherwise you want to use the normal ascending mode.

If you don't then you are going to end up overwriting the region you are also reading from which will be bad.

Yeah, otherwise you rewrite the next line with the one you copy every time, so you end up copying the same (first) line over all the other lines.
In that scenario you have to copy bottom-up and use descending mode.

and solution was as simple as DESC mode, thanks!

Sorry for resuming but today I was doing some more tests on this and I'm realizing it's not possible to shift vertically+horizontally in any direction *with the same blit*, just up/right or down/left, right? Or is there some trick?

I suppose you could "fake" it by e.g. in ascending mode shift right by 15 pixels then set the dest address one word earlier, in order to shift left by one pixel.

Thanks, something similar to a scroll happens but "a word earlier" means let blitter mess with adjacent part of memory, which is trouble :)

On AHRM there's something on the topic but it seems more confused than I am:

Quote:

Warning:
--------
Conditions 2 and 3 can be contradictory if, for instance, you are
trying to move an image one pixel down and to the right. In this
case, we would want to use descending mode so our destination does
not overwrite our source before we use the source, but we would want
to use ascending mode for the right shift . In some situations, it is
possible to get around general guideline 2 above with clever masking .
But occasionally just masking the first or last word may not be
sufficient; it may be necessary to mask more than 16 bits on one or
the other end. In such a case, a mask can be built in memory for a
single raster row, and the A DMA channel enabled to explicitly fetch
this mask. By setting the A modulo value to the negative of the width
of the mask, the mask will be repeatedly fetched for each row.

http://amigadev.elowar.com/read/ADCD.../node0121.html

If anyone could point to a working example maybe I can figure this out.