@kolla

Quote:

kolla wrote: @cdimauro Well, without any implementation to show for, there isn’t much value in these hypothetical “should have, could have” games, is there?

An implementation is NOT needed to prove it.
Quote:

And soon 40 years of hindsight.

The past is the past and cannot be changed.

However you continue to miss the point for this part of discussion, which I recap for your benefit.

There's an urban legend which is floating around since the Amiga was born, and that says that bitplanes were much more efficient than packed graphic.

This was also REPEATED by the Amiga's creator AFTER several years.

So, it's NOT hindsight rebutting this false statement. Rather, it's about dismantling a wrong statement.

I hope that it's clear now.

@cdimauro

A big difference between you and Jay Miner is that he designed and created hardware that would actually display graphics. Anyways, this “urban myth” seems to be repeated also on Wikipedia and elsewhere (without any quotes to Jay Miner, and it’s not like Amiga was the only system with planar graphics) so I think perhaps there are others you need to convince than us leg-pullers here at awn :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Here's a Gedankenexperiment:

You have two 256 colour bitmaps, each of which you can access as 8, 16 or 32 bit word sizes:
- Bitmap A uses 8 separate bitplanes.
- Bitmap B uses 1 byte per pixel.

You need to provide some basic drawing routines:
- Bresenham Line (any colour index)
- Trapezoid (any colour index)
- Rectangular Block Fill (any colour index)
- Rectangular Block Copy

Can you devise any algorithms for these that has lower complexity (fewer steps) for A than B?

Try the same thing again in 16 colours:
- Bitmap A uses 4 separate bitplanes.
- Bitmap B uses 1 byte per 2 consecutive pixels (nybble each).

I don't think I can think of an algorithm that's better for A in either of the above cases. So these are obvious cases and everyone knows chunky 8-bit pixels are faster for basic pixel operations.

Now let's get tricky and use 8 colours:
- Bitmap A uses 3 separate bitplanes.
- Bitmap B uses 3 bytes per 8 consecutive pixels.

Even with the additional complexity of masking out a single 3-bit pixel, I can't see that I can make a algorithm that's faster for A, simply because whatever algorithm I come up with for any planar display, I have to execute N times to make sure that all the drawn pixels have the right colour, whereas for the consecutive packed pixel mode, I can do it once. I can't just ignore any planes that have a zero bit for my colour index because they might already have bits set to 1 on the coordinate I need to render to.

For planar, we could think of interleaving the planes in such a way that for an N-bit display, each successive 32-bit word comprises the next bit plane for a span of 32 pixels. It would improve data locality somewhat but I can't see it resulting in an algorithm that's simpler than accessing the whole pixel in one step.

Hmm.

I can think of some nifty ways of setting all 32 bits of a word to match a bit position in a colour index that would definitely help with block filling planes but it would only be approaching the efficiency of filling packed pixels. No help at all for single pixel operations.

Last edited by Karlos on 01-Jun-2022 at 07:23 PM.
Last edited by Karlos on 01-Jun-2022 at 07:04 PM.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @cdimauro A big difference between you and Jay Miner is that he designed and created hardware that would actually display graphics.

This is a very common logical fallacy, the Argument from authority: https://en.wikipedia.org/wiki/Argument_from_authority
Quote:

Anyways, this “urban myth” seems to be repeated also on Wikipedia and elsewhere

And this is another logical fallacy, the Argumentum ad populum: https://en.wikipedia.org/wiki/Argumentum_ad_populum
Quote:

(without any quotes to Jay Miner,

I've reported his words from an interview which is on YT.
Quote:

and it’s not like Amiga was the only system with planar graphics)

This is again the Argumentum ad populum...

Logic isn't your friend, eh? But it looks lacking on the Amiga land...
Quote:

so I think perhaps there are others you need to convince than us leg-pullers here at awn :)

As I've said, I'll write an article about it.

I've no problem proving to the world that the above is an urban legend: math in on my side.

However Karlos already brought some concrete data and facts that shown it. Care to dismantle them?

You can call the best Amiga game coders and even all of them together: there's no way that any of them can prove that planar graphics is better than packed (except for the case of updating a single or a few bitplanes compared to the total amount).

@Karlos

You have two 256 colour bitmaps, each of which you can access as 8, 16 or 32 bit word sizes:
- Bitmap A uses 8 separate bitplanes.
- Bitmap B uses 1 byte per pixel.

One byte from BitMap A is the same as 8 bytes or 2 x 32bit ints (or a 64bit int depdning on the CPU) in BitMap B.

in bitmap A0, you all bits has value of 1
in bitmap A1, all your bits has value of 2
in bitmap A2, all your bits has value of 4
in bitmap A3, all your bits has value of 8
in bitmap A4, all your bits has value of 16
in bitmap A5, all your bits has value of 32
in bitmap A6, all your bits has value of 64
in bitmap A7, all your bits has value of 128

