Spent an hour looking at this, even changed to multithreaded, might have broken from one build to another… if you want it that badly, try a previous build, 3.6-3.7…
If that’s not working, one thing you could look into is making your own render control. You should be able to find some examples on google. Then you can make a WinForms project and instantiate your render controls in whatever windows you like.
It’s not going to be cross platform though, and you’ll be making your own render/update loops, but it works. I used it a while back for a basic editor I was working on. I never tried multiple windows, but in theory it should work.
@MrValentine yeah, I am pretty sure nobody uses this function so it broke without anybody noticing. Where can I report this as a bug? Thank you for welcoming me, I am looking forward to start using MonoGame!
@Trinith That sounds good, I might give a try. I have been programming for years but never really touched render code / platform specific stuff directly… we’ll see if I can figure this out
Kingsway (above) is a reference - but instead of a fake desktop I do want the windows on the user’s real desktop. This allows me to play with their expectations - spawning windows whenever I want for instance, emphasising the chaotic nature of the game.
I wonder if this is possible or if the perfomance takes a big hit - I don’t know much about Windows’ window management.
There might be a bit of a performance hit, but it will really depend on how busy easy window is. If it’s mostly static stuff, updated on demand, I think you’ll be ok. I used to work for a company who made a system that presented SCADA information in a multi window way. Our system could present a ton of windows and render graphics to it, but we were still bottlenecked by each individual open window. You also pay a bit of a cost to set each one up.
You might consider just making your game a full screen application and render your own windows. There’s quite a few UI libraries out there that should support this for you, or you can make your own if you like. The upside here is that everything exists in your game, it’s on application, and it would be much easier to port to other platforms if you desired. The downside of using real windows is that it will very much clutter up people’s desktop (task bar) and might be a little confusing. When everything is inside a game, the context is the game. When everything is on the desktop, it might be more difficult to differentiate between what is a game window and what is just some other application that’s running.
Ultimately it’s up to you, just throwing that feedback there
It’s a good suggestion! However the chaos that you get by having actual windows is by design! I want it to be messy. It’s important to me that the game embeds in the OS.
This is another great suggestion, but considering I’d like to open quite a few windows, I think it’s not that elegant to have that many instances of the game running unfortunately.
Maybe the only other thing that I would suggest is to prototype this. Devise a few tasks, maybe something you consider easy, another you consider average, and finally one you consider difficult. Prototype your window system and distribute the test to a handful of folks (at a minimum), then get some feedback on how it plays.
@MattiaNotFound
You don’t need to use CreateWindow(). Create a Form and pass the form.Handle to SwapChainRenderTarget().
I believe keyboard should work fine. The problem would be with Mouse.
I can give you my fork which has implemented the Mouse.Handle if you want, otherwise you need to implement your own mouse handling.
Here is the nuget package, It’s net.framerwok4 only, no netCore version at the moment.
If you want the complete SDK, (content building tools, mgcb editor, templates, etc) you can install it from this link. It works like the previous versions of MonoGame prior to 3.8.