GP32 Intensity Bit

[pea]

Hi all,

Have had issues with two white things not matching on screen, and finally figuring out its the intensity bit .

What should I set this to? 1 or 0? Is 0 the value which leads to washed out colours on all the lit units, but is ok on the non-lit?

 

[Blah]

According to Reesy, 1 is the value which leads to washed-out colors.

 

[Drag]

When the bit is set in the state that makes the colors not washed out, is something in the hardware invoked to make the colors stronger, or does setting the bit to 'washed out' just shift the values of r g and b to make the overall color lighter?

uhh... ok... now in English, that means "Does that bit affect something in the LCD hardware itself, or does it affect the actual values of R G and B?"

 

[Blah]

The intensity bit makes all of the colour brighter, this was useful for the old NLUs but gives washed out blacks on the new BLUs. All I did to fix it was NOT set the intensity bit.

GP32 pal data is 16bit in the following format

RRRR RGGG GGBB BBBI

So before to set full red I would use 0xF801 - 1111 1000 0000 0001
but now I use 0xF800 - 1111 1000 0000 0000
I simply do not set the intensity bit.

1. The Color format in 8 Bit mode is
%RRRRR GGGGG BBBBB I

This means you can have 32 colors for each RGB channel.
You have a palette, with 256 entrys in it.

If oyu set the I BIT, the intensity is normal.
If you dont set the I bit, the intensity is only the half.

So you can change one bit, ( instead of 3 bits ) to change it.

!!!! It will not give you more colors !!!

I bit on, is normal mode, i bit off, is the complete color, only half bright.

So my understanding is, if the bit is off, every color you specify has its intensity cut by half (divide r,g,b by 2), and if its on, the color you specify is left alone.

Edit: But I may be wrong, it is mostly a educated guess.

 

[DaveC]

All the intensity bit does is make color RGB 0,0,0 (black) a lighter shade of grey. This makes the contrast look quite washed out especially on the BLU. Black should always be at no intensity (total black) to give the best contrast. The intensity bit should always be set to 0 as in Reesy's instruction for the best contrast. the DrMD first release had this set incorrectly (1) but has been fixed in the releases after the very first by setting to 0 making it look much better.

Stuff that has this bit set to 1 making it look washed out that I know of:
Doom, OSNES 9x, Colem.

Short answer: don't set the intensity bit.

 

[Blah]

Then why do you set the bit for every color you put down (not just black), Mr. Genious?

 

[DaveC]

Then why do you set the bit for every color you put down (not just black), Mr. Genious?

​

I don't know the particulars except that when the bit is on it looks washed out and shitty on the BLU. If you want to know the exact effects you could ask Reesy. I just know that it looks MUCH better with the bit not set.

 

[DaveC]

Hi all,

Have had issues with two white things not matching on screen, and finally figuring out its the intensity bit .

What should I set this to? 1 or 0? Is 0 the value which leads to washed out colours on all the lit units, but is ok on the non-lit?

​

When it is set to 1 it looks washed out on the BLUs. It makes black backgrounds look hazy grey, like the LCD is low contrast.

 

[gp32rich]

I just checked it with my non-lit and it looks a damned sight worse with the bit set.

I'll be leaving it at 0 B)

 

[theNestruo]

Hi.

When the user use 5:5:5:1 format, the intensity data (I) is used as a common LSB bit of each RGB data. So 5:5:5:I format is same as R(5+I):G(5+I):B(5+I) format.

So let's assume we're trying to palettize a color in the format 8:8:8 (we know the values of the three intensities RGB). The 5:5:5 part is easy: the 5 MSB of each intensity are used. Now, the intensity bit should depend on the 6th MSB (the 3rd LSB) bit of the three intensities. By example, we can set I to 1 if two or more of that bits are 1...
One more exact approach would be convert those 3 bits of each intensity that we haven't used and convert them to the HSL format. Lightness is the factor we want to know: L=(R+G+B)/3. Finally, we can set the intensity bit to 1 if L>.5 (assuming each intensity varies from 0.0 to 1.0) and set it to 0 otherwise.

 

[Drag]

Oh! I think I understand now.

And if I don't, I'll just write a test program that compares it.

I never noticed any washing out on my FLU (but I might just be used to it). All of my test programs have had that bit set, so I dunno.

Ok, so the recommendation now is to leave that bit cleared? Got it.

I mean, I think it'd be very hardly noticable on the FLU, which is good, because no one would see the difference, except the BLU owners. So everyone's happy!

When someone says "the color is washed out", I immediately think about how the gameboy color washes the colors out, vs the gameboy advance's color. (I THOUGHT the grayscale palette (selectable for the gameboy mono games) on the gba looked darker...)

 

[DaveC]

Oh! I think I understand now.

And if I don't, I'll just write a test program that compares it.

I never noticed any washing out on my FLU (but I might just be used to it). All of my test programs have had that bit set, so I dunno.

Ok, so the recommendation now is to leave that bit cleared? Got it.

I mean, I think it'd be very hardly noticable on the FLU, which is good, because no one would see the difference, except the BLU owners. So everyone's happy!

When someone says "the color is washed out", I immediately think about how the gameboy color washes the colors out, vs the gameboy advance's color. (I THOUGHT the grayscale palette (selectable for the gameboy mono games) on the gba looked darker...)

​

It is hard to tell on the FLU/NLU you are correct. The FLU looks washed out anyway so it is almost unnoticeable. On the BLU the effect is dramatic. Below is a pic of a game running on the early DrMD with the bit set to 1 on the left, the image on the right is with the intensity bit set to 0 (was fGEN that I compared at the time but the current DrMD is the same as fGen contrast now). You can see how space looks grey and hazy and the contrast poor on the BLU with the bit at 1.

 

