Benefit of interleaved gfx data

[sparhawk]

I was wondering what the benefit is if bitmaps are stored in interleaved format. As I understand it, normally you have single block for each bitmap with contigous memory. With interleaving, the bitmaps are stored one line after the other, and the modulo must be added, so you get the next line.


Since the M68k has no memory caching, I dont understand what kind of benefits one gets from this approach.

[Samurai_Crow]

It allows opaque blits to be combined into one tall one. It avoids interrupts this way.

[alpine9000]

Advantage: CPU only needs to get involved once per blit.

Disadvantage: Masks are N times larger (using more chip ram) where N is the number of bitplanes you are blitting.

[roondar]

Yup, as pointed out in the posts above it's all about how often the Blitter needs to be set up/started to draw to all bitplanes.

I've found (in general - with my code at any rate) that interleaved Bobs are roughly 10-15% faster to draw than non-interleaved Bobs. The exact speed increase will depend on both the size of the object (smaller objects have relatively more CPU overhead so will gain more than bigger ones) and the number of bitplanes (more bitplanes means a bigger gain).

Whether this is worth the extra memory use is of course debatable. I've almost always opted for interleaved bitmaps myself, but if you don't need the speed it's just lost memory and some minor limitations over a non-interleaved approach, for no real gain.

[meynaf]

There is an advantage of using interleaved bitmaps in case you use the CPU to access the screen : you can do everything from a single pointer, which means less pressure on the registers.

[Thomas Richter]

Originally Posted by alpine9000

Disadvantage: Masks are N times larger (using more chip ram) where N is the number of bitplanes you are blitting.

No, masks are exactly the same size. BlitMaskBitMapRastPort() is just broken on 3.1 on interleaved bitplanes. That got fixed in 3.1.4.

[alpine9000]

Originally Posted by Thomas Richter

No, masks are exactly the same size. BlitMaskBitMapRastPort() is just broken on 3.1 on interleaved bitplanes. That got fixed in 3.1.4.

If you use the blitter directly and do a single “blit” for all bitplanes the masks needs to be the same size as the source data. I assume what you’re saying is that BlitMaskBitMapRastPort does an individual blit for each bitplane even when using interleaved bitplanes? Which is fine, but removes one of the reasons for using interleaved bitplanes?

[sparhawk]

What do you mean by mask? I thought that one can define an offset so you can blit smaller areas into bigger areas.

[alpine9000]

Originally Posted by sparhawk

What do you mean by mask? I thought that one can define an offset so you can blit smaller areas into bigger areas.

If you do a cookie cut blit (draw a non rectangular image over a background image) you need source data (image) as well as another plane of data (mask) that is used by the blitter to determine which pixels of the image are drawn and which pixels should show the background (transparent).

[ross]

Originally Posted by sparhawk

What do you mean by mask? I thought that one can define an offset so you can blit smaller areas into bigger areas.

What alpine9000 wrote (and others before) is right.

I go into some technical details about the blitter, maybe is even clearer for you (it has been helpful to me in the past).

Suppose that your sprite image, to be copied in the background, requires several bitplanes and therefore normally you should do n operations with the blitter.
In each bplane of your sprite there are several pixels at 0 and 1, but not all those at 0 must be transparent (i.e. that display the underlying background) but some 0s are significative for other bits in the other planes (logically if there are only 0s for the pixel in all the bplanes the wanted view is for a transparent color).

How to define which 0 bits are significant? By creating a mask where if at least one of the bits in the various bplanes of the initial sprite is at 1, thus defining a color, then the mask will have bits at 1 (so the mask could be easy generated at runtime..).

Now suppose to use the blitter with a logical operation (minterm) so to extract only the bits useful for the destination, that is:
A = mask, B = sprite, C = background (sources) and D = AB + A'C (destination)
(translated: for bits at 1 in the mask take the bit from the sprite image, otherwise from the background)

This is what is called cookie-cut, i.e. a blitting operation for a rectangular 'carved' source image (which actually defines a non-rectangular image, a sprite).
Obviously A and B have been chosen as sources for their masking characteristics of the edges and free shift operation included.

