Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
22 crawler(s) on-line.
 164 guest(s) on-line.
 1 member(s) on-line.


 dirkzwager

You are an anonymous user.
Register Now!
 dirkzwager:  4 mins ago
 clint:  10 mins ago
 vox:  16 mins ago
 Gunnar:  19 mins ago
 pixie:  27 mins ago
 NutsAboutAmiga:  32 mins ago
 zipper:  1 hr 7 mins ago
 Templario:  1 hr 13 mins ago
 RobertB:  1 hr 32 mins ago
 GPTNederlands:  1 hr 48 mins ago

/  Forum Index
   /  Amiga Development
      /  Packed Versus Planar: FIGHT
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 Next Page )
PosterThread
MEGA_RJ_MICAL 
Re: Packed Versus Planar: FIGHT
Posted on 5-Jun-2022 23:57:06
#21 ]
Super Member
Joined: 13-Dec-2019
Posts: 1200
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 6-Jun-2022 21:32:52
#22 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@matthey

Quote:

matthey wrote:
Packed CLUT format makes sense for 2 (1 bit), 4 (2 bit), 16 (4 bit) and 256 (8 bit) color bitmaps as pixels never cross byte boundaries and remain byte aligned so only need one memory access. The original Amiga chipset did not have enough bandwidth for a 256 color packed CLUT so this would have meant the Amiga only would have had 16 colors max instead of 32 (no 4096 color HAM or 64 color EHB using 6 bit planes either).

The original Amiga chipset had the enough bandwidth for 320x200 (256 for PAL) 256 color graphics.

Exactly like it had enough of it for 640 x 200 (256 for PAL) 16 color graphics.
Quote:
This would have only affected low resolution which would have been limited to 16 colors like high resolution.

Low-res had 64 color in EHB... 256 would have been possible.
Quote:
Planar also saved some memory if 8 colors (3 bit planes) was adequate. I wonder if there would have been more motivation to upgrade the Amiga custom chips and gfx memory to have enough bandwidth for 256 colors had they gone the packed route.

Much more efficiency (less bandwidth, less space) should be more than enough as motivation.
Quote:
Jay Miner wanted dual ported VRAM for the Ranger chipset upgrade but even it only supported 128 colors (7 bit planes). Planar was more flexible, could save memory and could save bandwidth.

Absolutely no: see above. It's the exact opposite: planar required MORE memory and MORE bandwidth compared to the equivalent in packed graphics.
Quote:
Aligned packed mode would have been faster.

Even misaligned packed graphics would have been faster than the equivalent in planar.
Quote:
It should have been possible to make a blitter that could have handled unaligned packed formats but it would have increased complexity.

Yes, the Blitter is a bit more complicated. However the rest (display controller. In general: Denise + Agnus) is simpler.
Quote:
Original bit plane Amiga
low res: 2, 4, 8, 16, 32 colors + 4096 color HAM6 & 64 color EHB
high res: 2, 4, 8, 16 colors

Upgraded bit plane AGA Amiga
low res: 2, 4, 8, 16, 32, 64, 128, 256 colors + 262,144 color HAM8, 4096 color HAM6 & 64 color EHB
high res: 2, 4, 8, 16, 32, 64, 128, 256 colors + 262,144 color HAM8, 4096 color HAM6 & 64 color EHB

Packed Amiga
low res: 2, 4, 16 colors
high res: 2, 4, 16 colors

Upgraded packed Amiga
low res: 2, 4, 16, 256 colors (packed HAM8?)
high res: 2, 4, 16, 256 colors (packed HAM8?)

Packed could 2, 4, 8, 16, 32, 64, 128, and 256 colors. HAM & HAM8 is possible as well (6 or 8 bits packed).
Quote:
All would have likely moved to true 16 bit chunky with no CLUT after this as CBM was planning for AA+.

That's too late: we were talking about an (original) Amiga (1985) with packed graphics instead of planar.
Quote:
Packed CLUT modes likely would have been faster which may have been noticeable with more colors. Would the packed performance have been more important than the flexibility of planar which allowed more colors and sometimes reduced memory requirements?

Packed graphics is better in almost every case.

@Karlos

Quote:

Karlos wrote:
@matthey

We aren't talking about vanilla power of two packed pixels in this nerd-off. It's the hypothetical "any bit depth from 1-8" packed pixels versus bit planes, based on the arguments being made in whichever "port to x86" thread before.

