Bug 78773 - Doom3 BFG doesnt start
Summary: Doom3 BFG doesnt start
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-16 07:03 UTC by Jan
Modified: 2014-09-06 17:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
log file (6.10 KB, text/plain)
2014-05-20 08:14 UTC, Jan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan 2014-05-16 07:03:55 UTC
Game returns me the following error ;
ERROR: GL_ARB_multitexture not available
Im using ubuntu 14.04 x64 with radeon driver. Problem seems to go away when i switch to closed source binary blob.

System: 4gigs of ram, a4-4300m apu plus radeon hd7670m gpu
Comment 1 Laurent carlier 2014-05-16 09:06:44 UTC
And the upstream issue: https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/107
Comment 2 Michel Dänzer 2014-05-16 09:30:55 UTC
I doubt this is our bug, but reassigning to Mesa core for now.
Comment 3 Tapani Pälli 2014-05-19 07:01:38 UTC
Is there something different within BFG edition than more content, engine is the same? I've just tested regular Doom3 with today's Mesa master on Intel IVB and everything works fine, log also says "...using GL_ARB_multitexture".
Comment 4 Tapani Pälli 2014-05-19 07:02:31 UTC
Jan, could you please add full log output from doom3 when you run it.
Comment 5 Jan 2014-05-20 08:14:17 UTC
Created attachment 99395 [details]
log file

i attached the log file. game also started to lower to my resolution to 640x480 which it didnt do in my first try.
Comment 6 Brian Paul 2014-05-20 13:58:38 UTC
Wasn't Doom 3 one of those older games that had a fixed-size buffer for storing the GL_EXTENSIONS string?  If the extension string was too long the buffer would overflow and the game would crash/misbehave.

Jan, you might try setting the MESA_EXTENSION_MAX_YEAR env var to something like 2005 so Mesa doesn't advertise extensions newer than that.
Comment 7 Tapani Pälli 2014-05-20 15:02:08 UTC
(In reply to comment #6)
> Wasn't Doom 3 one of those older games that had a fixed-size buffer for
> storing the GL_EXTENSIONS string?  If the extension string was too long the
> buffer would overflow and the game would crash/misbehave.
> 
> Jan, you might try setting the MESA_EXTENSION_MAX_YEAR env var to something
> like 2005 so Mesa doesn't advertise extensions newer than that.

I've verified that original Doom3 works fine with current Mesa. Doom3 here is 'rbdoom3', this is a custom one that uses >= OpenGL 3.2:

https://github.com/RobertBeckebans/RBDOOM-3-BFG

I haven't tried yet but my wild guess is that it uses core profile but still the old deprecated extensions query (not the new one).
Comment 8 Tapani Pälli 2014-05-26 10:54:01 UTC
Took a bit more look. The problem is that game opens a core context but expects to use legacy/compatibility extensions like GL_ARB_multitexture. Same happens with GL_ARB_texture_compression and GL_ARB_vertex_buffer_object which it queries as well.

You can get a bit further by forcing a legacy context (using MESA_GL_VERSION_OVERRIDE=2.0) but then after getting through extension checks there are problems with shader compiler because shaders seem to be gles3 (have "#version 300 es" in them), I'm not sure how to debug this further, I think there are issues either in the game or glew.
Comment 9 Jonathan Gray 2014-07-19 14:20:24 UTC
The latest RBDOOM-3-BFG git at the time of writing 
(485edfebc146c6c60fe4e918d7bb7b18e1e87f1b) seems to work fine with Mesa 10.2.3 on OpenBSD/amd64 with ivybridge mobile/HD4000 without needing to set any additional environment variables.

So it seems a recent change in Mesa has fixed this?

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.2 (Core Profile) Mesa 10.2.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 10.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
Comment 10 Tapani Pälli 2014-07-21 05:28:20 UTC
I'm getting a lot of shader compiler errors when testing current RBDOOM-3-BFG git (485edfebc146c6c60fe4e918d7bb7b18e1e87f1b) on IVB. These are all related to implicit conversion, coming from following code snippet:

--- 8< ---
144: 	int numSamples = 12 ;
145: 	float stepSize = 1.0 / numSamples ;
--- 8< ---

0:145(19): error: could not implicitly convert operands to arithmetic operator
Comment 11 Erik Faye-Lund 2014-07-23 09:46:01 UTC
That implicit cast was fixed in RBDOOM-3-BFG Git 79b8e04e.
Comment 12 Tapani Pälli 2014-07-23 10:16:21 UTC
(In reply to comment #11)
> That implicit cast was fixed in RBDOOM-3-BFG Git 79b8e04e.

cool, now it seems to initialize allright on IVB (still fails for me in loading though but I only have original pk4 files to test with, not BFG edition ones), someone with BFG files please resolve.
Comment 13 Tapani Pälli 2014-07-30 12:20:27 UTC
Jan, please try if it works for you
Comment 14 Tapani Pälli 2014-09-05 06:05:29 UTC
according to comment #9 this is fixed
Comment 15 Jan 2014-09-06 17:08:26 UTC
(In reply to comment #14)
> according to comment #9 this is fixed

i tried to get latest git and compile the code myself but that brought more errors. i dag for some time but i couldnt handle these errors. sorry


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.