Duke4.net Forums: Win10 + HD3000 + 32bpp crash on >4897 - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Win10 + HD3000 + 32bpp crash on >4897

User is offline   Jmoc 

#1

Hello to everybody,
Since I transitioned from 8.1 to 10, using Intel HD3000, EDuke32 refused to start. This is on every version beginning from 4897. 4887, for example, works just fine, with opengl fully engaged.
A brief review of log files:

4887

Quote

EDuke32 2.0.0devel r4887 (64-bit) C++ build
Compiled Jan 8 2015 07:31:10
Using D:/Games/duke3d/ for game data
Windows 8.1 (build 6.3.9600)
Initializing SDL system interface (compiled against SDL version 2.0.3, found version 2.0.3)
Using "windows" video driver
[...]
OpenGL Information:
Version: 3.1.0 - Build 9.17.10.4229
Vendor: Intel
Renderer: Intel® HD Graphics 3000


4897

Quote

EDuke32 2.0.0devel r4897 (64-bit) C++ build
Compiled Jan 10 2015 21:01:26
Using D:/Games/duke3d/ for game data
Windows 10 (build 10.0.10586)
Initializing SDL system interface (compiled against SDL version 2.0.3, found version 2.0.3)
Using "windows" video driver
[...]
OpenGL Information:
Version: 1.1.0
Vendor: Microsoft Corporation
Renderer: GDI Generic


Relevant changes

Quote

r4895 | terminx | 2015-01-10 20:53:44 -0800 (Sat, 10 Jan 2015) | 1 line

Clean up/refactor a few gamevar related functions based on building as C++/C99 and some interesting articles I read about how GCC and Clang optimize switches. Worth a few FPS here.
------------------------------------------------------------------------
r4894 | terminx | 2015-01-10 20:53:30 -0800 (Sat, 10 Jan 2015) | 1 line

Minor cleanup and formatting changes. DONT_BUILD.
------------------------------------------------------------------------
r4893 | terminx | 2015-01-10 20:53:16 -0800 (Sat, 10 Jan 2015) | 1 line

Make FORCE_INLINE aware of DISABLE_INLINING. DONT_BUILD.
------------------------------------------------------------------------
r4892 | terminx | 2015-01-10 20:53:01 -0800 (Sat, 10 Jan 2015) | 1 line

Detect running under Wine. DONT_BUILD.
------------------------------------------------------------------------
r4891 | terminx | 2015-01-10 20:52:45 -0800 (Sat, 10 Jan 2015) | 1 line

Identify Windows 10 in the startup window/log. DONT_BUILD.
------------------------------------------------------------------------
r4890 | terminx | 2015-01-10 20:52:15 -0800 (Sat, 10 Jan 2015) | 1 line

MSVC C++ build fixes. DONT_BUILD.


It's worth noting that sources beginning from 4897 compile just fine under VS2013; 4887 and below don't, complaining about missing objs to be linked, presumably because the compiler itself was changed.
There's something wrong in how newer versions query Windows 10 about opengl drivers.


Off topic: I was one of the guys trying to register with an Hotmail account, thanks for clarifying things up :)
0

#2

If your compiling from source, it would be nice if you could post a callstack :).
0

User is offline   Jmoc 

#3

View Posticecoldduke, on 08 December 2015 - 07:48 AM, said:

If your compiling from source, it would be nice if you could post a callstack :).


Quote

> eduke32.exe!polymost_drawpoly(const vec2f_t * const dpxy, const int n, int method) Line 1776 C++
eduke32.exe!polymost_dorotatesprite(int sx, int sy, int z, short a, short picnum, char dashade, char dapalnum, int dastat, unsigned char daalpha, int cx1, int cy1, int cx2, int cy2, int uniqid) Line 5118 C++
eduke32.exe!dorotatesprite(int sx, int sy, int z, short a, short picnum, char dashade, char dapalnum, int dastat, unsigned char daalpha, unsigned char dablend, int cx1, int cy1, int cx2, int cy2, int uniqid) Line 7552 C++
eduke32.exe!rotatesprite_(int sx, int sy, int z, short a, short picnum, char dashade, char dapalnum, int dastat, unsigned char daalpha, unsigned char dablend, int cx1, int cy1, int cx2, int cy2) Line 15353 C++
eduke32.exe!rotatesprite_fs(int sx, int sy, int z, short a, short picnum, char dashade, char dapalnum, int dastat) Line 1102 C++
eduke32.exe!G_PlayAnim(const char * fn) Line 292 C++
eduke32.exe!G_DisplayLogo() Line 10664 C++
eduke32.exe!app_main(int argc, const char * * argv) Line 12011 C++
eduke32.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hPrevInst, char * lpCmdLine, int nCmdShow) Line 438 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]