Check the gist. It contains test code to create both planar and packed bitmap structures, where the bitmap data are both contiguous and 32-bit aligned at each row, regardless of the depth.

The challenge is to see how such "odd depth" packed pixels, with their awkward dense bit packing that results in some pixels spanning byte boundaries compare to pure planar.

*

 Status: Offline
Profile     Report this post  
V8 
Re: Packed Versus Planar: FIGHT
Posted on 6-Jun-2022 22:27:04
#23 ]
Regular Member
Joined: 30-Mar-2022
Posts: 129
From: Unknown

@Karlos

I can only come up with one single example where planar would be objectively better.
IF you select the pallette carefully and are willing to sacrifice numbers of colors available
you can create certain effects very computationally cheaply by just shifting around the registers where
a certain plane starts.

Some types of parallax scrolling and point and click adventure games where EHB use used to highlight areas/items. Maybe the designers just really really like parallax scrolling.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 6-Jun-2022 23:01:43
#24 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@V8

So, some other examples of where discrete bitplanes are better are for certain oldschool polygon effects, especially pseudo transparency, where two overlapping polygons in different planes have different colours assigned and you then assign some blended version of those colours to the palette index corresponding to the pixel value that has the bit set for each plane. Or for simple shadowing effects, using one plane to render shadow masks into (e.g. EHB).

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 7-Jun-2022 4:50:18
#25 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@V8

Quote:

V8 wrote:
@Karlos

I can only come up with one single example where planar would be objectively better.
IF you select the pallette carefully and are willing to sacrifice numbers of colors available
you can create certain effects very computationally cheaply by just shifting around the registers where
a certain plane starts.

Changing a single bitplane pointer that way means that you're moving the specific bitplane graphics ahead or before by 16 pixels (on OCS/ECS. 32 or, more likely, 64 on AGA) at the time (so, for each word / 16-bit movement).

I don't find it particularly interesting (I mean: just changing one bitplane, for example, keeping all other the same) as an effect.
Quote:
Some types of parallax scrolling

Parallax graphics requires that ALL bitplanes are moved (and shifted "per pixel") together ahead or before at the same time.

And you can do it either using the display controller (changing where the bitplanes pointers start, and the bitplanes scrolling) or the Blitter (taking the graphic from the original / untouched background image, properly shifting it, and writing to the framebuffer).

I know it very well because I've implemented the parallex scrolling on Fightin' Spirit using the Blitter (however it didn't go in the final production code, because the artist didn't wanted to redo part of the background graphics).

This clarified, it can be implemented exactly in the same way with packed graphics.
Quote:
and point and click adventure games where EHB use used to highlight areas/items. Maybe the designers just really really like parallax scrolling.

This is completely different from parallex scrolling, because it requires changing only the single bitplane which actually selects if the luminosity is full or halved.

This is how we implemented the shadows in Fightin' Spirit.
Unfortunately another idea which I had wasn't implemented in the game. I suggested to have night scenarios where there were the characters that moving under the street lamps then the parts of their bodies which overlap with the cone light would have been highlight. IMO it could have been a spectacular light effect. However the idea was, again, discarded by the artist because it didn't wanted to change the graphics.

Anyway, this is the only case where bitplanes had a net advantage compared to packed graphics, because it only required changing a single bitplane, as I've written.

However if we take into account the gain coming from drawing the shadows and we compare it with the waste of memory and, especially, the ENORMOUS waste of bandwidth which we had using the bitplanes, a packed graphics version of Fightin' Spirit (I mean the game implemented into a "packed graphics Amiga") could have been MUCH better (never dropping to 17 FPS from time to time. And displaying / moving much more graphics on screen AND/OR implementing an 8 channels software mixer for the music & sound effects, for example).

There's really no story here: games with packed graphics could have been MUCH better.

@Karlos

Quote:

Karlos wrote:
@V8

So, some other examples of where discrete bitplanes are better are for certain oldschool polygon effects, especially pseudo transparency, where two overlapping polygons in different planes have different colours assigned and you then assign some blended version of those colours to the palette index corresponding to the pixel value that has the bit set for each plane. Or for simple shadowing effects, using one plane to render shadow masks into (e.g. EHB).

Indeed. Accessing single or a few bitplanes is the key (and only) advantage of planar graphics.

