ObtainPen on high/true color RTG screens

[BSzili]

I'd like to use graphics.library line drawing functions, like Move + Draw on 16-bit or 32-bit RTG screens, but I don't know how to pick a color using R,G,B values that's not in the 4 color Workbench palette set for the screen.
FindColor and ObtainBestPenA only picks from these 4 colors, ObtainPen with or without the PEN_EXCLUSIVE flag always returns -1 if the color isn't in the colormap already. I tried these both on the Workbench public screen and a custom screen, but it didn't seem to make any difference. If there's any other way to do this please let me know
I'm using Picasso96 2.0 as my RTG system.

[thomas]

Originally Posted by BSzili

FindColor and ObtainBestPenA only picks from these 4 colors, ObtainPen with or without the PEN_EXCLUSIVE flag always returns -1 if the color isn't in the colormap already.

Well, this should not be true in general.

Remove any patches like FullPalette.

Make sure that in Prefs/ScreenMode you moved Depth to the maximum number or colors.

If you open your own screen make sure to activate pen sharing. And set depth to at least 8.

The number of free pens on a screen still depends on the depth setting, even if the pixels can show many more colors.

Normally, if the depth of the screen's bitmap is larger than 8, you call ObtainPen with PEN_EXCLUSIVE once and then set the RGB value of that pen to the value you want to draw with. You can reuse the pen and set different RGB values as long as you need it. When done don't forget to release the pen. The advantage is that you need only one pen for all drawings because the drawn pixels keep their color even if the pen color changes.

[BSzili]

That makes sense, thanks for the explanation. This rules out public screens, as I'd be at the mercy of the depth setting in the prefs. Since both the CGFX and P96 APIs have rect fill functions that take a direct color value, I can use this as a workaround, at least for horizontal and vertical lines.

[Karlos]

Be careful. My experience with this is that on the hardware I had, Draw - which was hardware accelerated on the Permedia2 was slower than doing it myself, in software with a bitmap lock and a good Bresenam implementation. It wasn't until I fixed line drawing in an unrelated P2 68K Warp3D driver that I realised it wasn't an RTG problem. On that hardware, arbitrary line drawing is just slow, because reasons. It was literally faster to fake it using a 1 pixel wide triangle pair, but the results were not always ideal.

Of course, you need to be drawing a reasonable number of lines in a bitmap lock for software plotting to be worth it too.