MonoGame.Forms - Create your Editor Environment!

[BlizzCrafter]

The source is now up:

sqrMin1/MonoGame.Forms

Sorry for the late reply.

[YTN]

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

[craftworkgames]

@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

[BlizzCrafter]

Thank you very much @craftworkgames

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

[BlizzCrafter]

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]

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

Thank you very much for your ongoing support!

[BlizzCrafter]

MonoGame.RuntimeBuilder - out now!

GitHub - BlizzCrafter/MonoGame.RuntimeBuilder: The MonoGame.RuntimeBuilder...

---

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!

---

Hello Com,

The basic work on the RuntimeBuilder is done and depsite the fact that it is a part of the MonoGame.Forms familiy ( ), 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

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:

Feel free to follow me:

I wish you a happy day!

-Marcel | Sandbox Blizz

---

GitHub - BlizzCrafter/MonoGame.RuntimeBuilder: The MonoGame.RuntimeBuilder...

[BlizzCrafter]

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

I got 2 beta invites on this special day:

• GOG Galaxy 2.0 at 4:22 pm
• GitHub-Packages at 8:15 pm

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!

-Marcel

sqrMin1/MonoGame.Forms

---

Follow me for the extra portion luck in your life:

( lol )

[Charles_Humphrey]

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

[BlizzCrafter]

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:

• in OnCreateControl() it creates the GraphicsDevice and a SwapChainRenderTarget
• in BeginDraw() it sets the RenderTarget of the GraphicsDevice to the SwapChainRenderTarget
• in EndDraw() the SwapChain presents the rendered image

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

-Marcel

---

sqrMin1/MonoGame.Forms

[BlizzCrafter]

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!

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

2. 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.

3. 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

[11110]

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

[11110]

@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?

[BlizzCrafter]

@11110

Yeah, changes are needed:

MonoGame.Forms - Create your Editor Environment!

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.Framewo…

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.

[azaphrael]

@BlizzCrafter

I have some weird behaviour when using Monogame.Forms: Created a small program and do some keyboard input in Update().
I noticed that it only registers keystrokes when the mouse has been hovered over the control once. After that, it works even when the mouse is outside.

I have set the following though:

AlwaysEnableKeyboardInput = true;
MouseHoverUpdatesOnly = false;

Shouldn’t it register keystrokes immediately? Is this intended? Do I miss something? I am stumped.

[BlizzCrafter]

This is normal behavior.

Try to programmatically focus the specific control before doing keyboard input and tell me if this works / solves your problem.

[azaphrael]

I tried with control.SetFocus() and control.Select(), but to no avail. I also tried overriding OnLostFocus, no chance either. Is there any other way?

[BlizzCrafter]

Ok, I found the problem; I need to push a small update to make your request possible.

Just to clearify: You want an option to enable the keyboard input right from the start of your application and without that the user needs to hover the mouse over a control beforehand, right?

Edit: try it with this patch (master): https://github.com/sqrMin1/MonoGame.Forms/commit/ef34d49f607bf47bb79d340c45bc6c2d44bbe496

Nugets will follow.

[azaphrael]

Yes, exactly!

Thank you very much! Works like a charm now.

[BlizzCrafter]

Perfect.

Nugets updated acordingly.

[BlizzCrafter]

Changed the Readme.md file of MonoGame.Forms to show a short description of the Mercury Particle Sandbox. It’s still possible to show the real Readme.md file of MonoGame.Forms by clicking on the respective link in the file.

This is what the Readme.md file now shows:

[start of file]

Mercury Particle Sandbox

The first application on Steam which uses the MonoGame.Forms library!

Click on the image to visit the Steam Store Page and read the full app description.

Following and adding it to your Wishlist is the best way to support the MonoGame.Forms library, the Mercury Particle Sandbox and me!

Thank you very much for your ongoing support!

:: Sandbox Blizz

[screenshots]
[end of file]