CGX4 with AGA

[bloodline]

Most importantly, it allowed AGA users to run software writen for graphics cards. it was quite a clever idea to depreciate the amiga graphics.library and replace it with the cybergraphics one...

[bloodline]

Karlos wrote:
@Piru

Pity CGX5 isn't available outside of MorphOS. The frustration I had trying to create a decent graphics class library for OS3.x back in the day. I ended up with a polymorphic Rasterizer class that had pure software, mixed software/RTG and Warp3D children. You got whichever one was best suited at runtime to your system (via a factory method, naturally).

The version of the class that used RTG ended up pretty much only using RTG for block fills and some flat colour stuff as there really wasn't much else it could do (either because of the pen limitation or for speed reasons) that software alone didn't completely surpass.

Perhaps a backport of AROS's cgx implemetation would be a good idea?

[bloodline]

Karlos wrote:

bloodline wrote:

Karlos wrote:
@Piru

Pity CGX5 isn't available outside of MorphOS. The frustration I had trying to create a decent graphics class library for OS3.x back in the day. I ended up with a polymorphic Rasterizer class that had pure software, mixed software/RTG and Warp3D children. You got whichever one was best suited at runtime to your system (via a factory method, naturally).

The version of the class that used RTG ended up pretty much only using RTG for block fills and some flat colour stuff as there really wasn't much else it could do (either because of the pen limitation or for speed reasons) that software alone didn't completely surpass.

Perhaps a backport of AROS's cgx implemetation would be a good idea?

Possibly. Isn't it just a wrapper for the HIDD layer? If so, it is the latter that needs backporting (or an equivalent system thereof) ;-)

Yes and yes... but that was kind of the point I was making :-) fancy making an AGA.hidd?

[bloodline]

Karlos wrote:

fancy making an AGA.hidd?

No, because it would seriously suck :lol:

To justify that, you'd basically end up with a lot of the problems CGX-AGA had anyway, not the least of which would be the 256-colour limit.

Or how about an 8bit "Low colour" mode... 2bits red, 4bits green, 2bits blue... scaling hi/tru colour pixels down to their lo colour equivalent :-) This was an idea suggested by Fabio...

CGX-AGA could have been so much more. Especially since it "relied" on the ppc.library (in the same way that your fridge relies on your kitchen floor)

I remember playing with the various EVD that were available for shapeshifter at the time. There were some which used PPC for C2P, able to convert an entire frame and copy only the changed areas to the display faster than the 68K could actually update the source framebuffer. There was also a 16-bit colour -> HAM8 driver which delivered suprisingly good results (very little HAM artifacts) and was faster than most of the 68K 256-colour EVDs.

IMNSHO, this is the sort of functionality CGX-AGA should have delivered - support for chunky 8/15/16-bit (possibly even 24/32-bit) framebuffers in fast ram and a PPC colourspace-converter/C2P *if* it was going to lay claim to using the PPC for anything.

Yeah, I agree, but I imagine the complexity of PPC->68k context switches made it undesierable... though I can't remember how horrible it was... the PPC on my A1200 simply doesn't get used any more and since UAE doesn't have a PPC emu... I'm not going to find out anytime soon...

I do remember thinking about setting the PPC up as a GFX co-processor... but you would have to have assigned a seciton of the PPC memory space as non cacheable.. then written a smal GPU emualtor for the PPC to read the non cacheable region as registers... actaully that does sound like fun...

[bloodline]

Karlos wrote:

I do remember thinking about setting the PPC up as a GFX co-processor... but you would have to have assigned a seciton of the PPC memory space as non cacheable.. then written a smal GPU emualtor for the PPC to read the non cacheable region as registers... actaully that does sound like fun...

A different approach would be to have library that employs the PPC as a graphics device. You send it rasterization requests (just basic function calls in reality), which get buffered up then executed (as part of a context switch minimisation job). It would handle all the drawing, colourspace conversion and C2P.

That would be a fun thing to try :-)

There might be synchronization issues with that approach..? You ould send your display list to the PPC and then have to poll to determine when the PPC had actually completed the operations... unless the 68k could wait on an interupt generated by the PPC... I'm sure this is a very sticky issue...

[bloodline]

Karlos wrote:
Who said it has to be asynchronous? I simply envisaged doing the buffered rendering immediately the next screenbuffer becomes free :-)

You can do asynchronous context switches but I'm not sure they'd be that useful in this scenario. Or rather they could be, were they not such a pain to use.

oh, yeah... ok... are you talking about PowerUp or WarpOS?