Bug 4316 - SDL Gamma sometimes fails to initialize; must be asked twice
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Video
Version: GIT MASTER
Hardware: PC Windows XP
: P3 minor
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2009-10-23 04:01 EDT by Chris "Lakitu7" Schwarz
Modified: 2009-10-25 17:51:08 EDT
2 users (show)

See Also:


Attachments
ask SDL_SetGamma nicely a second time to please work correctly (567 bytes, patch)
2009-10-23 04:01 EDT, Chris "Lakitu7" Schwarz

Description Chris "Lakitu7" Schwarz 2009-10-23 04:01:05 EDT
Created attachment 2185 [details]
ask SDL_SetGamma nicely a second time to please work correctly

For some people with Nvidia cards in Windows, hardware gamma sometimes fails to
initialize. As a result, the user is stuck in software gamma, wondering why
nothing happens when they change r_gamma.

After finally getting more people than just myself who experience this pretty
rare issue, we narrowed down the common denominator to multiple monitors. You
can have any Nvidia card on any flavor of windows (actually, this problem has
followed me across motherboards and GPUs and from XP32 to Win7-64), but the
main narrowing constant between my setups and those of the others affected is
two monitors running in Dualview.

Anyhow, while this is clearly not a bug in ioq3, there is a workaround that can
be applied trivial that fixes the issue completely for all known affected users
while not affecting anyone else. Quite simply, the first request to
SDL_SetGamma is lazy and fails mysteriously without returning an error, but if
you ask it a second time, it complies. Thus, you simply take this line:

glConfig.deviceSupportsGamma = !!( SDL_SetGamma( 1.0f, 1.0f, 1.0f ) >= 0 );
and do it twice, to form:
glConfig.deviceSupportsGamma = !!( SDL_SetGamma( 1.0f, 1.0f, 1.0f ) >= 0 );
glConfig.deviceSupportsGamma = !!( SDL_SetGamma( 1.0f, 1.0f, 1.0f ) >= 0 );

A couple links have been found discussing the issue elsewhere that are
consistent with our findings:
http://cubeengine.com/forum.php4?action=display_thread&thread_id=1890&start=264
http://trac.wildfiregames.com/ticket/136

This workaround has been in widespread use in several popular unofficial builds
of Tremulous clients, without causing any ill effects. While I certainly
realize the problem is not IOQ3's and the "fix" is in fact a hacky workaround,
you could save a subset of users some hassle and confusion by applying it. And,
even if you choose not to, then at least this bug is here so it's known. 

Thank you to "Napkin," "TwoFacedRat", Timbo, and tjw for their help narrowing
this down.
Comment 1 Thilo Schulz 2009-10-23 04:58:33 EDT
Have you brought this to the attention of the SDL devs? They actually released 1.2.14 a few days ago. You are right about this should probably be addressed in SDL. I wouldn't have a problem with including this workaround if the SDL are not going to address this in the near future. I'd just like the other devs weighing in on this before I do anything.
Comment 2 Tim Angus 2009-10-25 17:50:38 EDT
I think we're reasonably confident this is an NVidia driver bug as both the directx and windib SDL video drivers are affected. Hack committed in r1704. It would be good to get to the bottom of this properly though, someday.
Comment 3 Tim Angus 2009-10-25 17:51:08 EDT
.