FoFiX should check for a 32-bit color display, and suggest change if not set

[GoogleCodeExporter]

What steps will reproduce the problem?
Opening the FretsOnFire.exe file from a fresh download.

What is the expected output? What do you see instead?
The expected output is a smooth framerate, but the framerate is less than
1FPS, rendering the game unplayable.  The CPU also jumps, from 10% to 50%.
 All other applications and processes run fine.

What version of the product are you using? On what operating system?
FoFiX 3.030 on Windows Vista x64 w/ SP1
The graphics card and processor are more than good enough to play the game

Please provide any additional information below.
The issue recently occurred and will not go away.  I've tried a
reinstallation, reboot, pretty much everything.

Original issue reported on code.google.com by ice.crea...@gmail.com on 6 Feb 2009 at 7:38

[GoogleCodeExporter]

Problem solved: make sure your video settings are at 32-bit compared to 16-bit. 
 I've
seen a message pop up when you open Google SketchUp, telling you that it's a 
good
idea to switch to 32-bit.  If it's similar to implement this in FoFiX I think it
should be there.

Original comment by ice.crea...@gmail.com on 7 Feb 2009 at 12:26

[GoogleCodeExporter]

Issue changed.

If FoFiX can detect when display settings are not at 32-bit color depth, and 
then
display a message that suggests you set to 32-bit color for the game to run 
properly
(requiring you to hit OK).  

Original comment by chris.paiano@gmail.com on 7 Feb 2009 at 1:50

• Changed title: FoFiX should check for a 32-bit color display, and suggest change if not set
• Changed state: Accepted
• Added labels: Performance, Type-Enhancement

[GoogleCodeExporter]

Original comment by evily...@gmail.com on 18 Apr 2009 at 5:58

[GoogleCodeExporter]

I have some code to check it through win32api under Windows and through pygame 
on
other systems.

The issue, though, is the notification; while we can use win32api.MessageBox() 
under
Windows and there is a Mac-specific module that looks like it can produce a 
standard
Mac message box (I don't have a Mac myself, so I can't say more), presenting the
notification under GNU/Linux in a distribution-portable way will be an issue.  
(We
could call out to things like zenity or whatever the equivalent of it is under 
other
desktop environments until we find something that works.)

Original comment by john.stumpo on 18 Apr 2009 at 2:46

[GoogleCodeExporter]

If i understand correctly, a low color depth causes a performance lost but the 
game
is still playable. I'd think that an in-game messagebox displaying a warning 
would do
the trick. No need for a WindowManage-level msgbox.

Of course, if we don't already have a msgbox "widget" in Dialogs.py, that means 
we'll
have to create one.

Original comment by evily...@gmail.com on 18 Apr 2009 at 8:47

[GoogleCodeExporter]

Not to worry, we already have a msgbox type thing in Dialogs.py.... I'll post 
it here
shortly when I find it again

Original comment by chris.paiano@gmail.com on 18 Apr 2009 at 8:50

[GoogleCodeExporter]

Dialogs.showMessage is the method.  

Original comment by chris.paiano@gmail.com on 18 Apr 2009 at 8:53

[GoogleCodeExporter]

@Chris: Thanks
@John: Are you using pygame.display.mode_ok(resolution) ?
As you mentioned that you've code for this already, i'll wait for your input.
Feel free to takeover this issue if you feel like fixing it yourself.

Original comment by evily...@gmail.com on 18 Apr 2009 at 9:02

[GoogleCodeExporter]

By all means, I did know all about good ol' Dialogs.showMessage(), but I 
thought this
would be the kind of thing we would do before we even start doing any OpenGL 
stuff,
but if we want to show it in the game window itself upon startup that's fine 
too.

All I did was:
# somewhere after the pygame.display.init():
if pygame.display.Info().bitsize != 32:
  # do something

Pascal: You have more of an idea as to how you want to actually handle it, so I 
think
you should just do it however you think is best.

Original comment by john.stumpo on 19 Apr 2009 at 1:01

[GoogleCodeExporter]

Hmm... pygame.display.Info().bitsize report 32 while i'm expecting 24 (based on 
my
config and the effective value visible in /var/log/Xorg.0.log).

Original comment by evily...@gmail.com on 19 Apr 2009 at 3:14

[GoogleCodeExporter]

Hmm.. if i set my X server colordepth to 24 i get 32 and if i set it to 16 i 
get 16.
However, if my colordepth is 16, FoFiX just won't start as pygame is unbale to 
enable
OpenGL in 16.

I'm not comfortable at implementing something i can't test...

Original comment by evily...@gmail.com on 19 Apr 2009 at 4:26

[GoogleCodeExporter]

Pascal, if I may share this; I'm sure it is something you are already aware of, 
however.

http://ubuntuforums.org/archive/index.php/t-217770.html
https://www.linuxquestions.org/questions/linux-software-2/nvidia-drivers-no-32-b
it-depth-351647/

I was confronted with this long ago, when I first installed my nvidia drivers, 
as a
matter of fact. From my (limited) understanding, Linux doesn't do 32-bit colour
depth, and in reality, neither does Windows, because of the whole alpha channel 
>
graphics card stuff.

Essentially what I take from all of that is 24-bit colour depth is the 
virtually the
same thing as 32-bit colour depth in Windows.

If I am understanding everything correctly, maybe this is why the detection 
allows
you to run with 24, but not 16?

Disclaimer: I'm out of my league as far as a thorough knowledge and 
understanding of
the subject goes, right now.

Original comment by lysdestic@gmail.com on 19 Apr 2009 at 4:55