Amiga.org

Amiga computer related discussion => General chat about Amiga topics => Topic started by: lassie on September 12, 2012, 09:56:15 AM

Title: chunky pixel mode
Post by: lassie on September 12, 2012, 09:56:15 AM
Hi i have been thinking about 3D on Amiga and read about something called chunky pixel mode, if they had used that in an Amiga 1200 and CD32 would it have made the Amiga better at 3D games? or should there more to it, maybe more ram etc?

I have an Super Nintendo and Sega Cd and they are quite good at making (fake) 3D games but they also have something called mode 7. But Sega CD only have 128 kb ram but it sure can make some decent 3D games, i know it is not real 3D but it looks great. so i have been thinking what Amiga could have done to keep up with the newer games from the 3D era. But i have seen some demos on a stock Amiga 1200 and they were quite cool 3D demos :)
Title: Re: chunky pixel mode
Post by: NovaCoder on September 12, 2012, 10:42:00 AM
Quote from: lassie;707797
Hi i have been thinking about 3D on Amiga and read about something called chunky pixel mode, if they had used that in an Amiga 1200 and CD32 would it have made the Amiga better at 3D games? or should there more to it, maybe more ram etc?

A chunky mode would have helped in the early days but you need more than a chunky mode to do decent 3D.
Title: Re: chunky pixel mode
Post by: Hattig on September 12, 2012, 11:06:33 AM
A chunky pixel mode would have helped with the early-style 3D games which used software rendering, especially ray-casters like Doom.

But other things would have been better - fast RAM as default on the CD32, a SIMM slot in the A1200 for easy Fast RAM addition. Hardware changes include a faster, 32-bit-wide blitter and explicit polygon rendering acceleration hardware.
Title: Re: chunky pixel mode
Post by: bloodline on September 12, 2012, 11:56:31 AM
Chunky pixel mode, put very simply mean that the CPU only needs a single write to the memory per pixel. On the Amiga, due to the planar pixel mode, the CPU has to make 8 separate writes to the memory per pixel (for 256 colours), this can be optimised a bit... But it's still quite an overhead when compared to chunky pixel mode.
Title: Re: chunky pixel mode
Post by: Digiman on September 12, 2012, 12:03:30 PM
Put simply if Amiga had chunky pixel mode Doom would run faster on Amiga than it does. Or possibly even a simple 256 colour game in super hi-res interlace mode (which is pretty much only good as a static screen due to speed on AGA)

And the reason we had the insane architecture of 8 bitplanes not byte per pixel in 256 colour displays was...........
Title: Re: chunky pixel mode
Post by: bloodline on September 12, 2012, 12:09:16 PM
Quote from: Digiman;707807
Put simply if Amiga had chunky pixel mode Doom would run faster on Amiga than it does. Or possibly even a simple 256 colour game in super hi-res interlace mode (which is pretty much only good as a static screen due to speed on AGA)

And the reason we had the insane architecture of 8 bitplanes not byte per pixel in 256 colour displays was...........


