dxwrapper
dxwrapper copied to clipboard
elishacloud
Support for dummy output (no-op APIs) mode?
Many older games used engines like GameMaker, which did not allow the developer to opt-out of graphics and/or audio output, but was also extensible. This led to cute situations where entire full-fledged tools were built on such engines using only system APIs, because this allowed the main game code to be reused and shared. However, such programs were still forced to waste resources on running subsystems they didn't need. One obvious example here is dedicated servers.
What would be nice to see is the ability to turn off actual output (activity imitation) in the following different ways:
- Report successes, but do not perform any output to the device and discard the input where appropriate.
- Force
D3DDEVTYPE_NULLREFand its associated semantics in all corresponding functions instead of actual values. - Force reporting that a suitable device or driver is missing.
- Always return status codes indicating failure on all relevant operations.
This would make it possible to obtain greater performance in such applications, as well as make them independent of real hardware configurations and contexts unfriendly to DirectX (for example, running in Wine).
Interesting idea. Though I am not sure how much performance improvement this would actually give you. If the game engine loads DirectSound, for example, but does nothing with it because the game is using XAudio then I doubt there wold be much saved by simply giving the game engine an empty stub instead of the DirectSound APIs.
It's not just about performance, but also about decoupling from unnecessary dependencies. For example, GameMaker has a bad habit of showing a warning messagebox if it fails to initialize DirectSound, which blocks further loading and requires user interaction. As you can imagine, this complicates the automation of restarts, which is critical in the case of dedicated servers.
For example, GameMaker has a bad habit of showing a warning messagebox if it fails to initialize DirectSound, which blocks further loading and requires user interaction.
I see. And what would cause it to fail? If there a no sound cards in the device? I could consider making an option for creating an empty DirectSound wrapper option, because that is a real problem with dedicated servers.
And what would cause it to fail? If there a no sound cards in the device?
Yes, that's literally one of the reasons. But in general, such a window appears on any DirectSound initialization error in GameMaker runner, so there also may be others.
GameMaker has a bad habit of showing a warning messagebox if it fails to initialize DirectSound
Understood. Adding a dummy wrapper for DirectSound, for these cases makes sense. However, I am not sure it has much value to make a dummy wrapper for all DirectX interfaces (DirectInput, DirectDraw, Direct3D7, Direct3D8, Direct3D9, Direct3D10, etc.).
However, I am not sure it has much value to make a dummy wrapper for all DirectX interfaces (DirectInput, DirectDraw, Direct3D7, Direct3D8, Direct3D9, Direct3D10, etc.).
It does IMO, because in GameMaker, for example, if something goes wrong on the initialization of Direct3D or DirectInput, then not only the same thing happens as with DirectSound (a modal window is displayed), but also the application aborts itself, even if input and display are in fact provided by other means (for example, WinAPI). This is why I originally proposed the ability of having four different methods of stubs in the request - GameMaker is just one example that I'm aware of, while others may employ more or less strict error handling semantics.
Though I am not sure how much performance improvement this would actually give you.
Another benefit is that it would allow running games you previously couldn't without having an active Mesa and an Xorg server installed for the sole purpose of running the said game.
GameMaker has a bad habit of showing a warning messagebox if it fails to initialize DirectSound
Understood. Adding a dummy wrapper for DirectSound, for these cases makes sense. However, I am not sure it has much value to make a dummy wrapper for all DirectX interfaces (DirectInput, DirectDraw, Direct3D7, Direct3D8, Direct3D9, Direct3D10, etc.).
Actually, in cher-nov's case DirectSound failing doesn't make a huge difference as you can easily close the nagging window with xdotool (or ydotool, in case you've decided to use a headless Wayland compositor).
As for the Direct3D, you can obviously close the window too, but the game wouldn't budge and start. So all that's left for you is to install Mesa, the "llvmpipe" software driver, and an Xorg server with GLX enabled. There is, unfortunately, no other facilities to run such apps in Wine without having to pollute your server with those packages. The performance is really not the issue, but space wasted is, as in some distros Wine installs can take severals of GBs, and Xorg w/ Mesa is not lighweight either.
Today I've came upon another use case for this feature: to avoid D3D device losses. For example, in the case of GameMaker they require considerable time to overcome, and versions from 8.1.141 to 8.1.218 could even crash on this (see this patch: https://github.com/skyfloogle/gm8x_fix/tree/be7fa448?tab=readme-ov-file#the-display-reset-patch).