Shift bitplanes 1 pixel

[REAKTOR BEAR]

We would like to move bitplanes left and right on the screen, 1 pixel per frame... but if we shift the memory pointer to the bitplanes, they move 8 pixels on the screen, because memory is organised in bytes (8bits/8pixels).

What if we want to move bitplanes 1 pixel?

[a/b]

x = scroll offset (-N, ..., -1, 0, 1, ..., N)
bits = x&15
set $dff102 to (bits<<4)|bits
set $dff0ex (bitplane pointers) to bitplane_ptr+(x>>4)*2

Docs: http://amigadev.elowar.com/read/ADCD.../node0022.html

[Thomas Richter]

Do NOT poke the hardware directly, even more so as this is a graphics primitive that is easily available from the operating system. The corresponding function is called ScrollRaster() in the graphics.library.

[Galahad/FLT]

Originally Posted by Thomas Richter

Do NOT poke the hardware directly, even more so as this is a graphics primitive that is easily available from the operating system. The corresponding function is called ScrollRaster() in the graphics.library.

Zero harm whatsoever.

If the returning copperlist is properly written, hardware scroll values will instantly be reset in any case.

A nothing "problem"

[Thomas Richter]

Originally Posted by Galahad/FLT

Zero harm whatsoever.

Does not clip on window or screen boundaries. Does not work ideally on interleaved bitmaps. Does not work on RTG graphics. Does not reserve the blitter, so does not work with multitasking. That's >>0 harm that is done here.

Originally Posted by Galahad/FLT

If the returning copperlist is properly written, hardware scroll values will instantly be reset in any case.

Moving a bitplane is something different than panning, and this problem is not related to the copper at all.

[a/b]

He didn't explicitely specify whether he's using OS or hw banging, so based on his previous enquiries I'm assuming it's hw banging (also, hw forum ).

[Galahad/FLT]

Originally Posted by a/b

He didn't explicitely specify whether he's using OS or hw banging, so based on his previous enquiries I'm assuming it's hw banging (also, hw forum ).

Exactly, that's the inference I got.

So to repeat, zero harm

[Bruce Abbott]

Originally Posted by Thomas Richter

Do NOT poke the hardware directly, even more so as this is a graphics primitive that is easily available from the operating system. The corresponding function is called ScrollRaster() in the graphics.library.

It might be 'easy', but ScrollRaster() is very expensive. In this case it will blit the entire screen (less a one pixel vertical strip) and then fill the 'gap' left behind with solid color (that will probably have to be overwritten with new image data). Very inefficient!

This is the kind of advice that gives neophytes the impression that the Amiga's hardware is underpowered.

Does not work on RTG graphics.

RTG is 3rd party stuff that only works through proprietary libraries and drivers. Not appropriate for this subforum.

[jotd]

Originally Posted by Thomas Richter

Does not clip on window or screen boundaries. Does not work ideally on interleaved bitmaps. Does not work on RTG graphics.

The sub-topic is "coders asm/hardware", that is perfectly clear what OP wants. It's probably for a game, not an application.

Does not reserve the blitter, so does not work with multitasking. That's >>0 harm that is done here.

Are you sure the blitter is involved in hardware scrolling by changing shifting and screen pointers?

[modrobert]

Originally Posted by Bruce Abbott

This is the kind of advice that gives neophytes the impression that the Amiga's hardware is underpowered.

I remember a friend a who bought Obliterator (Psygnosis) for the A500 back in the day, supposedly it was made system friendly (using library calls), it had abysmal frame rate (think unintended flickering slow motion) and horrible controls. In my mind, assuming Obliterator is system friendly as rumored, it is a perfect example of what to expect regarding limitations when not banging the hardware (using registers).

[Thomas Richter]

Originally Posted by Bruce Abbott

It might be 'easy', but ScrollRaster() is very expensive. In this case it will blit the entire screen (less a one pixel vertical strip) and then fill the 'gap' left behind with solid color (that will probably have to be overwritten with new image data). Very inefficient!

it depends on what you want to do. Panning or scrolling. For panning,we have ScrollVPort() or MoveScreen().

Originally Posted by Bruce Abbott

This is the kind of advice that gives neophytes the impression that the Amiga's hardware is underpowered.

The type of answer banging the hardware gives people the impression AmigaOs is underpowered. Everything you want is there in the system.

Originally Posted by Bruce Abbott

RTG is 3rd party stuff that only works through proprietary libraries and drivers. Not appropriate for this subforum.

Banging the hardware is not apropriate because it does not work on every graphics mode. AmigaOs and its hardware is as proprietary as these drivers.

[Rotareneg]

Originally Posted by Thomas Richter

The type of answer banging the hardware gives people the impression AmigaOs is underpowered. Everything you want is there in the system.

Everything except performance.

[Olaf Barthel]

Originally Posted by Thomas Richter

Do NOT poke the hardware directly, even more so as this is a graphics primitive that is easily available from the operating system. The corresponding function is called ScrollRaster() in the graphics.library.

Hm... ScrollRaster() needs a RastPort (as the name implies), which is fine in most cases. You can even call it on the RastPort of a Screen, if there are no Windows open on it whose contents would be affected. No clipping is performed, which should make it reasonably fast.

If there is no need for clipping via the RastPort or the Layer it is a part of, then BltBitMap() might just do the minimum required, and nothing more. Could be worth a try. You may have to call BltBitMap() on the column of pixels which the blit operation did not copy. ScrollRaster() would have filled that column with the current background colour.

[Olaf Barthel]

Originally Posted by Rotareneg

