CGX4 with AGA

[Lemonty]

I own a copy of CGX4 and I have read here somewhere that using a patch of some sort you could use CGX4 on AGA.
Unfortunately I cannot find the article using the search facility on Amiga.org anymore.
Does anyone know if it can be done at all? Which patches do I need?
Many thanks!

[Karlos]

You sure that wasn't CGX3? I remember using CGX-AGA on that before getting an RTG card.

At the end of the day, it wasn't anything that revolutionary, it simply allowed the CGX library calls to work on an AGA screen. You didn't get simulated HAM8 highcolour or anything funky like that. However, it did allow you to make more use of fast ram for image buffers and the like, which makes your 2MB chip go further.

I remember having an autoscrolling 1280x1024 16-colour workbench screen on a 640x512 interlaced PAL screen and using MagicTV to reduce the flicker. Under CGXAGA this was pretty useable.

[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...

[Lemonty]

I remember browsing the picture galleries of Aorg and some comments of a certain screenshot made a reference to some patches you could use to enable cgx aga. I'm pretty sure it was for CGX4 not CGX3 [which would enable aga on ppc machines iirc?]. I then actually downloaded the files but since an unfortunate harddisk failure I have lost the files. I never got to actually try it out.

[Karlos]

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

Well, it allowed RTG software to run that would run on 256 colours or less. In my experience, most RTG software at the time was aimed at using true colour depth. Games were the notable exception (but most 256 colour games that supported AGA tended to do so directly).

As for replacing the graphics.library, yeah, I wish ;-) The cybergraphics.library didn't contain any drawing functions at all (with the exception of various pixel array writing methods duly noted).

The thing which irritated me most with RTG was the fact it provided no alternate rasterization functions, simply patching the existing ones in graphics.library to work on RTG - great for OS friendly apps but not much use for pushing the envelope. I mean using pens on an RGB screen. How retarded is that?

[Piru]

The thing which irritated me most with RTG was the fact it provided no alternate rasterization functions, simply patching the existing ones in graphics.library to work on RTG - great for OS friendly apps but not much use for pushing the envelope. I mean using pens on an RGB screen. How retarded is that?

It indeed sucked. CGX5 fixed it.

[Karlos]

@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.

[Lemonty]

Hmm, I think I may have found another reference. Sadly I don't speak Polish so I'm not entirely sure...
klik hier

[itix]

I mean using pens on an RGB screen. How retarded is that?

Very. But it was possible do truecolor rendering by allocating one pen for your program. CGX4 made this little more easier by allowing colormap for offscreen bitmaps.

[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?

[Karlos]

itix wrote:

I mean using pens on an RGB screen. How retarded is that?

Very. But it was possible do truecolor rendering by allocating one pen for your program. CGX4 made this little more easier by allowing colormap for offscreen bitmaps.

Sure you could do it, but it was an agonizingly retarded and slow way of working. Software rendering to a BitMap ended up being an order of magnitude faster in almost all cases - you'd have to be out of your mind to render, say, a gradient fill using pens and continuously setting them.

The single best thing cybergraphics.library gave you as a developer was LockBitMapTags()...

[Karlos]

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) ;-)

[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?

[Karlos]

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.

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.

[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...