MonoGame.Forms - Create your Editor Environment!

Showcase
1

Banner
Banner800Ɨ200

Welcome to MonoGame.Forms!

MonoGame.Forms is the easiest way of integrating a MonoGame render window into your windows forms project. It should make your life much easier, when you want to create your own editor environment.

Demo

With the beginning of the year 2017 I started to research the possibility of integrating MonoGame into a WindowsForms project, so it would have been possible for me to create my own editor environments.

Since then some projects saw the light of the day like the PenumbraPhysics.Editor or the Rogue Engine Editor. I worked with them alot to find the best possible way of handling the window management and MonoGame related stuff like SpriteBatch, ContentManager, GameTime and so on.

During that time I also heared some people saying that they need a simple render window integration for their own custom editor projects - it was about time to create the MonoGame.Forms PCL! :smiley:

So yes, it isnā€™t something very complex, but it is enough for a basic integration where you can build upon. It currently lacks 3D services, because I have no knowledge in this area. But itā€™s well suited for 2D.

Initializing, Updating and Drawing works the same like you are currently doing in MonoGame. You can also have multiple render windows in one project. There is also a Camera2D component so you can move the control view.

Adding one render control to your forms project is fairly easy:

You just inherit from the DrawWindow or UpdateWindow class and override the corresponding Initialize() [Update()] and Draw() methods. A draw window is updated through invalidation. An update window is updated by a real game loop. When you are building the project, the toolbox controls are created automatically for you. You just need to drag and drop them where they should be!

Donā€™t worry; I have also written a sample project, from which you can learn and a more detailed tutorial you will find in the Readme.md of the GitHub project.

If you want to know more about MonoGame.Forms then please visit the GitHub repo. You can build the PCL from source or even install it through NuGet.

Now Have Fun with MonoGame.Forms!

Twitter Follow
Wiki
NuGet
License

Logo

13 Likes
2

Most important question: does it flicker when resizing?

3

No, but resizing isnā€™t supported anyway as it also streches and distort the drawn content.

4

You can use Ratio Scaling to work around thatā€¦

5

Depending on how youā€™re drawing it you could set the image layout to ImageLayout.Zoom and itā€™ll do ratio scaling.

But thatā€™s only if youā€™re using some sort of picture-rendering control to show the MonoGame render window to the userā€¦ and said control supports use of ImageLayout.

6

This project looks amazingā€¦ :relaxed:

However, my big questions is can this solution provide games with a built in way of using the interface controls of Windows Forms with relation to the game mechanics???

If so, then we MonoGame Developers would no longer need 3rd party interface projects since we could then integrate the Windows Forms controls as our gameā€™s interface infrastructureā€¦

7

If you mean getting the winforms UI elements to render INSIDE monogameā€¦ yeahā€¦good luck with that. WinForms is not at all designed for that use case and if you do get it to workā€¦youā€™ll be plagued with framerate issues (because WinFormsā€™ll be using GDI) unless you want to totally rewrite its rendering backend.

And at that point, itā€™s no longer feasible to use WinForms. Itā€™s better to just write your own specialized UI toolkit.

8

Well, one could hopeā€¦ :grin:

9

unless you want to totally rewrite its rendering backend.

Most of the backend is sealed anyways.

10

Hmmā€¦ this seems to be a popular trend and one which I plan to tackle soonā€¦

Perhaps sooner than even I thinkā€¦

11

@Watercolor_Games Itā€™s not a PictureBox. Itā€™s a custom GraphicsDeviceControl, which inherits from a regular System.Windows.Forms.Control. The contents of the back buffer is presented though a ā€˜SwapChainRenderTargetā€™, which just inherits from RenderTarget2D. So itā€™s also possible to have different render targets and work with complex Effects / shaders.

You can treat MonoGame.Forms basically the same you would do with your MonoGame game, but so far I didnā€™t work out a control-resize-solution regarding to the drawn content on the SwapChainRenderTarget. In the moment there are also other limitations (see below).

@SNaidamast Thanks :] MonoGame.Forms is build with in mind of having a simple solution of integrating a MonoGame render window / control to a WindowsForms project to create you own editor environment. Theoretically you could host a game into a form now, yes, but there are some things currently missing in MonoGame.Forms. For example: GamePad and Keyboard controls. When I have time in the future I could imagine to implement keyboard funtionallity, where the key presses are recognised. In the moment you have only the option to use the left, right and middle mouse button.
You asked if itā€™s possible to use windows forms controls (UI) in relation to game mechanics. The answer is yes of course! Itā€™s already in the sample project. Just take a look. This is a key feature, because it should be possible to create a complex editor environment, which has this Forms-Control-MonoGame-Mechanics-relation ;). But you couldnā€™t use your MonoGame game with a reference to MonoGame.Forms to create your ingame UI. You rather would host you game inside a forms project to use the forms controls capabilities. But as I sad you would have some limitations.

Regarding ratio scaling: I didnā€™t try this so far, because I didnā€™t need this feature in the past. But this project is open source, so itā€™s possible for everyone to work on that an then share it with a nice PR :slight_smile:

Iā€™m generally open for good ideas, which enhance this project; thanks at all for you nice input so far!

1 Like
12

Good luck. Iā€™m hesitant to volunteer as the only flicker solution I found was to force the main thread to sleep, that at least reduced resize flickering (from rebuilding the back-buffer) to occur only when the machine was legitimately doing too much work. I got the sample in github working but it was flicker nightmare (edit: the MonoGame sample, not yours).

This is really cool though. Iā€™ve worked with Sonyā€™s ATF before and while it was mostly great ā€¦ bloody hell does it flicker all of the time. I might be able to put up with it if rendering were less of an issue (oh dear, I went with ā€˜slavingā€™ a native SDL window into it before ā€¦ that was fun).

A rock-solid MonoGame WinForms control would be awesome.

1 Like
13

MonoGame.Forms v1.4 - Keyboard Functionality

I had time to look at a proper keyboard implementation to push MonoGame.Forms ability of hosting / embedding
a MonoGame game with keyboard controls.

Itā€™s working fine so far:

The Repo is already updated as well as the NuGet.

The sample project from the video to test the controls by yourself is included.

I recently saw / used a working WindowsForms XBOX controller implementation. I think itā€™s also possible to put that functionality to MonoGame.Forms.

1 Like
14

I just wanted to say this looks like a really awesome project.

Congrats man! :slight_smile:

1 Like
15

We need OpenGL support here! :smiley:

1 Like
16

Just to complete the ā€œcontrols-sectionā€:

The gamepad worked out of the box (instead of the Keyboard). I recently updated the Repo or rather the AdvancedControlsTest.cs sample, which makes it possible now to control the player sprite with a gamepad.

Now you can use a keyboard or a gamepad inside a MonoGame.Forms render window.

Again thank you all for your comments! :slight_smile:

17

Thereā€™s a trick to enable the Keyboard on WinForms.
http://community.monogame.net/t/work-around-call-non-public-method-custom-game-loop-not-using-game-class-only-partial-info-from-keyboard-getstate/

1 Like
18

Indeed this is a very nice trick :slight_smile:

I already implemented keyboard functionality in a different way:

  1. In the main form I override ProcessKeyPreview to catch keyboard messages and traverse them to registered controls.

  2. The messages are getting processed in the GraphicsDeviceControl and formatted into the MonoGame specific format through a MappingDictionary if the corresponding control is visible.

  3. You can then read the valid key presses through a custom Keyboard.GetState() method.

I saw this approach a while ago in a blog and main reason for using this was that Control.Focus() for neccessary keyboard input didnā€™t worked well (sometimes keyboard input worked and sometimes not). However I donā€™t saw your solution before, but it seems to be much simpler and more elegant :slight_smile: . Thanks for sharing @nkast!

The custom Mouse.Windows.cs in the end of your linked post is also looking helpful for having full mouse support. Currently I just getting the mouse clicks through a simple forms MouseDown event, which works without a problem, because the control automatically gets focus on click (instead of by a key press).

19

You mean when the control doesnā€™t have the focus?
I had the same issue with mouse wheel, I wanted to send the Wheel delta to the control bellow the mouse, not to the one that had focus. I found this little gem (CaptureMouseWheelWhenUnfocusedBehavior) at stackoverflow.

It traps all app messages and redirect them to some controls you register. With the right modification you can do the same for KeyUP/KeyDown messages.

20

@nkast Sorry for the late reply, I was pretty busy. Thanks for sharing the stackoverflow topic and yes, I had problems with the control focus regarding keyboard input; but they are solved.

I did some small tests with regular windows forms mouse events in custom controls with a good success. I was also able to use the mouse wheel in multiple custom controls (render windows) in the same view and without explicit focus.

I will soon report back with an updated repo which has full mouse support.