Help with BLTSIZE and image width (in words): do we have to add 1 word to it?

[axilmar]

By the way, the Amiga Hardware Reference Manual does not mention anywhere that words passed to BLITSIZE width should be incremented by 1 if there is shifting involved.

I scanned the document's relevant paragraph at least 3 times...either I am blind and missed it or this detail is not mentioned.

[jotd]

Originally Posted by axilmar

Sorry, what is not clear?

'x' is the destination position.
'x & 15' is extracting the lower 15 bits.
This is compared to 0: if true, then 16 is divided to 16, so the result is 1 word, otherwise, if there is a shift involved, 32 is divided to 16.

just bad experience from a game I wrote on the Amiga which used C++.

I love the language but my experience was that the game was bloated, big and unefficient despite using blitter

I know it's possible to write efficient amiga code in C, but I just can't do it. Back to asm.

(and I coded C and C++ for decades, I'm currently a C++ trainer in my company, I love C++ but I hate when code tries to get as close to the machine as possible and gets caught in implicit unsigned/signed cast, size cast (and truncation), to name a few.

[roondar]

Originally Posted by axilmar

By the way, the Amiga Hardware Reference Manual does not mention anywhere that words passed to BLITSIZE width should be incremented by 1 if there is shifting involved.

I scanned the document's relevant paragraph at least 3 times...either I am blind and missed it or this detail is not mentioned.

The thing is that this bit of information is not disussed in the section about shifts & masks, but rather in the section about "Copying Arbitrary Regions".

From that section:

Originally Posted by HRM

A source image that spans only two words may, when copied with certain shifts , span three words. Our 23 pixel wide rectangle above, for instance, when shifted 12 bits, will span three words. Alternatively, an image spanning three words may fit in two for certain shifts . Under all such circumstances, the blit size should be set to the larger of the two values, such that both source and destination will fit within the blit size. Proper masking should be applied to mask out unwanted data.

So it is mentioned, just not where the shifting is initially explained. Which is confusing, but there you have it

Source: http://amigadev.elowar.com/read/ADCD.../node0121.html

[axilmar]

Originally Posted by roondar

The thing is that this bit of information is not disussed in the section about shifts & masks, but rather in the section about "Copying Arbitrary Regions".

From that section:

So it is mentioned, just not where the shifting is initially explained. Which is confusing, but there you have it

Source: http://amigadev.elowar.com/read/ADCD.../node0121.html

Yes, indeed. Thank you. Now it is totally clear.

[axilmar]

Originally Posted by arcanist

My math for the BLTSIZE width is here (width_words).

It calculates which word the first pixel falls in. Then which word the pixel beyond the last pixel falls in. Subtract the two. Repeat for source/destination and take the larger of the two, to account for any shift.

I think it's correct for all shifts, but the HRM's vague descriptions led to much head scratching.

I tried your function 'blit_copy' to blit one part of the screen to the other part of the screen, but there was an issue:


https://ibb.co/6XHgfYP

I am using a descending blit (force_desc flag == 1), to blit a 16x16 image at position 0, 200 to position 1, 220. The result is the above.

If the target position is 0, 220, then there is no problem.

[roondar]

Originally Posted by axilmar

I tried your function 'blit_copy' to blit one part of the screen to the other part of the screen, but there was an issue:


https://ibb.co/6XHgfYP

I am using a descending blit (force_desc flag == 1), to blit a 16x16 image at position 0, 200 to position 1, 220. The result is the above.

If the target position is 0, 220, then there is no problem.

The issue is probably that the shift direction in descending mode is reversed (so the Blitter shifts to the left rather than the right). So, to plot to 1, 220 you need to shift left by 15 and add 2 bytes to the starting pointer (compared to blitting in ascending mode).

[axilmar]

Originally Posted by roondar

The issue is probably that the shift direction in descending mode is reversed (so the Blitter shifts to the left rather than the right). So, to plot to 1, 220 you need to shift left by 15 and add 2 bytes to the starting pointer (compared to blitting in ascending mode).

I have made sure the shift value is 15.

I have added 2 bytes to the destination start address.

It still does not work. The result is this:

https://ibb.co/6rkRf7S

If I subtract 2 bytes from the destination start address, the result is this (the last pixel column in missing):

https://ibb.co/cQY83vH

And if I move the source image to x=16 and the destination to x=17, I get this:

https://ibb.co/smYrFNV

[roondar]

Originally Posted by axilmar

I have made sure the shift value is 15.
I have added 2 bytes to the destination start address.

Hmm, next question: did you also add 2 bytes to the source start address?

Reason for asking is that all the pictures you show seem to me to be consistent with the shift going across the word boundary. This is why it seems to me to be a descending mode vs ascending mode setup issue.

Hope you get it figured out

[axilmar]

Originally Posted by roondar

Hmm, next question: did you also add 2 bytes to the source start address?

Reason for asking is that all the pictures you show seem to me to be consistent with the shift going across the word boundary. This is why it seems to me to be a descending mode vs ascending mode setup issue.

No, I have not added 2 bytes to the source start address.

If I also add 2 bytes to the source start address, it blits the white background.

Originally Posted by roondar

Hope you get it figured out

It seems I cannot figure it out. Everything seems to be correct. I have spent the last 5 hours scratching my head, doing small test changes, reading and reading the hardware reference manual and other sites, but I still cannot figure it out.

Here is the code:

https://pastebin.com/eiAeXVgm

I am trying to create a blit function for moving bits around within an image.

The code is based on the function 'copy_blit' by arcanist.

For ascending mode, it works perfectly, for all positions and blit sizes.

[roondar]

Originally Posted by axilmar

No, I have not added 2 bytes to the source start address.

If I also add 2 bytes to the source start address, it blits the white background.

Appologies, I made an error here. In descending mode, all pointers should start at the very last word of the blit. Assuming you've already done this for the source, the same goes for the destination.

Setting up for a position which takes into account shifting is then done by moving the destination pointer only, not the source. So you indeed don't need to add 2 bytes to the source.

Here is the code:

https://pastebin.com/eiAeXVgm

For ascending mode, it works perfectly, for all positions and blit sizes.

Looking at the code, it seems like you might not be setting the correct masking values. In descending mode, the two masks are reversed in order (i.e. ALFWM masks the last word instead of the first and vice versa).

Originally Posted by HRM

...
the first word mask masks the last word in a row (which is still the first word fetched), and the last word mask masks the first word in a row
...

[axilmar]

Originally Posted by roondar

Appologies, I made an error here. In descending mode, all pointers should start at the very last word of the blit. Assuming you've already done this for the source, the same goes for the destination.

Setting up for a position which takes into account shifting is then done by moving the destination pointer only, not the source. So you indeed don't need to add 2 bytes to the source.

Looking at the code, it seems like you might not be setting the correct masking values. In descending mode, the two masks are reversed in order (i.e. ALFWM masks the last word instead of the first and vice versa).

The code already reverses the mask values, at lines 43/44.

[roondar]

Originally Posted by axilmar

The code already reverses the mask values, at lines 43/44.

To be honest, I did not manually calculate the values generated by the code for the mask, but I'd say that just swapping the values around as you do is not enough unless the mask is set to either $ffff or $0000.

Here's my thought experiment:

Suppose that the ascending mask is set to first word %000111 and last word %100000 (pretending this mask represents all 16 bits rather than just 6). For descending mode this needs to be flipped around because the first word mask is applied to the last word of each line and vice versa.

But that would mean that the first word fetched (i.e. the last word in the blit) now has a mask of %000111, which is surely not correct as that cuts of pixels on left and leaves pixels on the right. My guess is that you'd instead need to generate a mask based on the shift value and direction.

Edit: this would be a lot easier if I actually had access to my assembler to check some stuff. Doing it all from memory is not the best way
Edit 2: the above is not correct, I forgot that flipping the two values around does mean the last word in the blit gets the correct value.

The only thing I'm still wondering about is what the left vs right shift means for the value of the mask. I'm still thinking that a mask for a left-shift blit and a mask for a right-shift mask can't be the same.

[axilmar]

Originally Posted by roondar

To be honest, I did not manually calculate the values generated by the code for the mask, but I'd say that just swapping the values around as you do is not enough unless the mask is set to either $ffff or $0000.

Here's my thought experiment:

Suppose that the ascending mask is set to first word %000111 and last word %100000 (pretending this mask represents all 16 bits rather than just 6). For descending mode this needs to be flipped around because the first word mask is applied to the last word of each line and vice versa.

But that would mean that the first word fetched (i.e. the last word in the blit) now has a mask of %000111, which is surely not correct as that cuts of pixels on left and leaves pixels on the right. My guess is that you'd instead need to generate a mask based on the shift value and direction.

Edit: this would be a lot easier if I actually had access to my assembler to check some stuff. Doing it all from memory is not the best way
Edit 2: the above is not correct, I forgot that flipping the two values around does mean the last word in the blit gets the correct value.

The only thing I'm still wondering about is what the left vs right shift means for the value of the mask. I'm still thinking that a mask for a left-shift blit and a mask for a right-shift mask can't be the same.

I don't think the first and last word masks affect the destination...it only affects how the are retrieved from the source.

Anyway, even if I use 0xffff for both first and last world masks, nothing changes.