http://bugs.winehq.org/show_bug.cgi?id=35963
Bug ID: 35963 Summary: crash in Syberia2 Product: Wine Version: 1.7.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: farmboy0+winehq@googlemail.com
Created attachment 48060 --> http://bugs.winehq.org/attachment.cgi?id=48060 backtrace #1 from wine
I have found 2 places in the game that show this backtrace. One is near the beginning of the game. Once you can control Kate Walker enter the toilet in the train.
http://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #1 from farmboy0+winehq@googlemail.com --- Created attachment 48061 --> http://bugs.winehq.org/attachment.cgi?id=48061 backtrace #2 from wine
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #2 from Austin English austinenglish@gmail.com --- What graphics card/drivers?
Please attach the full log running the game under wine.
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #3 from farmboy0+winehq@googlemail.com --- Created attachment 48072 --> https://bugs.winehq.org/attachment.cgi?id=48072 full log with mesa debug output for backtrace #1
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #4 from farmboy0+winehq@googlemail.com --- Created attachment 48073 --> https://bugs.winehq.org/attachment.cgi?id=48073 full log with mesa debug output for backtrace #2
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #5 from farmboy0+winehq@googlemail.com --- I am using * Mesa git * Radeon SI open source driver git * Kernel 3.14 * X.org server 1.15
My graphics card is an AMD Radeon HD 7750 (Cape Verde)
http://bugs.winehq.org/show_bug.cgi?id=35963
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3d |-unknown
http://bugs.winehq.org/show_bug.cgi?id=35963
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
http://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #6 from farmboy0+winehq@googlemail.com --- Created attachment 48091 --> http://bugs.winehq.org/attachment.cgi?id=48091 patch that fixes the problem
http://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #7 from farmboy0+winehq@googlemail.com --- Created attachment 48102 --> http://bugs.winehq.org/attachment.cgi?id=48102 patch v2
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- I suspect this might primarily be a Mesa issue. What are the actual values that get passed to glLightf()? INF/NAN by any chance?
http://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #9 from farmboy0+winehq@googlemail.com --- %f prints the value as -nan so you are correct. but both the directx manual and the opengl spec define the values as >= 0, so the check should be correct. There is a bug in mesa however as the glLight function is supposed to return GL_INVALID_VALUE on negative values of ATTENUATION.
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #10 from Henri Verbeet hverbeet@gmail.com --- (In reply to farmboy0+winehq from comment #9)
%f prints the value as -nan so you are correct. but both the directx manual and the opengl spec define the values as >= 0, so the check should be correct.
Yes, but I think it should be unnecessary, since GL should take care of it.
There is a bug in mesa however as the glLight function is supposed to return GL_INVALID_VALUE on negative values of ATTENUATION.
Yes. Specifically, at http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/light.c#n257 "if (params[0] < 0.0) {" should probably either read "if (!(params[0] >= 0.0)) {", or explicitly check for NaN. http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/light.c#n173 does use ">= 0.0" in the assertion, at that's probably what causes your issue.
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #11 from farmboy0+winehq@googlemail.com --- (In reply to Henri Verbeet from comment #10)
(In reply to farmboy0+winehq from comment #9)
%f prints the value as -nan so you are correct. but both the directx manual and the opengl spec define the values as >= 0, so the check should be correct.
Yes, but I think it should be unnecessary, since GL should take care of it.
No it shouldnt. the GL manual says it should return an GL_INVALID_VALUE which would still be an error in wine but probably with lesser consequences. The comments in the wine code even state not to accept all the BS windows apps set as attenuation values.
There is a bug in mesa however as the glLight function is supposed to return GL_INVALID_VALUE on negative values of ATTENUATION.
Yes. Specifically, at http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/light.c#n257 "if (params[0] < 0.0) {" should probably either read "if (!(params[0] >= 0.0)) {", or explicitly check for NaN. http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/light.c#n173 does use ">= 0.0" in the assertion, at that's probably what causes your issue.
Yes the assertion causes the error. I will file a bug in mesa for that.
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #12 from Henri Verbeet hverbeet@gmail.com --- (In reply to farmboy0+winehq from comment #11)
(In reply to Henri Verbeet from comment #10)
(In reply to farmboy0+winehq from comment #9)
%f prints the value as -nan so you are correct. but both the directx manual and the opengl spec define the values as >= 0, so the check should be correct.
Yes, but I think it should be unnecessary, since GL should take care of it.
No it shouldnt. the GL manual says it should return an GL_INVALID_VALUE which would still be an error in wine but probably with lesser consequences.
GL commands generating errors are ignored, with only a few exceptions. I.e., if the GL driver would correctly handle the NaN, the effect should be the same as what your patch does.
It's possible NaN is supposed to behave in a specific way in D3D, but that would need some tests, and I suspect it's just undefined.
http://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #13 from farmboy0+winehq@googlemail.com --- After some more research I have come to the conclusion that the mesa implementation is in accordance with the OpenGL 2.1 spec. (http://www.opengl.org/sdk/docs/man2/xhtml/glLight.xml)
The spec says: GL_CONSTANT_ATTENUATION GL_LINEAR_ATTENUATION GL_QUADRATIC_ATTENUATION params is a single integer or floating-point value that specifies one of the three light attenuation factors. Integer and floating-point values are mapped directly.
**Only nonnegative values are accepted.**
etc..
It also says: GL_INVALID_VALUE is generated ... if a negative attenuation factor is specified.
NaN is neither nonnegative nor negative thus it is neither accepted nor is an error generated which is exactly what Mesa does.
This means that it is wine's responsibility to reject NaN values.
https://bugs.winehq.org/show_bug.cgi?id=35963
--- Comment #14 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=35963
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #15 from winetest@luukku.com --- This game is available for free for limited time from origin.
https://www.origin.com/fin/fi-fi/store/free-games
https://bugs.winehq.org/show_bug.cgi?id=35963
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #16 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.2?
https://bugs.winehq.org/show_bug.cgi?id=35963
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #17 from Sergey Isakov isakov-sl@bk.ru --- (In reply to joaopa from comment #16)
Does the bug still occur with wine-4.2?
I can't check the game behaviour under Mesa but the claim "This means that it is wine's responsibility to reject NaN values." is still not corrected.