MonoGame.Forms - Create your Editor Environment!

Showcase
207

MonoGame.Forms 2.3.8 - Combined NuGet-Packages

  • Now importing the MonoGame.Content.Builder.targets and MonoGame.Common.props file and setting the MonoGamePlatform property in all MonoGame.Forms.target files (DX, GL). @harry-cpp
  • Added MonoGame.Content.Builder content/libs/nuspecs/targets for DX and GL platform.
  • Added combined NuGet-Packages which containing pre-setuped .mgcb files and the corresponding toolset as well as a custom MonoGame.Content.Builder.targets file to build MonoGame-Content.
  • Added new doc image to visualize the available nuget packages in the readme:

asd

To comply with the recently added Visual Studio templates, now there are also NuGet-Packages available which containing all necessary files and setups to build content with the MonoGame-PipelineTool to make content compiling a breeze:

NuGet

NuGet

These packages are containing both, the library and the content builder, so you can install the complete setup in one go.

I created seperate packages to still allow library-only-installations just in case content compiling is not needed by the end user (like the sample projects in the repo. They are containing pre-compiled content for example).

There is still a difference between the combined NuGet packages and the VS templates; the templates containing a sample control, which demonstrates the general usage idea of the library. The NuGet packages are full ‘skeletons’.

Hope you’ll have fun! :wink:

Have a nice day,
-Marcel

PS: The regular NuGet packages also containing properties like the MonoGamePlatform and they are also importing MonoGame targets and probs files, just in case the user started with these libraries and wants to integrate the .mgcb file in a later state. So he really just needs to include this file and is ready to go!

2 Likes
208

@BlizzCrafter Neat project!

I am testing it out and have a basic project going.

I am running into a minor issue where I am currently using a slightly modified version of the Monogame DLL (I have a PR with my changes still pending review and merge) which doesn’t quite work when I swap out the monogame DLL that comes in the nuget package with my modified one.

If I use your DLL, then my code doesn’t compile. If I swap out your DLL for my DLL, then everything works and runs, but the form designer no longer works.

On the github page, you mentioned that you are using a modified version of the Monogame DLL. Can you clarify what changes you made?

The weird thing is, the code compiles and runs with my Monogame DLL, but the form designer won’t work.

209

Hey @YTN and thanks!

Yes, you can’t easily swap the MonoGame.Framework in the moment.

Are you using the DX or the GL library?
What error are you receiving when you try to open the form designer?

210

@BlizzCrafter Thanks for the reply!

This is the DX version.

There was an option to ignore the error which allowed the form to render. Now I can’t get back the original error. I do get a different error now whenever I change or set any properties for the Monogame control. The error I get when I try to save after changing the property is “Code generation for property GraphicsProfile failed. Error was ‘Type Microsoft.Xna.Framework.Graphics.GraphicsProfile is not available in the target framework’”

The only way for me to modify and save the form properties is if I restore the original DLL (which means I can’t compile my code). I then switch back to my dll in order to build and run.

Would it be possible for you to build me a new Monogame.Framework.dll with this PR integrated?

This will have the changes I need so I can use the form designer and build and run without issues.

The PR should be fully backward compatible, so shouldn’t impact any existing behavior if you leave it in.

Thanks!

211

@BlizzCrafter Separate question… my current framework can draw directly to the screen (GraphicsDevice.SetRenderTarget(null) ) or to a rendertarget which I can then draw on the screen.

I tried shoehorning that into MonoGame.Forms, but I don’t get anything displayed. I suspect it’s because my framework is setting the rendertarget back to null (physical screen) when it’s done, and that’s breaking your stuff.

Are you using a RT internally?

If so, how do I get access to your RT?

How does MonoGame.Forms work with existing frameworks that usually have direct access to the GraphicsDevice?

Thanks.

212

I think I will push the modified source of the MonoGame.Framework to the repo, so you can modify it for your own custom build as you wish.

But I currently don’t know when I have time for it. Maybe during this weekend.

Yeah, this don’t work like this in MonoGame.Forms. You would need to set the render target back to the SwapChainRenderTarget: GraphicsDevice.SetRenderTarget(SwapChainRenderTarget)

You can generally find alot of hints/examples/explanations in the wiki:

Like for your problem:

There is also a RenderTargetManager, which simplifies work like that:
Class: Home · BlizzCrafter/MonoGame.Forms Wiki · GitHub
Create: https://github.com/sqrMin1/MonoGame.Forms/blob/master/MonoGame.Forms.DX/Services/GFXService.cs#L395
Sample: Home · BlizzCrafter/MonoGame.Forms Wiki · GitHub

213

@BlizzCrafter Thanks for the details!

I figured out my RenderTarget issues. The only thing left is the dll problem.

If you could upload your modified MonoGame source to GitHub, I’d be more than happy to build my own modified version with the PR I submitted.

