Zooming using BPLCON1 (horiz. shift) — am I doing it wrong?

[losso]

Hello y'all!

I took a stab at a simple zoom effect using only horizontal shifts and bitplane modulos. My idea was to alter the width using BPLCON1/$dff102 during each line and using bitplane modulos to stretch/squeeze the image vertically. For the shift and modulo values, I took the lazy route and used precomputed tables.

After some tries, the prototype looked reasonably well in WinUAE. However, when I tested the effect on my A1200, I noticed flickering vertical stripes when zooming in and little gaps between bitmap stripes when zooming out.

See the attached screenshot and source code.

So, my questions are:

* Am I doing something wrong with my horizontal scaling?

* Why does it look different in WinUAE (latest beta)?

Thanks for any help,

losso

PS: Bonus observation: Normally, I run an A500 config in WinUAE. When I tested the example code with an A1200 config, no bitmaps would be displayed; only when I ran the executable again I saw the image.

PPS: Switching to OCS in the Early Startup Control on the Amiga 1200 had no effect.

[Toni Wilen]

Most likely the usual cause, if some trick never works (or part of it won't work) and causes obvious display glitches, it is never used, not even accidentally = it never gets emulated properly

AFAIK BPLCON1 zoom trick only works if scroll value keeps decreasing, increasing it causes side-effects mid scanline.

Attach few binaries (no need for sources) that have gaps on real hardware, thanks.

[losso]

AFAIK BPLCON1 zoom trick only works if scroll value keeps decreasing, increasing it causes side-effects mid scanline.

I see… So, I am doing it wrong. Will try that out, thanks!

Attach few binaries (no need for sources) that have gaps on real hardware, thanks.

Oops, I meant to, but forgot to attach the executable. Here you go.

[losso]

On second thought… My current implementation already uses both shift »directions« (increasing and decreasing values when zooming in and out, respectively), and they both look glitchy on real hardware.

Maybe it does not make sense to update BPLCON1 continuously (every 8 pixels), as it only seems to have an effect every 16 pixels. (i.e. have alternating MOVE and NOP instructuons instead)

[losso]

Cool, it's working now. Thanks for pointing me in the right direction! So, I'll try to remember:

* Use only decrementing shift values

* Use pairs of MOVE BPLCON1 + NOP, not two MOVEs

The second point is because a new shift value can only be set every 16px, anyway — because bitplane data is fetched word by word, not byte-wise, correct?

Luckily, a horizontal shrinking of 15px is still enough for my purposes…

[Codetapper]

I think the move + nop only applies if the original image you're stretching is in 4 bitplane mode. If you use 5 bitplanes, you'll probably find you need 2 moves and 1 nop, and if you're using 6 planes you just do constant moves.

(At least for multiplexing sprites, this is the timing I've determined that's required to have a rock-steady sprite display).

[hooverphonique]

nice.. I'll have a look.. always wanted to tinker with this trick myself..

[Toni Wilen]

I finally figured out how BPLCON1 (and Denise) internally works, old emulation code was quite wrong even if results were mostly correct.

(Still rewriting emulation code, this is quite big change)

Quick explanation:

When Agnus writes to Denise's BPL1DAT, BPLxDAT registers are copied to internal temp registers and flag is set.

When bitplane delay value matches Denise's internal hpos counter ((hpos & mask) == delay) and flag is set, internal temp register is copied to 16-bit shift register and flag is reset. Comparison checks are continuous, writes to BPLCON1 can at any time cause comparison to match early or delay matching or even keep it missing longer time (Not sure if this can be used for some effect? Not confirmed if this happens but I am quite sure)

Pixels are clocked out of each bitplane shift registers which goes to color palette, merged with sprites and so on.. The usual.

There is no 32-bit shift register, it is 16-bit only (at least UAE incorrectly used 32-bit shift registers).

This explains "blanking" side effect (above test programs). BPLCON1 is increased which causes comparison match to be delayed. If match is delayed long enough, shift register is not loaded with new data, it becomes empty and keeps outputting zeros.

[riksfetto]

OT, but nevertheless; is there any value at all obtained by setting/writing BPLxDAT? Sorry about the noob-question, but I just don't get the meaning of the register.

[Toni Wilen]

Originally Posted by riksfetto

OT, but nevertheless; is there any value at all obtained by setting/writing BPLxDAT? Sorry about the noob-question, but I just don't get the meaning of the register.

Yes, there are two useful side-effects.

Sprites are enabled (until end of scanline) when BPL1DAT is written: can have sprites visible in left border before DDFSTRT without wasting DMA time for bitplanes. (Only useful with OCS/ECS, AGA can have sprites in border without extra tricks).

OCS/ECS only "7-plane" trick. Setting BPLCON0 to 7 planes causes Agnus to use normal 4 plane cycle diagram but Denise thinks mode is 6 plane, plane 5 and 6 data (16-bit repeating pattern) comes from whatever CPU or copper has written to BPL5DAT and BPL6DAT.

[Toni Wilen]

WinUAE 2.7.1 beta 2 now emulate BPLCON1 mid-scanline modifications perfectly, zoom test binaries now have correct gaps and flicker exactly right