Everything except performance.

First determine what the budget for the operation is. The budget not only includes how much time is spent for the operation to complete, but also for learning how to perform it, debug it and measure the actual performance attainable. You can always reconsider the approach if you know your numbers.

Assuming that the operating system's toolbox, as available to you, will let you down is a shortcut. Not all shortcuts will be to your benefit or advantage It's also possible that just by giving it a shot you might stumble upon something that you did not expect to find and which adds to your own "bag of tricks".

And, no, I never felt the acute urge to make use of the Blitter on its own terms. I'm much too lazy for that, especially considering how much can go wrong if you do not know exactly what is called for and lack the patience to debug the smoking ruins. Laziness can be a superpower. Let somebody else solve that problem for you.

[REAKTOR BEAR]

Yes, direct hardware banging if possible... we are trying to make a depth of field parallax effect, where the bitplanes in the background move slowly, and the foreground move fast:

Playfield 1 (foreground) move bitplanes(1,3,5) 6 pixels per frame.

Playfield 2 (background)
move bitplane6, 1 pixels per frame
move bitplane4, 2 pixels per frame
move bitplane2, 3 pixels per frame

Graphics.lib is loaded but used only to setup a View since we have zero experience with graphics.lib. The game is designed for OCS A500, but should also work on other amigas like A1200.

[REAKTOR BEAR]

Originally Posted by a/b

x = scroll offset (-N, ..., -1, 0, 1, ..., N)
bits = x&15
set $dff102 to (bits<<4)|bits
set $dff0ex (bitplane pointers) to bitplane_ptr+(x>>4)*2

Docs: http://amigadev.elowar.com/read/ADCD.../node0022.html

So you are talking about these (BPLCON1) ?
PF2H=Playfield 2 horizontal scroll code
PF1H=Playfield 1 horizontal scroll code

How do we set it to 1pixel scroll?

[a/b]

Yeah, BPLCON1 ($dff102).
1px scroll? Change x by +/-1.
x=-17 => $102 = $000f, $0e0/$0e2 = bpl_ptr1-4, $0e8/$0ea = bpl_ptr3-4, $0f0/$0f2 = bpl_ptr5-4
x=-16 => $102 = $0000, $0e0/$0e2 = bpl_ptr1-2, $0e8/$0ea = bpl_ptr3-2, $0f0/$0f2 = bpl_ptr5-2
...
x=-2 => $102 = $000e, $0e0/$0e2 = bpl_ptr1-2, $0e8/$0ea = bpl_ptr3-2, $0f0/$0f2 = bpl_ptr5-2
x=-1 => $102 = $000f, $0e0/$0e2 = bpl_ptr1-2, $0e8/$0ea = bpl_ptr3-2, $0f0/$0f2 = bpl_ptr5-2
x=0 => $102 = $0000, $0e0/$0e2 = bpl_ptr1+0, $0e8/$0ea = bpl_ptr3+0, $0f0/$0f2 = bpl_ptr5+0
x=1 => $102 = $0001, $0e0/$0e2 = bpl_ptr1+0, $0e8/$0ea = bpl_ptr3+0, $0f0/$0f2 = bpl_ptr5+0
...
x=15 => $102 = $000f, $0e0/$0e2 = bpl_ptr1+0, $0e8/$0ea = bpl_ptr3+0, $0f0/$0f2 = bpl_ptr5+0
x=16 => $102 = $0000, $0e0/$0e2 = bpl_ptr1+2, $0e8/$0ea = bpl_ptr3+2, $0f0/$0f2 = bpl_ptr5+2
... etc.

2px scroll => change x by +/-2, use the same calcs..
Since you are only scrolling playfield1 you only set $dff102 bits 0-3 and leave bits 4-7 at 0. To scroll everything you also set bits 4-7 (e.g. $0011, $0022, ... $00ff), this is a difference from my first post.

[REAKTOR BEAR]

Awesome, thanks a/b, as a sidenote why was this information not in the Commodore Amiga hardware reference manual (playfields section) .. strange

[chb]

Originally Posted by REAKTOR BEAR

Yes, direct hardware banging if possible... we are trying to make a depth of field parallax effect, where the bitplanes in the background move slowly, and the foreground move fast:

Playfield 1 (foreground) move bitplanes(1,3,5) 6 pixels per frame.

Playfield 2 (background)
move bitplane6, 1 pixels per frame
move bitplane4, 2 pixels per frame
move bitplane2, 3 pixels per frame

It is not possible to have a different x-scroll value for every bitplane of playfield 2; scroll registers work per playfield. You'd need to either shift two bitplanes with the blitter, have 16 copies of them in memory (shifted by 1,2,3... pixels) or use some other trick.

[Photon]

Originally Posted by Thomas Richter

Do NOT poke the hardware directly, even more so as this is a graphics primitive that is easily available from the operating system. The corresponding function is called ScrollRaster() in the graphics.library.

I created the different sub-forums from a poll a long while back to allow experts to subscribe to the forums matching their interest and area of expertise, help make threads more on-topic, and to avoid giving conflicting advice.

This forum is specifically for banging the hardware, algorithms, or writing in Assembly in general (although if you're writing a utility, language or driver in Assembly which uses the OS extensively, coders should ask in Coders.System to get the best advice).

I would say that there are a few cases when OS programming advice is very useful in this HW programming forum, such as switching the OS off, on, and semi-on safely, supporting CPU, RAM, and other expansion cards and peripherals in a compatible way, file formats, early boot, media boot, and reset.

But generally, this is not the place to say "do it with the OS instead".