Blitter affecting audio?

[pink^abyss]

Originally Posted by phx

With the usual technique (ScrollingTrick.lha) you need three extra columns for horizontal scrolling. Not two.

I don't know about this ScrollingTrick.lha but two columns is correct.

[pink^abyss]

Originally Posted by aros-sg

Really? Assuming a non scrolling at all screen with visible 320 pixels. Does it still need to be 320+16+16 internally for clipping to work? That would suck. Can't that be avoided some way by for example using descending blit mode for clipping at the left side.

Isn't any modification to the base blit some kind of clipping?
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.

[pink^abyss]

Originally Posted by aros-sg

Assuming 16x16 tiles, then for scrolling you only need 16 + 16 extra pixels. So for visible width of 320 pixels (max. 21 visible tiles) = 320 + 32 = 352. I don't think that's is enough space for unclipped 32 pixel wide bobs.

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.

[phx]

Originally Posted by aros-sg

No, only two and you know that because I corrected you about that already once or twice. I wrote ScrollingTrick.lha.

LOL
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(?).

[roondar]

Originally Posted by aros-sg

Really? Assuming a non scrolling at all screen with visible 320 pixels. Does it still need to be 320+16+16 internally for clipping to work? That would suck. Can't that be avoided some way by for example using descending blit mode for clipping at the left side.

Well, you don't actually need any space for clipping if you don't want to. Just write a clipping routine that is pixel perfect and you're all set

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.

[aros-sg]

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

[roondar]

Originally Posted by aros-sg

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.

I admit that I haven't seen that much real world game code, but the code I did see generally didn't clip at all and instead used space around the bitmap that was as big as the biggest BOB drawn (usually 32 pixels).

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

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

I'm not sure what you mean here. As far as I understand it, while many registers need to be set differently the only real change that might impact clipping is the difference in shift direction. Or am I missing something?

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?

[aros-sg]

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))

[roondar]

Originally Posted by aros-sg

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.

Yeah, that indeed how I approached it

I just don't want no WORDs to be changed (blitted) outside the screen.

Right, this is what I call 'pixel perfect clipping'. I don't do that myself, but it's perfectly reasonable and possible to want/do this. And like you say, it would save a bit of memory to do it that way (if you're not using horizontal scrolling).

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))

Thanks, I get it now.
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.