so if have lookup table result of all the 8 bitmaps,
you only need to read from index table, get 2 x ints.
and or the result and write out data into the BITMAP2, converting 32bit.

The output bitmap should by aligned with 8 bytes or 16bytes per row.

most optimal convertion should be....
8 reads, 8 or's and 1 write, muliply by (width/8) * height

on some 32bit CPU's its.
16 reads, 16 or's and 2 write, muliply by (width/8) * height

If you know altivec/vmx/mmx, you can maybe compress it doing like 128bit or 256bits operations, this can give fewer writes, and more speed. 128bit as that equal to 16bit planar convertion routine is ideal, the tables are only 65536 bytes per table.

Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:54 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:47 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:44 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:43 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:42 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:37 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:36 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:35 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:31 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:29 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

A lookup table is additional memory accesses though. Your response doesn't answer the question either.


Try to implement the first line drawing algorithm with this scheme and compare it to a chunky pixelmap.

If the line drawing algorithm is too difficult, consider just setting a single pixel.

If I use 32 bit words as my primitive for plane access, and I'm setting the colour of a single pixel, I have to do 8 32-bit data reads and up to 8 writes for that (depending on the colour index value I may get lucky and discover the bit I need to set or clear already has the desired value and I can skip a write, but I still had to read). Already that's a ton of IO and conditional cases.

Only in the best case that I'm drawing a horizontal span of 32 pixels does it reduce to 8 direct word writes and no reads. A chunky pixel could be set directly with one byte write but even if you were restricted to 32-bit transfers only, it's one read and one write for the single pixel case.

Last edited by Karlos on 01-Jun-2022 at 08:57 PM.
Last edited by Karlos on 01-Jun-2022 at 08:50 PM.

_________________
Doing stupid things for fun...

@Karlos

The complexity increases with etch plane, a 1 plane bitmap (2 colors), will be as fast as copy routine almost.

Last edited by NutsAboutAmiga on 01-Jun-2022 at 08:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Again, describe how you would plot a single pixel to an 8 bit colour index in a planar display comprising of 8 separate bitplanes. This is the simplest operation feasible.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

Any sane person will just switch to Windows/Linux/OSX. Amiga OS or it clone on commodity hardware may be 10% maybe 15% worse Windows/Linux/OSX.

Hello Mr Hermans.

@Karlos

setbit = 0x80 >> (X % 8);
maskbit = ~setbit;
ByteX = X / 8;
INDEX = ByteX + Y * BytesPerRow;

*(plane0 + INDEX) = (*(plane0 + INDEX) & MaskBit) | (color & 1 ? setbit : 0)
*(plane1 + INDEX) = (*(plane1 + INDEX) & MaskBit) | (color & 2 ? setbit : 0)
*(plane2 + INDEX) = (*(plane2 + INDEX) & MaskBit) | (color & 4 ? setbit : 0)
*(plane3 + INDEX) = (*(plane3 + INDEX) & MaskBit) | (color & 8 ? setbit : 0)
*(plane4 + INDEX) = (*(plane4 + INDEX) & MaskBit) | (color & 16 ? setbit : 0)
*(plane5 + INDEX) = (*(plane5 + INDEX) & MaskBit) | (color & 32 ? setbit : 0)
*(plane6 + INDEX) = (*(plane6 + INDEX) & MaskBit) | (color & 64 ? setbit : 0)
*(plane7 + INDEX) = (*(plane7 + INDEX) & MaskBit) | (color & 128 ? setbit : 0)

“(color & (1 < < plane) ? setbit : 0)” this can maybe be made faster by lookups.
or at least you do it when seting the pen color, before doing the pixel plot.

Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:33 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:32 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:25 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:25 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:18 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:15 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:15 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:14 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Now try again to set a single pixel in the chunky bitmap...

Last edited by Karlos on 01-Jun-2022 at 09:18 PM.

_________________
Doing stupid things for fun...

@Karlos

chunky8bit[y*BytesPerRow+x] = color;

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

The result was never in doubt of course.

Obviously once you are doing block fills horizontally, you can get to a point where you can do planar or chunky in a similar efficiency.

Last edited by Karlos on 01-Jun-2022 at 09:24 PM.

_________________
Doing stupid things for fun...

@Karlos

Naturally you want avoid doing planar on modern graphic systems, but its 100% doable, and depending how often you need to display result, and size of image.

With block fill, you do some interesting things, with bits in planar mode.

I think real benefits, if you’re not changing all planes, but only doing some planes, do some kind transparency, or stencil / layering effects. Planar mode can be fast to use in collision detection rutines. Working with bob’s is also not the worst thing, when copying more then 16-pixel width images.

Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:41 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:40 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:37 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

