Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: yakumo9275 on February 10, 2012, 01:53:29 AM

Title: colour pens question..
Post by: yakumo9275 on February 10, 2012, 01:53:29 AM
So when I test on my stock wb3.1, everything goes fine., doing SetDrMd(rport, JAM1 | INVERSVID);, it all looks good.

when I test on wb3.1 using 32bit screen depth, using inversvid, does not do anything.

I assume its the colourpens not working the same in a 32bit screenmode? is there a way to know if the colourpen will do what I want when I invoke inversvid?

when I invoke inversvid on the 32bit screen depth, its like just using JAM1 without change...

just not sure what I need to do to get it working across all screenmodes/depths...

I've tried setting the B pen, but again got odd results.

Right now B pen is default -1 as described in the window creation structure.

/tears hair out
Title: Re: colour pens question..
Post by: yakumo9275 on February 10, 2012, 01:29:16 PM
I had a thought driving to work this morning.. I wonder if colour pen is using a 32bit RGB value in a 32bit video mode and an colour index in an <=8bit mode...
Title: Re: colour pens question..
Post by: Thomas on February 10, 2012, 02:14:33 PM
The question is what you expect from INVERSVID. It is mainly meant for text and it causes those areas which are usually drawn in background color or left transparent to be drawn in foreground color and vice versa.

So if you set JAM1 | INVERSVID and then draw lines or other figures which don't use the background color, doing nothing is correct behaviour.

For me INVERSVID works correctly on a 32 bit screen (see attachment).
Title: Re: colour pens question..
Post by: yakumo9275 on February 10, 2012, 02:49:44 PM
I am only using Text(), so I expect to see what was in your screenshot, and I get that but only on my basic wb screen but not on my 32bit wb screen. I will have to investigate more and see if I am doing something wrong.
Title: Re: colour pens question..
Post by: Thomas on February 10, 2012, 02:52:53 PM
Cybergfx or Picasso96?
Title: Re: colour pens question..
Post by: yakumo9275 on February 10, 2012, 03:29:53 PM
Quote from: Thomas;680083
Cybergfx or Picasso96?


I believe my test system for this is a "Classic Workbench P96" install.
Title: Re: colour pens question..
Post by: Thomas on February 11, 2012, 07:45:33 AM
WinUAE or real Amiga? Which version, which model, which gfx card?
Title: Re: colour pens question..
Post by: yakumo9275 on February 13, 2012, 02:17:52 PM
Its on euae, the last release from a few years back. I've not had a lot of luck with puae so I'm still on euae something wip4.

I've narrowed it down to ClearEOL(rport) not doing the clear (as I expect it to). Text renders with jam1/jam2 and combos of INVERSVID just fine but calling ClearEOL does not clear to the line as I expect if I do JAM1|INVERSVID.

For some reason ClearEOL is behaving differently on a stock wb3.1 ecs with basic screen mode vs the p96 32bit screen mode.

to make clear, my testing with euae

stock wb3.1 install on a 'a2000' style machine, ECS chip, '020, 1mb chip ram
'classic wb p96' install of wb3.1 on an 'a1200' style machine, heaps of ram, '040.
Title: Re: colour pens question..
Post by: Thomas on February 13, 2012, 04:44:58 PM
Well, JAM1 | INVERSVID means that pixels which would normally be drawn are left unchanged. For ClearEOL this means it does nothing (as would Draw and similar functions). IMHO it works as expected. And for me it does the same on native and gfx card screens.
Title: Re: colour pens question..
Post by: Minuous on February 19, 2012, 11:12:36 AM
I have a somewhat related question...
  Is there a limit of 256 pens supported by OS3.9? Because it seems that AmiDock is allocating most of those pens, and therefore my program can't allocate its pens. This happens even on eg. a 16-bit screen, where there should presumably be 65536 pens. The pen number is a LONG, but I have never seen a pen number higher than 255. The graphics.library autodoc doesn't say how many pens are supported.
  Is there some kind of workaround for this limitation that will allow my program to access pens beyond the first 256 in a cooperative way? Thanks.
