graphics.library expert required :-)

[Karlos]

Hi,

Picture the scene. I have a windowed application running on a 15-bit (or higher) Workbench.

The application uses an offscreen BitMap for rendering, the contents are then copied to the window with a ClipBlit().

I am experimenting with a software Draw class that basically draws onto a BitMap. I want to see my own algorithms versus the OS drawing code (the usual graphics.library stuff).

My own code locks the bitmap and draws into it directly. This means that everything is done in software.

My assumption is that OS code may be faster than my hand rolled code due to the potential of HW acceleration by the gfx card's driver.

My problem is that I need to be able to set any arbitrary colour for drawing. For my own code that is not a problem, but the graphics.library seems a bit more arcane.

I know that the graphics.library code uses Pens for all of its normal rendering. I also know that you can get locks on Pens...

My question is this. Assuming my offscreen BitMap is a friend of the Workbench screen Bitmap and is at least 15 bits deep, how do I arbitrarily set the colour I want to draw with?

Im guessing I need to allocate my own pen, set its colour, set the RastPort drawing pen to use it and so on, but the graphics.library docs are a little vague.

In particular, ObtainPen() uses a ColorMap structure that is in turn obtained from GetColorMap(). I assume in the case of an existing display such as the workbench screen that there would be an existing ColorMap already. How do I get a handle to it?

Does anybody actually have any working examples of this type of stuff? In particular - get a pen on an existing (hi/truecolour) screen, change it to whatever colour you want and use graphics.library drawing functions.

Thanks for any tips...

[itix]

First, I'm not a graphics.library expert...

But I think you cant do this with OS3 graphics.library only. You need
CGS/P96 libraries here.

If your application is very CPU demanding I suggest throwing 8bit
support away.

*No blutterflies were harmed in the production of this avatar.

Phew! :-D

[Kronos]

@Karlos

You know there is an easy way ?

Just put down that MG and embrace the butterfly  :-o  :-P  ;-)

Pains (o.k.cheap joke) are one of the hardest things in AOS-progging,and yes it
is as complicated as you thing.

Basiclly you will need to GetColorMap(),followed by a number of
SetRGB32CM().

[Karlos]

@itix & Kronos

Hi,

Basically I am experimenting. Just now, supporting actual 8-bit stuff is not on the agenda, but I need to investigate the existing graphics.library's speed versus my own code.

It's not that my code is slow, but it is pure software. I am working on the assumption that the graphics.library, although stuck in arcane "8-bit Pen land" may use some degree of hardware acceleration that I could benefit from.

My principal problem is in getting to choose my own colours for the RastPort. If I were running fullscreen I can see that it's not a problem, but this is a for window running on a high/truecolour desktop...

Kronos wrote:

You know there is an easy way ?
Just put down that MG and embrace the butterfly  :-o  :-P  ;-)

:lol: That chaingun sure has some ammo in it, eh?

Pains (o.k.cheap joke) are one of the hardest things in AOS-progging,and yes it
is as complicated as you thing.

Basiclly you will need to GetColorMap(),followed by a number of
SetRGB32CM().

Yeah thats what I figured. I don't see the connection between the GetColorMap() and the existing screen though. It doesn't take any argumetns other than the size of the colormap.

Am I missing something? Or is there a way (hopefully) that I can take a Screen* pointer to the workbench (well, whatever Screen my Window is on) and get the existing ColorMap for it?

Then I can lock a few pens from that and everybody is happy :-)

[Kronos]

Colormap from Window

win->WScreen->ViewPort.Colormap

[Karlos]

Kronos wrote:
win->WScreen->ViewPort.Colormap

That looks promising. So I can take a pointer to that and feed it to ObtainPen() to get my custom drawing colour, right?

[Karlos]

I wouldn't be in this mess if everybody had a 3D card.

Draw2D* DrawFactory::getDraw2D(Surface* primary)

returns a pointer to a Warp3D enabled version of the Draw2D interface (DrawHW) on systems that have it :-)

Alas, not everybody does :-(

[Kronos]

Yes you can,but better use ObtainBestPen().

[Karlos]

Kronos wrote:
Yes you can,but better use ObtainBestPen().

Well, once I get my pen, I am going to change its colour quite a lot for successive drawing operations - assuming previously drawn objects wont change colour (as it is a truecolour display) that is. Basically I dont want anybody else (ie other apps running) to share the pen in case subsequent colour changes I make to it confuse them ;-)

[Gelb]

First, theres the possiblity to obtain more than one pen, putting them into an array and then look up the pens when doing your drawing stuff.

Second, there is also cybergraphics.library/WriteRGBPixel

If you really need graphics.library only stuff and need to support 8bit later on, then this is of course no option.

[Karlos]

Gelb wrote:
First, theres the possiblity to obtain more than one pen, putting them into an array and then look up the pens when doing your drawing stuff.

Second, there is also cybergraphics.library/WriteRGBPixel

If you really need graphics.library only stuff and need to support 8bit later on, then this is of course no option.

Well, the whole reason I am looking at graphics.library is not for legacy 8-bit support, rather to see if any its drawing operations (lines, polygons, circles etc) are faster than my own code that does direct (but software only) rendering. The old graphics.library might indeed be faster if the rtg software has patched it with hardware accelerated functions...

Basically the ultimate point is this. My own C++ libaries provide an abstract Draw2D class. This class gives a high level interface for basic drawing stuff. You obtain a handle to it via a factory. The actual class returned may be one of several Draw2D implementors depending on what is available.

There are currently two implementations avaliable in the AmigaOS version. The first is a pure software one (my own code)  that is a fall back. Then there is also a very fast warp3d based one, but that depends on systems having a 3D card.

I am experimenting to see if I can improve upon the software only one for users with 2D gfx cards that have good rtg drivers offering hardware acceleration for basic drawing.