nextnoob.blogg.se

1. #Hitman codename 47 unable to initialize direct3d Patch
2. #Hitman codename 47 unable to initialize direct3d software

IIRC, psVoodoo full-screen worked when QEMU switched to full-screen with Ctrl-Alt-F as psVoodoo simply scaled its rendering context to QEMU window context, but I will double-check.Īt the moment, the only infrastructure we have is, if the DLL exported a symbol, then it will be called to inform the wrappers of running within QEMU. I have done extensive testing with OpenGlide and psVoodoo, if the later is what more of a resemblance of nGlide for Direct3D9 backend. The Glide pass-through is just another device model, and it has to live with what the architecture provides, so that it won't break easily as upstream QEMU continues to improve.

#Hitman codename 47 unable to initialize direct3d Patch

It is not a good idea to patch out QEMU extensively to change its original designs. Unfortunately, I am afraid this is something that we will have to live with and find ways around it. I knew the problem quite well as I stumbled on resizing window during early development. That's why I had to rely on posting SDL messages for window handling. In fact, QEMU threaded its internal workloads very extensively. Yes, I did come to realize that QEMU rendering thread is different from the main thread where the device models are instantiated. What's even worse QEMU message pump is executed only between Glide API invocations. That's because the patch calls Glide functions from a different thread that created QEMU main window. Not to offer fullscreen mode and Alt+Enter switch feature for QEMU (very bad) or to hook your FreeLibrary() call, making as a result glidexx.dll libraries loaded permanently within QEMU process.Īnother workaround is to create a second window from the same thread that calls Glide API functions (this is exactly what you do with CreateWindow option in glide.cfg), but it's even worse, so I don't consider it as a reasonable solution. This create a situation where nGlide doesn't have a chance to synchronize itself. Some games like Hitman forget to call grSstWinClose() at exit, directly calling grGlideShutdown().

#Hitman codename 47 unable to initialize direct3d software

nGlide can cover such cases and can synchronize itself, but like any other software it needs windows message pump to be functioning during Glide API execution (which QEMU don't provide waiting for Glide API call to be complete). The requirement for D3D fullscreen mode is that 3D devices need to be created and released from the same thread that created a window. What's even worse QEMU (SDL2) message pump is executed only between Glide API invocations. In the meantime I have an important question for you, Kjliew.Ĭan you rewrite the patch so Glide API functions will be executed from the same thread that created QEMU window? Perhaps you are wondering why all Glide wrappers freeze with your patch and fullscreen exclusive mode.

I will soon publish the first wave of the Glide implementation issues I found in the patch.