[random notes] Compiling to run on Windows 8.1 + Intel HD4000 about wickedengine HOT 2 CLOSED

Hi,
First of all, thanks for trying it and the very detailed report. 👍

• Are you planning to do a pull request for this? (Or did I just miss it somehow?)

• What is the reason for trying for Win 8.1? I guess it would be understandable if you only have a win 8.1 machine, but as you mentioned this brings some complexity into building it while I see no benefit from windows 8.

• Ifdefing DX12 bits: I'm not sure, but maybe this could just be automatic, like the Vulkan device, which looks up if the user has the vulkan headers installed or not like this: #if __has_include("vulkan/vulkan.h"), and emitting a WICKEDENGINE_BUILD_VULKAN preprocessor if it exists.

• Not sure what's the best way to handle audio, it's been too long since I touched it

• Modifying DX11 device creation: it should be ifdefed, then it is probably best to add a new solution configuration for Win 8. That also means more bookkeeping required to keep the whole solution buiilding correctly. By the way, I have no problem with even lesser Intel GPUs than the 4000 running the engine as long as it is Win 10.

• Editor default working directory is the /Editor/ folder. Every path is relative to that in the editor code.

• Secondary scene: ah sorry that is a crappy left over naming from long ago. It is the RenderPath3D::RenderSecondaryScene function. Basically everything is rendered there which is dependent on the Opaque scene render (which was Primary scene first I think). For example transparent objects which receive the opaque scene render target as readable texture and can do distort on it, or read the depth buffer, etc. But there is no other real Scene at the moment apart from the one contained in wiRenderer (globally accessible).

• I am planning to refactor the post processing part which probably has some wasted render targets, and render passes that start to affect the intel GPU. But as you suspected, the PBR shaders are quite heavy as well. Also the forward path is probably very bad, because it always runs through every light in the frustum for every piyel. The Tiled forward is better, although for low end GPUs, it might be too heavy (because of light culling compute shader and very long pixel shaders). Maybe the deferred path would be more suitable for the Intel GPU, but maybe it would use too much bandwidth for Gbuffer.

from wickedengine.

What is the reason for trying for Win 8.1? I guess it would be understandable if you only have a win 8.1 machine, but as you mentioned this brings some complexity into building it while I see no benefit from windows 8.

I was more after seeing how well Tiled-Forward worked on the intel since your implementation is pretty much feature complete and far more useful a gauge of costs on that hardware than the many forward/clustered samples. 8.1 was really just a matter of convenience (disposable surface pro [no tears when an MC crash shatters it], upgrading to win10 would've been HD-drive murder). I don't consider that hardware serious, just as a stuff needs to at least be intelligible/quasi-workable for working on the go.

I didn't bother with a PR since I was really just diving through to get it running, my more serious intention is to write some premake scripts to do the build and deal with the XAudio/build-flags more appropriately but I'll have to do a Vulkan build on my main machine to see how shader builds are dealt with there.

I don't believe the include check would work for dx12, you can compile for DX12 (since final runtime is dynlinked) from windows 8 as the DX12 sdk is available there - just can't actually run anything.

from wickedengine.