... Because AGA was little more than a bug fix to ECS, and back in the mid 80's bitplanes made sense as you could very carefully control the amount of memory used in your gfx... Once ram became cheap in the 90's bitplanes were a nasty bit of legacy :(
Title: Re: chunky pixel mode
Post by: Hattig on September 12, 2012, 12:17:30 PM
Quote from: Digiman;707807
And the reason we had the insane architecture of 8 bitplanes not byte per pixel in 256 colour displays was...........


Commodore cheaping out.

It probably wouldn't even have been much logic to implement (compared to the rest of the logic). Instead of reading up to 8 words from bitplanes at different addresses, just read 8 words sequentially, and interpret the data differently.

I'm guessing the data from each bitplane was read (32 bits at a time) into shift-registers (one per plane) on the chip, and that the data was shifted out (at the pixel clock rate) as a number that was fed into the colour palette (CLUT) to get the RGB display value for that pixel.

So to implement a byteplane you would just need to feed those 8 shift-registers differently, or have an chunky shift-register that shifted 8 bits at a time.
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 12, 2012, 01:24:32 PM
Quote from: bloodline;707808
... Because AGA was little more than a bug fix to ECS, and back in the mid 80's bitplanes made sense as you could very carefully control the amount of memory used in your gfx... Once ram became cheap in the 90's bitplanes were a nasty bit of legacy :(

It also allowed you to do cool stuff like hardware parallax scrolling, easy masking of bobs (in fact it generally makes much more sense with the blitter), really there are a lot of ways in which bitplanes are better for the 2D, sprite-based games you got in the '80s and early '90s, it was only when Doom came out, and then Quake, and everyone got excited about 3D texture mapping that chunky mode became... a game changer.  Suddenly a fast CPU was the most crucial factor, and all the Amiga's clever custom-chip hardware was all for naught.
Title: Re: chunky pixel mode
Post by: Crumb on September 12, 2012, 02:34:34 PM
Quote from: lassie;707797
Hi i have been thinking about 3D on Amiga and read about something called chunky pixel mode, if they had used that in an Amiga 1200 and CD32 would it have made the Amiga better at 3D games? or should there more to it, maybe more ram etc?

I have an Super Nintendo and Sega Cd and they are quite good at making (fake) 3D games but they also have something called mode 7. But Sega CD only have 128 kb ram but it sure can make some decent 3D games, i know it is not real 3D but it looks great. so i have been thinking what Amiga could have done to keep up with the newer games from the 3D era. But i have seen some demos on a stock Amiga 1200 and they were quite cool 3D demos :)

For SNES-like*mode-7 style effects check out "Brian The Lion", it was coded by sceners and they programmed blitter to make it rotate and zoom bitmaps with higher accuracy than SNES
and quite fast (the intro screen rotozoom runs at 25fps on a stock amiga with no fastmem)
http://www.youtube.com/watch?v=m-IDcTW8JQ4

Chek out minute 9:24, 9:30 to see the big platforms rotated using Amiga Blitter.
http://www.youtube.com/watch?v=m-IDcTW8JQ4&feature=player_detailpage#t=564s

IMHO*the problem with AGA was
1. Not enough sprites
2. That caused that people used blitter to draw the remaining gfx but it was more or less as fast as the OCS/ECS ones
3. Since blitter was slow some coders of modern games draw the stuff in fastmem and copy to chipmem and that's when you realize chipmem's top speed of 7MB/s with a good accelerator (faster than most ISA cards) is not enough
4.*Chunky modes would have been useful at the beggining with slow cpus but from 040 upwards you can perform c2p as fast as you perform a copy from fast to chip. Even if you had a chunky mode if your game gfx are moderately complex you probably won't like to draw byte by byte to chipmem, you'll prefer to do that in fastmem and copy the result to chipmem at the end. So with 040+ cpus chunky modes are not a problem. In fact first IDSoftware games ran in planar 16-colour EGA mode on peecees and ray^tscc showed some years ago wolf3d was possible on a 8Mhz Atari

More sprites would have made a real difference. Check out Neo Geo games. These are 2D only but impressive anyway. CBM*should have added more sprites or a 32bit blitter and that would have made a lot of difference in the quality of Amiga games. Chunky games usually looked like sh*t anyway.

Although challenges are always fun (doing chunky games on Amiga) I think more effort should have been done in taking advantage of AGA+fastram and doing some great neo-geo like games.
Title: Re: chunky pixel mode
Post by: Hattig on September 12, 2012, 03:25:54 PM
Quote from: Crumb;707821

More sprites would have made a real difference. Check out Neo Geo games. These are 2D only but impressive anyway. CBM*should have added more sprites or a 32bit blitter and that would have made a lot of difference in the quality of Amiga games. Chunky games usually looked like sh*t anyway.

Although challenges are always fun (doing chunky games on Amiga) I think more effort should have been done in taking advantage of AGA+fastram and doing some great neo-geo like games.


Adding more sprites would have been difficult due to the nature of Amiga sprites - a scanline of each sprite is loaded into the chip during HBLANK, and there's only so much bandwidth available, which coincides with the AGA sprite size and count. Sprites were an after-thought on the Amiga. To do them like the NeoGeo/etc there would have had to be a separate sprite memory, scanline buffer and memory bus so that accesses to sprite data could be done at any time.

The best option would have been a 32-bit blitter and a faster chipram bus. The latter would have helped the sprite count too.
Title: Re: chunky pixel mode
Post by: runequester on September 12, 2012, 04:10:41 PM
Chunky mode would have helped, but processing power was more of a bottleneck in my opinion. 030's vs 486's isn't really any reasonable comparison for a CPU intensive game.
Title: Re: chunky pixel mode
Post by: Hattig on September 12, 2012, 05:03:57 PM
Quote from: runequester;707831
Chunky mode would have helped, but processing power was more of a bottleneck in my opinion. 030's vs 486's isn't really any reasonable comparison for a CPU intensive game.


But the 486s were in £1000+ systems, and the A1200 was a £400 (then £300) system.

Which brings us onto the other failing: No £600 A1230 with 40MHz '030 and 4MB RAM at release. Upselling - Commodore hadn't heard of it, apart from that hard drive included SKU.

At Release:
A1200 2MB '020 14MHz: £399
A1200 4MB '020 14MHz: £479
A1200 4MB '030 25MHz: £549
A1200 4MB '030 40MHz: £599
A2200 4MB '030 40MHz: £799 (A1200 in desktop case w/ separate keyboard)

People would have easily been persuaded to get a higher level A1200 in shops because the price increments aren't too shocking.
Title: Re: chunky pixel mode
Post by: runequester on September 12, 2012, 05:08:30 PM
Quote from: Hattig;707840
But the 486s were in £1000+ systems, and the A1200 was a £400 (then £300) system.

Which brings us onto the other failing: No £600 A1230 with 40MHz '030 and 4MB RAM at release. Upselling - Commodore hadn't heard of it, apart from that hard drive included SKU.

At Release:
A1200 2MB '020 14MHz: £399
A1200 4MB '020 14MHz: £479
A1200 4MB '030 25MHz: £549
A1200 4MB '030 40MHz: £599
A2200 4MB '030 40MHz: £799 (A1200 in desktop case w/ separate keyboard)

People would have easily been persuaded to get a higher level A1200 in shops because the price increments aren't too shocking.


Oh, I agree completely. When people have brought this up in the past, the response is usually some sort of resigned "well, PC's were faster anyways, so nobody would have bought it", but the stock 1200's sold extremely well. A 1200 with even a bit of FAST RAM and either a faster 020 or a decent 030 would have sold just as well.
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 12, 2012, 05:10:39 PM
Quote from: runequester;707831
Chunky mode would have helped, but processing power was more of a bottleneck in my opinion. 030's vs 486's isn't really any reasonable comparison for a CPU intensive game.

This is true, an A1200 with native 68060 would have been truly awesome.  A1600?
Title: Re: chunky pixel mode
Post by: Pentad on September 12, 2012, 06:00:34 PM
Quote from: bloodline;707808
... Because AGA was little more than a bug fix to ECS...(


I could not agree more.  The Amiga was wonderful in 1985 but Commodore never did anything to the hardware after.  Oh, there were minor upgrades but the Amiga's amazing designs of the 80's became a liability in the 90's.  

I could be wrong about this in 1988 didn't R&D show some amazing chip designs that would have be the next gen for the Amiga?  I thought I recalled that they said -looking back- it would have been like the Voodoo I from 3DFX for the PC years later.  

Sad, really....

-P
Title: Re: chunky pixel mode
Post by: runequester on September 12, 2012, 06:03:54 PM
I get that it wasn't the upgrade Commodore maybe needed, but I'll be honest, I  don't recall anyone bitching about AGA back in the day. We were all pretty stoked about, and the games suddenly looked nicer. :)
Title: Re: chunky pixel mode
Post by: bloodline on September 12, 2012, 07:38:01 PM
Quote from: Pentad;707847
I could not agree more.  The Amiga was wonderful in 1985 but Commodore never did anything to the hardware after.  Oh, there were minor upgrades but the Amiga's amazing designs of the 80's became a liability in the 90's.  

I could be wrong about this in 1988 didn't R&D show some amazing chip designs that would have be the next gen for the Amiga?  I thought I recalled that they said -looking back- it would have been like the Voodoo I from 3DFX for the PC years later.  

Sad, really....

-P


You mean the legendary "Ranger Chipset"... Designed by the original team while still at Commodore... But never put into production... Apparently it would have been a killer!!!
Title: Re: chunky pixel mode
Post by: itix on September 12, 2012, 07:45:15 PM
Quote from: Hattig;707840
But the 486s were in £1000+ systems, and the A1200 was a £400 (then £300) system.

Which brings us onto the other failing: No £600 A1230 with 40MHz '030 and 4MB RAM at release. Upselling - Commodore hadn't heard of it, apart from that hard drive included SKU.

At Release:
A1200 2MB '020 14MHz: £399
A1200 4MB '020 14MHz: £479
A1200 4MB '030 25MHz: £549
A1200 4MB '030 40MHz: £599
A2200 4MB '030 40MHz: £799 (A1200 in desktop case w/ separate keyboard)

People would have easily been persuaded to get a higher level A1200 in shops because the price increments aren't too shocking.


On PC games got better with faster CPU but on Amiga (2D) games rarely got better with faster CPU.
Title: Re: chunky pixel mode
Post by: lassie on September 12, 2012, 07:45:20 PM
Quote from: Crumb;707821
For SNES-like*mode-7 style effects check out "Brian The Lion", it was coded by sceners and they programmed blitter to make it rotate and zoom bitmaps with higher accuracy than SNES
and quite fast (the intro screen rotozoom runs at 25fps on a stock amiga with no fastmem)
http://www.youtube.com/watch?v=m-IDcTW8JQ4

Chek out minute 9:24, 9:30 to see the big platforms rotated using Amiga Blitter.
http://www.youtube.com/watch?v=m-IDcTW8JQ4&feature=player_detailpage#t=564s

IMHO*the problem with AGA was
1. Not enough sprites
2. That caused that people used blitter to draw the remaining gfx but it was more or less as fast as the OCS/ECS ones
3. Since blitter was slow some coders of modern games draw the stuff in fastmem and copy to chipmem and that's when you realize chipmem's top speed of 7MB/s with a good accelerator (faster than most ISA cards) is not enough
4.*Chunky modes would have been useful at the beggining with slow cpus but from 040 upwards you can perform c2p as fast as you perform a copy from fast to chip. Even if you had a chunky mode if your game gfx are moderately complex you probably won't like to draw byte by byte to chipmem, you'll prefer to do that in fastmem and copy the result to chipmem at the end. So with 040+ cpus chunky modes are not a problem. In fact first IDSoftware games ran in planar 16-colour EGA mode on peecees and ray^tscc showed some years ago wolf3d was possible on a 8Mhz Atari

More sprites would have made a real difference. Check out Neo Geo games. These are 2D only but impressive anyway. CBM*should have added more sprites or a 32bit blitter and that would have made a lot of difference in the quality of Amiga games. Chunky games usually looked like sh*t anyway.

Although challenges are always fun (doing chunky games on Amiga) I think more effort should have been done in taking advantage of AGA+fastram and doing some great neo-geo like games.


You are right, there were something like mode 7 on Amiga i could see now :) i have never seen that before.
Title: Re: chunky pixel mode
Post by: runequester on September 12, 2012, 08:02:10 PM
Quote from: itix;707862
On PC games got better with faster CPU but on Amiga (2D) games rarely got better with faster CPU.


For a certain type of games sure. We'd all have loved to have UFO Enemy Unknown be less pokey. But there were plenty of areas where CPU power was important: Coding, all sorts of applications (including graphics which was a popular use of the amiga community), and later games.

It'd also permit more advanced games. Look at things like Genetic Species and Onescapee for some simple things that were possible with a decent 030 and AGA.
Title: Re: chunky pixel mode
Post by: lassie on September 12, 2012, 09:13:21 PM
Quote from: runequester;707865
For a certain type of games sure. We'd all have loved to have UFO Enemy Unknown be less pokey. But there were plenty of areas where CPU power was important: Coding, all sorts of applications (including graphics which was a popular use of the amiga community), and later games.

It'd also permit more advanced games. Look at things like Genetic Species and Onescapee for some simple things that were possible with a decent 030 and AGA.


Hi i just tried Genetic Species quite a good game :)
Title: Re: chunky pixel mode
Post by: Digiman on September 12, 2012, 09:39:47 PM
Quote from: Hattig;707840
But the 486s were in £1000+ systems, and the A1200 was a £400 (then £300) system.