Title: Re: colour pens question..
Post by: itix on February 19, 2012, 11:58:14 AM
Quote from: Minuous;680988
I have a somewhat related question...
 Is there a limit of 256 pens supported by OS3.9? Because it seems that AmiDock is allocating most of those pens, and therefore my program can't allocate its pens. This happens even on eg. a 16-bit screen, where there should presumably be 65536 pens. The pen number is a LONG, but I have never seen a pen number higher than 255. The graphics.library autodoc doesn't say how many pens are supported.


Number of pens is limited to 256. In theory system could support more pens than that but would need expanding other structures as well and managing thousands of pens is not practical.

Quote

Is there some kind of workaround for this limitation that will allow my program to access pens beyond the first 256 in a cooperative way? Thanks.


If you have CGX 4 you can use true colour rendering to offscreen bitmaps.
Title: Re: colour pens question..
Post by: Thomas on February 19, 2012, 12:25:56 PM
Quote from: Minuous;680988
 Is there some kind of workaround for this limitation that will allow my program to access pens beyond the first 256 in a cooperative way? Thanks.


You could check the depth of the screen's bitmap and if it is higher than 8 you need only one exclusive pen and use SetRGB32 to set the actual color before you draw.

If you don't insist on exact colors, another possibility is to use shared pens, i.e. use ObtainBestPen.
Title: Re: colour pens question..
Post by: Minuous on February 20, 2012, 02:58:11 AM
>If you don't insist on exact colors, another possibility is to use shared pens, i.e. use ObtainBestPen.

It prefers to allocate them exclusively so that the user can adjust the colours themself (via the program's inbuilt palette editor). In the case where this isn't possible it will fall back to allocating them as shared pens (and it disables the palette editor in this case).

>You could check the depth of the screen's bitmap and if it is higher than 8 you need only one exclusive pen and use SetRGB32 to set the actual color before you draw.

Sorry, I don't understand how this would work...I allocate one pen, draw with it, change the colour via SetRGB32, draw with it...wouldn't the colour of the first pixel(s) already onscreen then be changed?
Title: Re: colour pens question..
Post by: Piru on February 20, 2012, 05:58:44 AM
Quote from: Minuous;681062
Sorry, I don't understand how this would work...I allocate one pen, draw with it, change the colour via SetRGB32, draw with it...wouldn't the colour of the first pixel(s) already onscreen then be changed?

No.

>8 depth screens are not palette indexed. With depth >8 the palette is only used as lookup table when actually drawing. Thus you can draw every single colour with just 1 pen (you just need to change the palette entry with SetRGB32 before every draw).
Title: Re: colour pens question..
Post by: Minuous on February 20, 2012, 06:42:27 AM
Ah, I see now. I'll improve the program so that it uses this method on deep screens. Thanks Itex, Thomas and Piru for your help.
Title: Re: colour pens question..
Post by: Minuous on February 20, 2012, 07:18:27 AM
I replaced the call to WritePixelArray8() with SetRGB32() & WritePixel(); this works but is very slow. Presumably doing efficient >8-bit output would require CGX/P96. That's probably not worth it in the case of this particular program.
Title: Re: colour pens question..
Post by: Piru on February 20, 2012, 07:23:27 AM
Quote from: Minuous;681076
I replaced the call to WritePixelArray8() with SetRGB32() & WritePixel(); this works but is very slow.

Yeah, there's a lot of overhead when writing single pixels like this.
Quote
Presumably doing efficient >8-bit output would require CGX/P96.

cybergraphics/WritePixelArray can be used to render truecolor gfx. P96 emulates this API.

Quote
That's probably not worth it in the case of this particular program.

Yeah. If it begins to matter then you should use cgx/WPA.