This is a quick note that I’ve setup a repository on GitHub specifically for code and examples related to MonoGame WinForms controls. You can find it here:
https://github.com/jaquadro/MonoGame-WinFormsControls
The repository unifies all of the code that I’ve put up as separate downloadable projects in each post. The code is also improved in some places, and includes better example projects. Since I’ve caught myself re-implementing the basic control code several times now in projects, I’ve setup the main control project as a standalone library that you can include and extend. You can still use the code as a template to directly copy into your projects if that fits better.
So far I’ve written three entries on this topic. Two of them have been prompted by your questions and feedback. The WinForms controls repository will be updated accordingly I write new entries, although it may continue to see minor changes regardless.
Looking forward, MonoGame is still undergoing plenty of turmoil. There’s several different proposals on the table that could invalidate some or all of the code I’ve put up so far. Two particular items that have caught my eye:
-
There’s an open pull request on multi-GameWindow support for DirectX. It looks like this will be included, and then will be applied to OpenGL. This could result in DirectX-controls becoming viable. It could result in a better way of managing OpenGL controls down the road. It may also remove the need to implement our own version of the Game class. That would be very welcome, but I don’t have any answers yet.
-
There’s open debate on whether SDL2 could replace OpenTK as an underlying game/rendering platform. This would likely invalidate everything that has been put up so far, since we currently depend on OpenTK’s GLControl and what it exposes in terms of OpenGL context and APIs. It’s unclear if there will be an SDL2 equivalent that works without hacking into MonoGame and/or SDL2.
These are issues I’m keeping an eye on. If you have more information on these topics, feel free to share in the comments.
Top work. I’ll definitely be keeping an eye on this 🙂
Hi!
I just checked in your code and I’m getting a NullReferenceException at
_device = new GraphicsDevice(adapter, profile, pp);
any ideas?
Thanks a lot!
Kak
it’s weird because adapter, profile and pp are not null
Go ahead an open an issue on the GitHub project — it will be easier to diagnose this back and forth there. But here’s a few questions:
– Are you running any of the three included demo projects and getting this error?
– What version of the MonoGame DLL did you reference? The last release that MonoGame released (3.0.1) is ancient. The current WinForms code is meant for more recent versions, which you must check out and build yourself from source.
Hi Jaquadro!
I’ve decided to post the bug in the MonoGame issues as it seems clearly related to MonoGame. https://github.com/mono/MonoGame/issues/2114
Curiously the program works with 3.0.1 but not with 3.2 🙂
Thanks, see you there 🙂
Kak
Hi Jaquadro,
what would I need in order to be able to use Content in this example? I mean, loading a texture, a model, …
I’m always lost when I’m outside my control zone 🙁
It’s identical to content loading in other MonoGame projects. I believe this is still relevant: https://github.com/mono/MonoGame/wiki/MonoGame-Content-Processing
Hi!
I meant where is the ContentManager “Content” object which usually is inside the Game object. In this example, Content is available to “ExampleGame” but it’s not available to “ExampleGame.embedded”
I’ve tried to build the Content object as MonoGame.Framework does, but I end up needing a “Game” object, but the moment I call the Game constructor, the windows form is rendered white instead of rendering the pong game.
Thanks!
Kak
Maybe I’m missing something, but I don’t see where MonoGame.Framework needs a Game object to create a ContentManager.
In my open source engine, I push the responsibility for ContentManager down into the Engine object, rather than using the one provided by the Game object. It’s for the same reason here — so that I can get by without a Game object when I need to work with a control. https://github.com/jaquadro/Amphibian/blob/master/Amphibian/Engine.cs
I got it now, thanks a lot! 🙂
Hi Justin, me again 🙂
have you tried the control with several simultaneous forms ?
I’m working in a game editor and it works great when using them in the main form (which uses two MGWinFormControls)
However, if I open another Dialog (let’s call it a “tool form”) with another MGWinFormControl in it, the control seems to work but it has two side effects:
1) A crash disposing the GraphicsDeviceControl when exiting the app.
2) The framerate of the “main form” is reduced every time I open one new “tool forms” (even after closing them all)
I think the problem may be that for some reason the MGWinFormControl is not released or disposed when I close the “tool form” which contains it. Is it possible? How can I do it automatically?
p.s. just checked a little bit before posting, the crash seems to be producted by a MGWinFormControl that is “zombie” after closing a “tool form”, not by the two main MGWinFormControls in the main form. This may reinforce the idea that the MGWFControl is not released.
thanks a lot, sorry for the annoying continuous posts! 😉
Kak
Do you have samples running the amphibian engine under windows 7
jfcqva
segj0v
piw9h8
833mkj
psl66d