Are We Stuck At 16Bit Graphics?

[SomeGuy99]

I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?

 

[Pickle]

I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?

xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet

 

[Exophase]

Where did you read this?

I can't saw authoritatively right now, but a 16-bit LCD would be very strange, given that most over the past several years are at least 18-bit - even Nintendo DS's. For this size and resolution I'd definitely expect full 24-bit. According to the Pandora Hacker's Manual the LCD connector is at least 24-bit, so the LCD most likely is.

The display controller on Pandora can definitely output 24-bit as well, this I can tell you with full confidence. If you can't use it it might be a matter of driver support in the X drivers. I think the DSS2 drivers might currently only support 16-bit as well.

 

[iampanis]

The LCD's datasheet says that it supports 16 million colors.

 

[SomeGuy99]

I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?

xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet

Ah ok, cheers.

 

[Asiyura]

The LCD's datasheet says that it supports 16 million colors.

Great, 24bpp will give even smoother gradients
Friggin' great screen we have there.

 

[notaz]

For a test, open terminal and type 'op_gammatool' and press Y when the app appears.

 

[hedwards]

The LCD's datasheet says that it supports 16 million colors.

Great, 24bpp will give even smoother gradients
Friggin' great screen we have there.

Excellent, so basically all the colors that a typical monitor will do. I assume that means that the entire 32bpp are available, given that the remainder is just alpha.

 

[paulguy]

for monitors and displays, 24 bpp == 32 bpp usually. just 32 bits is word aligned.

 

[Pleng]

xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet

How about minimenu? Will 32bpp ever be possible there?

 

[paulguy]

If they both use X11, they'll probably both use the same settings, so if one works the other will just as well.

 

[Lobo]

For a test, open terminal and type 'op_gammatool' and press Y when the app appears.

app runs;see the screen with all the pretty colors, but pressing Y does not change the color depth.

 

[urjaman]

app runs;see the screen with all the pretty colors, but pressing Y does not change the color depth.

Y as in the game button Y (upmost), works for me?

 

[atomicthumbs]

heh. my LCD cable is busted and only the right side on that gamma test shows pink. the left is normal.

 

[fusion_power]

A Retro Console don't need 32 Bit (game) Graphics.

If 32bpp means less performance (and I bet it means this ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this.

 

[Asiyura]

A Retro Console don't need 32 Bit (game) Graphics.

If 32bpp means less performance (and I bet it means this ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this.

The pandora is not just a Retro Console, it's meant to have its own original games, so 32bpp is a desirable option.

 

[sebt3]

As stated above 32bpp is 24bpp word aligned.
For Xorg (linux graphical environnement) setting 32 as depth will be effectivly treaded as 24.
Actually xorg.conf state depth=16, and without xrandr not app will change this dynamicaly. so minimenu is as 16bpp as the rest.
If OPT could have set this to 24, they would have done it, so I'm going with exo guess : driver limitation

 

[Dunny]

A Retro Console don't need 32 Bit (game) Graphics.

If 32bpp means less performance (and I bet it means this ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this.

Hmm. Usually, 32bpp graphics are more efficient than 16bpp, especially on a 32bit processor - assuming you're not using hardware acceleration, that is. Mind you, 16bpp (while not as efficient in as 32bpp in many repects) can be more efficient than 24bpp, especially when banging rows of pixels around the screen.

D.

 

[hedwards]

As stated above 32bpp is 24bpp word aligned.
For Xorg (linux graphical environnement) setting 32 as depth will be effectivly treaded as 24.
Actually xorg.conf state depth=16, and without xrandr not app will change this dynamicaly. so minimenu is as 16bpp as the rest.
If OPT could have set this to 24, they would have done it, so I'm going with exo guess : driver limitation

Admittedly, I could be wrong, but I thought those extra 8 bits were used for alpha. Or is that just when it comes to graphics utilities as the extra bits aren't really being used anyways.

EDIT: 8 for red, 8 for green, 8 for blue and 8 for alpha.

 

[Exophase]

Hmm. Usually, 32bpp graphics are more efficient than 16bpp, especially on a 32bit processor - assuming you're not using hardware acceleration, that is. Mind you, 16bpp (while not as efficient in as 32bpp in many repects) can be more efficient than 24bpp, especially when banging rows of pixels around the screen.

D.

32bpp will almost never be more efficient than 16bpp. Most 32-bit CPUs have the ability to to write individual 16bit words, and writes to areas like video memory are usually write buffered and often write combining (are in the case of Cortex-A8). So with 16bpp you don't have any overhead and you have a lower memory bandwidth footprint both in writing the framebuffer and for the display controller to read it, lower cache utilization for anything intermediate too. The difference will be minor though.

The only area in which 32bit may be more efficient is in doing pixel math using SIMD, since the channels align better with the vector words. But this is often negated again by higher data density.. all depends on how the operations are laid out.

Admittedly, I could be wrong, but I thought those extra 8 bits were used for alpha. Or is that just when it comes to graphics utilities as the extra bits aren't really being used anyways.

EDIT: 8 for red, 8 for green, 8 for blue and 8 for alpha.

A display doesn't usually have any use for an alpha channel. Framebuffers may have alpha bits if a renderer is using destination alpha for alpha blending operations. Also may have them if they're overlaid in hardware with per-pixel blending.