Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revamped per-engine renderers #158

Merged
merged 64 commits into from
Mar 2, 2024
Merged

Revamped per-engine renderers #158

merged 64 commits into from
Mar 2, 2024

Conversation

veeenu
Copy link
Owner

@veeenu veeenu commented Feb 29, 2024

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

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.

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 veeenu mentioned this pull request Feb 29, 2024
4 tasks
@veeenu veeenu changed the title Heck compositors altogether Revamped per-engine renderers Feb 29, 2024
@veeenu veeenu merged commit b7e057c into main Mar 2, 2024
1 check passed
@veeenu
Copy link
Owner Author

veeenu commented Mar 2, 2024

yoloooo :shipit: :shipit: :shipit:

@veeenu veeenu deleted the heck-compositors-altogether branch March 2, 2024 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment