Dear community, I come to you with an even worse PR than #156, which is now superseded by this one.

immagine

Due to the unacceptable performances of the composition in Dx9 and OpenGL3, I decided to scrap that approach altogether and go back to the basics. This PR fully reimplements, from scratch, all four renderers internally. As I now have a much better grasp on how all our supported engines work, I was able to end up with a cleaner and more maintainable design for all of them, one that relies on traits to factor together common behavior which is now starkly separated: renderers only care about rendering the draw data when given a render target, and the Pipeline cares about all the other stuff in a 100% renderer agnostic manner.

Changes

Press F for the unified renderer

There is of course no more unified renderer as per #156. The four separate renderers fit much better our use case workflow and aren't much bigger than the compositors were in the previous PR; in fact, the net change in LoC is about the same (~2000 added).

Asynchronous input processing

Same as #156.

Wine support

The library works seamlessly under Wine/Proton with the games tested: Dark Souls, Dark Souls III, Elden Ring. OpenGL 3 has not been tested against a game but the test harnesses work well.

Texture support in all renderers

All renderers have their own texture support. For the time being, textures can only be added in the ImguiRenderLoop::initialize method through a callback function which results in an ugly breaking change. I'm fine with iterating on this and do breaking changes as the effort required to the users won't be much at all -- just a couple lines of code -- but I do eventually want to settle for something cleaner that doesn't require adding all those lifetimes to the trait method.

One common window procedure

Window procedure setup responsibility has been moved away from the hooks and into the Pipeline. This means that the behavior will always be consistent across hooks.

Exposed some utility methods

Useful parts of the hudhook::util crate were made public and other methods were added. Not sure I will want to make any guarantees with respect to semver there, as they aren't really core to the library, but they're there if someone wants to use them.

Affected issues

Closed issues

Closes #155.
Closes #151.
Closes #130.
Closes #96.
Closes #78.

Issues that need review

If you are/were directly impacted by any of the issues below, please test them or let me know if I can close them.

139
137
107 the Wine related thing mentioned by @SkyLeite should now be fixed?
103 needs testing; I don't have those games but should be fixed with the new changes
79 should work now with the asynchronous messaging

Conclusion

We did it. Thank you everyone.

I will keep working to fix a few more things and add a couple more features, but we are looking at a new release soon ™️ .

veeenu / hudhook

Revamped per-engine renderers #158