#270 closed defect (fixed)
Crash rendering water shaders when GL_ARB_shader_objects not supported
Reported by: | Aviv | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | |
Component: | Core engine | Keywords: | glext, simple |
Cc: | Patch: |
Description
Game crashed on startup. I have a pretty crappy graphics card - Mobile Intel 945 Express Chipset Family - so that might be the cause.
Attachments (2)
Change History (15)
by , 15 years ago
Attachment: | crashlog.txt added |
---|
by , 15 years ago
Attachment: | crashlog.dmp added |
---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
crashlog.dmp indicates the problem is that pglCreateProgramObjectARB == NULL while calling RenderWater. That makes sense since the drivers don't do GL_ARB_shader_objects. But why do we try to load the shaders in that case, instead of detecting the unsupportedness?
Jeru: You might be able to circumvent this problem by creating a plain text file binaries\data\config\local.cfg
containing the line
fancywater=false
follow-up: 7 comment:3 by , 15 years ago
Summary: | Crash on game start → Crash rendering water shaders when GL_ARB_shader_objects not supported |
---|
comment:4 by , 15 years ago
Thank you, my specific issue has been fixed.
(I didn't hit "resolve" because you still need to add the detection code)
comment:5 by , 15 years ago
Keywords: | glext simple added |
---|
comment:6 by , 14 years ago
Many free drivers are affected by this this bug, e.g. mesa r300 (for ATI cards R300/R400/R500). It would be nice to have it fixed soon to make the game run on them. Mesa demos have code for checking this, see e.g.: http://cgit.freedesktop.org/mesa/mesa/tree/progs/demos/arbfslight.c#n247
comment:7 by , 14 years ago
comment:8 by , 14 years ago
comment:9 by , 14 years ago
fabio: I can't be entirely sure it's because of that, since I can't test it myself on drivers without fragment shader support, but it seems very likely. Can anyone confirm that it crashes with the old version of the code (if you don't force fancywater=false
) and works correctly if you compile it with the changes from r7385?
comment:10 by , 14 years ago
The patch disables fancywater when GL_ARB_fragment_shader is missing. My RV530 card is however missing that extension but it works also with the old code, so the problem is probably due to some other extension. I updated the PC with the intel card (to current Ubuntu lucid 10.04) and now it doesn't crash even with the old code.
Anyway, could you add a message on sterr/stdout when fancywater gets disabled?
comment:11 by , 14 years ago
Update: on the intel card with the old code instead of the crash I noticed that I am now getting this:
i915_program_error: Exceeded max ALU instructions
but the rendering is apparently fine. The r7385 patch remove that message.
So the patch does something at least on intel.
comment:12 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Given this forum discussion, it looks like the RV530's drivers don't support the extension but they still export the glCreateProgramObjectARB
function and make it return an error code (instead of crashing when the function doesn't exist at all), and the error code causes "ERROR: Failed to load water shader. Falling back to non-fancy water." so it still runs.
There's no guarantee that function exists unless the extension is advertised, so it's not safe for the game to rely on that behaviour. The RV530 drivers aren't doing anything wrong, but the ones in the original bug report (which crash) aren't doing anything wrong either.
Mesa's current i915 drivers appear to support fragment shaders, so it makes sense that they'd work too when you updated the system.
I think your observations are consistent with what ought to be happening, so I'll mark this as fixed for now and hope nobody reports more crashes on other hardware. Thanks :-)
Reporting to users when features are disabled would be good, but there's more than just fancywater - I think we'll need an overhaul of the graphics setting system so that it takes account of hardware capabilities, performance, and user preferences, to pick sensible behaviour. Filed as #475. I'm not sure it's worth adding a special case just for fancywater shaders now.
I can confirm that on Vista SP2. (i tested 0AD on two notebooks and got error #253 and this, no luck try it yet :)