Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Lemonty on May 05, 2007, 08:03:59 PM
-
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!
-
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.
-
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...
-
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.
-
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?
-
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.
-
@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.
-
Hmm, I think I may have found another reference. Sadly I don't speak Polish so I'm not entirely sure...
klik hier (http://www.ppa.pl/forum_ppa/read.php?f=4&i=8515&t=8515)
-
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.
-
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?
-
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()...
-
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) ;-)
-
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?
-
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.
-
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...
-
Yeah, I agree, but I imagine the complexity of PPC->68k context switches made it undesierable
I disagree here. The worst case scenario is a 68K->PPC->68K context switch per frame, assuming something changes on screen each frame. This would of course, depend on having all drawing operations accumulated in the fast ram buffer and invoking a chip ram update only on refresh, but again that is doable. Most WarpOS/PUP games already have worse switching overhead than that.
Secondly, a smart implementation would evaluate the amount of work required to update the screen (in terms of pixels requiring conversion). Below a certain threshhold (user tunable) it would stay purely 68K. The PPC would kick in where larger areas need modifying.
Regarding the low colour thing, you might be better off using the web 216 palette, since it basically gives 6 levels per gun, which is better than any bitwise aportioning of the space.
-
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 :-)
-
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...
-
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.
-
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?
-
Either. The choice is purely academic since later versions of PUP improved the context switch times. The approach I'm talking about really only requires a context switch pair per frame.
I wrote some test code in VBCC some time ago for WOS that basically defined a display context for PPC native apps. It used one context switch per frame (PPC->68K and back). The 68K code called all the OS routines for swapping the buffers and gathering the IDCMP messages into a local buffer before switching back. The PPC then called ppc-native mouse/keyboard callbacks with the captured IDCMP data, so basically the 68K only handled interfacing with the OS.
What I am talking about here is simply the inverse approach, using the PPC to perform rendering operations and screen updates (specifically the colour conversion and C2P, not flipping buffers etc which would still be done on the 68K)