Logged from the latest revision, 5466

The method that crash it is bglActiveTextureARB(texunits); this is obvious since the exe is using the Microsoft GDI soft driver, that is providing OpenGL 1.1, thus without ARB instruction set.
The problem is not the crash, that's understandable (but in older version there was a guard against outdated GL versions). The real issue here is the correct detection of the graphic driver. Something changed between 4887 and 4897 that broke compatibility, but can't pin-point it. Even worse, I can't compile 4887 as-is.

Can you check the sdl_createwindow method in sdllayer.c? This is one of the things that actually changed from 4887 and 4897, and maybe kept changing until now. I'm not sure what it does, but as it creates the OpenGL contest, maybe it has something to do with the correct driver picking.

NB: all this stuff was compiled with SDL, as it was the only target that would compile without errors
0

User is offline   TerminX 

  • el fundador

  #4

What happens when you revert the changes to manifest.game.xml from r4891?
0

User is offline   Jmoc 

#5

View PostTerminX, on 08 December 2015 - 12:28 PM, said:

What happens when you revert the changes to manifest.game.xml from r4891?


Removing the Windows 10 line in the manifest did the trick!
I had another issue with all versions, in fixtransparency method inside polymost.c: when j is 0 inside the loop (no "if" was evaluated), it would trigger EDUKE32_UNREACHABLE_SECTION(break) and crash the game with an access violation; I commented it and everything works fine now.

Thanks for all the support!!
0

User is offline   TerminX 

  • el fundador

  #6

View PostJmoc, on 09 December 2015 - 02:55 AM, said:

Removing the Windows 10 line in the manifest did the trick!
I had another issue with all versions, in fixtransparency method inside polymost.c: when j is 0 inside the loop (no "if" was evaluated), it would trigger EDUKE32_UNREACHABLE_SECTION(break) and crash the game with an access violation; I commented it and everything works fine now.

Thanks for all the support!!

This is an interesting problem. It looks like others have run into it, too: http://forum.drdteam...php?f=24&t=6696

It sounds like the driver is defective.
0

#7

View PostJmoc, on 08 December 2015 - 09:57 AM, said:

The method that crash it is bglActiveTextureARB(texunits); this is obvious since the exe is using the Microsoft GDI soft driver, that is providing OpenGL 1.1, thus without ARB instruction set.


I'm confused about this statement, the exe doesn't provide any driver what so ever, it instead uses the driver present on your system. Your HD3000 supports at least OpenGL 3.0. glActivetexture is supported on your hardware.

"Renderer: GDI Generic" Sounds like you don't have your display drivers installed.

This post has been edited by icecoldduke: 09 December 2015 - 10:02 AM

0

User is offline   TerminX 

  • el fundador

  #8

Yeah, it's some kind of issue with Intel's driver specifically. It sounds like you don't get any GL acceleration if the driver is able to detect an OS it isn't explicitly programmed to support.

Jmoc, does running the official binaries we provide in Windows 8.1 compatibility mode work? It's unfortunate that Intel's driver behaves in this way and that they have dropped support for the GPU in question. Hopefully the compatibility settings Windows provides are enough to work around the problem.
0

#9

View PostTerminX, on 09 December 2015 - 10:24 AM, said:

Yeah, it's some kind of issue with Intel's driver specifically. It sounds like you don't get any GL acceleration if the driver is able to detect an OS it isn't explicitly programmed to support.

Jmoc, does running the official binaries we provide in Windows 8.1 compatibility mode work? It's unfortunate that Intel's driver behaves in this way and that they have dropped support for the GPU in question. Hopefully the compatibility settings Windows provides are enough to work around the problem.


That seems odd that a Windows driver would have to check the OS in order determine device capability...seems like it would be the other way around :thumbsup:. Normally when Windows 8/8.1 drivers are installed on Windows 10 you just don't get the new WDDM 2.0 support.

Jmoc can you open up DXDIAG and see what Direct3D version it reports your device supporting? I wonder if its just Intel's OpenGL implementation that's fucked up.

This post has been edited by icecoldduke: 09 December 2015 - 11:51 AM

0

User is offline   TerminX 

  • el fundador

  #10

View Posticecoldduke, on 09 December 2015 - 11:07 AM, said:

