Evan Hemsley
Evan Hemsley
Looks like this is an open issue on the Vulkan-Portability repo so we should probably wait for clarification from Khronos before patching this in. https://github.com/KhronosGroup/Vulkan-Portability/issues/14
I suppose it's basically a no-op on conformant implementations.
Ran a bunch of RADV tests, Flotilla complains about a buffer not being cleaned up on close but that's the only thing I've seen out of the games I own.
the process is currently: 1. compile FNA.dll (xbuild FNA.sln) 2. throw FNA.dll and FNA.dll.config into the game folder 3. download fnalibs.tar.bz2, put the contents of the correct subdirectory into the...
My guess is that Flinthook is doing some threaded memory set/get somewhere and we need to stick a mutex around the buffer map.
Actually, refresh my memory - is buffer access supposed to be thread-safe in XNA or is this a spec violation?
It's either a buffer set or the texture staging buffer being accessed simultaneously, we should probably just put a mutex around each of those map/unmaps.
Seriously considering just downgrading all my tools to .NET Framework 4.7 at this rate, at least Microsoft can't pull the rug out from under me if I just use VS2015...
I can confirm this issue is still a problem on OSX. I tried all the solutions listed in this thread and none of them work, I get a native crash...
Unfortunately mono native traces are not particularly detailed... I will try to rig up an xcode project at some point and see if the debugger can tell us anything.