21 June 2020, 21:29 | #1 |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
Benefit of interleaved gfx data
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. |
21 June 2020, 21:32 | #2 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,213
|
It allows opaque blits to be combined into one tall one. It avoids interrupts this way.
|
21 June 2020, 22:14 | #3 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 908
|
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. |
22 June 2020, 00:18 | #4 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,450
|
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. |
22 June 2020, 07:58 | #5 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,366
|
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.
|
22 June 2020, 10:58 | #6 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,368
|
|
22 June 2020, 11:27 | #7 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 908
|
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?
|
22 June 2020, 13:38 | #8 |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
What do you mean by mask? I thought that one can define an offset so you can blit smaller areas into bigger areas.
|
22 June 2020, 14:02 | #9 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 908
|
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).
|
22 June 2020, 15:02 | #10 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,503
|
Quote:
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. Last edited by ross; 22 June 2020 at 15:19. Reason: my usual typos.. |
|
22 June 2020, 15:10 | #11 |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
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. |
22 June 2020, 15:59 | #12 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
|
|
22 June 2020, 16:15 | #13 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,503
|
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. |
22 June 2020, 16:44 | #14 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
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. |
22 June 2020, 17:58 | #15 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,503
|
Quote:
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 Last edited by ross; 22 June 2020 at 19:17. Reason: cut, because some things I wrote didn't make much sense or needed to be developed better ;) |
|
22 June 2020, 18:29 | #16 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,368
|
Quote:
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. |
|
26 June 2020, 09:39 | #17 | |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 193
|
Quote:
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. |
|
26 June 2020, 15:08 | #18 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,368
|
Quote:
Quote:
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. Quote:
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. |
|||
26 June 2020, 15:40 | #19 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,450
|
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. |
27 June 2020, 20:51 | #20 | |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
Quote:
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. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Raw Interleaved Graphics | Hungry Horace | Coders. General | 12 | 28 January 2023 23:30 |
Interleaved graphics in Blitz | earok | Coders. Blitz Basic | 6 | 31 March 2019 22:34 |
interleaved bitmap / doublebuffering | grond | Coders. System | 1 | 16 July 2015 23:18 |
BLITZ2 : interleaved bitmap | Raislin77it | Coders. General | 0 | 22 April 2014 21:28 |
interleaved bitmaps and blitting | h0ffman | Coders. Asm / Hardware | 6 | 07 December 2013 20:58 |
|
|