MonoGame.Forms - Create your Editor Environment!

Showcase
185

Hm, this sounds strange to me. In the moment I can’t explain why this is not working for you.

If it’s realy just a fresh Windows Forms project with the installed MonoGame.Forms library, then it will work on my machine.

But yes, upload it somewhere and I will take a look. Would be nice if I could help you.

186

MonoGame.Forms 2.3.0.1 - Hotfix Mouse.GetState()

  • Updated the MonoGame.Framework to bring back Mouse.GetState() functionallity from the MonoGame.Framework, which got overriden by the newer develop branch of MonoGame.Framework 3.8.0.270.

I just released this update as a hotfix because I detected that Mouse.GetState() always had the default values.

Then I realised that an old PR from @nkast:

wasn’t merged so far. Back in time this PR solved the problem, that when using the MonoGame.Framework independently from its Game class, the user wouldn’t have had any mouse input events through Mouse.GetState() in his editor environment anymore.

This PR seemed good to me to become merged, but instead it became closed and I don’t know why, because it’s actually pretty helpful and, as far as I can see, it wouldn’t have had broken game specific stuff. But who knows, maybe i’m wrong.

Here, just for you to compare (current develop branch vs. fix from nkast).

Anyway, this problem is fixed now for MonoGame.Forms (again :P).

Cheers,
Marcel

PS: NuGets updated accordingly (2.3.0.1).

187

is there any framerate limit like, wpf?

188

It’s limited to 60fps.

189

Question : Any pro and cons between WPF and Winform.
Which 1 is preferred for editor like solution ?

190

Both will work to create an editor but there there are many differences between them.

  • WPF is a newer technology, WinForms is older.
  • WPF uses an XML based language called XAML, WinForms generates code based designer files.
  • If you use WPF you’ll learn about things like MVVM using a declarative Binding based approach, WinForms is all C# code (at first it feels easier, but many people prefer the declarative XAML based approach).
  • You can embed MonoGame into either, but doing so requires different code (if you look around you can find other people that have done this).
  • Both technologies are Windows based, although there are projects around to try and make them multi-platform (I’ve never seen one that works really well though).
2 Likes
191

@craftworkgames put it well together, but just for the sake of completeness I also want to mention the awesome imgui library (C++).

There is also a .Net wrapper called ImGui.Net.

From the readme file:

This is a .NET wrapper for the immediate mode GUI library, Dear ImGui (GitHub - ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies).
ImGui.NET lets you build graphical interfaces using a simple
immediate-mode style. ImGui.NET is a .NET Standard library, and can be
used on all major .NET runtimes and operating systems.

There is a sample program which shows you how to use it together with MonoGame.

The advantage here is that you can integrate it into a DesktopGL project which makes your editor available on multiple platforms without extra work.

I also managed to make it work with MonoGame.Forms so you would have additional designing options in a WindowsForms environment, where it’s often painful to design things (like a property grid).

Another advantage is that you can still use WindowsForms controls / user controls or file dialogs which makes working with directories and files pretty easy.

But in the end it really depends on your ambition and technology knowledge. I would say:

  1. Are you skilled with WPF? Then try to create your editor with the MonoGame.WpfInterop.
  2. You just want a little tool window for manipulating level files? Maybe then MonoGame.Forms is simple enough.
  3. You want a full blown multi platform editor? Maybe then you should try the ImGui.Net library with the MonoGame.Framework.
  4. Are you experienced with WindowsForms but not with WPF and you want fast results without missing designing capabilities? Well, I can show you how to integrate ImGui.Net into a MonoGame.Forms project.

Hope this helps with your decision.

2 Likes
192

Thanks for all the detail information !! :grinning:

1 Like
193

how rendertarget work on MonoGame.Forms. When i try to use do my rendertarget, it show red color output. 2nd Question can Mouse.GetState() work in Monogame.form?

194

It works likewise but you need to set the render target back to the SwapChainRenderTarget afterwards (GraphicsDevice.SetRenderTarget(SwapChainRenderTarget))

I recommend using the integrated RenderTargetManager. Here is a sample.

Yes, Mouse.GetState() should work as well as the WindowsForms input events.

195

thanks , ermm i dun get any mouse input and position is always 0.

196

It seems you are using an outdated version. Try upgrading to the newest release.

Regarding mouse position I recommend working with GetAbsoluteMousePosition and GetRelativeMousePosition to get the exact mouse coordinates:

Editor.GetAbsoluteMousePosition
Editor.GetRelativeMousePosition

197

MonoGame.Forms 2.3.5

  • Added void RunFrames(int) to run a specific amount of frames of a MonoGameControl, when the bool MouseHoverUpdatesOnly was set to true.
  • Open up the ResourceContentManager to enable content loading from a resource file .
  • Using void ResourceContentManagerInitialize(ResourceManager) to initialize the ResourceContentManager, which is available for the user to load custom content from a resource file (.resource).
  • Property bool IsMouseInsideControl is now directly accessible through the GraphicsDeviceControl, so there is no need of using the editor service class for this.
  • Added protected bool IsMouseInsideControlArea(int, int, int, int), so the user can check if the mouse cursor is inside a specific control area.
  • Reattaching the Mouse.WindowHandle when entering a different GraphicsDeviceControl in case it gets lost.

