The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi,

I work on the game 'Bitfighter'. We have support for both SDL 2 and
SDL 1.2 in the game. We recently moved our Mac and Windows ports to
use SDL2 permanently because it provided much better window
management.

However, someone showed up in our IRC channel saying that it crashes
for him. I sent him a debug binary with loads of printf statements to
find out where the crash was and the last statement printed directly
before SDL_CreateWindow here:
https://code.google.com/p/bitfighter/source/browse/zap/VideoSystem.cpp#117

The game crashes right there and the SDL_GetError() call below it is
never invoked.

He is running Windows XP on a Dell D620 with graphics card NVIDIA
Quadro NVS 110m.

I had him install the nvidia drivers (thinking it may be an OpenGL
issue) but it didn't work. He can run an older version of our game
that used SDL 1.2 just fine, but not the SDL2 port.

Would anyone have an idea of might cause this?

I know it's really hard to debug on a machine one doesn't have access
to, but any help would be appreciated.

Thanks!
D
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It's pretty tricky, I think you might be right suspecting that OpenGL
is responsible.

The graphics chip you mentioned is a laptop variant (for some reason
NVIDIA refuse to support these properly in their Windows driver
updates), and pretty old (equivalent to the Geforce Go 7300, I have a
test machine with that one and it only works with the "legacy" driver
under Linux). Probably worth getting the full details from dxdiag just
for some more information (e.g. chip type, driver version, driver
date).

You could easily find out what bit of SDL is tripping up with a debug
build of the game/libSDL2 with just a backtrace from gdb, but
unfortunately this'd require convincing the user to get a portable
MinGW toolchain and have a go at building/debugging it. Or you could
try instrumenting with something like Breakpad which generates
portable stack dumps - http://code.google.com/p/google-breakpad , but
it looks like complete overkill for something like this.

(btw, worth mentioning that SDL_GL_SetAttribute only has an effect if
you call it before creating a window, you should move that block up
before SDL_CreateWindow)

On 19 March 2013 14:32, D B wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The NVS is a business/CAD GPU not a regular consumer GPU like the Geforce series is, its drivers are rather different for OpenGL to improve performance on CAD apps (I think the Direct3D ones are
identical though).

Regardless, mobile GPUs are often bound by support contracts where only the laptop vendor is allowed to release drivers for a given laptop, so when it gets end-of-life you have a problem, sometimes
these drivers are modified to keep GPU clocks below certain levels for power saving or even engineering reasons (running the part full speed may be very ill-advised).

On AMD GPUs there is a thing called Mobility Modder which modifies desktop drivers to accept laptop (Radeon Mobility) parts, but I do not know the equivalent for NVIDIA drivers.

It is possible it is using the stock Windows driver also, which has often been buggy at launch (I remember severe graphics issues on some nvidia GPUs when using the stock Windows XP driver for
instance), in which case the user needs to get the latest drivers from the laptop vendor website.

In this particular case it may be best to investigate the underlying crash and work around the driver bug rather than asking users to modify driver installers to get newer desktop drivers onto their
end-of-life laptop.

It could be a call to an API in such a way that was never tested in the driver version in question - so checking which gl calls are made by SDL_CreateWindow is worthwhile.

On 03/19/2013 01:58 AM, Scott Percival wrote:


--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Actually that's not a bad idea. See if you can get the user to run the
game through apitrace - http://apitrace.github.com. All they'd have to
do is:
- Download the latest Windows build from
http://people.freedesktop.org/~jrfonseca/apitrace/apitrace-latest-windows.7z
- Unpack it to somewhere that's easy to type (e.g. C:\apitrace)
- Open up a cmd.exe prompt, get them to cd to the game path
- Run "C:\apitrace\x86\bin\apitrace.exe trace gamename.exe"

This makes a portable dump of just the OpenGL-related calls, and
should stop logging at the one before the crash. Ask them to send the
.trace file that's just been made in the game directory and post it up
somewhere.

On 20 March 2013 00:34, Forest Hale wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sadly, giving a debug build or asking the user to use gdb or any
debugging tool is beyond the ability of this particular user, and I
don't have access to the specific hardware.

Although, the user has since disappeared. So that means the problem
is resolved? :)

I dislike having unresolved mysteries; but the work required to solve
this isn't feasible for the benefit gained.

(And thanks for the tip about SDL_GL_SetAttribute, I missed that when
porting to SDL 2.0)

D

On Tue, Mar 19, 2013 at 2:58 AM, Scott Percival
wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org