Angle: "D3D compiler module not found" and maybe set HXCPP_NO_WINXP_COMPAT

[madrazo]

Referencing from https://github.com/haxenme/nme/issues/521 and https://github.com/haxenme/nme/issues/522

To avoid this error on Windows <8.1, it should either

1)include d3dcompiler in the binaries https://wiki.libsdl.org/SDL_HINT_VIDEO_WIN_D3DCOMPILER setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to none

2)copy the DLL to the exe directory https://blogs.msdn.microsoft.com/chuckw/2012/05/07/hlsl-fxc-and-d3dcompile/ Actually, it would need to copy D3DCOMPILER_47.DLL from newer SDKs and rename it to D3DCOMPILER_46.DLL since its the one that SDL tries to load setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to d3dcompiler_46.dll Also, for WindowsXP compatibility, it is required d3dcompiler_43.dll

3)add the option to use precompilated shaders removing d3dcompiler dependency (setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to none). they should be compiled from opengl using angle's standalone shader_translator. would work on any windows if shader model 2 or 3 is used *shaders for ogl view should be precompiled using macros?

HXCPP has a flag <set name="HXCPP_WINXP_COMPAT" value="1" unless="HXCPP_NO_WINXP_COMPAT" /> it would be a better to drop XP support with HXCPP_NO_WINXP_COMPAT by default, and optionally use HXCPP_WINXP_COMPAT that would disable angle?

[hughsando]

Yes, I would rather just not use angle than add any kind of additional XP support.

I don't like option 3, since the standard shaders are built programmatically and they are not easily enumerated.

So that leave either shipping one of the dll, not using angle by default or perhaps shipping both angle and non-angle nme ndlls and choosing at runtime.

The last option allows easier comparison between the two as well and could be nice for development.

Angle works faster for "big" draw calls (many tiles) but there is a bit of overhead per-object, and there are a few issues with multiple-of-4 bytes, so angle is not a clear win. So only using angle on Winrt by default also solves the problems.

Does anyone have any opinions on Angle v non-Angle performance?

On Sat, Mar 10, 2018 at 3:00 AM, Carlos Madrazo notifications@github.com wrote:

Referencing from #521 https://github.com/haxenme/nme/issues/521 and #522 https://github.com/haxenme/nme/issues/522

To avoid this error on Windows <8.1, it should either

1)include d3dcompiler in the binaries https://wiki.libsdl.org/SDL_HINT_VIDEO_WIN_D3DCOMPILER setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to none

2)copy the DLL to the exe directory https://blogs.msdn.microsoft.com/chuckw/2012/05/07/hlsl- fxc-and-d3dcompile/ Actually, it would need to copy D3DCOMPILER_47.DLL from newer SDKs and rename it to D3DCOMPILER_46.DLL since its the one that SDL tries to load setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to d3dcompiler_46.dll Also, for WindowsXP compatibility, it is required d3dcompiler_43.dll

3)add the option to use precompilated shaders removing d3dcompiler dependency (setting SDL_HINT_VIDEO_WIN_D3DCOMPILER to none). they should be compiled from opengl using angle's standalone shader_translator. would work on any windows if shader model 2 or 3 is used *shaders for ogl view should be precompiled using macros?

HXCPP has a flag

it would be a better to drop XP support with HXCPP_NO_WINXP_COMPAT by default, and optionally use HXCPP_WINXP_COMPAT that would disable angle?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/haxenme/nme/issues/524, or mute the thread https://github.com/notifications/unsubscribe-auth/ABlp1q9ZZ4ks-7J-EQPb1UOmKG717Qlyks5tctFCgaJpZM4Skt3f .

[man2]

Does anyone have any opinions on Angle v non-Angle performance?

I don't know about windows build, but got a lot of performance hit on Android build. Is there some changes on rendering part for Android? I'm now reverting back to 5.7.1 which works great ( I use a lot of vector rendering using swf )

[hughsando]

None of the Angle changes should have affected to android build. And, I can't think of what has changed in the android pipeline, apart from the bitmap pixel formats. If you are doing a lot of bitmap rendering (or vectors with cacheAsBitmap or filters) then maybe there is some extra pixel copy for some reason. The other possibility is with the framerate logic. You could try setting your FPS to 1000 and see if this helps. If we could nail down the build where it slowed down, I should be able to fix it.

[madrazo]

I was thinking that the following would be enough for option "1", but I need to test it on Windows 7

add to ToolkitBuild

         <section if="windows" unless="winrt">
....
            <lib name="d3dcompiler.lib" if="NME_ANGLE"/>
         </section>

and SDL2Stage.cpp

   #ifdef NME_ANGLE
   SDL_SetHint(SDL_HINT_VIDEO_WIN_D3DCOMPILER, "none");
   SDL_GL_SetAttribute(SDL_GL_CONTEXT_EGL, 1); 
   ...
#endif

For option 3, we have done this for non-opengl targets. They can be built and set to the "templates" directory and passed on as assets. I am thinking on this as an option, like for a "final release" buld. However I'm not in a hurry. Also, GLES3 prefers to create the precompiled shaders on the first time, so its a little faster on the following times. So it would be another way to do it. https://software.intel.com/en-us/articles/opengl-es-30-precompiled-shaders

Personally I would prefer to choose Angle for a final deployment (to Steam), and also for testing GLES shaders as in mobile, for GLView, Otherwise non-angle would be OK for quicker compilation.

[madrazo]

I am installing NME on Windows7 32 bit. For now, I got that haxelib run nme calls the HXCPP_M64 flag haxelib run hxcpp ToolkitBuild.xml -Dwindows -DHXCPP_M64 -Dstatic_link

with HXCPP_M32 got C:/HaxeToolkit/haxe/lib/nme-toolkit/6,2,0/angle/src\common/platform.h(56) : fatal error C1083: Cannot open include file: 'd3dcompiler.h': No such file or directory Installing http://www.microsoft.com/en-gb/download/details.aspx?id=6812 Got error S1023 https://support.microsoft.com/en-us/help/2728613/s1023-error-when-you-install-the-directx-sdk-june-2010

Actually VS2010 was installed, installed VS2017. Had to change %ProgramFiles(x86)% to %ProgramFiles% https://github.com/HaxeFoundation/hxcpp/blob/8b99e1fa83b5df9d5ce21581a7b769dc461c0943/toolchain/msvc-setup.bat#L10

Automatic nme tool compile does not work because it wants to do 64 bit, however manually doing neko build.n ndll-windows-m32 and haxe compile.hxml (did it on all nme tools) solves the issue and succesfully build and ru DisplayingABitmap. It did not recure any other flags, so this works almos OK with VS2017 and Windows10 sdk (even it is Windows7 32 bit)