Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: The Hanged Man on April 06, 2010, 12:50:25 AM
-
Wanting to use a graphicscard, this is a real prob to me. I need a (RastPort*, WORD/LONG). I suppose it's because it's using cgx.library instead of the regular graphics.library... Where do I find some 'autodocs' ?
-
If you are using graphics.library, pens are limited from 0-255, regardless of what your display is running on.
If you need to set an arbitrary colour for area pens for use on an RGB display, you need to use LoadRGB32 to set the colour of your chosen pen (or pens). On an RGB display, you can keep changing the pen colour without affecting already rendered pixels. On an indexed display, you have to worry about finding a suitable pen that is close to your desired colour in the first place.
Here's a bit of code from an old project:
void Draw2DAmiga::setPenRGB(Colour32 c, sint16 pen) // private
{
// sets the desired RGB value for a given pen index. For RGB modes only.
uint32 rgb32tab[] = {
1UL<<16|(pen&255),
(uint32)(c.red())<<24,
(uint32)(c.green())<<24,
(uint32)(c.blue())<<24,
0
};
// according to docs, this is faster than SetRGB32, even for 1 colour...
LoadRGB32(view, rgb32tab);
}
-
Thx, but I know all that stuff (UBYTE is only 8bit...)
Yes, I know I'll probably not be using pens at all, rather, just be choosing by RGB values from 16/32 bit.
I found this link:
http://utilitybase.com/ref/?action=List&funcgroup=Picasso96
-
The thing is, unless you intend to be doing your drawing using your own routines, you'll still need to deal with the graphics.library, regardless of which RTG system you are using. Which means messing about with pens, unfortunately. FWIW, I thought it was poor that neither CGX nor P96 provided RGB capable replacements.
To clarify that, if all you want to do is blast an RGB image onto a display, then you'll have no problems with p96 or cgx chunky pixel functions. If you actually want to do some block fills and rasterize primitives, then you'll need the graphics.library. It doesn't actually matter that you are using a pen in those cases since on an RGB display, you can allocate a pen and change it's colour as often as you want without affecting anything you already rendered (unlike in 8-bit indexed mode). It's a pain in the arse having to actually reload the pen colour from your nice RGB value, but you can put that into a function and forget about it. Although it feels like bloat, at least you should get the benefit of hardware acceleration for the actual rendering then.
-
So, I can use regular grapgics.library for +8bit displays, but I will be using 'pen 1', and then change the palette value of 'pen 1' by using the values with SetRGB32(), but without SetRGB32() changing colorvalues, in contrast to the behavior of a 8bit display ?
I think Commodore failed even on 3.0. The more colors of the AGA was very poorly implemented. Even making the WB use more than 8colors was a real pain. I personally had to make a program to set and lock the pens in order for that to work reliably. I wonder if drawing in HAM8 was even implemented.
-
So, I can use regular grapgics.library for +8bit displays, but I will be using 'pen 1', and then change the palette value of 'pen 1' by using the values with SetRGB32(), but without SetRGB32() changing colorvalues, in contrast to the behavior of a 8bit display ?
Yes. Just allocate a pen, set it's RGB value, render with it, change the RGB value again, render some more and when you are done release the pen. If it's on your own screen, you can just allocate the pen after you open the screen then release it before you close it. You aren't restricted to using just the one pen, you can allocate pens for area, fill etc. Regarding SetRGB32(), the documentation makes it clear that it's slower than LoadRGB32() with a single colour index.
I think Commodore failed even on 3.0. The more colors of the AGA was very poorly implemented. Even making the WB use more than 8colors was a real pain. I personally had to make a program to set and lock the pens in order for that to work reliably. I wonder if drawing in HAM8 was even implemented.
Well, they managed to accomplish quite a lot in making intuition/graphics sufficiently detached from the native chipset that you could ever use an RTG system in the first place. Arbitrary RGB rendering functions would not have made sense on ECS/AGA since neither system offered a true RGB display.
In my opinion, CGX and P96 should have implemented a forwards-compatible true RGB graphics.library equivalent implementation for applications that needed to use true colour rendering. This could have been realised in a fashion that would be far more efficient than routing all rendering calls through the existing graphics.library. Instead, all we have are read and write pixel functions.
-
If you're targetting OS4:
IGraphics->SetRPAttrs( rastport, RPATTR_APenColor, 0xRRGGBB, TAG_DONE );
-
If you're targetting OS4:
IGraphics->SetRPAttrs( rastport, RPATTR_APenColor, 0xRRGGBB, TAG_DONE );
Much cleaner. Pity there's no 3.x equivalent.
-
Well if everyone bought a SAM or X-1000, we could forget about 3.x ;-)
-
Well if everyone bought a SAM or X-1000, we could forget about 3.x ;-)
Well, speaking as a 4.1U1 owner, I still enjoy using and coding on 3.x.
-
I know, i know. Hence the smiley.
-
I know, i know. Hence the smiley.
You know, this sort of brings be back to the point that RTG on 3.x could do with updating, even if it means an entirely new system.
I was so fed up with the lack of decent drawing acceleration on RTG that I ended up using Warp3D to do 2D drawing :lol:
-
Much cleaner. Pity there's no 3.x equivalent.
On AFA OS 68k ,AROS and MOS you can set RGB foreground and background colors with that Tag
RPTAG_FgColor:
RPTAG_BgColor:
SetRPAttrs( rastport, RPTAG_FgColor:, 0xRRGGBB, TAG_DONE );
do the Job here.
if you like the OS4 syntax you can just do
#define RPATTR_APenColor RPTAG_FgColor
>Well if everyone bought a SAM or X-1000, we could forget about 3.x ;-)
haha when peolple should force to OS4 it should get lots better i think.
I better not tell what i miss(the list get too long)on OS4, but a AOS with all features of MOS and OS4 and Hardware support of MOS and OS4 that come in my mind for a good future AOS.
but so, i stay on 68k and better add a few minutes and add OS4/MOS features that are usefull to AFA.
-
Sure, but that's thanks to AfA, not AmigaOS 3.x tself.
-
If you're targetting OS4:
IGraphics->SetRPAttrs( rastport, RPATTR_APenColor, 0xRRGGBB, TAG_DONE );
And if you were targetting AROS/MorphOS you would use:
SetRPAttrs( rastport, RPTAG_FgColor, 0xRRGGBB, TAG_DONE );
At least MorphOS defaults to 3.x pens though, so before using truecolor rendering you should call SetRPAttrs( rastport, RPTAG_PenMode, FALSE, TAG_DONE );. That tells MorphOS that you really want to render by using RGB rather than pens. I don't remember if AROS had such "pen mode" default or not.
Anyway, if AROS graphicslibrary would be backported you'd get the RPTAG_FgColor and RPTAG_BgColor similar to AROS/MorphOS.
Here's some example code I wrote some time ago: http://www.sintonen.fi/src/misc/truecolortest.c
-
I better not tell what i miss(the list get too long)on OS4, but a AOS with all features of MOS and OS4 and Hardware support of MOS and OS4 that come in my mind for a good future AOS.
You just can't go a single post without making a dig at OS4 can you? *sigh*
-
@Piru
There is no "mode" on OS4, or at least the mode is transparent. If you set "APenColor" APen is an RGB colour value. If you then use SetAPen(), its a pen again.
-
The OP hasn't really said what his target platform was, but reading between the lines, I assumed vanilla OS3.x.
The 4.x/AROS/MOS methods are interesting to note, but are they relevant?
-
Sure, but that's thanks to AfA, not AmigaOS 3.x tself.
sure but AFA can use for free, nobody must buy a expensive Hardware for this or pay any cent.
And btw this programs run too well when run on MOS(either 68k /PPC or compile for AROS)
only problem AFA have, it have no Licence from Ainc and no AOS source.But it run stable and is near 100% compatible and enhance AOS with the important missed features.
-
@Piru
There is no "mode" on OS4, or at least the mode is transparent. If you set "APenColor" APen is an RGB colour value. If you then use SetAPen(), its a pen again.
Well I hope there at least is some way to get and set the mode somehow? Else it'd be a bit messy to write library code that does some rendering using specific mode while restoring the old mode afterwards.
-
You just can't go a single post without making a dig at OS4 can you? *sigh*
You was the guy that tell all should buy OS4.If you not write it, i need nothing write about too few OS4 features for me to buy.
I tell what i miss in short this time in OS4.
Maybe the OS4 guys make it better, then maybe i can buy it.