Open KakCAT opened 6 years ago
Ahh, I forgot about the HorizontalMouseWheelEventArgs, I had ignored the other stuff since I figured it was obvious, but I'll add it to the readme.
The exact imports I used were (the marshaller should figure out the return value difference):
[System.Security.SuppressUnmanagedCodeSecurity] // We won't use this maliciously
[DllImport("user32.dll")]
public static extern bool TranslateMessage([In] ref NativeMessage lpMsg);
[System.Security.SuppressUnmanagedCodeSecurity] // We won't use this maliciously
[DllImport("user32.dll")]
public static extern IntPtr DispatchMessage([In] ref NativeMessage lpmsg);
Added a link in the readme for a minimal example: as a github gist.
just another change I had to make (this time to compile the example). Inside WinFormsGameWindow :
internal WinFormsGameForm Form; --> public (otherwise you can't access .Form )
and a little comment for uncareful guys like me: The call to PeekMessage has different values than the monogame version (a 1 instead of a 0). (I read the "CHANGES HERE" comment and I supposed that it was the only change in the block, but it wasn't :joy: )
Finally, it seems there's a mandatory usage of GraphicsProfile.HiDef in the game. If using Reach, the imgui system fails to compile a shader required for the fonts.
And it's working now! :)
Thanks a lot for the 'port', I've been waiting a long time for a tool like this, specially for the Virtual Viewport features.
A lot of those visibility changes could have been dealt with via reflection. The big ones where it's a no go are the Backbuffer and Texture native handle, since those get hit every frame.
Yeah, PeekMessage now has to pop the message, MonoGame was only inspecting it before, I should've marked that or at least used a const for PMREMOVE
instead of just typing in the 1.
HiDef requirement is because of the cbuffers in the ImGui shaders, so it has to be a regular DX11 target, not a compatibility target like Reach uses (9C IIRC).
I should really roll those changes into a branch or at least a zip file with the files to diff ... didn't expect anyone to actually try it out so soon.
I was thrilled when the ImGui Viewport stuff came along. Finally able to phase WPF out of my life, without embedded Mono woes.
Don't mind my hyperactiveness ;) I'm in the middle of a project where imgui would fit perfectly, and I didn't even knew it existed. When I saw the post, I downloaded it and started tinkering. The intention of this issue was more intended to be a reference for others having similar problems.
I also thought of using reflection, but as a change in the RunLoop function is required, modification of MonoGame is inevitable. Once you have to create a new custom DLL for the debug build, it doesn't matter much if the changes are 2 or 10.
I'm in the same bandwagon in the WPF department. I really like it for tool development, but for ingame editors is more a nuisance than anything else.
Hi,
in order to make the monogame changes compile, I had to add this, in addition to your instructions:
[DllImport("user32.dll")] static extern bool TranslateMessage([In] ref NativeMessage lpMsg);
[DllImport("user32.dll")] static extern bool DispatchMessage([In] ref NativeMessage lpMsg);
and also had to make the HorizontalMouseWheelEventArgs class public.
Now into trying to get the whole thing running... :)