Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: colour pens question..  (Read 1822 times)

0 Members and 1 Guest are viewing this topic.

Offline yakumo9275

colour pens question..
« 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
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

Re: colour pens question..
« Reply #1 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...
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline Thomas

Re: colour pens question..
« Reply #2 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).

Offline yakumo9275

Re: colour pens question..
« Reply #3 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.
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline Thomas

Re: colour pens question..
« Reply #4 on: February 10, 2012, 02:52:53 PM »
Cybergfx or Picasso96?

Offline yakumo9275

Re: colour pens question..
« Reply #5 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.
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline Thomas

Re: colour pens question..
« Reply #6 on: February 11, 2012, 07:45:33 AM »
WinUAE or real Amiga? Which version, which model, which gfx card?

Offline yakumo9275

Re: colour pens question..
« Reply #7 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.
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline Thomas

Re: colour pens question..
« Reply #8 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.

Offline Minuous

Re: colour pens question..
« Reply #9 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.
 

Offline itix

Re: colour pens question..
« Reply #10 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.
My Amigas: A500, Mac Mini and PowerBook
 

Offline Thomas

Re: colour pens question..
« Reply #11 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.

Offline Minuous

Re: colour pens question..
« Reply #12 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?
« Last Edit: February 20, 2012, 03:50:19 AM by Minuous »
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: colour pens question..
« Reply #13 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).
 

Offline Minuous

Re: colour pens question..
« Reply #14 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.