For interleaved bitmaps, because of the unique operation for all bitplanes, the mask need to be replicated in memory for all bitplanes (every single line of the mask need to be n-replicated, with n = bplane number, to be in sync with the interleave).
Raw blitter speed is the same, but overall, thanks to the single initialization, a faster operation, but bplane*mask in memory instead of 1*mask per image.

Cheers.

[sparhawk]

Thanks for the explanation!
I haven't yet started to work with the blitter, because currently I work on a gfx converter that can downscale colors from RGB PNG images. It will either write out PNG images (as desired) or bitplanes in raw format, so that I can simply load them directly into memory. And I read about this interleaving, so I thought it might be worth to support this as well, so I can convert an PNG to an Amiga interleaved (if desired). I was not sure if this really would be helpful, so I wanted to know first, if this is really useful to have, but from this thread it seems the answer is yes.

[Asman]

Originally Posted by ross

What alpine9000 wrote (and others before) is right.

I go into some technical details about the blitter, maybe is even clearer for you (it has been helpful to me in the past).

Suppose that your sprite image, to be copied in the background, requires several bitplanes and therefore normally you should do n operations with the blitter.
In each bplane of your sprite there are several pixels at 0 and 1, but not all those at 0 must be transparent (i.e. that display the underlying background) but some 0s are significative for other bits in the other planes (logically if there are only 0s for the pixel in all the bplanes the wanted view is for a transparent color).

How to define which 0 bits are significant? By creating a mask where if at least one of the bits in the various bplanes of the initial sprite is at 1, thus defining a color, then the mask will have bits at 1 (so the mask could be easy generated at runtime..).

Now suppose to use the blitter with a logical operation (minterm) so to extract only the bits useful for the destination, that is:
A = mask, B = sprite, C = background (sources) and D = AB + A'C (destination)
(translated: for bits at 1 in the mask take the bit from the sprite image, otherwise from the background)

This is what is called cookie-cut, i.e. a blitting operation for a rectangular 'carved' source image (which actually defines a non-rectangular image, a sprite).
Obviously A and B have been chosen as sources for their masking characteristics of the edges and free shift operation included.

For interleaved bitmaps, because of the unique operation for all bitplanes, the mask need to be replicated in memory for all bitplanes (every single line of the mask need to be n-replicated, with n = bplane number, to be in sync with the interleave).
Raw blitter speed is the same, but overall, thanks to the single initialization, a faster operation, but bplane*mask in memory instead of 1*mask per image.

Cheers.

I have question about cookie-cut. Can we just do D = B + A'C ?

[ross]

Originally Posted by Asman

I have question about cookie-cut. Can we just do D = B + A'C ?

Hi Asman , no.

D=AB+A'C
B=0, A=0 -> D = 0 + 1*x= x==background
B=0, A=1 -> D = 0 + 0*x= 0==B (thanks to A=1)
B=1, A=0 -> D = 0 + 1*x= x==background
B=1, A=1 -> D = 1 + 0*x= 1==B (thanks to A=1)

For
D=B+A'C
B=0, A=0 -> D = 0 + 1*x= x
B=0, A=1 -> D = 0 + 0*x= 0
B=1, A=0 -> D = 1 + 1*x= 1+x==1 (wrong)
B=1, A=1 -> D = 1 + 0*x= 1

There is an wrong possible result.

[Asman]

Hi ross

IMHO third option (with wrong mark) never happen. Damn... I am so stuborn and I am going to check this today evening. Thanks ross for force me to think and check about it.

[ross]

Originally Posted by Asman

Hi ross

IMHO third option (with wrong mark) never happen. Damn... I am so stuborn and I am going to check this today evening. Thanks ross for force me to think and check about it.

Well, if you generate statically the mask at run-time, you're right (the third option is impossible, A cannot be 0 when a single B=1 exist).
I've used 'wrong possible result' and not 'wrong result'.

But for the same object with different mask (like for special flash effect)?
Or sprite that add some adjunct (already in original sheet) and masked manually to be visible later?

So better use a generic minterm that works in all cases

[Thomas Richter]

Originally Posted by alpine9000

I assume what you’re saying is that BlitMaskBitMapRastPort does an individual blit for each bitplane even when using interleaved bitplanes? Which is fine, but removes one of the reasons for using interleaved bitplanes?