Which brings us onto the other failing: No £600 A1230 with 40MHz '030 and 4MB RAM at release. Upselling - Commodore hadn't heard of it, apart from that hard drive included SKU.

At Release:
A1200 2MB '020 14MHz: £399
A1200 4MB '020 14MHz: £479
A1200 4MB '030 25MHz: £549
A1200 4MB '030 40MHz: £599
A2200 4MB '030 40MHz: £799 (A1200 in desktop case w/ separate keyboard)

People would have easily been persuaded to get a higher level A1200 in shops because the price increments aren't too shocking.

The real problem IMO was 030 was a weak improvement on 020 but from 286 to 486 Intel made genuine improvements. The A4000/030 was available for £999 but then was both crippled by the bitplane system of 256 colour modes AND the fact for the same money you got an 040 class CPU in the £1000 486 SX25

Textured 3D was coming whether you liked it or not and 3DO/Saturn/Playstation all instantly aged the Jaguar/SNES/Megadrive over night. The 486 PC + byte per pixel VGA screen mode also did the same to the Atari and Commodore computers.

I don't think it was so much a matter of money with AGA as such, although I agree they didn't have the money to do much with anyway, but the problem is they left it really late, A1000,500,2000,1500,3000,600,CDTV all had the same abilities for 320x256 resolution. All of a sudden the sales started dropping off and Commodore needed 256 colour graphics FAST. TIME that's what Commodore didn't have, even if R.J. Mical and Dave Needle still worked for Commodore in 1990 I don't believe there was enough time between A500Plus launch and A1200/4000 launch to actually create a true successor regardless of loss of engineering talent and loss of cash.

