SetAPen(RastPort*, UBYTE);

[Karlos]

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:

Code: [Select]

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

[Karlos]

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.

[Karlos]

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.

[Karlos]

If you're targetting OS4:

IGraphics->SetRPAttrs( rastport, RPATTR_APenColor, 0xRRGGBB, TAG_DONE );

Much cleaner. Pity there's no 3.x equivalent.

[Karlos]

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.

[Karlos]

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:

[Karlos]

Sure, but that's thanks to AfA, not AmigaOS 3.x tself.

[Karlos]

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?