I can dream up operations in which planar nodes are faster. I remember doing demo effects with pseudo transparent polygons in which each basic polygon was rendered into a plane and the palette was set up to have intersection colours defined. Using the blitter to draw the polygons and the copper to modify the palette for some shading effects I got pretty nice results that looked like shaded transparency. This was a use case to which planar graphics was uniquely suited.

However, for almost every normal drawing operation, planar is a pain.

Last edited by Karlos on 01-Jun-2022 at 09:45 PM.

_________________
Doing stupid things for fun...

@Karlos

But it is the Amiga legacy, that have to deal with when we are working on old source code, or messing around on classic Amiga System.

Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:55 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 09:54 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

The context is the efficiency of packed versus planar. You've already demonstrated the worst case for planar, the single pixel write.

_________________
Doing stupid things for fun...

@Karlos

when looking at the pixel plot code, I think I can do one better with different functions for different color values. you can set a function pointer to the rutine to use. or function table.

something like

setPixel[color](x,y);

you do a "&clearBit" on the bytes you like set to 0, and "|setBit" on the bytes like set.
(where clearBit is a not'ed value)

256 different routines , small code generator, or self-modifying code, if can’t have the bloat.

Get pixel, is one that is the worst case, as you can’t predetermine the value

Last edited by NutsAboutAmiga on 02-Jun-2022 at 12:25 AM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:24 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:21 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:20 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:19 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:12 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:10 PM.
Last edited by NutsAboutAmiga on 01-Jun-2022 at 11:09 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: I think real benefits, if you’re not changing all planes, but only doing some planes, do some kind transparency, or stencil / layering effects.

That's what I've already said several times:
"there's no way that any of them can prove that planar graphics is better than packed (except for the case of updating a single or a few bitplanes compared to the total amount)".

However those aren't that common use cases.

On Amigas common cases were/are "cookie-cut" (rendering BOBs), filling AKA restoring the background (which was made dirty by rendering a BOB, for example), moving rectangular regions AKA windows, filling rectangular regions with a color and/or pattern, drawing lines with a color/pattern, etc.

If you write code for each use case you will see yourself that there's no chance that planar could do better than packed.
Quote:

Planar mode can be fast to use in collision detection rutines.

Why? If you use a single bitplane to check them, planar and packed graphics are equivalent (1 bit per pixel is the "common denominator": they exactly match).
Quote:

Working with bob’s is also not the worst thing, when copying more then 16-pixel width images.

That's the exact contrary: BOBs ("cookie-cut" method) is the absolute worst case, where planar graphics miserably fails compared to packed graphics, whatever is the BOB size (so, even for less than 16 pixels width, or for multiple of 16).

You can do the math yourself: take any scenario (less than 16 pixels, exactly 16 pixels, 32/48/64/etc. pixels) and you immediately see how bad is planar. And of course, the more the pixel depth, the worse it becomes. No chance...

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos when looking at the pixel plot code, I think I can do one better with different functions for different color values. you can set a function pointer to the rutine to use. or function table. something like setPixel[color](x,y); you do a "&clearBit" on the bytes you like set to 0, and "|setBit" on the bytes like set. (where clearBit is a not'ed value) 256 different routines , small code generator, or self-modifying code, if can’t have the bloat. Get pixel, is one that is the worst case, as you can’t predetermine the value

All of this super-complications for just setting a pixel.

And you're still light years behind packed...

Now imagine the above common scenarios that I've reported, and think about implementing them with bitplanes.

0 Bitplanes!

Last edited by QBit on 02-Jun-2022 at 07:32 AM.
Last edited by QBit on 02-Jun-2022 at 07:02 AM.
Last edited by QBit on 02-Jun-2022 at 06:57 AM.
Last edited by QBit on 02-Jun-2022 at 06:56 AM.
Last edited by QBit on 02-Jun-2022 at 06:46 AM.
Last edited by QBit on 02-Jun-2022 at 06:41 AM.
Last edited by QBit on 02-Jun-2022 at 06:38 AM.
Last edited by QBit on 02-Jun-2022 at 06:31 AM.
Last edited by QBit on 02-Jun-2022 at 06:28 AM.
Last edited by QBit on 02-Jun-2022 at 06:24 AM.
Last edited by QBit on 02-Jun-2022 at 06:14 AM.
Last edited by QBit on 02-Jun-2022 at 06:07 AM.
Last edited by QBit on 02-Jun-2022 at 06:01 AM.
Last edited by QBit on 02-Jun-2022 at 05:58 AM.
Last edited by QBit on 02-Jun-2022 at 05:53 AM.
Last edited by QBit on 02-Jun-2022 at 05:49 AM.
Last edited by QBit on 02-Jun-2022 at 05:45 AM.
Last edited by QBit on 02-Jun-2022 at 05:40 AM.
Last edited by QBit on 02-Jun-2022 at 05:37 AM.