[pea]

Cool thanks everyone. 0 it is.

 

[Puck2099]

I've tried coding one image using intensity bit as 0 and 1 but I don't see any difference between them...

I've used GP32Converter to set the bit, must I do anything more?

Thanks

 

[pea]

If its anything like my graphics loading routines, it doesn't matter what the value is in the image, when the code loads it, it sets the palette colours (and the intensity bit) itself, so the intensity bit is set in the code, not the image.

I had to change all my HexToColor, rgbTripletToColor, sprite blitting, alpha blending and graphic loading routines to remove the intensity bit. Its now set as a #define

p.s. Does anybody know if the compiler will remove the redundant addition (and OR) by itself here if intensity bit is set to 0:

#define gp_intensityBit 0

...
*coff = (ra<<11)+(ga<<6)+(ba<<1)+gp_intensityBit; 
...


unsigned short gp_colorRGB24to16( unsigned char R, unsigned char G,	unsigned char B ){
	return (((R >> 3) << 11) | ((G >> 3) << 6) | ((B >> 3) << 1)) | gp_intensityBit;
}

 

[DaveC]

If its anything like my graphics loading routines, it doesn't matter what the value is in the image, when the code loads it, it sets the palette colours (and the intensity bit) itself, so the intensity bit is set in the code, not the image.

I had to change all my HexToColor, rgbTripletToColor, sprite blitting, alpha blending and graphic loading routines to remove the intensity bit. Its now set as a #define

p.s. Does anybody know if the compiler will remove the redundant addition (and OR) by itself here if intensity bit is set to 0:

#define gp_intensityBit 0

...
*coff = (ra<<11)+(ga<<6)+(ba<<1)+gp_intensityBit; 
...


unsigned short gp_colorRGB24to16( unsigned char R, unsigned char G,	unsigned char B ){
	return (((R >> 3) << 11) | ((G >> 3) << 6) | ((B >> 3) << 1)) | gp_intensityBit;
}

​

You may want to ask Reesy directly about this. I know he dealt with the intensity bit in DrMD. I also know it looks alot better with it at 0. He would know the particulars though.

@ Puck, what GP32 do you have? Anything other than a BLU will not be obvious as far as the difference in the image. Rule of thumb here is if you can't tell the difference set it at 0

 

[Drag]

I only have used 8bpp mode for my programs thus far. Does that make me weird?

Whenever I hardcode a palette value into my program, I use this:

#define PALRGB(r,g,b)   ((2048*r)+(64*g)+(2*b)+1)
gp_setPalette (0,PALRGB(0,0,0));
gp_setPalette (1,PALRGB(31,31,31));
etc...

but I removed the +1 at the end, so instantly my programs were fixed. Of course, they were all just test programs of mine, but now they're fixed! ...come on, it's the concept that matters.

Well anyway, this intensity bit is barely noticable on NLU and FLU, so maybe does the LCD in the newer BLUs interpret this bit differently? Or do the older Samsung LCD BLUs have the washing out problem too? It's probably just that the backlight makes the problem more apparent, but still, it's nice to be sure.

 

[DaveC]

I only have used 8bpp mode for my programs thus far. Does that make me weird?

Whenever I hardcode a palette value into my program, I use this:

#define PALRGB(r,g,b)   ((2048*r)+(64*g)+(2*b)+1)
gp_setPalette (0,PALRGB(0,0,0));
gp_setPalette (1,PALRGB(31,31,31));
etc...

but I removed the +1 at the end, so instantly my programs were fixed. Of course, they were all just test programs of mine, but now they're fixed! ...come on, it's the concept that matters.

Well anyway, this intensity bit is barely noticable on NLU and FLU, so maybe does the LCD in the newer BLUs interpret this bit differently? Or do the older Samsung LCD BLUs have the washing out problem too? It's probably just that the backlight makes the problem more apparent, but still, it's nice to be sure.

​

All that I noticed that it does is make the background color (black) like in a space game a grey instead of black on the BLU. This grey reduces contrast and makes things look washed out.

With a NLU/FLU you can't notice as much as the light has to pass through the LCD twice (once where it enters through the LCD from outside light or frontlight, then the same light bounces off of the reflector back through the LCD the second time and to the viewer). Plus you lose a bit more light at the reflector as no reflector reflects 100% of light, there is loss. So this grey gets darker each time the light passes through the LCD and a little darker at the reflector (3 places for light loss). The intensity bit was an attempt to compensate for this effect. It doesn't seem to work that well though, it is a kludge to try to cheat physics, but there is always a side effect (lowered contrast). With a BLU the light just goes from the backlight through the LCD directly to the viewer, one pass. This causes the grey to show as a hazy background. The BLU produces more accurate and consistant color values, backlighting is much better for contrast because of this.

 

[fdave]

Ermm. Isn't this thread over-simplifying the problem somewhat? As I understand it, the intensity bit simply makes the colour slightly lighter.

So if you set it to 0 for everything all your colours are going to be darker. Sure your blacks are going to be real 'black' not grey, but your whites aren't going to be full 'white' then. Which IMHO is worse, but then again I'm biased because I have no backlight.


Don't we need a nice formula relating R G B and I?

e.g. if I have r=30 g=30 b=30 i=0, is that the same as r=0 g=0 b=0 i=1?

 

[fdave]

Here we go - try this
http://www.finalburn.com/Bars.fxe

you might have to cut and paste that link because i think offsite linking is not allowed



there are 6 rows of colours the intensity bit is:
off, on, on, off, on, off on each of the rows

the grey scale bar obviously runs from 0 to 31 (full intensity). I reckon the intensity bit adds roughly 1 unit, what do you reckon?


If anyone's got a Blu or Flu, post a piccy...