No, I'm not saying that. I am saying "the interface the Os provides has to be independent of the layout of the target bitmap", and it was not for 3.1 due to an oversight.



In fact, you probably do not want to know how this function works as it is radically slower than you may hope for, and its speed is pretty much independent on whether the bitmap is interleaved or not. It performs its operation by a double-XOR trick (actually, two BltBitMaps()) and thus it flickers. Ok for generic rendering, definitely not ok for animation.



The reasons for this are very technical, and due to a missing feature of the blitter. In essenence, if you blit masked to a rast port, you need to apply three masks at once, not only one, and that is where the trouble is coming from. One mask is the boundary of the rast port, the second from the size of the bitmap you blit from, and the third is the mask supplied. There is unfortunately no better generic solution to the problem.


If you can get away with sources and masks that are multiplies of 16 pixels wide, yes, then there are better solutions - that is what the GEL system does. If you want smooth animation, this system is the right answer, and not BlitMaskBitMapRastPort().


It's all very technical, really.

[aros-sg]

Originally Posted by Thomas Richter

The reasons for this are very technical, and due to a missing feature of the blitter. In essenence, if you blit masked to a rast port, you need to apply three masks at once, not only one, and that is where the trouble is coming from. One mask is the boundary of the rast port, the second from the size of the bitmap you blit from, and the third is the mask supplied. There is unfortunately no better generic solution to the problem.

That's unproven. Maybe no one has tried/thought hard enough. Maybe it's possible if you split up impossible (because of blitter's limited features) blits into two blits.


Simliar to BltBitMap() and it's tempA which is there because sometimes AFWM and ALWM are not enough and the routine needs a real A mask to mask out additional stuff -> in theory it may be possible for BltBitMap() to avoid that (not that it is necessarily the better/faster way) if instead it split up the blit into two?


Instead of:


XXXXXXXX
XXXXXXXX
XXXXXXXX


do:


XXXXXXXZ
XXXXXXXZ
XXXXXXXZ


ie. first blit does X, second blit does Z (column of last words).


If that would work with BltBitMap() theoretically (as said not the necessarily the better idea, as current way of creating real temp A mask may be faster, who knows) maybe something like that would also work with BltMaskBitMapRastPort() where - if that ends up being so - maybe would usually be faster than the current double XOR blit. Who knows.

[Thomas Richter]

Originally Posted by aros-sg

That's unproven. Maybe no one has tried/thought hard enough. Maybe it's possible if you split up impossible (because of blitter's limited features) blits into two blits.

Well, it is already split up into two blits....

Originally Posted by aros-sg

Simliar to BltBitMap() and it's tempA which is there because sometimes AFWM and ALWM are not enough and the routine needs a real A mask to mask out additional stuff -> in theory it may be possible for BltBitMap() to avoid that (not that it is necessarily the better/faster way) if instead it split up the blit into two?

In the BltBitmap() case, why is that any better? There is only a source and a destination, so one blit is sufficient even though it needs an extended mask.

BltMaskBitMapRastPort() is not a low-level function, but designed to operate on the existing "primitives", namely BltBitmap(). This is from a design point of view a good approach, though means that the higher level function is slower.

With your approach, another low-level blitter function would be needed, and would need to be debugged.

Originally Posted by aros-sg

A mask may be faster, who knows) maybe something like that would also work with BltMaskBitMapRastPort() where - if that ends up being so - maybe would usually be faster than the current double XOR blit. Who knows.

It might potentially be faster, yes, but it means that there is more to debug.

The faster alternative (speed wise) is the GEL system if you can get away with the limitation of source "bitplane" widths that are multiples of 16 pixels wide.

[roondar]

Personally, I don't think the goal of OS functions for graphics should necessarily be speed in the first place. They should mostly be aimed at working in as many situations as possible. Doesn't mean there can't be functions with additional restrictions that are faster, but I'd argue that interoperability, stability and compatibility are ultimately more important for most OS functions.

Size and speed are not unimportant, simply IMHO less important than the above.

[sparhawk]

Originally Posted by roondar

Size and speed are not unimportant, simply IMHO less important than the above.

What you said. I also think that stabillity is more important for an OS, then speed, because you can always write some specialized code for your particular problem. And the OS may be updated later if there is some better generic solution.