Cheers,

  • Marcel
198

@BlizzCrafter is monogame.forms native looking to the os’s current theme?

199

No, MonoGame.Forms itself does no theming. Just what WindowsForms has to offer.

But of course you can do your own themes or load various user controls with different themes.

So, theming is completly up to you.

200

my issue is I want to make the control always look native to the os

201

MonoGame.Forms 2.3.7

  • Refactored Camera2D component.
  • Added public float DefaultZoom/DefaultRotation/DefaultPosition properties, so that it’s possible to reset these values to specific default values.
  • Added overloads to the ResetCam method, so that it is possible to reset specific camera values like Position, Zoom and Rotation.
  • It’s now possible to quickly set the default values of the camera to the current ones with SetDefaultsFromCurrent().
  • Added Buy me a Cola-Light support button.
  • Added a GitHub Sponsor button.

MonoGame.Forms is now 21 month old and recently reached over 20.000 views here in the MonoGame community. This makes it the second most viewed thing in the “Showcase” topic.

Additionally we achieved 9.868 downloads of the library on nuget.

So, it’s time to raise a glass or two :cocktail::tropical_drink::beers::champagne: :grinning:

Huge thanks for your ongoing support and furthermore happy editing! :two_hearts:

Cheers,

  • Marcel
4 Likes
202

A bit of a side note, since I realized I never mentioned it, I have published Gtk version of MonoGame for quite some time (sorry @SpiceyWolf, I know I hijacked the package from you). Gtk for those of you who don’t know is a GUI toolkit mainly used by Linux apps, however it works under Windows and Mac as well. To try it out do:

# install templates
dotnet new --install MonoGame.Template.Gtk.CSharp

# create project in current dir
dotnet new mggtk

# run project
dotnet run

(On Windows you need to install Gtk beforehand: https://github.com/GtkSharp/GtkSharp/wiki/Installing-Gtk-on-Windows)

@BlizzCrafter Some of my random thoughts.

  • We could make an Eto.Form control
  • you can specify the MonoGamePlatform property in the nugets themselves
  • you can compile content during runtime by using MG.Content.Pipeline dll file found next to the Pipeline Tool, its what MGCB/Pipeline Tool actually use to compile content
  • What are you doing regarding input handling, if anything? With Gtk version I made a limitation of only 1 active control so I fully implemented input handling based on widget position and focus
1 Like
203

I remember seeing that Gtk version of MonoGame somewhere. I believe it was on GitHub. But I haven’t tried it so far.

  1. An Eto.Forms version of MonoGame.Forms would be a great addition, because our GL implementation would be slower than a more “native” multi platform integration through the original graphics context rather than just converting the back buffer to a bitmap like in our case.

  2. Oh, never thought about that, but this is a nice idea. So the end-user has less pre-setup to do before using the library. Now that you addressed this, I think about setting up a seperate .targets file which also imports the MonoGame.Content.Builder.targets file and includes a basic MonoGameContentReference file (.mgcb). I’m sure one could also create a template for this, but I never did that so far and would need to read a bit into this topic.

  3. Yeah, personally i’m using the MGCB.exe in a different project to do this. I’m not sure how I would implement this in the MonoGame.Forms library for the end-user so that it would makes sense in his editor project. I now it’s possible to directly use the MG.Content.Pipeline.dll and make the content compilation available without an extra tool. Maybe I could write a helper class for it and let the user decide how to use this functionality.

  4. It’s the same for MonoGame.Forms. Only the control with active focus receives input from the user. We are using the original input functionality from the MonoGame.Framework for mouse, keyboard and gamepad interaction. The DX version utilizes a nice little keyboard trick using reflection (@nkast showed it to me first ;)). The GL version uses the SDL-Input capabilities from the MonoGame.Framework by using SDL.PushEvent() (same for mouse input). The DX version receives mouse input by setting the window handle to the control handle as soon as the mouse enters the specific control. We put that not in the initialization of a control to avoid null pointers, when the user disposes the specific control in a multi viewport application. To make this available we needed to refer to an older PR from nkast and merge that with a custom build of the MonoGame.Framework, because this PR wasn’t merged with the original source so far.

Can you point me to your Gtk repo if available? I would be happy to link that in our README.

I also saw that the GitHub repo of the MonoGame.Framework has a support button now. I will update the MonoGame.Forms repo with this additional support url soon.

Thanks for your input!

BTW: I’m not experienced with Eto.Forms, so I would need to read into this topic too. I think we would need something like an EtoViewport for GL rendering which gets the graphics context from the MonoGame.Framework (SDL). Is there something like that in existence? Because then such an implentation would be not that hard, I think.

204

For now the Gtk version lives in my fork but I’ll try to get it into main repo once again at a later point: https://github.com/cra0zy/MonoGame/tree/gtk

1 Like