-
Notifications
You must be signed in to change notification settings - Fork 30
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
egui support #22
Comments
It does not say everything everything. For instance, it doesn't mention the words "please" and "thank you" that I, like any self respecting person, would expect of some stranger on the internet asking me to add such a complex feature to a project of mine, for free, as opposed to some one liner without even a hint of punctuation that was coughed up in barely a few seconds of thought. But yeah. |
Sorry, its just almost every issue i see/read is something like i wrote. So i though thats how u "write" issue's. Sorry if that doesn't make sense. I would really appreciate egui support because i like the design/look of it more than imgui. |
It's cool. I'm not sure how other maintainers feel about that in general, but courtesy and kindness are a hard boundary for me. Regardless of how other people behave, if I may offer a piece of advice: kindness will always go a long way, because when you write anywhere on the internet it's always real people who will read you, and all other things being equal, people always prefer to be treated kindly.
We will have to build 6 units of code, so to speak; 3 egui renderers (dx9, dx11, dx12) and one hook for each of those. Most of the code could be shared with the current imgui implementations but it'll still take a bit of testing and experimentation. |
i would try to make it support egui myself. but i am too stupid to get the example to work Edit: error[E0603]: struct Edit 2: |
Although egui seems interesting, I'd say it'd be out of the scope of this project since it heavily relies on imgui general behavior. It would involve either writing specific wrappers (as @veeenu said) or trying to write a more 'generic' code that at the end of the day would hurt maintainability. I'd love to see more options for hooking into games, but I'd prefer keeping this one as imgui only. Of course, that's just my view. Maybe this repository would be a good template for starting another one with an egui implementation. |
I don't fully agree with that -- after all, the API surface that the three current hooks share and expose to the top level is relatively minimal and quite generic, and otoh each egui renderer would share a lot of code with imgui's, so keeping and maintaining everything together may be simpler than rewriting the same mechanisms elsewhere, as the core problems to support a rendering hook have already been solved, so to speak. Besides, it is not necessary to abstract all the way and we can get away with breaking the library in a few top-level traits (i.e. imgui hooks with whatever renderer vs egui hooks with whatever renderer). But yeah, in general this will require a modicum of careful and proper design. Luckily Rust has a lot of mechanisms to ease a similar process, feature flags and the excellent module system being two great examples. |
This is a genuine issue, I created #23 to track it. |
maybe relevant: https://github.com/sy1ntexx/egui-d3d11 |
A few of these libraries has indeed started to appear. To me it seems like they sorta follow the same base. They can be found here: I definitely also agree that egui support could be very interesting to support here, especially given that egui is written purely in Rust, although I am unsure of what changes it’d require in hudhook. |
hi! is this still planned? |
There is active work being done on it, but the codebase is not in a state where abstracting things away altogether will be practical; no matter how you slice it, the task will result in a lot of added code so not sure how this will work out. |
title says everything
The text was updated successfully, but these errors were encountered: