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

[axilmar]

Hi.

I've been playing with the template code for Visual Studio Code + WinUAE (found here: https://github.com/BartmanAbyss/vsco...emplate/main.c).

At line 476, the code is:

custom->bltsize = ((16 * 5) << HSIZEBITS) | (32/16);

The size of displayed image is defined as 32 pixels (in "32/16"), however the image is 16 pixels wide.

I.e. the number of words given to the BLTSIZE register for width is 2, while the graphic is 16 pixels, and that number should be 1.

Is that because the graphic is actually interleaved? i.e. because each row contains image bitplane data followed by mask data? do we have to add the mask size to the image size to get the proper width to pass to BLTSIZE if the image is interleaved?

I've seen in various source code examples that sometimes 1 is added to the number of words given to BLTSIZE and sometimes it is not.

I've been searching online for a lot of hours but I can't find an answer to this...neither could I find answer to this in this forum...any help will be appreciated.

[DanScott]

You usually have to have an extra word to shift into, so if the source image is 16 pixels (1 word) wide, your blitsize width will be 2 words.

This only applies if you are shifting (for example masked bobs etc..)

[jotd]

Even with a zero shift value you have to add 2 bytes at the end of each line of the source.

If it's possible to do without that, that would interest me (same for rectangle fill)

[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.

[DanScott]

Originally Posted by jotd

Even with a zero shift value you have to add 2 bytes at the end of each line of the source.

If it's possible to do without that, that would interest me (same for rectangle fill)

No, not true.. a 16 pixel wide object blitted without any shifting, can use a width of 1 word in BLTSIZE

and (for example) a 24 pixel wide object (with a BLTSIZE of 2 words), could be shifted from 0-7 without adding the extra word too

[mc6809e]

The width is determined by the needs of the destination and not by the source.

Even a two-pixel-wide source will need an extra word on each line if there is any possibility that the blitter will have to touch two words per line at the destination. For example, if bit 15 of the source (first pixel) needs to be written to bit 0 of the destination (last pixel of a word) then the second pixel needs to be written to bit 15 of the next word in the bitplane. The two.pixels from one source word span two words at the destination.

Basically if the last pixels of a line of the source ever need to cross a word boundary at the destination, then an extra source word is required.

Conversely, if the last pixels of a line of the source NEVER need to cross a word boundary at the destination, then no extra word is needed.

[axilmar]

So, the blit width has nothing to do with the source, it has to do with how many words per line the blitter will affect in the destination?

[mc6809e]

Originally Posted by axilmar

So, the blit width has nothing to do with the source, it has to do with how many words per line the blitter will affect in the destination?

Pretty much. Of course that also determines how many words will be read from the source whether the source in terms of actually used bits is really that wide or not, hence the need to.pad the source.

You can even store the source image with the extra words for use with some blits but ignore them for others where the last pixels on a source line don't cross a word boundary at the destination -- as long as you take care to properly adjust the modulo values. This will save blitter cycles on average.

Lets say you have a 24 pixel wide object. For shifts up to 7 you only affect two words in the destination. For larger shifts it affects three words. The width and modulos used will be different in the two cases.

[axilmar]

Originally Posted by mc6809e

Pretty much. Of course that also determines how many words will be read from the source whether the source in terms of actually used bits is really that wide or not, hence the need to.pad the source.

You can even store the source image with the extra words for use with some blits but ignore them for others where the last pixels on a source line don't cross a word boundary at the destination -- as long as you take care to properly adjust the modulo values. This will save blitter cycles on average.

Lets say you have a 24 pixel wide object. For shifts up to 7 you only affect two words in the destination. For larger shifts it affects three words. The width and modulos used will be different in the two cases.

So if there is no shift to be involved, the bltsize should be equal to the width of the source image (in words)?

So if line 476 is changed to this (i.e. given bltsize is 16 if no shift is involved, otherwise 32):

custom->bltsize = ((16 * 5) << HSIZEBITS) | (((x & 15) == 0 ? 16 : 32)/16);

The result is this distorted image:

https://ibb.co/CMqVxZ5

So it does not seem to me that it is correct that one word is added to BLTSIZE if only a shift is involved.

Unless I have misunderstood something.

Could it be that the additional word is needed due to the bitmap being interleaved?

[jotd]

C expressions aren't making code any clearer

No it's not because of interleaved. It's bad input data. You have to add 2 words in your source too.

[axilmar]

Originally Posted by jotd

C expressions aren't making code any clearer

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.

Originally Posted by jotd

No it's not because of interleaved. It's bad input data. You have to add 2 words in your source too.

Eh? what does this mean? what two words to the source? why? the source pointer is computed as needed in the loop.

[Tigerskunk]

Originally Posted by axilmar

Sorry, what is not clear?

We are all Assembler people here...

[axilmar]

Originally Posted by Tigerskunk

We are all Assembler people here...

Hey, no problem with that, although I haven't written much MC68000 assembly, I can read such code.

What I can't understand through is why in the example given, the blit size is 2 words and not 1.

Shifting does not seem to play a role, as mentioned earlier, because I have already tested the case shift being 0 and it's 2 words for that case as well.

[roondar]

Originally Posted by Tigerskunk

We are all Assembler people here...

Indeed, I wrote C code profesionally for a decade and both during that time and afterwards, I've never liked the ? : operator. It just doesn't 'read' nicely for me and I always have to think twice about what it means.

Lot's of people do love it though, so it's clearly a personal preference

Originally Posted by axilmar

Hey, no problem with that, although I haven't written much MC68000 assembly, I can read such code.

What I can't understand through is why in the example given, the blit size is 2 words and not 1.

Shifting does not seem to play a role, as mentioned earlier, because I have already tested the case shift being 0 and it's 2 words for that case as well.

BLTSIZE can indeed be based on whether or not you need to shift. If no shift is needed, you don't need to add a word to the width. So in this case, a 16 pixel object blit (interleaved or no) requires a 2 word width for any shift other than 0* and a 16 pixel object blit with a shift of 0 requires a 1 word width.

*) note that I'm not going into the example given earlier of an object that has some empty room around it. Such objects can shifted without always needing the extra word, but I feel this muddles the basic discussion so I'll leave it here for 'tricks' and 'advanced use' - my post assumes only objects that are exact multiples of 16 pixels wide

