Without a GPU, the CPU of the computer is AMD, and the running failure flashes by. There is a breakpoint when compiling C++files. Can I have the program support my computer

[chuiliuyiyi]

Describe the bug
Without a GPU, the CPU of the computer is AMD, and the running failure flashes by. There is a breakpoint when compiling C++files. Can I have the program support my computer
ArmorySDK2304
Windows10
blender3.3

[RobDangerous]

This is not the Armory repo.

[MoritzBrueckner]

Hey Rob, this is very likely a Kinc issue, but @chuiliuyiyi didn't give enough information for you to know. It was originally reported in armory3d/armory#2832 (and armory3d/armory#2831) and I told them to test some of the Kinc samples and if the breakpoint is triggered there as well to report it here. I don't know whether they actually tested it with pure Kinc.

@chuiliuyiyi You need to provide much more information about this issue and your hardware so that others unaware of the Armory issue can make sense of it. As unfortunate as it sounds, either you need to find the cause for the breakpoint yourself OR you need to provide others with enough information so that they can find out what's going on. Just mentioning that something is not working for you somewhere is not enough, since the issue might be very specific to your local setup (hardware, drivers, software versions, etc.).

---

A quick summary of the original issue:

When initializing the g4 API, Kinc fails the assertion in this line (the current Kode/Kinc source code is identical with the Armory version of Kinc), suggesting that somehow there was a failure initializing a D3D11 device.

This could be a hardware issue, but maybe the current code is missing some edge case with the specific hardware, system or drivers of @chuiliuyiyi that causes the failing assertion. Due to a language misunderstanding I initially assumed that @ chuiliuyiyi has no graphics card at all (not even an integrated one), but nonetheless I could imagine that the D3D_DRIVER_TYPE enum mentioned in armory3d/armory#2832 (comment) could be related (in this specific case, of course D3D_DRIVER_TYPE_HARDWARE should be preferred when possible).

[RobDangerous]

Hm, we had a warp-fallback once but Zeta kicked it out. Putting it back in, it was a cool thing to have (even though chuiliuyiyi will then likely just complain that everything is way too slow).

[RobDangerous]

That would error in line 213 though, not in line 214 - but probably somebody was just confused by how Visual Studio marks the current and next line.

[RobDangerous]

Done.