Thanks again!

214

The source is now up:

Sorry for the late reply.

215

@BlizzCrafter Thanks! I built a modified version of the DLL with your modified Monogame code and my PR and it works great!

1 Like
216

@BlizzCrafter Hey mate. I added MonoGame.Forms to MonoGame Awesome when I added MonoGame.WpfCore because I think they are both equally awesome projects.

I was surprised it wasn’t in the list already :smile:

1 Like
217

Thank you very much @craftworkgames :thumbsup:

It’s also nice to see a modern Wpf implementation. Good work :slight_smile:

1 Like
218

Just wanted to inform you what i’m currently working on.

It’s the Runtime Content Compiler (RCC) for MonoGame.Forms (suggested by @harry-cpp) . It’s a WIP but I thought it would be nice to share my current state and what decisions I made. So, let’s start!

Helper class or re-implementation?

I originally thought about how the implementation of this thingy would look like or rather what would be the best possible way of having the RCC integrated into the MonoGame.Forms library.

I started creating a simple helper class which interacted with the original MGCB and the PipelineManager from the MonoGame.Framework.Content.Pipeline namespace. It worked but I was not satisfied with it because a couple of reasons:

  • It was a “Single-Task-Job” and you needed to wait till it’s finished.
  • It was not customizable.
  • It cluttered the output with MGCB binaries in every project - regardless if they use the RCC or not.
  • [insert more issues here] :wink:

However, I rethought everything and came to the idea / conclusion that it would be way nicer to integrate the original MGCB class (BuildContent.cs), the PipelineManager (and adjacents) and re-implement it at least asynchronously and as a seperate project which can be installed per NuGet on demand.

This also has the advantage, that the RCC will have all the original features of the MGCB as well as its exception- and log system.

So, I decided to go that route and just created a small wrapper around it, which is easy to use by the end user and very practial in a MonoGameControl, but still works independently from the MonoGame.Forms library - yup, that sounds nice®.

The Prototype

I already created all the basics. Take a look:

I picked a bunch of .jpgs & .pngs and let the RCC do the rest. You don’t need to set importers or processors for regular content, because it will fallback to the default ones based on the extension of the raw content - thanks to the features of the original MGCB!

Basically you can do everything what is possible with the MGCB now and the content compilation happens asynchronously - that’s why I wanted to re-implement all the pieces.

The Release Date

I think during this week.

Still need to do a couple of things and general cleanup. The MonoGame.Forms version to be expected is 2.4.0, which is the next milestone (we are currently at 2.3.8).

See you then and have a nice day!

-Marcel | Sandbox Blizz

GitHub: https://github.com/sqrMin1/MonoGame.Forms

BTW: The Visual Studio templates went pretty well. In about 2 Months we received 2,477 installs :tada:

Thank you very much for your ongoing support!

3 Likes
219

MonoGame.RuntimeBuilder - out now!

The MonoGame.RuntimeBuilder builds your raw content asynchronously to the .XNB format during runtime.

This library is a part of the MonoGame.Forms project,
but it is fully usable without the MonoGame.Forms library!

sample

Hello Com,

The basic work on the RuntimeBuilder is done and depsite the fact that it is a part of the MonoGame.Forms familiy ( :sweat_smile: ), it don’t need to live in the MonoGame.Forms repo or library. It’s generally usable as a standalone library to build your own tool with runtime content builder functionality - hurray :tada:

Using the MonoGame.RuntimeBuilder is fairly easy:


// Creating the property.
private RuntimeBuilder _RuntimeBuilder { get; set; }

// Initialize the RuntimeBuilder.
_RuntimeBuilder = new RuntimeBuilder(
                Path.Combine(Application.StartupPath, "working"),           // working directory
                Path.Combine(Application.StartupPath, "working", "obj"),    // intermediate directory
                Path.Combine(Application.StartupPath, "Content"),           // output directory
                TargetPlatform.Windows,                                     // target platform
                GraphicsProfile.Reach,                                      // graphics profile
                true)                                                       // compress the content
            {
                Logger = new StringBuilderLogger()                          // logger
            };
            
// Pick Files & Build Content.
private async void ButtonPickFiles_Click(object sender, System.EventArgs e)
{
    if (openFileDialog.ShowDialog() == DialogResult.OK)
    {
        await _RuntimeBuilder.BuildContent(openFileDialog.FileNames);
    }
}

And… that’s it!

Read more on GitHub!

Of course it’s also available on nuget:

NuGet

Feel free to follow me:

Twitter Follow

I wish you a happy day! :smiley:

-Marcel | Sandbox Blizz

1 Like
220

:four_leaf_clover: Yesterday, Friday the 13th, was my lucky day (it has always been my lucky day) :four_leaf_clover:

I got 2 beta invites on this special day:

I’m telling you this mainly because of the GitHub thingy. As a result packages of all my libraries are also available on GitHub now!

These are the packages of MonoGame.Forms.
These are all packages currently available on my GitHub profile.

Have fun checking these out!

I wish you a nice and lucky weekend! :four_leaf_clover: :wink:

-Marcel

Follow me for the extra portion luck in your life:

Twitter Follow

( lol )

221

Cool, did you do it in a similar way to my friends post for XNA from way back when?

222

There are similarities as far as I can see, but I followed a different design philosophie. For example in MonoGame.Forms you will not work with a classical XNA/MonoGame Game.cs class. It’s a “game-class-independent-implementation” if you want to call it like that.

The core class is the GraphicsDeviceControl which inherits from a regular System.Windows.Forms.Control and has the following core purpose:

It also handles client resizing and user input by converting the pressed keys to the XNA/MonoGame equivalents.

The general idea was to extend the library functionality later by service classes so that users would have a nice and easy time to start their own editor projects.

So if the user wants to have an updateable render surface, then the only thing he needs to do is to inherit from MonoGameControl like this:

using Microsoft.Xna.Framework;
using MonoGame.Forms.Controls;

namespace nugetTest
{
    public class DrawTest : MonoGameControl
    {
        string WelcomeMessage = "Hello MonoGame.Forms!";

        protected override void Initialize()
        {
            base.Initialize();
        }

        protected override void Update(GameTime gameTime)
        {
            base.Update(gameTime);
        }

        protected override void Draw()
        {
            base.Draw();

            Editor.spriteBatch.Begin();

            Editor.spriteBatch.DrawString(Editor.Font, WelcomeMessage, new Vector2(
                (Editor.graphics.Viewport.Width / 2) - (Editor.Font.MeasureString(WelcomeMessage).X / 2),
                (Editor.graphics.Viewport.Height / 2) - (Editor.FontHeight / 2)),
                Color.White);

            Editor.spriteBatch.End();
        }
    }
}

"Editor" is the underlying GFXService class, which contains basic XNA/MonoGame functionality as well as helper classes like a RenderTargetManager which makes working with render targets easier (client resizing etc.). Generally you will find additional useful stuff to jumpstart your editor creation process. Fell free to take a look at the Wiki to discover more of them.

Have fun and a nice day :sunglasses:

-Marcel

1 Like
223

I recently updated the repo and the old MonoGame.Forms nuget and want to share some infos with you regarding this.

  1. The old MonoGame.Forms nuget package recently reached over 6000 downloads and got his last update mid 2018. Nevertheless I decided to completly unlist the old package from nuget. Why?

With version 2.0 I created new packages with a complete re-design of how MonoGame.Forms should work. Since then the old package was just listed as a reference and to have a stable alternative to the new packages.

Now, roughly one and a half year later, the old package still received ca ~8 downloads per day (~240 / month, ~2880 / year). I don’t know how many new users are in these numbers nor how often they downloaded the old package, but if it were only 2% of them, we would still have ~58 new users per year installing the old package. Yeah, this doesn’t sound much and it is probably not a big deal, but… every single user counts! :slight_smile:

So, I kinda “forcing” them now to download the new packages instead. They are containing the latest updates, features and improvements; there is really no need in using the old package anymore and I recommended using the new packages ever since.

There is only one disadvantage on my side: the overall download count of nuget packages on my nuget profile is now misleading because the 6000 downloads of the old MonoGame.Forms package got substracted. Well, i’m getting over it :smiley:

  1. I also updated the tutorial section of the Readme.md file to make it clearer and more obvious for beginners to start with MonoGame.Forms and better understandable to correctly use the library.

  2. I added an ImplementationDetails.md file to the repo, so that I can easily refere to it in case someone asks me about this topic (which happened a lot over the time).

That’s it!

Have a nice day.

:: Marcel

BTW: my old english teacher told me once, that ending a presentation with “that’s it” is unprofessional and stupid. Well, I guess I did something stupid here, but I don’t care :stuck_out_tongue:

1 Like
224

im still not able to use Mouse.GetState() in the Control with the latest source. When i console Mouse.GetState().LeftButton it always return in Released state, and i pressing it all time. FYI i am using attached my control in docksuite https://github.com/dockpanelsuite/dockpanelsuite

225

@BlizzCrafter i noticed when i change the monogame reference to the official release “v3.7.1.189” the Mouse.GetState() dont work. But when i change the reference back to the version your provide in your github, it actual worked! May i know what have u change from the source?

226

@11110

Yeah, changes are needed:

The original source is included:
https://github.com/sqrMin1/MonoGame.Forms/tree/master/Libs/MonoGame/_src/Windows

Just merge it with the MonoGame version you want to use and make your own specific changes.

And yes, it works with DockPanelSuit.