I suppose they could have done what Sony did with PS3, essentially put all the custom chips of the previous generation inside the new machine AND add the new more advanced incompatible custom chips. So a sort of firmware based emulation. This would have allowed 0-64 colours as before and only needed a simple 24bit chip for 256,65000 or 24 million colour modes. Very expensive way of doing it though, would probably have added £100 to price of A1200 and at £400 it was too high already with 880kb floppy and only 4 channel sound (easily fixed with a dual Paula motherboard mind).

There is one thing nobody considered, they could have implemented a mini version of the A3000s video slot inside the A1200 too and left the ECS chipset as is. Then all you need to do is buy hundreds of thousands of cheap powerful graphics chips as used in PC cards and put them on a simple videoslot adaptor to give the extra features of 24bit colour.

Essentially this would then be like the Commodore 128, when you switch from different screen modes it used a different chip after power off/on cycle. VDU or VIC-II. Bil Herd and Dave Haynie who designed a lot of the 128 still worked at Commodore at that time so I'm sure that was possible. And probably would have cost less in R&D than making the ECS compatible AGA chipset.
Title: Re: chunky pixel mode
Post by: Karlos on September 12, 2012, 09:45:29 PM
Quote from: Digiman;707885
The real problem IMO was 030 was a weak improvement on 020 but from 286 to 486 Intel made genuine improvements.


Of course, you skipped a generation on the intel side. The odd numbered 68K parts were intended to be refinements. The 68010 cleaned up the 68000 instruction set (from a virtualization perspective at least) but didn't do much for performance. It was the even numbered parts where you got significant updates to the silicon.

That said, the 030 did make some significant improvements over the 020 when you consider the non-EC parts. The full 030 added on-die MMU and can run at 50MHz (the latter feature being more significant for Amiga machines).
Title: Re: chunky pixel mode
Post by: NorthWay on September 12, 2012, 10:02:49 PM
Chunky would have bought you mindshare, something that would have been way more important than cpu/system performance.

The thinking was "you can't to Wolfenstein on Amiga because it doesn't have chunky" - which is of course bollox, but any kind of 3D on the Amiga at that time was (AFAIK) centered around doing blitter or bitmanipulation directly when drawing the screen, and not adding an extra step with a chunky buffer you convert to planar later.

A 68000 or 68020 is relatively slow, but pc games typically just let you set what size the view should have if you thought it was running too slow (i.e. scale it down), and so you can of course do on any computer.

By the time 'everyone' used c2p the train had left the station.
(And it typically adds 1 frame extra per update so it is a bit disadvantaged, but you can live with that.)
Title: Re: chunky pixel mode
Post by: lassie on September 12, 2012, 11:24:09 PM
Quote from: Digiman;707885
The real problem IMO was 030 was a weak improvement on 020 but from 286 to 486 Intel made genuine improvements. The A4000/030 was available for £999 but then was both crippled by the bitplane system of 256 colour modes AND the fact for the same money you got an 040 class CPU in the £1000 486 SX25

Textured 3D was coming whether you liked it or not and 3DO/Saturn/Playstation all instantly aged the Jaguar/SNES/Megadrive over night. The 486 PC + byte per pixel VGA screen mode also did the same to the Atari and Commodore computers.

I don't think it was so much a matter of money with AGA as such, although I agree they didn't have the money to do much with anyway, but the problem is they left it really late, A1000,500,2000,1500,3000,600,CDTV all had the same abilities for 320x256 resolution. All of a sudden the sales started dropping off and Commodore needed 256 colour graphics FAST. TIME that's what Commodore didn't have, even if R.J. Mical and Dave Needle still worked for Commodore in 1990 I don't believe there was enough time between A500Plus launch and A1200/4000 launch to actually create a true successor regardless of loss of engineering talent and loss of cash.

I suppose they could have done what Sony did with PS3, essentially put all the custom chips of the previous generation inside the new machine AND add the new more advanced incompatible custom chips. So a sort of firmware based emulation. This would have allowed 0-64 colours as before and only needed a simple 24bit chip for 256,65000 or 24 million colour modes. Very expensive way of doing it though, would probably have added £100 to price of A1200 and at £400 it was too high already with 880kb floppy and only 4 channel sound (easily fixed with a dual Paula motherboard mind).

There is one thing nobody considered, they could have implemented a mini version of the A3000s video slot inside the A1200 too and left the ECS chipset as is. Then all you need to do is buy hundreds of thousands of cheap powerful graphics chips as used in PC cards and put them on a simple videoslot adaptor to give the extra features of 24bit colour.

Essentially this would then be like the Commodore 128, when you switch from different screen modes it used a different chip after power off/on cycle. VDU or VIC-II. Bil Herd and Dave Haynie who designed a lot of the 128 still worked at Commodore at that time so I'm sure that was possible. And probably would have cost less in R&D than making the ECS compatible AGA chipset.


Hi nice written :) was the 060 CPU produced around 1993 or was that later? but if it was, i would imaging it will cost to much to put in an Amiga and sell in stores. But it sure could compete with the PC from that time if it could be done :)
Title: Re: chunky pixel mode
Post by: bbond007 on September 12, 2012, 11:37:15 PM
Quote from: Karlos;707886
That said, the 030 did make some significant improvements over the 020 when you consider the non-EC parts. The full 030 added on-die MMU and can run at 50MHz (the latter feature being more significant for Amiga machines).

The same is true with the upgrade from the 286 to 386... most of the speed improvement was the higher clock...

I had a 286  clocked at 25mhz :) it was quick like a 386 and most software still ran in 8088 mode anyway.

I was going to buy a 386 20mhz mb but my system builder guy convinced me should take the faster 286 and the (more expensive) Tsing video over the Trident :)
Title: Re: chunky pixel mode
Post by: Pentad on September 13, 2012, 12:05:53 AM
Quote from: bloodline;707861
You mean the legendary "Ranger Chipset"... Designed by the original team while still at Commodore... But never put into production... Apparently it would have been a killer!!!


Yep!  I could not think of the name for anything.  I am hoping that On the Edge - Part II will shed some more light on this, the original team, and how this all got shuffled around.

If memory serves, it would have put CBM insanely far ahead of everyone else.

Alas, what could have been.

-P
Title: Re: chunky pixel mode
Post by: Karlos on September 13, 2012, 12:06:12 AM
The 386 was a major architectural improvement over the 286 though, at least when running in non-segmented mode.
Title: Re: chunky pixel mode
Post by: bbond007 on September 13, 2012, 03:11:53 AM
Quote from: Karlos;707903
The 386 was a major architectural improvement over the 286 though, at least when running in non-segmented mode.


It certainly made a real UNIX possible on PC hardware. That segment/offset crap was a major PIA. I recall trying to track down a bug in something I was writing caused by the use of a "near" pointer when I should have used a "far" pointer.... whatever... don't miss that nonsense.

By the time games started to use 32bit modes of the 386, they really needed a 486....
Title: Re: chunky pixel mode
Post by: Cammy on September 13, 2012, 03:17:44 AM
If Amiga had a chunky mode, this would be even faster!

[YOUTUBE]RKixK1gxOns[/YOUTUBE]

Unfortunately it's only AGA. :(
Title: Re: chunky pixel mode
Post by: itix on September 13, 2012, 07:25:30 AM
Quote from: runequester;707865
For a certain type of games sure. We'd all have loved to have UFO Enemy Unknown be less pokey. But there were plenty of areas where CPU power was important: Coding, all sorts of applications (including graphics which was a popular use of the amiga community), and later games.

It'd also permit more advanced games. Look at things like Genetic Species and Onescapee for some simple things that were possible with a decent 030 and AGA.


Better CPU allows better 3D games, better productivity apps and so on but PC world was already having SVGA as a standard and games used it.

After all in mid 90s Amiga was losing its fight on all fronts: 68k CPU arch was dying, AGA couldnt compete against SVGA, the OS development was slow and 4 channel 8-bit audio (Paula) was aging. Even if Commodore did few more things right they didnt have a chance.

And of course all those fancy companies making fancy games for PC...
Title: Re: chunky pixel mode
Post by: runequester on September 13, 2012, 07:41:42 AM
This is true, but those were solvable problems ultimately. RTG, AHI and PCI sound cards, PowerPC stuff. They just weren't solved at the time it needed to happen.
Title: Re: chunky pixel mode
Post by: Crumb on September 13, 2012, 10:28:00 AM
Quote from: Digiman;707885

I suppose they could have done what Sony did with PS3, essentially put all the custom chips of the previous generation inside the new machine AND add the new more advanced incompatible custom chips.


IIRC project "Hombre" included amongst other goodies ECS Amiga compatibility in a chip (that's the reason cbm didn't want to release AGA information).
Title: Re: chunky pixel mode
Post by: psxphill on September 13, 2012, 12:07:08 PM
Quote from: Digiman;707885
Textured 3D was coming whether you liked it or not and 3DO/Saturn/Playstation all instantly aged the Jaguar/SNES/Megadrive over night. The 486 PC + byte per pixel VGA screen mode also did the same to the Atari and Commodore computers.

A chunky pixel mode on it's own wouldn't have made a huge difference, it would have needed a texture mapper added to the blitter as well.
 
If they could have achieved that around the a500+ timeframe then it could have saved them. The amiga had already started winding down by then and needed a shot in the arm. ECS was not good enough to keep people buying amigas. They could probably have stuck with a 68000 and still had some good games.
Title: Re: chunky pixel mode
Post by: ElPolloDiabl on September 13, 2012, 12:58:07 PM
A lot of people say that Amiga was dead at the time of A500+
People wouldn't buy one when it was starting to lose popularity. Me as a user was was still happy till the A1200 release, which was a disappointment. Cool, but if the add-ons had been cheaper I would still have it as a second machine. Now it is just a retro machine, used occasionally.
Title: Re: chunky pixel mode
Post by: bloodline on September 13, 2012, 01:50:53 PM
Just thinking about the possibilities... If Lisa had been given a 256 colour chunky pixel mode at 320 x 256, plus if she had 128k of ram as the chunky display buffer mapped to the chipset address space by where she had priority, and if the regular planar display could be mixed over the chunky display... We might have had something really cool to play with at relatively little extra cost...
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 13, 2012, 02:15:15 PM
if multiple displays could simply be combined together like layers in photoshop, a truecolour display could be made by adding three 8-bit paletted screens together!  (Chunky or otherwise.)  Plus any other weird and wonderful combinations one could dream up...
Title: Re: chunky pixel mode
Post by: psxphill on September 13, 2012, 02:19:55 PM
Quote from: bloodline;707972
Just thinking about the possibilities... If Lisa had been given a 256 colour chunky pixel mode at 320 x 256, plus if she had 128k of ram as the chunky display buffer mapped to the chipset address space by where she had priority, and if the regular planar display could be mixed over the chunky display... We might have had something really cool to play with at relatively little extra cost...

That sounds very complex to shoehorn in. Lisa already ran out of registers and you're going to have to duplicate alot of them for the dual chunky and bitplane mode.
 
I'd prefer the option of 640x512 chunky modes than being able to mix them.
Title: Re: chunky pixel mode
Post by: runequester on September 13, 2012, 03:34:52 PM
Would the Amiga have been able to function with as little RAM as it had, using Chunky modes, or is that not an issue?
Title: Re: chunky pixel mode
Post by: Vanilla on September 13, 2012, 04:07:58 PM
@lassie

Quote
Hi i have been thinking about 3D on Amiga and read about something called chunky pixel mode, if they had used that in an Amiga 1200 and CD32 would it have made the Amiga better at 3D games? or should there more to it, maybe more ram etc?


AlienBreed 3d had a copper chunky mode for the display mode. Which probably just modified a background colour or something with a 12-bit RGB pixel value. Most likely a manual CLUT mode was used with a lookup table to help. Or it was was used directly but then the instructios skipped over. It was at super low res. 160x256. :D

The CD32 had chunkly to planar hardware. You wrote some chunky in and read some planar out so it was still manually controilled to an extent.
Title: Re: chunky pixel mode
Post by: Vanilla on September 13, 2012, 04:11:07 PM
@Crumb

Quote
More sprites would have made a real difference. Check out Neo Geo games. These are 2D only but impressive anyway. C


The Amiga had virtual spriites. Which could multiple them up to 64 IIRC provided the scan line had enough to work with. The OS even supported them. So you could program the OS instead of trying to work it out yourself.
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 13, 2012, 04:15:28 PM
You could fit a 640x512 truecolour (24 bit) screen in just under 1Mb.  I'd recommend a bit of FAST RAM as well, though.

Put simply, a chunky mode wouldn't use any more RAM than the equivalent planar mode.  Planar modes only save memory if you're not using all 8 bitplanes, except HAM8, which is clever but not much use for games (and in theory you could have a Chunky mode HAM anyway).
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 13, 2012, 04:23:04 PM
Quote from: Vanilla;707989
The Amiga had virtual spriites. Which could multiple them up to 64 IIRC provided the scan line had enough to work with. The OS even supported them. So you could program the OS instead of trying to work it out yourself.

But there are many complex and difficult limitations for virtual sprites.  Essentially you re-use the same sprites several times by using the copper, so there is no limitation on the number on screen but if you want them to be able to overlap arbitrarily you've got problems.  This trick has been used to get extra layers of parallax.

Also you lose a sprite when you start the screen data fetch early which is required for full screen hardware scrolling.  Note the Turrican game screen is actually 16 pixels in from the left!  Presumably this is so they can use all 8 sprites.
Title: Re: chunky pixel mode
Post by: runequester on September 13, 2012, 06:32:54 PM
Quote from: Mrs Beanbag;707991
You could fit a 640x512 truecolour (24 bit) screen in just under 1Mb.  I'd recommend a bit of FAST RAM as well, though.

Put simply, a chunky mode wouldn't use any more RAM than the equivalent planar mode.  Planar modes only save memory if you're not using all 8 bitplanes, except HAM8, which is clever but not much use for games (and in theory you could have a Chunky mode HAM anyway).


Thanks for the clarification. So by the time we're talking 256 colours, there's no savings involved in planar?
Title: Re: chunky pixel mode
Post by: Zac67 on September 13, 2012, 06:33:52 PM
Quote
Which could multiple them up to 64 IIRC provided the scan line had enough to work with.
Actually, the Amiga's sprites are channels which are limited to 8 sprites per scanline. So, theoretically you could use up to 512*8 = 2048 on PAL interlaced with no more than 8 overlapping on any scanline. ;)
Title: Re: chunky pixel mode
Post by: Mrs Beanbag on September 13, 2012, 06:43:38 PM
In fact you can re-use a sprite several times on a scanline with clever use of the copper.
Title: Re: chunky pixel mode
Post by: zioben1976 on March 09, 2016, 01:55:20 PM
I never realized why Commodore dosen't make a chunky mode for AGA. AGA is born to support more than 5 bitplanes. Simply designers could add a bit in some register to switch to 8-bitplanes and 256 colors chunky mode when set ( like the bit to switch to real 6-8 Bpl mode and EHB-Ham-6/8 mode...).
I think it costs nothing to design the ciruitry in Agnus.
With 8BPL chunky mode, Fetch 4X, and 32 bit access Bandwidth to the ram was theorically 8MB/sec in Lo-Res and and 6.3MB/sec in HiRES, enough to obtains 100FPS in lo-res and 20FPS in hi-res.
What really think is that AGA is an old designed OCS upgrade and no more.
I think Commodore had AGA chipset ready a lot time before launch of A1200 and 4000. I think those machine were forcedly launched too early in response to the growing market of PC and Consoles.
Title: Re: chunky pixel mode
Post by: Themamboman on March 09, 2016, 03:58:58 PM
Wasn't the Akiko chip in the CD32 there to provide chunky mode conversion for CD32 games?

I wonder how much performance impact it had?
Title: Re: chunky pixel mode
Post by: guest11527 on March 09, 2016, 07:31:58 PM
Quote from: Themamboman;805656
Wasn't the Akiko chip in the CD32 there to provide chunky mode conversion for CD32 games?

I wonder how much performance impact it had?

Akiko? Next to nothing. Akiko hat a series of registers into which the CPU could write a sequence of chunky data, and a second set of registers where the converted planar data could be obtained. This avoids a lot of shifting and masking for the C2P transformation, but the CPU still has to touch each pixel manually.

In particular, there is no DMA channel that could automate the process, C2P is still a CPU hog. If Akiko could be feed by the blitter, or would have been part of the blitter, or part of Agnus as part of the bitplane DMA - this would have helped. But the given design is a minimalistic solution that does not help much.
Title: chunky pixel mode
Post by: SamuraiCrow on March 10, 2016, 11:46:20 AM
Quote from: runequester;708010
Thanks for the clarification. So by the time we're talking 256 colours, there's no savings involved in planar?


Correct.
Title: Re: chunky pixel mode
Post by: itix on March 10, 2016, 12:30:35 PM
Quote from: Thomas Richter;805670
Akiko? Next to nothing. Akiko hat a series of registers into which the CPU could write a sequence of chunky data, and a second set of registers where the converted planar data could be obtained. This avoids a lot of shifting and masking for the C2P transformation, but the CPU still has to touch each pixel manually.


I recall on 020 Akiko was faster than the software C2P, on 030 they got roughly even and on 040 the software C2P was always faster...

Quote
In particular, there is no DMA channel that could automate the process, C2P is still a CPU hog. If Akiko could be feed by the blitter, or would have been part of the blitter, or part of Agnus as part of the bitplane DMA - this would have helped. But the given design is a minimalistic solution that does not help much.


Could be I remember wrong, it has been so many years since this information was relevant... but I recall C2P was not great bottleneck on faster CPUs. Fast 68060 and C2P was a non-issue again.