[mc6809e]

Originally Posted by axilmar

So it does not seem to me that it is correct that one word is added to BLTSIZE if only a shift is involved.

Unless I have misunderstood something.

Could it be that the additional word is needed due to the bitmap being interleaved?

Are your modulo values correct? If your width is one word less then the modulo value must be increased by one (assuming the source is stored as a rectangular bitmap).

[DanScott]

Modulo needs adjusting depending on BLTSIZE width...

[axilmar]

Originally Posted by roondar

BLTSIZE can indeed be based on whether or not you need to shift. If no shift is needed, you don't need to add a word to the width. So in this case, a 16 pixel object blit (interleaved or no) requires a 2 word width for any shift other than 0* and a 16 pixel object blit with a shift of 0 requires a 1 word width.

But I just did this and it doesn't work like that.

[jotd]

create some simple example so people can check.

Every time I had problems either I found the problem (usually wrong data source, wrong modulo, wrong size...) or provided a simple example so everyone can check what's wrong

[roondar]

Originally Posted by axilmar

But I just did this and it doesn't work like that.

It could be (as DanScott & mc6809e pointed out) an error in the modulo values: if you have a 2 word blit, the modulo values aren't going to be the same as for a 1 word blit. But the basic point, no shift means no extra word required, does hold.

[axilmar]

Indeed, the modulo needed fixing!

THANKS A LOT GUYS, much obliged.

Here is the code that currently works:

		for(short i = 0; i < 16; i++) {
			const short x = i * 16 + sinus32[(frameCounter + i) % sizeof(sinus32)] * 2;
			const short y = sinus40[((frameCounter + i) * 2) & 63] / 2;
			const APTR src = (APTR)bob + 32 / 8 * 10 * 16 * (i % 6);
			const short w = (x & 15) == 0 ? 16 : 32;

			WaitBlt();
			custom->bltcon0 = 0xca | SRCA | SRCB | SRCC | DEST | ((x & 15) << ASHIFTSHIFT); // A = source, B = mask, C = background, D = destination
			custom->bltcon1 = ((x & 15) << BSHIFTSHIFT);
			custom->bltapt = src;
			custom->bltamod = w / 8;
			custom->bltbpt = src + w / 8 * 1;
			custom->bltbmod = w / 8;
			custom->bltbdat = 0xffff;
			custom->bltcpt = custom->bltdpt = (APTR)image + 320 / 8 * 5 * (200 + y) + x / 8;
			custom->bltcmod = custom->bltdmod = (320 - w) / 8;
			custom->bltafwm = custom->bltalwm = 0xffff;
			custom->bltsize = ((16 * 5) << HSIZEBITS) | (w/16);
		}

So indeed the shift value affects the width passed to BLTSIZE, and the modulos need adjustment too.

Superb!

Thanks again!