But the gain isn't so common neither so much to justify all other cases where there's a loss (even a huge one).

 Status: Offline
Profile     Report this post  
Hypex 
Re: Packed Versus Planar: FIGHT
Posted on 13-Jun-2022 10:33:39
#26 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Karlos

Quote:
Speaking of which, first blood. Given the constraint that bitmaps are contiguous and rows begin at 32-bit aligned boundaries, planar concedes the first defeat:


Hang on, what says they need 32 bit alignment? The Amiga would need 16-bit minimum but even that is irrelevant as we are comparing packed with planar, not packed with Amiga. Therefore, I see no technical reason why a planar bitmap must be aligned, it could start on any byte in theory.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 13-Jun-2022 11:23:04
#27 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hypex

We're comparing the two implementations in the gist posted at the start of the thread, the sole point of which was to explore a pair of otherwise identical implementations in order to be as fair as possible. It's packed versus planar without being specific to the exact Amiga implementation. I chose 32 bit alignment to be a reasonable model for a 32 bit hardware implementation.

Nevertheless having to align your width to 16 pixels, it's the same. You waste less memory than if aligned to 32-bit. The same is true for 8 bit, even. An 8 bit aligned planar bitmap requires an alignment of 8 pixels, so 121 will be rounded to 128. In 256 colour mode a packed bitmap with the same alignment considerations would be 121 bytes wide, saving 7 bytes per row. The savings are less when you go to odd bit depths, and maybe no saving at all for some depths, but it's never worse.

Last edited by Karlos on 13-Jun-2022 at 11:27 AM.
Last edited by Karlos on 13-Jun-2022 at 11:27 AM.
Last edited by Karlos on 13-Jun-2022 at 11:23 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 13-Jun-2022 14:24:11
#28 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Hypex

Quote:

Hypex wrote:
@Karlos

Quote:
Speaking of which, first blood. Given the constraint that bitmaps are contiguous and rows begin at 32-bit aligned boundaries, planar concedes the first defeat:


Hang on, what says they need 32 bit alignment? The Amiga would need 16-bit minimum but even that is irrelevant as we are comparing packed with planar, not packed with Amiga. Therefore, I see no technical reason why a planar bitmap must be aligned, it could start on any byte in theory

Do you want to have planar graphics aligned to bytes? np!

