2D games will always be around and will be some of the most fun games but they will certainly be using the 3D horsepower of modern platforms more of the time. (for scaling and rotating of the 2d art)

Games like Wario land Shake it, Odin Sphere, and Guilty Gear are great examples.

But why did you choose RGBA and not ARGB ? To me the latter seems more consistent with actual palette hardware which has the "unused" part in the high order bits, i.e. I'd find more logical to use 32bit/8A8R8G8B.

^
| /
|/
+-->

from where would the X,Y and Z axis would it point of origin be on the screen and how would it be orientated?

Ben Blish described the concept in Amiga Transactor more eloquently than I ever could. Here is the text of the article, the latter half of which contains the most relevance.
EXTERNAL LINK  (25.67 KB)

I understand the theory but have no idea of the hardware design. Maybe it's an idea that's time has passed but I just thought the alpha channel could be used for more than transparency effects. What say you all?

The text document suggests encoding drawing operations in a tiny 8 bits of data per pixel, and using specialized hardware to decode and perform these operations, such as do bitwise XOR on this pixel, or move one pixel left before drawing the next pixel.

People always find clever uses for strange functionalities, but in a modern system with a linear frame buffer and a powerful GPU and CPU that can do any imaginable arithmetics and operations, possibly at a zero cost for many common graphics operations, this Cartesian pixel plane will in my opinion be a curiosity at best.

Why specialized hardware?
Well because we need to be able to do more in less time.
And specialized hardware has been known to be faster then generic.

A modern GPU is a monstrosity, it consist still out of relative simple building blocks.
It's just they have serveral more then we can afford.

We look at 3 categories
1. Basic functions, usually done in Hardware compares to breathing.
2. Complex functions, Sometimes done in hardware, mostly in software when proven too limiting in hardware, or too costly.
3. Rare functions, Think, something posible but useful in one application.

In what Category would Cartesian fall?
And think about this not every single thing has to be taken over word for word.

you can deinterleave the chunky graphics into planar one's using relative simple hardware.
However this would increase the need for more layers exponentially.

Marcel Verdaasdonk wrote:

you can deinterleave the chunky graphics into planar one's using relative simple hardware.   However this would increase the need for more layers exponentially.

Again, not quite the problem. Deinterleaving - chunky to planar and planar to chunky - is only part of the problem. The problem is also color indirection and masking.

For example: BlitTemplate takes a bitmap as output, has a planar(!) mask as input and has to cookie-cut through the layer boundaries. Thus, you need to convert the current data (chunky for a chunky bitmap), need to use the color in the APen of the rastport, go there to the current pen definition, use the true-color value there for the current pen whose value is the APen, then cookie-cut this through the bitmap (which is planar) - for the JAM1 draw mode - and then render back to the chunky bitmap. It is *not only* a simple planar-chunky conversion, but a round-trip through several lookup steps that simply do not happen this way in a traditional planar setup where color-indirection happens in the hardware.

The linear 24-bit modes require special-cases in the blitter hardware and will therefore remain unsupported by the NatAmi.  Byte-planar graphics take advantage of blitter features already included in the chunky-8 display mode support.

another interesting Idea is to do chunky to HAM conversion in the hardware...

A) Reverse engineer the drivers for P96 and write a Natami driver. P96 would need to be installed to use chunky modes under Natami.
B) License P96 or CGFX obtaining the needed documentation to make a driver. A distribution license could be obtained allowing Natami to come pre-installed with chunky support.
C) Add better planar support to AROS.
D) Write a new graphics.library that support chunky and is API compatible to AROS/CGFX.

  Option A is cheap with moderate difficulty. Option B is faster than A with more cost but may not be available. Option C will take a long time and a lot of testing. Option D has too many variables to say much. Option A, Reverse engineering and creating a P96 driver looks like the best short term solution to me. Option C or D could possibly use the P96 driver created in A or B.

What is smarter to do in hardware?
build up from the back and overdraw where intended to?
Or build up from the front screen and mask the under laying layers, when alpha isn't set?

As if CGX 4 wasn't hijacked by MorphOS?

What I mean by this is, with SuperAGA, we don't need to carry around the same restrictions. If the hardware is new, and the software making use of this enhanced hardware will be new, then the restrictions need not apply, correct?