English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 11 November 2013, 04:37   #1
losso
Registered User

losso's Avatar
 
Join Date: Oct 2013
Location: Hamburg
Posts: 51
Zooming using BPLCON1 (horiz. shift) — am I doing it wrong?

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.
Attached Thumbnails
Click image for larger version

Name:	bplcon1-zoom.jpg
Views:	660
Size:	101.4 KB
ID:	37763  
Attached Files
File Type: zip zoomtest.zip (38.4 KB, 171 views)

Last edited by losso; 11 November 2013 at 04:38. Reason: typo; also I switched "zoom in" and "zoom out", but you get the idea…
losso is offline  
Old 11 November 2013, 09:08   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,368
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.
Toni Wilen is offline  
Old 11 November 2013, 10:17   #3
losso
Registered User

losso's Avatar
 
Join Date: Oct 2013
Location: Hamburg
Posts: 51
Quote:
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!

Quote:
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.
Attached Files
File Type: zip zoom.zip (3.1 KB, 124 views)
losso is offline  
Old 11 November 2013, 12:38   #4
losso
Registered User

losso's Avatar
 
Join Date: Oct 2013
Location: Hamburg
Posts: 51
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 is offline  
Old 12 November 2013, 00:45   #5
losso
Registered User

losso's Avatar
 
Join Date: Oct 2013
Location: Hamburg
Posts: 51
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…
Attached Files
File Type: zip zoom2.zip (84.2 KB, 201 views)
losso is offline  
Old 12 November 2013, 02:37   #6
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,153
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).
Codetapper is offline  
Old 12 November 2013, 12:51   #7
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 842
nice.. I'll have a look.. always wanted to tinker with this trick myself..
hooverphonique is offline  
Old 11 January 2014, 21:01   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,368
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.
Toni Wilen is offline  
Old 12 January 2014, 04:06   #9
riksfetto
aka "den Ensamma mannen"
 
Join Date: Dec 2011
Location: Eskilstuna/Sweden
Posts: 12
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.
riksfetto is offline  
Old 12 January 2014, 15:40   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,368
Quote:
Originally Posted by riksfetto View Post
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 is offline  
Old 14 January 2014, 18:00   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,368
WinUAE 2.7.1 beta 2 now emulate BPLCON1 mid-scanline modifications perfectly, zoom test binaries now have correct gaps and flicker exactly right
Toni Wilen is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Demoeffect: zooming riksfetto Coders. Asm / Hardware 11 13 January 2014 23:46
Right Shift+Right Amiga works, but not Left shift+Left Amiga Photon support.WinUAE 13 22 November 2010 22:43
Glitchy Horiz Lines With WinUAE2000 Ed Cruse support.WinUAE 34 19 December 2009 00:06
1084s RGB screen zooming shot Anemos Hardware pics 3 30 October 2009 19:22
WinUAE handling of ECS:BPLCON1:DOFF flag RedskullDC support.WinUAE 1 26 December 2007 18:12

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07894 seconds with 13 queries