Then you'll save some space BUT, on the other hand, you'll:
HALVE the bandwidth (yes, you've read it correctly) on a system with 16-bit data bus / reduce to A A QUARTER on a system with 32-bit data bus, etc.
OR complicate the display controller AND still waste some bandwidth (depending on the data bus size).

It's up you decide which scenario should be taken into account of the above possible two.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 13-Jun-2022 16:09:58
#29 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

For the avoidance of doubt, the code I posted at the start of the thread assumes a 32-bit alignment for both planar and packed modes.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 13-Jun-2022 18:09:53
#30 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

For the avoidance of doubt, the code I posted at the start of the thread assumes a 32-bit alignment for both planar and packed modes.

Which was/is absolutely fair.

However, I think that HypeX wanted to advocate planar graphics... without considering the consequences of his "suggestion".

But, hey, who cares: he can decide whatever he likes. It doesn't change the thesis: packed graphics continues to be better than planar graphics in almost all scenarios.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 12:21:59
#31 ]
Regular Member
Joined: 6-Jun-2018
Posts: 330
From: Aotearoa

@Karlos

Quote:

Karlos wrote:
@Hypex

Nevertheless having to align your width to 16 pixels, it's the same... In 256 colour mode a packed bitmap with the same alignment considerations would be 121 bytes wide, saving 7 bytes per row. The savings are less when you go to odd bit depths, and maybe no saving at all for some depths, but it's never worse.

Correct. The total amount of memory required for 'standard' resolutions is the same with planar or packed. I adjusted your code to compile with SASC, and removed the structure overhead to see how much memory the actual pixel data used. This showed that at sensible resolutions the memory used was identical.

The next question is - what is the difference in rendering speed for various operations? This could be tricky because it would depend on what code the compiler generated, and how fast the particular system executed it. However to start with we could look at the number of graphic data / screen memory reads and writes that are required, which represents an upper limit on efficiency.

I am interested in what advantages packed pixels might have had on classic Amiga hardware. I would like to test this on a stock machine (eg. A500 with ChipRAM only) to see what improvement packed pixels could have had on the original chipset and CPU. If the improvement is worthwhile I might consider making a hardware addon to implement it.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 12:58:55
#32 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@bhabbott

We can see intuitively that for rectangular block fills where the span width is large enough, planar and packed should converge, since it's only the left and right extents that will need multiple read/write operations per plane.

The worst case scenario is single pixel plotting with an arbitrary colour index. You have to read and write all N planes to make sure the correct bit pattern is set. You can skip writes if the bit that you need to set or clear marches what's already in the plane at that location. That becomes very branchy code though and may suffer its own issues.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Hypex 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 14:42:25
#33 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Karlos

Okay I see what you mean. Yes an odd width like 121 pixels takes up less space as packed. Especially since it only needs 121 bytes with a byte per pixel.

Planar is more suitable as a format at lower bit depths. And when the pixel width is a multiple of 8. At 8 bit depth planar has outdone it's usefulness against direct pixels.

As a comparison the C64 had some odd sizes with 21 pixel height sprites but the width was 24. I've noticed that alot of graphics tended to be multiples of two like 16 and 32 in width. But the standard screen widths were sizes like 320 or 640. So aligned objects would end up with 10, 20 or 40 across.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 18:23:49
#34 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hypex

It remains to be seen how effective oddly sized packed pixels are. I'm considering implementing both approaches in the MC64K machine host just for fun.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 20:37:09
#35 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@bhabbott

Quote:

bhabbott wrote:
@Karlos

Quote:

Karlos wrote:
@Hypex

Nevertheless having to align your width to 16 pixels, it's the same... In 256 colour mode a packed bitmap with the same alignment considerations would be 121 bytes wide, saving 7 bytes per row. The savings are less when you go to odd bit depths, and maybe no saving at all for some depths, but it's never worse.

Correct. The total amount of memory required for 'standard' resolutions is the same with planar or packed. I adjusted your code to compile with SASC, and removed the structure overhead to see how much memory the actual pixel data used. This showed that at sensible resolutions the memory used was identical.

This applies only to the display controller, and only for (horizontal) resolutions which are multiples of the data bus size.

However graphic primitives / operations are a completely different thing, since they can happen to any part of the framebuffer (e.g.: starting at any horizontal position).
Quote:
The next question is - what is the difference in rendering speed for various operations? This could be tricky because it would depend on what code the compiler generated, and how fast the particular system executed it.

You can write a super optimized code in assembly, but it doesn't change the above.
Quote:
However to start with we could look at the number of graphic data / screen memory reads and writes that are required, which represents an upper limit on efficiency.

Indeed. But custom chipset registers setup is also important.
Quote:
I am interested in what advantages packed pixels might have had on classic Amiga hardware. I would like to test this on a stock machine (eg. A500 with ChipRAM only) to see what improvement packed pixels could have had on the original chipset and CPU. If the improvement is worthwhile I might consider making a hardware addon to implement it.

As I've already said, packed graphics is almost always better than the planar one.

The only cases where it planar is better are when you access a single bitplane, or less bitplanes compared to the pixel depth.

@Karlos

Quote:

Karlos wrote:
@bhabbott

We can see intuitively that for rectangular block fills where the span width is large enough, planar and packed should converge, since it's only the left and right extents that will need multiple read/write operations per plane.

Width is one factor, but alignment (where the operation starts on the horizontal axis) is also another important one.

@Hypex

Quote:

Hypex wrote:
@Karlos

Okay I see what you mean. Yes an odd width like 121 pixels takes up less space as packed. Especially since it only needs 121 bytes with a byte per pixel.

See above: alignment is also very important, even with widths which are multiples of the data bus size.
Quote:
Planar is more suitable as a format at lower bit depths. And when the pixel width is a multiple of 8. At 8 bit depth planar has outdone it's usefulness against direct pixels.

If you continue to repeat it, it doesn't make it true.

In fact and see above: packed is almost always better than planar, except when you access less bitplanes.
Quote:
As a comparison the C64 had some odd sizes with 21 pixel height sprites but the width was 24. I've noticed that alot of graphics tended to be multiples of two like 16 and 32 in width. But the standard screen widths were sizes like 320 or 640. So aligned objects would end up with 10, 20 or 40 across.

The fact that sprites used power-of-twos for horizontal resolution and/or pixel size means nothing: packed graphic, even with odd pixel sizes, is almost always better.

@Karlos

Quote:

Karlos wrote:
@Hypex

It remains to be seen how effective oddly sized packed pixels are. I'm considering implementing both approaches in the MC64K machine host just for fun.

Just pick any Amiga videogame, think about it implemented on a packed graphic Amiga with oddly sized pixels, and you'll see how overall it's better than the planar / original version.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 14-Jun-2022 21:20:46
#36 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

I don't doubt for a second that packed pixels will be faster for generic drawing use cases. I'm just curious to see them in action.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Hypex 
Re: Packed Versus Planar: FIGHT
Posted on 28-Jun-2022 15:07:50
#37 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Okay so dragging this discussion into here for some closure.

Quote:
I've remarked that packed graphic is anyway better than bitplanes, even on those problematics.


Now I'm wondering if you are a bitplane booster.

Given at this point with Karlos, we were discussing packed formatting and only packed, bitplane is out of depth here.

Quote:
You're further complicating the situation trying to use such hybrid bitplane / packed formats.


The best way would be implementing it as simple as possible. At 1 bit they are equal. I imagine a BPLCON register to handle the case taking pixel width. Either direct or a multiplier. Depth would be only one plane but pixel width would specify to use packed pixels at set bpp.

Another idea I had was an indirect packed mode. Likely restricted to 8 bits. So, somehow with copper list, OCS/ECS can do 4 pixels a move and AGA 2 pixels a move. I'm sure there's some trick as I read it's half that in actual speed. So, I was thinking, if the copper was disabled and instead used as a direct index. Depending on bandwidth the bitplanes would or would not also be disabled. So the copper could setup the screen and sprites but once the pointers are set another copper move disables the copper. When the next line is rastered, instead of DMA reading in copper codes, it reads in a direct CLUT index so it would be restricted to 8 bits. Sounds more simple in my head than that explanation.

Quote:
Indeed. If you understand how the display controller and Blitter work with the regular bitplanes, and apply the same operations with packed graphics, you'll see that there's absolutely no difference whatever is the pixel size: you always need shift & masking when there are scrolling playfields to be displayed, or operations like the cookie-cut.


I was thinking in writing a single pixel. In some cases it would fit in a byte. In other cases two bytes would need writing. Or fit it into a word.

But, regarding the blitter, I see it as quite easily being able to blit packed data. Provided it has the width for it. Even arbitrary pixel sizes are no problem. Just mask off the edges.

Quote:
First you have to prove that a concrete implementation is absolutely needed in this case.


At this point it still looks like conjecture.

Quote:
I think that math is enough to prove that packed graphic is almost always better than planar.


If you reduce the pixels to generic packed data in arbitrary sizes of course the math will always be in favour of packed. But this wasn't in dispute. What was is if the data size needs restrictions in the display controller since it is pixel data.

As a comparison I examined sources of data compressors years ago. It was common for 68K code to shift and rotate data in one bit at a time. It basically took packed data and bit packed it instead of doing it in chunks. It was was storing it in a register so I understood why.

Some more recent years ago I wanted to store data of random sizes. I could have copied the same method but I wanted it more efficient than one bit at a time. So I wrote a routine that shifted and merged it as one chunk. In cases it overflowed the long word in the register I simply split it and pushed the register to memory. I seemed happy with it. Guess it's a chunk packer. Didn't do any speed tests for either.

Quote:
You don't need to touch a black hole to prove its existence...


You don't want to fall in one either!

Quote:
Correct. And if you understand how the display controller works when it has to render a scan line, pixel by pixel, then you might finally get why its implementation would have been MUCH easier with packed graphics (sprites included).


I can see how easier it would be by only reading one block of chip ram. Rather than needing multiple blocks. And the parallel to serial conversion.

Quote:
That was a tease, my friend: not humour...


LOL.

Quote:
Well, you said exactly the opposite before...


Looking back at what I couldn't imagine, using that exact phrase, was the side effect of splitting the scroll offsets on Amiga with a packed hardware. Because it was a side effect of the Amiga hardware set up. It's not clear cut because, apart from being unable to find any code demonstrating it and yes I should have just done it, it was a side effect of splitting even and odd plane offsets in *single* playfield mode. By your response it would need to be duplicated with a *dual* playfield mode

What else I couldn't see was related to practicability of packed sizes.

Quote:
Quote:
Whether it is practical in actual use is another story. I clearly have argued my points against the practicality of it as I see it, so dismissing them doesn't mean I have no arguments, and I have no need to reiterate them.

Everything was already rebutted. And examples were also given which clearly shown that bitplanes have no points on the common graphic primitives..


Are you throwing in a red herring? That would be a logical fallacy.

My dispute was practicability of arbitrary bit sizes of pixels inside the display controller.

What have bitplanes got to do with packed data sizes?

Quote:
You don't see it because you're not able to distinguish the display controller SETUP (I've highlighted it) for one or two playfields to be shown (which is absolutely the same, besides the differences with the one or two pointers to the graphic) with the RUNTIME operation of such controller..


So as a means to an end it needs two playfields to duplicate a one playfield trick?

Quote:
I think that you've no clue on how the Amiga hardware was programmed AND how effectively it worked color clock by color clock. This could explain your problems.


My problems are actually knowing what the trick did, what it was called and where to find some damned example code for it.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 28-Jun-2022 16:42:04
#38 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

I still haven't had time, but I am planning to add arbitrary bit depth packed pixel support to MC64K as well as planar, just for a laugh, based on the software definitions at the star of this thread. However, something approximating the "display controller" for each case still has to be implemented and that's where we might get some quantifiable understanding of the complexity difference.

I still believe that N-bit packed pixels will be essentially no more complex than a single 1-bit bitplane: you'll still need to start somewhere at a machine aligned boundary and use shifts and masks to isolate pixels. The only complication for 3,5,6 and 7 bit packed pixels will be where the mask for a pixel spans a machine word boundary. This problem doesn't exist for 1,2,4 and 8 bit depths.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Hypex 
Re: Packed Versus Planar: FIGHT
Posted on 2-Jul-2022 15:50:48
#39 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
See above: alignment is also very important, even with widths which are multiples of the data bus size.


A case like 121 in width wouldn't be a screen width and would be an image width so can be more flexible.

Quote:
If you continue to repeat it, it doesn't make it true.


You disagree? Well, as a comparison, I'll invert what I put, and I certainly think you would disagree!

Planar is more suitable as a format at higher bit depths. And when the pixel width isn't a multiple of 8. At 8 bit depth planar has outdone direct pixels!



BTW I meant screen width when I put pixel width in the above and ealier.

Quote:
In fact and see above: packed is almost always better than planar, except when you access less bitplanes.


That agrees with my first point

Quote:
The fact that sprites used power-of-twos for horizontal resolution and/or pixel size means nothing: packed graphic, even with odd pixel sizes, is almost always better.


I was just pointing out how they fit across in multiples of tens.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Packed Versus Planar: FIGHT
Posted on 2-Jul-2022 16:32:06
#40 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Karlos

Quote:
still haven't had time, but I am planning to add arbitrary bit depth packed pixel support to MC64K as well as planar, just for a laugh, based on the software definitions at the star of this thread. However, something approximating the "display controller" for each case still has to be implemented and that's where we might get some quantifiable understanding of the complexity difference.


Has no one written any drawing examples? Well, it will be interesting to see, since you can implement a flexible display controller. Using vector operations should speed up any planar to framebuffer conversions.

Quote:
I still believe that N-bit packed pixels will be essentially no more complex than a single 1-bit bitplane: you'll still need to start somewhere at a machine aligned boundary and use shifts and masks to isolate pixels. The only complication for 3,5,6 and 7 bit packed pixels will be where the mask for a pixel spans a machine word boundary. This problem doesn't exist for 1,2,4 and 8 bit depths.


Yes it's just a matter of calculating it. It's easy enough to pack data across if keep track of where to shift it in and account overflow. I did write an E module for this exact purpose a few years back that bitpacks variable width data into long words and stores it as well as read it back.

Another consideration on the Amiga, had it supported packed, is the bus width. The max words it loads in would be six for EHB or HAM mode and in blocks of 16 pixels. 16 pixels of 3,5 and 6 works fine and needs 3, 5 or 6 words as it happens. Unless I missed something. OTOH another possibility is pixels needng to be fit into a word and being restricted to 16 bits with any gaps like xx33333, xx555or xxx66.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle