Does anyone know how to determine if a 16bit windows desktop is
running with 555 pixel format or 565 format?
Without using DirectX?
I’ve found a problem in the SDL windib code - ambiguous use of
555/565 formats. I’ll post an update here when I get it working
properly.
Is anyone actually using/working on the windib driver?
Ben.–
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com
This has been a big problem for me and for several other developers on
Windows.
You can ask DircetX to do it with EnumDisplayModes and something like this
in the call back;
if(lpDDSurfaceDesc->ddpfPixelFormat.dwRGBBitCount == 16)
{
if(lpDDSurfaceDesc->ddpfPixelFormat.dwGBitMask == 0x7e0)
{
// it’s 565
}
else
{
// it’s 555
}
}
But the call in DirectX isn’t reliable (many cards report the wrong value)
and you don’t want to use DX. The other problem is there is no way in
windows to query the rgb masks of the hardware.
So, the only way that I know of to get the actual 555 565’nes of the display
is to ask GDI to write a green pixel (or a red pixel) read it back and look
and see what bits have been set. This works as long as you can get a GDI
surface on the device that you are writing to. Which you can do on just
about everything but the old Voodoo cards.
Lars Brubaker
CEO
Reflexive Entertainment.
“Ben Campbell” <ben.campbell at creaturelabs.com> wrote in message
news:399926E8.1178A5D8 at creaturelabs.com…> Does anyone know how to determine if a 16bit windows desktop is
running with 555 pixel format or 565 format?
Without using DirectX?I’ve found a problem in the SDL windib code - ambiguous use of
555/565 formats. I’ll post an update here when I get it working
properly.
Is anyone actually using/working on the windib driver?Ben.
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com
Lars Brubaker wrote:
This has been a big problem for me and for several other developers on
Windows.
Thanks for the reply!
Is it just me, or does windows go out of its way to be annoying?
The big problem for the windib driver is (I think) detecting which is
the ‘best’ pixelformat - ie what is the desktop running in.
I already know which formats I can actually use, because it’s purely
software - defined by win32 and not some hardware feature.
So SDL_SetVideoMode() is easy - it’s just the SDL mode query
functions which are tricky (especially given my ignorance of the
internal layout of SDL).
You can ask DircetX to do it with EnumDisplayModes and something like this
in the call back;
if(lpDDSurfaceDesc->ddpfPixelFormat.dwRGBBitCount == 16)
{
if(lpDDSurfaceDesc->ddpfPixelFormat.dwGBitMask == 0x7e0)
{
// it’s 565
}
else
{
// it’s 555
}
}
But the call in DirectX isn’t reliable (many cards report the wrong value)
and you don’t want to use DX. The other problem is there is no way in
windows to query the rgb masks of the hardware.
Hmmm… I’d probably be happy requiring DirectX 3 to do the test - even
NT4 supports it once you get it servicepacked up.
So, the only way that I know of to get the actual 555 565’nes of the display
is to ask GDI to write a green pixel (or a red pixel) read it back and look
and see what bits have been set. This works as long as you can get a GDI
surface on the device that you are writing to. Which you can do on just
about everything but the old Voodoo cards.
Ouch.
I don’t suppose you could provide some pseudo-code? I gave up on GDI
coding at a very early stage, wrote a dib-section wrapper, and stuck to
raw pixel access. So my knowledge of GDI calls is pretty flimsy. Off
the top of my head, I’d imagine I need to do something like this:
Am I close? Can it even be done all offscreen?
What is the problem with the old voodoo cards? I thought they simply
didn’t support GDI at all… (in which case, no problem 
Again, thanks for the info,
Ben.–
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com
Comments are in the text. Sorry I haven’t checked back in a while.
Ben Campbell wrote:
Lars Brubaker wrote:
This has been a big problem for me and for several other developers on
Windows.Thanks for the reply!
Is it just me, or does windows go out of its way to be annoying?The big problem for the windib driver is (I think) detecting which is
the ‘best’ pixelformat - ie what is the desktop running in.I already know which formats I can actually use, because it’s purely
software - defined by win32 and not some hardware feature.So SDL_SetVideoMode() is easy - it’s just the SDL mode query
functions which are tricky (especially given my ignorance of the
internal layout of SDL).You can ask DircetX to do it with EnumDisplayModes and something like this
in the call back;
if(lpDDSurfaceDesc->ddpfPixelFormat.dwRGBBitCount == 16)
{
if(lpDDSurfaceDesc->ddpfPixelFormat.dwGBitMask == 0x7e0)
{
// it’s 565
}
else
{
// it’s 555
}
}
But the call in DirectX isn’t reliable (many cards report the wrong value)
and you don’t want to use DX. The other problem is there is no way in
windows to query the rgb masks of the hardware.Hmmm… I’d probably be happy requiring DirectX 3 to do the test - even
NT4 supports it once you get it servicepacked up.
You can’t count on any version of DX to give the right value (the card
manufactures do not implement the function correctly). You have to
either know from the drivers GUID or check with GDI.
So, the only way that I know of to get the actual 555 565’nes of the display
is to ask GDI to write a green pixel (or a red pixel) read it back and look
and see what bits have been set. This works as long as you can get a GDI
surface on the device that you are writing to. Which you can do on just
about everything but the old Voodoo cards.Ouch.
I don’t suppose you could provide some pseudo-code? I gave up on GDI
coding at a very early stage, wrote a dib-section wrapper, and stuck to
raw pixel access. So my knowledge of GDI calls is pretty flimsy. Off
the top of my head, I’d imagine I need to do something like this:
- Create a DC compatible with the desktop
- Create a small bitmap and select it into my DC
- Write a single red or green pixel using putpixel (or whatever
the name is)- Ask for the raw pixeldata back from the bitmap
Am I close? Can it even be done all offscreen?
What is the problem with the old voodoo cards? I thought they simply
didn’t support GDI at all… (in which case, no problemAgain, thanks for the info,
Ben.
I wish that I did have some code that I could give you. We have not as
yet shipped a game that runs in 16 bit so I haven’t coded it up. What
you have stubbed out looks like just what you want to do. You just have
to make sure the DIB section is compatible. I think there is a call
something like CreateCompatableDIB. Anyway, hope this helps.
Lars Brubaker,
Reflexive Entertainment.> –
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com
Find attached a file from the September 1999 issue of Windows
Developer Journal (http://www.wdj.com/code/archive.html).
I’m not sure how it works - but it reads the first DWORD after the
header of a screen-compatible bitmap. Why that content is defined, I
don’t know!
Francis (who loves Deja News :-)On Mon, 21 Aug 2000 22:45:44 -0700, Ben Campbell wrote:
Ouch.
I don’t suppose you could provide some pseudo-code? I gave up on GDI
coding at a very early stage, wrote a dib-section wrapper, and stuck to
raw pixel access. So my knowledge of GDI calls is pretty flimsy. Off
the top of my head, I’d imagine I need to do something like this:
- Create a DC compatible with the desktop
- Create a small bitmap and select it into my DC
- Write a single red or green pixel using putpixel (or whatever
the name is)- Ask for the raw pixeldata back from the bitmap
I wish that I did have some code that I could give you. We have not as
yet shipped a game that runs in 16 bit so I haven’t coded it up. What
you have stubbed out looks like just what you want to do. You just have
to make sure the DIB section is compatible. I think there is a call
something like CreateCompatableDIB. Anyway, hope this helps.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: vidfmt.c
Type: application/octet-stream
Size: 1997 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000822/e09c8afc/attachment.obj
Francis Irving wrote:
Find attached a file from the September 1999 issue of Windows
Developer Journal (http://www.wdj.com/code/archive.html).
[snip]
Bloody hell - what an evil little method!
Exactly what I need though - thanks, Francis, Lars!
Ben.–
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com