256 Colours, Chunky Vs Planar, what was better?

[Leffmann]

Originally Posted by Dunny

I don't think you quite understand how these things work. If the A1000/A500 had a chunky mode then memory requirements would have been much, much higher - one of the main reasons we got planar was due to the smaller display footprint. And back in the 80s, RAM was expensive.

How much, much higher exactly? How much memory does some of the existing modes use, such as 16 color Hires interlaced for example?

[Dunny]

Of course, 16 colour (4 bitplane) hires laced (640x512) is precisely double the requirements of a 320x256 8bpp screen - so the requirements there would be the same. However, I'll pass that back to you and ask how quickly we could shift that amount of data around? Are the hires laced screens particularly fast?

And then there's the memory requirements for day to day usage - don't forget that the Amiga was initially released with just 256Kb of RAM - a 640x512x16 screen would mean that space would be very tight - it would take up more than half available RAM. You'd need an upgraded Amiga to do that. Hell, even with the A500 512Kb, you can't have very many hires screens open at once unless you drop to 4 colours or less.

Miggy4Eva:

Hell, if we're shooting for things the Amiga never had (which is a pointless exercise) then how about a 1-pixel resolution copper? Might as well if we're using things that never were in order to prove some sort of superiority contest

The initial post (and thus the point of this thread was to ask what advantages planar modes had over chunky. The reduction in graphics memory needed was basically the entire reason for planar - and lest we forget, using chunky graphics modes for 3D games was so far in the future at the Amiga's release date that it didn't figure in their design.

[Miggy4eva]

Originally Posted by Leffmann

How much, much higher exactly? How much memory does some of the existing modes use, such as 16 color Hires interlaced for example?

the same bitmap image is exactly the same size whether it's stored as chunky or planar. A frame buffer with the same resolution and bit depth is exactly the same size in planar or chunky. It makes no difference there.
The difference is in throwing the 2d graphics and sprites around, masking sprites over others etc. There are easier ways to perform those operations on planar-formatted graphical data, which uses both less CPU / coprocessor resources, and less RAM.

[Miggy4eva]

Originally Posted by Dunny

The initial post (and thus the point of this thread was to ask what advantages planar modes had over chunky. The reduction in graphics memory needed was basically the entire reason for planar - and lest we forget, using chunky graphics modes for 3D games was so far in the future at the Amiga's release date that it didn't figure in their design.

Other systems of the day had chunky modes. E.g. Mac.
To say "Oh I wish the Amiga had a Chunky mode, it would have helped with 3d" is crime of the century and derailing the thread, huh?

[Dunny]

Originally Posted by Miggy4eva

Other systems of the day had chunky modes. E.g. Mac.

And a massively higher price tag, but don't let that get in the way of your Amiga-master-race fantasies.

To say "Oh I wish the Amiga had a Chunky mode, it would have helped with 3d" is crime of the century and derailing the thread, huh?

Well, yes. You did somewhat hijack the thread.

[chb]

To be fair, there was the MSX2 from 1985 which had an 8-bit (256 color) chunky mode at a lower price tag. I guess the main problem in terms of hardware complexity would have been the number of color registers - 256 12-bit Registers need already ~20k transistors, quite a lot at that time. The MSX2 for that reason used direct 8-bit-RGB (3 red bits, 3 green, 2 blue) without a palette. Interesting if they could have used something like 3-bit EHB in the Amiga (5 bit palette, 3 bit intensity).

In principle, one could also use chunky modes with less than 8 bit (although only powers of two a re practical), a 4 bit nibble chunky mode would have been certainly better suited for single pixel operations. But as most CPUs do not have efficient special instructions to handle nibbles, it would have meant lots of masking + shifting, making it slower than a byte chunky mode for a lot of things. Probably that's why it wasn't considered.

What would have been comparatively easy to implement in the Amiga: a 16-bit, 4096 chunky mode in halve the x-resolution. Bit of a waste of memory, but C64 lowres mode on steroids!

[Locutus]

Do we have threads about Chunky/Planar every 4 months? Does someone keep a calendar for them?

[robinsonb5]

Originally Posted by Miggy4eva

the same bitmap image is exactly the same size whether it's stored as chunky or planar.

The same 256-colour bitmap image is, certainly. A 32-colour image in chunky format, though, would either wastefully allocate 1 byte for each 5-bit pixel, thus increasing the required storage space by more than 50%, or pack the bits densely, 8 pixels to 5 bytes - thus throwing away the speed advantage of chunky, since it would be more even more painful to handle with the CPU than planar data.

[Leffmann]

Originally Posted by Dunny

Of course, 16 colour (4 bitplane) hires laced (640x512) is precisely double the requirements of a 320x256 8bpp screen - so the requirements there would be the same. However, I'll pass that back to you and ask how quickly we could shift that amount of data around? Are the hires laced screens particularly fast?

Not particularly fast, but that's never stopped anyone from finding uses for those screen modes, and with everything we've seen in demos and games you can't honestly suggest that noone would find use for chunky mode graphics on OCS just because it needs more memory and bandwidth.

[redblade]

Hi guys thanks for the replies. Like I said in the first post by the time they got to 256 colours, they might of realised that perhaps the Chunky mode might be best and they could of thrown one in the mix, using 1 word for each pixel. I don't know how much work that would of had to have been to the chipset. I know that the origional Amigas didn't come with much memory 256kb was not much but that would of been enough for slide shows, like they did with the HAM mode

[Dunny]

Originally Posted by Leffmann

Not particularly fast, but that's never stopped anyone from finding uses for those screen modes, and with everything we've seen in demos and games you can't honestly suggest that noone would find use for chunky mode graphics on OCS just because it needs more memory and bandwidth.

Yeah, point taken but I doubt that there was anything meaningful done in those modes aside from productivity or turn-based/adventure games. It was just too slow to update fast enough for an action game.

Originally Posted by redblade

Hi guys thanks for the replies. Like I said in the first post by the time they got to 256 colours, they might of realised that perhaps the Chunky mode might be best and they could of thrown one in the mix, using 1 word for each pixel. I don't know how much work that would of had to have been to the chipset. I know that the origional Amigas didn't come with much memory 256kb was not much but that would of been enough for slide shows, like they did with the HAM mode

I suspect that the reason chunky mode was not considered for AGA machines was because they basically added the AA graphics in as cheap and fast a manner as possible - just extend the current planar system by a further three planes. Same memory requirements as chunky 8bpp, very little extra silicon needed. Of course, then Doom came out but by that time the Amiga was dying off fast and nobody had either the inclination or the resources to implement a proper advanced graphics architecture.

[Megol]

Originally Posted by Dunny

Of course, 16 colour (4 bitplane) hires laced (640x512) is precisely double the requirements of a 320x256 8bpp screen - so the requirements there would be the same. However, I'll pass that back to you and ask how quickly we could shift that amount of data around? Are the hires laced screens particularly fast?

I wonder why you think 8 bits in a chunky mode requires the bandwidth of 16 planar bits. Bits are bits.

320x256 with 4 bpl would provide enough bandwidth for 160x256 in 8 bit chunky.
640x256 with 4 bpl -> 320x256 8 bit chunky.

Of course 4 bit chunky in 160x256 resolution would still be usable.

One problem with 8 bit chunky would be the color management. Amiga used 32 palette entries even for the 64 color mode to save gates, going up to 256 palette entries would be expensive.

And then there's the memory requirements for day to day usage - don't forget that the Amiga was initially released with just 256Kb of RAM - a 640x512x16 screen would mean that space would be very tight - it would take up more than half available RAM. You'd need an upgraded Amiga to do that. Hell, even with the A500 512Kb, you can't have very many hires screens open at once unless you drop to 4 colours or less.

Yes but adding chunky modes in ECS or more likely a slightly tweaked ECS would still be possible.

Doing it in a hack-style manner would still be better for some rendering techniques even if chunky pixels would be interleaved in some manner.

Still couldn't be as crappy as the [IBM][PC] VGA Mode-X where pixels are chunky distributed over 4 planes and the processor having direct access to one plane at a time. But we liked it!

[duga]

Originally Posted by idrougge

Play Doom on an A4000 with graphics card (no c2p involved). Still not fast.

030/040/060/604e?

Not fast on an 386 either, they say.

[Dunny]

Originally Posted by Megol

I wonder why you think 8 bits in a chunky mode requires the bandwidth of 16 planar bits. Bits are bits.

I didn't say that - I was giving as evidence the fact that moving things around at 640x512x4 was slow, and that 320x256x8 would be just as slow - same amount of data to move.

Yes but adding chunky modes in ECS or more likely a slightly tweaked ECS would still be possible.

Absolutely, but there was no call for a chunky mode back when the chipset was designed. The intention was to save memory where possible as most productivity screens use a low colour count, and gaming was very much a secondary part of the design, if it was even considered at all.

Still couldn't be as crappy as the [IBM][PC] VGA Mode-X where pixels are chunky distributed over 4 planes and the processor having direct access to one plane at a time. But we liked it!

Yes, there were indeed. Even more fun setting up interrupts for paging in/out memory for high resolution SVGA modes in DOS though

[idrougge]

Originally Posted by duga

030/040/060/604e?

Not fast on an 386 either, they say.

Plain 1992 A3640. Not that the exact kind of CPU matters, since every A4000 is vastly faster than the A500 with chunky we're imagining here.

[TuRRIcaNEd]

Originally Posted by Samurai_Crow

Remember that the classic Mac version took 8 megabytes just for Wolfenstein, let alone Doom.
...
The classic Mac 2 had chunky modes and colors. 16 colors. The A500 wouldn't have had 8bit color in 1987 even with chunky modes.

But those modes were more-or-less redundant because the Classic Mac's graphics were entirely CPU-driven, and for a long time Mac CPUs weren't what one could call particularly quick. The genesis of raycasting games on the PC grew out of having relatively quick processors with limited graphics capability(in the EGA era) and later taking advantage of the quirks inherent in VGA mode 13h (neither of which were available on the classic Macs).

Originally Posted by Miggy4eva

We can only wish OCS had a chunky mode because then Doom and Wolf3d would have been possible on A500 with no need to C2p conversion.

Well, no. Original DOOM considered a 486 with a full VGA card to be minimum spec, meaning that a 486 core running at at least 20MHz (and yes, the SX could be downclocked to 16MHz, but we'll get to that...) was the minimum required to perform the raycasting calculations, do the game logic and drive the VGA frame buffer via the CPU; it should also be noted that minimum true VGA spec required 256kB dedicated VRAM.

I remember very clearly at the time (thanks to hours trying to get my school computers to run it) that if you had a 486SX (i.e. no FPU) and bog-standard VGA, you'd have to reduce the size of the play viewport to get it to run at a decent clip. Getting it to run remotely smoothly in full-screen mode usually meant a VESA-compatible graphics card was necessary on anything less than a 486DX2.

The concept of first-person games built around a raycasting engine was an outgrowth of people like John Carmack, Doug Church, Michael Abrash et al. discovering something to which the mid-evolution PC architecture turned out to be well-suited (though it required DOS extenders and the like to make it work). It simply wasn't remotely feasible during the period in which the Amiga was designed (limited transistor counts and a worldwide RAM shortage being limiting factors).

I think it's also worth bearing in mind that even if you had a 486DX2 with a VESA card in about 1994, the architecture was singularly bad at reproducing the kind of "2D" games which were the norm until the early-mid '90s. I vividly remember playing Project X on a friend's PC with that exact spec and almost getting a headache from how jerky the horizontal scrolling was.

Originally Posted by Galahad/FLT

The irony is, if the Amiga designers had designed the copper chip to be able to reload the colour registers every 1 pixel instead of the 8 it could do.....theres your chunky mode right there in 1985!

I'd always thought it was every 4px on OCS/ECS and every 2px on AGA (hence the original AB3D and Gloom, which took advantage of that). Please correct me if I've been labouring under a misapprehension!

[drHirudo]

Chunky modes were possible on Amiga with the custom chips, but they were very low-res (lower than 8 bit computers).

Ambermoon used hybrid chunky mode for the floor/ceilings.
There is also a chunky screen mode with using the copper:

http://aminet.net/package/dev/misc/chopper

Some demo scene productions used these hybrid modes, but they were not very practical for gaming, especially on the Amiga were everyone was used to pixel graphics.

[hooverphonique]

Originally Posted by TuRRIcaNEd

I'd always thought it was every 4px on OCS/ECS and every 2px on AGA (hence the original AB3D and Gloom, which took advantage of that). Please correct me if I've been labouring under a misapprehension!

The copper can load a palette register every 8 lo-res pixels. When you see "copper chunky" with a higher res, it's because multiple palette registers have been pre-loaded for that horizontal section and then a horizontal mask is used, which shows all the loaded colors in succession (e.g. 4 px col 1, 4 px col 2, 4 px col 3,etc). On AGA you can do some palette bank switching things to further enhance this.

The argument about using a faster copper to create e.g. 1px copper chunky is bullshit, because even if it was possible to fit in-between all the other dma cycles, it would eat so much bandwidth that the rest of the system would not be able to do anything..

[TuRRIcaNEd]

Thanks @hooverphonique - that's really useful info!

(Also, you're named after a really cool band... )

[hooverphonique]

Originally Posted by TuRRIcaNEd

(Also, you're named after a really cool band... )

I know