GP32 Grey Scale

[hal9000]

Hello!

I am currently writing an homebrew game in which I render a snowy terrain. It needs grey scale, from light grey to white.

Problem: the difference between two consecutive grey is quite big, much bigger than when I run the same program on my computer, so the result is not so nice.

Do I miss something or is there no way to display more than 32 greys, even in palettized 8 bit mode?

I know that GP2X graphics are 16 bits, but what does it mean exactly? No more than 65535 colors at the same time, or no more than 65536 color in all? In this second case, how does in work? 5 bits for red, green and blue? But then what does the last bit do?

Thanks!

 

[Alex.]

I can't help with the technical bits, but the GP2X MK2 screen is dodgy for colours close to one another (such as two subtle grays). Try tilting the GP2X towards you, and look at the screen from that angle. That usually makes subtle colour differences more visible.

 

[mrsnature]

from wikipedia:

QUOTE
16-bit color uses 5 bits to represent red, 5 bits to represent blue, but (since the human eye is more sensitive to the color green) uses 6 bits to represent 64 levels of green. These can therefore be combined to give 65,536 (32 × 64 × 32) mixed colors. Sixteen-bit color is referred to as "thousands of colors" on Macintosh systems.

 

[hal9000]

from wikipedia:

QUOTE
16-bit color uses 5 bits to represent red, 5 bits to represent blue, but (since the human eye is more sensitive to the color green) uses 6 bits to represent 64 levels of green. These can therefore be combined to give 65,536 (32 × 64 × 32) mixed colors. Sixteen-bit color is referred to as "thousands of colors" on Macintosh systems.

OK, Thanks for the link, which makes things a bit clearer. However, this does not explain why in palettized 8-bit mode, colors cannot be chosen from a 24-bit palette, but only from a 16-bit palette.

It is quite surprising. Even my 15 years old A1200 can do that. Anyone can confirm that this is a limitation of the GP2X grachic chipset?

 

[sbseb88]

It is quite surprising. Even my 15 years old A1200 can do that. Anyone can confirm that this is a limitation of the GP2X grachic chipset?

I thought it was more of a LCD limitation.

 

[Orkie]

I thought it was more of a LCD limitation.

Kind of. The GP2X SoC supports it, the LCD supports it, the kernel supports it, but GPH decided not to connect all the pins needed for 24-bit colour, leaving us stick with 16-bit (or something like that).

 

[hal9000]

OK, thanks for this information. Actually, it seems to be 18 bits, and not 16, allowing 262000 colors and 64 greys.

 

[Hooka]

Also, you could not go down by one from each everytime and just minus one from each going in a loop then it would give the appearance of slightly different grey shades (and I believe it's spelt and said grey, not gray like html seems to like grrr...) without letting too much color get mixed in.

 

[Squidge]

OK, thanks for this information. Actually, it seems to be 18 bits, and not 16, allowing 262000 colors and 64 greys.

The GP2X screen is organised as 153600 bytes, which is 2 bytes per pixel. How do you get 18-bits out of 2 bytes?

 

[hal9000]

The GP2X screen is organised as 153600 bytes, which is 2 bytes per pixel. How do you get 18-bits out of 2 bytes?

I was talking about 8-bit palettized mode. Each color of the palette is defined with 3 bytes, 1 byte for each component. However, if you set up a palette of 256 greys and you displays all of them on the screen, you see only 64 different greys on the screen (which makes impossible to display a nice grey shade).

So when you define a palette color, the 2 least significant bits of each components are somehow ignored. That is why I said that palette colors are actually defined with 18 bits.

 

[Squidge]

Ah, I know what your talking about now. got slightly confused there

18-bits rings a bell actually. I'll have to investigate.

 

[Parkydr]

That explains that bit in the gp2x.com technical specification that always confused me

QUOTE

Display * 3.5" TFT LCD (Hardware : 16.7 Million Colors / Software: 260,000 Colors)



24 bits = 16777216
18 bits = 262144

 

[hal9000]

Also, you could not go down by one from each everytime and just minus one from each going in a loop then it would give the appearance of slightly different grey shades (and I believe it's spelt and said grey, not gray like html seems to like grrr...) without letting too much color get mixed in.

Thanks for the tip! There is a slight rainbow effect, but the result is not bad. The best result I got was when increasing red and green together, alternatively with blue, with a blue component always a bit higher than the others. This give a nice result for the snow.

You should see the result soon!

 

[A_SN]

Hello!

I am currently writing an homebrew game in which I render a snowy terrain. It needs grey scale, from light grey to white.

Problem: the difference between two consecutive grey is quite big, much bigger than when I run the same program on my computer, so the result is not so nice.

Do I miss something or is there no way to display more than 32 greys, even in palettized 8 bit mode?

I know that GP2X graphics are 16 bits, but what does it mean exactly? No more than 65535 colors at the same time, or no more than 65536 color in all? In this second case, how does in work? 5 bits for red, green and blue? But then what does the last bit do?

Thanks!

Well, you can use dithering, or even better, dynamic random dithering, here's what I wrote on it http://www.gp32x.de/board/index.php?s=&am...st&p=488339

 

[hal9000]

Well, you can use dithering, or even better, dynamic random dithering, here's what I wrote on it http://www.gp32x.de/board/index.php?s=&am...st&p=488339



Thanks, and the demo looks nice. However, I don't think I can afford it, in terms of CPU time.

 

[A_SN]

Well, you can use dithering, or even better, dynamic random dithering, here's what I wrote on it http://www.gp32x.de/board/index.php?s=&am...st&p=488339



Thanks, and the demo looks nice. However, I don't think I can afford it, in terms of CPU time.


Well, in case you haven't followed the thread till the end, it's not like it's about generating random numbers in real-time but adding pre-calculated random numbers in an array. I should have tested how fast my demo went.. anyways, otherwise you still have static dithering, it helps, it was used all the time in old games like games from the late 80's early 90's.

 

[hal9000]

Well, in case you haven't followed the thread till the end, it's not like it's about generating random numbers in real-time but adding pre-calculated random numbers in an array. I should have tested how fast my demo went.. anyways, otherwise you still have static dithering, it helps, it was used all the time in old games like games from the late 80's early 90's.

I am working on a game in which a landscape is rendered in real time. Each fps count. Therefore, I think that even static dithering is not possible. But I could try.

Anyway, I realized that this was mainly a problem with pure grey. When you slightly shift the color to blue, you can have much more colors, and the result is acceptable.

 

[rokdcasbah]

are you doing a voxel engine? because i love me some voxels. anyway this sounds pretty cool regardless.

 

[hal9000]

are you doing a voxel engine?

Actually, yes. I am coding a ski game, and I should release an alpha version soon. I'll release the source code, too, so anyone interested in the engine could use it.

 

[rokdcasbah]

damn, wish i hadn't given up on mine. you beat me to it. maybe i'll try to add lighting normals to yours or something