Was doing some benchmark runs on this hardware using different wrappers and noticed this huge performance drop:
Running with ddrawcompat 1.3.2:
<img width="239" height="43" alt="Image" src="https://github.com/user-attachments/assets/04ec67be-5390-49d8-91ce-908d0898cb3e" />
dd7to9:
<img width="246" height="48" alt="Image" src="https://github.com/user-attachments/assets/8c3cfdbc-eabc-41fd-923b-7bd5f64ef59b" />
This laptop I'm using has an i5 8250u. Not the latest and greatest but I don't think the wrapping overhead would take that much of a toll on this thing, so I'm not really sure
Unfortunately, there is significantly more overhead when converting DirectDraw/Direct3D to Direct3D9 than simply translating API calls.
Many legacy DirectDraw and early Direct3D features are not supported by Direct3D9 and must be emulated. For example, color keying has to be converted into an alpha channel, which adds additional processing. Likewise, when a game issues a simple `Draw...` call, dxwrapper often has to perform a considerable amount of work behind the scenes to configure the correct render state, matrices, viewport, textures, z-buffer, shaders, and other graphics state before the draw can be executed correctly.
There are also compatibility-focused design decisions that add some overhead. For example, dxwrapper emulates Direct3D state blocks instead of relying on Direct3D9's native implementation so that the behavior more closely matches older Direct3D versions. It also emulates multiple simultaneous Direct3D devices instead of mapping them to Direct3D9 swap chains. While using swap chains could be more efficient, emulating separate devices provides much better compatibility with tools such as ReShade and NVIDIA Remix, both of which generally expect a single Direct3D9 device.
While all of this introduces additional overhead, it is necessary for compatibility across the wide variety of DirectDraw and Direct3D games. In the vast majority of cases, the performance impact is small enough that games remain very playable, and many actually perform better than native DirectDraw on modern hardware.
There are certainly optimizations that could be made to reduce the overhead significantly, but my current priority is compatibility and correctness. Unless a game is unplayable or the performance impact is severe, I generally focus on making sure everything works correctly before spending time on performance optimizations.
I also forgot to mention that dxwrapper renders the game's primary surface to an intermediate render target and then copies it to the back buffer every frame. This does add a fair amount of overhead, but it provides a number of compatibility benefits.
For example, it allows the game to render to 16-bit surfaces while still keeping a standard 32-bit back buffer. It also enables features such as gamma correction and provides the foundation for future features like color correction (which is not yet implemented). Using a consistent 32-bit back buffer also simplifies compatibility with modern graphics APIs and post-processing tools.
This is another area where dxwrapper intentionally trades some performance for compatibility and functionality.
With the latest dev build on my laptop I am seeing this:
dxwrapper build 8537:
<img width="502" height="372" alt="Image" src="https://github.com/user-attachments/assets/a79f97e2-7b5f-46f6-ae46-47a702e8edd8" />
DDrawCompat 7.1:
<img width="506" height="374" alt="Image" src="https://github.com/user-attachments/assets/0bcb4fdf-82f5-4cab-8cf3-01d86c921b1e" />
With the latest build of dxwrapper (from the [Actions](https://github.com/elishacloud/dxwrapper/actions) tab) on my laptop it is able to beat DDrawCompat v7.1 performance. Here is the new bench mark:
<img width="502" height="372" alt="Image" src="https://github.com/user-attachments/assets/1d59e3e7-cc74-47a1-a108-bf1df43c44bb" />
_Edit: updated with a closer like-for-like comparison with DDrawCompat._