23 July 2021, 17:03 | #21 |
Registered User
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 408
|
|
23 July 2021, 17:18 | #22 | |
Registered User
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 408
|
Quote:
However, the safety buffer is really not that bad. You only need to add once 32 pixel in front of your planes and 32 pixel for each line. This means only ~10% chipmem increase for your buffers. If you are using copper blits then avoiding clipping is also a good idea to handle the extra complexity. |
|
23 July 2021, 17:24 | #23 | |
Registered User
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 408
|
Quote:
It's enough if you add 32 pixel also on top+bottom of your planes (forgot to mention bottom before). Your display is only 320 pixel wide, so the 32 pixel bob can be shifted completely of of screen. |
|
23 July 2021, 18:07 | #24 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
I keep forgetting. I shouldn't look that up in my own sources. At least three seem easier to handle for me. And you have your two columns for clipping, even when one extra column is shown due to scrolling(?). |
|
23 July 2021, 18:46 | #25 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
The reason I need the 16 pixels is that I simply prefer to only clip to the nearest 16 pixels instead of doing it pixel perfect. As a consequence, there's part of the bob still being drawn outside of the screen edges in most clipping cases. |
|
23 July 2021, 21:10 | #26 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Yes, but isn't everybody (who clips) clipping to nearest WORD (16 pixel)? I'm still wondering if you need the extra 16 pixels left and right.
Say you want to blit a BOB at x = -1, y = 0. What happens if you blit in descending mode with shift = 1 to memory address 0 (not -2). Doesn't that end up as clipped-blit the way one wants it? ascending: x1234567890abcde descending: 234567890abcdefx |
24 July 2021, 01:14 | #27 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
To be honest, I'm still not exactly seeing how clipping to nearest 16 without buffer space would work. If I clip to the nearest 16 pixels, it seems to me that it's unavoidable there will be cases (in fact, all but one case) where I have some pixels left on either the left or the right side of the BOB that I either don't want to draw, or that would go into the buffer space. Solving this seems to me to require either buffer space or pixel-perfect clipping (which is certainly possible, but not what I'm doing). That said, if a way exists to clip to nearest 16 pixels without needing the buffer space that would be really nice. So, I'm certainly up for seeing if it can be done or not Quote:
Suppose I want to draw a bob that crosses over the edge of the screen (left or right). If I round the bob size to the nearest 16 pixel multiple, the part that crosses over the edge will somewhere between 0 and 15 pixels after I do this cut. Without going to the effort of pixel-perfect clipping, doesn't this pretty much always happen? |
||
24 July 2021, 07:34 | #28 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
I think the confusion is because you maybe think of clipping from the source (BOB) point of view, while I think of it from the destination (screen) point of view.
I just don't want no WORDs to be changed (blitted) outside the screen. So if a unclipped blit of a 32 pixel BOB would blit into WORD -1 and WORD 0 and WORD 1 (memory x word offsets) either: a) let blitter still blit into WORD -1 but use BLTAFWM of 0 to avoid blitter doing any modification in that out of screen area b) if it works, tell blitter to blit into WORD 0, 1, 2 using descending mode and shift to the left (for example dest pixel coordinate -1: shift = 1, pixel coordinate -10: shift = 10) c) if it works, tell blitter to descending-mode-blit only into WORD 0, 1 with modulo increased by 1 WORD and blit width decreased by 1 WORD. When the dest pixel offset is <= -16 (so even further out of screen) reduce blit size, increase source address, increase modulos, dest address will always be WORD offset -1 (case (a), or 0 (case b and c)) |
24 July 2021, 13:11 | #29 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
Quote:
Quote:
Without testing it, I'd say a) should definitely work. I don't see any reason why b) and c) wouldn't work as you describe them, but as I said - I didn't do any tests. |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Immediate Blitter & Wait for Blitter... | volvo_0ne | support.WinUAE | 32 | 18 September 2022 09:52 |
wait for blitter vs immediate blitter | jotd | support.WinUAE | 1 | 08 September 2020 04:14 |
Audio adapters - cheapest way to add an audio input to my A1200? | Laika | support.Hardware | 10 | 21 February 2019 18:11 |
Blitter busy flag with blitter DMA off? | NorthWay | Coders. Asm / Hardware | 9 | 23 February 2014 21:05 |
increase 1 layer size without affecting the rest | turrican3 | support.WinUAE | 3 | 23 September 2013 01:01 |
|
|