That seems odd that a Windows driver would have to check the OS in order determine device capability...seems like it would be the other way around :thumbsup:. Normally when Windows 8/8.1 drivers are installed on Windows 10 you just don't get the new WDDM 2.0 support.

Jmoc can you open up DXDIAG and see what Direct3D version it reports your device supporting? I wonder if its just Intel's OpenGL implementation that's fucked up.

It is odd, but it seems to be what's happening. If you don't have the Windows 10 stuff in your application manifest, all of your GetVersionEx() calls are supposed to return Windows 8.1--this was done by Microsoft for purposes of compatibility with apps that have poorly implemented version checks. Unfortunately, it seems that Intel's driver for this GPU contains one of these version checks, leaving users of this GPU in a bit of a predicament as far as running apps that have actually been updated for Windows 10 are concerned. Intel has already stated that they aren't supporting the HD3000 under 10, so it's unlikely this will ever be fixed unless someone patches the driver to bypass the check in whatever the last compatible driver Intel released was.
0

#11

View PostTerminX, on 09 December 2015 - 11:42 AM, said:

It is odd, but it seems to be what's happening. If you don't have the Windows 10 stuff in your application manifest, all of your GetVersionEx() calls are supposed to return Windows 8.1--this was done by Microsoft for purposes of compatibility with apps that have poorly implemented version checks. Unfortunately, it seems that Intel's driver for this GPU contains one of these version checks, leaving users of this GPU in a bit of a predicament as far as running apps that have actually been updated for Windows 10 are concerned. Intel has already stated that they aren't supporting the HD3000 under 10, so it's unlikely this will ever be fixed unless someone patches the driver to bypass the check in whatever the last compatible driver Intel released was.


I would have thought version checking during runtime would have caused a fail during the driver cert process. That chip only supports D3D10 it's time for a upgrade :thumbsup:.

This post has been edited by icecoldduke: 09 December 2015 - 01:34 PM

0

User is offline   Jmoc 

#12

Yes, Intel dropped support of my chip starting from Windows 10, so, technically speaking, it makes sense for applications to drop it as well. But in this case there's absolutely no reason to, as it's only a difference of 2 (!) lines of code that make it useless.
And it's not underpowered either, since it can run polymost with hrp models just fine. It will be really outdated only when EDuke will use OpenGL > 3.1 for some strictly mandatory instructions; then I'll give up and consider a new rig :thumbsup:

BTW, apart from newer Java versions, every app is detecting the card, either OGL and D3D.
0

User is offline   TerminX 

  • el fundador

  #13

Can you confirm whether or not running in compatibility mode fixes the problem? Thanks.
0

User is offline   Jmoc 

#14

View PostTerminX, on 11 December 2015 - 02:41 PM, said:

Can you confirm whether or not running in compatibility mode fixes the problem? Thanks.

Compatibility mode doesn't fix the problem
0

User is offline   Jmoc 

#15

I'm resurrecting the thread to make everyone aware of the definitive answer to the (somewhat specific) Intel 2nd generation GPU, HD3000 etc, problem.

The solution is to compile from source code removing the Windows 10 reference from the manifest xml configuration file.

Tested with the very latest (r5718) snapshot, classic, polymost and polymer work great on Windows 10 with HD3000. Precompiled binaries do not.
3

#16

For those that don't know how to compile and build software, we have something on the DRD/ZDoom forums that one of the forum users wrote to patch the GZDoom internal manifest to solve this problem. All it does is remove the "Windows 10" lines.

I have found this tool also works on the latest compiled EDuke32 build and it seems to be a generic program that should work on any program with those lines in the manifest.

Link: WTFI


So hopefully those who just play the game and don't want to become programmers are sorted, at least for now.

Bad marks to Intel for desupporting capable hardware merely due to OS upgrade. Then again, after their involvement in the Itanium debacle, should we really be surprised LOL
1

#17

View PostMartin Howe, on 05 October 2016 - 12:57 AM, said:

For those that don't know how to compile and build software, we have something on the DRD/ZDoom forums that one of the forum users wrote to patch the GZDoom internal manifest to solve this problem. All it does is remove the "Windows 10" lines.

I have found this tool also works on the latest compiled EDuke32 build and it seems to be a generic program that should work on any program with those lines in the manifest.

Link: WTFI


So hopefully those who just play the game and don't want to become programmers are sorted, at least for now.

Bad marks to Intel for desupporting capable hardware merely due to OS upgrade. Then again, after their involvement in the Itanium debacle, should we really be surprised LOL

I cringe whenever I see Itanium in production. Pointless waste of money.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options