Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started 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
-
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...
-
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).
-
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.
-
Cybergfx or Picasso96?
-
Cybergfx or Picasso96?
I believe my test system for this is a "Classic Workbench P96" install.
-
WinUAE or real Amiga? Which version, which model, which gfx card?
-
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.
-
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.
-
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.
-
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.
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.
-
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.
-
>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?
-
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).
-
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.
-
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.
-
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.
Presumably doing efficient >8-bit output would require CGX/P96.
cybergraphics/WritePixelArray can be used to render truecolor gfx. P96 emulates this API.
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.