MonoGame.Forms - Create your Editor Environment!

BlizzCrafter · April 2, 2018, 11:07pm

Ok fine. Please try the following:

Place this code block:

protected override void OnMouseWheel(MouseEventArgs e)
{
      base.OnMouseWheel(e);
}

in the MapHost class and place a breakpoint inside this method.

See if it can reach this breakpoint.

mgtaa · April 3, 2018, 4:26pm

I added that in and placed a breakpoint, but it still doesn’t seem to be working. Very weird.

BlizzCrafter · April 3, 2018, 5:04pm

It’s possible that the controls may not have input focus.

Let’s try this:

Put this code block additionally:

protected override void OnMouseEnter(EventArgs e)
{
        base.OnMouseEnter(e);

        if (!Focused) Focus();
}

protected override void OnMouseLeave(EventArgs e)
{
        base.OnMouseLeave(e);

        if (Focused) Parent.Focus();
}

in the MapHost class and test these events as well as the mouse wheel events from the previous posts.

mgtaa · April 3, 2018, 5:47pm

That did it! Upon adding those, it hits the breakpoint I added in OnMouseWheel.

Thank you so much!

BlizzCrafter · April 3, 2018, 5:51pm

This is great I’m glad I could help.

Can you confirm that the breakpoints in OnMouseWheelUpwards and OnMouseWheelDownwards are working too now?

mgtaa · April 3, 2018, 6:10pm

Yeah, both of those are working now as well.

BlizzCrafter · April 3, 2018, 6:42pm

Okay nice.

I already applied a patch on the dev branch (not public). It will be available on the master branch in the next iteration of MonoGame.Forms, so you don’t need to fiddle around with OnMouseEnter and OnMouseLeave in your custom controls.

I will push out along other improvements soon.

Thanks for reporting the issue @mgtaa!

BlizzCrafter · April 5, 2018, 1:23am

MonoGame.Forms 1.6.5.0 - MouseWheel Event Fixes and DebugPanel

Added the public Texture Pixel and the public Color DisplayBackColor to draw a panel behind the text of the integrated display and make them useable by the end user.
Also rewrote the drawing logic of the integrated display accordingly.
Fixed that the MouseWheel events didn’t fire for some users, because custom controls didn’t get Focus() when the mouse cursor entered a custom control.
Set the cached float FontHeight in GFXService to public as it is also useful in custom controls, when working with the integrated display font.
Relative and absolute MousePositions switched from Microsoft.Xna.Framework.Vector2 to System.Drawing.Point, as it’s more fluent in a WindowsForms environment.
Added protected bool IsMouseInsideControl to the GraphicsDeviceControl, so that it’s easily possible to check if the mouse cursor is inside a (resized) control.

NuGet: NuGet Gallery | MonoGame.Forms 1.6.7.1

Better readable debug panel:

ID_00.png920×300 410 KB

ID_01.png920×236 297 KB

BlizzCrafter · April 10, 2018, 11:27pm

MonoGame.Forms 1.6.5.1 - Removed IGFXInterface and added global MousePositions

Access modifier of UpdateFrameCounter() and UpdateDisplay() are now internal.
Removed IGFXInterface as it’s not needed anymore.
Added internal void UpdateMousePositions to the GraphicsDeviceControl and calling it in the DrawWindow and UpdateWindow (GameControl) to make them available in all custom controls through the Editor service classes.
- This makes it possible to use the relative- and absolute mouse positions in the DrawWindow (updated through invalidation).

NuGet: https://www.nuget.org/packages/MonoGame.Forms/

BlizzCrafter · April 17, 2018, 10:39pm

MonoGame.Forms 1.6.5.2 - BackBuffer Fixes

The BackBufferWidth and BackBufferHeight (PresentationParameters) are now equally set on all custom controls.

This fixes a bug where resizing a control also resizes the BackBuffer- Width and Height for other controls (because they weren’t updated accordingly).

NuGet: https://www.nuget.org/packages/MonoGame.Forms/

KiloMikeCodesStuff · April 23, 2018, 2:06am

Hi, I’m very interested in this, as I’m making a GameBoy emulator and I’m going to use MonoGame for the rendering and sound, and WinForms for the UI controls and GameBoy debugger.

Someone said WinForms uses GDI+ and therefore MonoGame will be slow. Is this true? I really have no idea about MonoGame nor WinForms so I can’t answer this question myself.

Thanks.

Jjagg · April 23, 2018, 9:17am

Even when embedded in WinForms, MonoGame will use DirectX or OpenGL for rendering, so MG will not run slower than usual.

SNaidamast · April 23, 2018, 3:16pm

This may sound like a “dumb” question but could someone explain exactly what MonoGame-Forms is.

Is this a way to add a complete GUI to your MonoGame Project?

Thank you…

BlizzCrafter · April 23, 2018, 6:08pm

@SNaidamast

No, this is exactly not the purpose of MonoGame.Forms.

To quote the headline of the readme file:

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.

So the purpose of MonoGame.Forms is - for example - creating your own editor tool, which needs a rendering window, for your own game.
This could be a level editor or a particle effect editor for example.

You basically create a new WindowsForms project and then add the MonoGame.Forms library to this project, to make the rendering capabillities of the MonoGame.Framework available in your editor project in a very easy way.

Also what @KiloMikeCodesStuff said should be possible. Creating your GameBoy emulator with MonoGame.Forms should be very doable, when you know how to render your contents using the MonoGame.Framework. Everything else is just the usual business of WindowsForms (working with a complete GUI solution for projects like that).

I also reccommend reading the README file and the Wiki (which describes the class library) to get a better overview.

Regarding developing games inside MonoGame.Forms: Yes, it’s kinda possible. The library has native Keyboard and GamePad support of the MonoGame.Framework as well as RenderTarget support. However it only supports the Windows platform and I have never tested things like fullscreen support and different resolutions (but it’s possible to resize the render controls), because - as I said - this is not the purpose of the MonoGame.Forms library.

I recommend using the MonoGame.Forms library for tools and editors only. Not for whole games on a bigger scope.

SNaidamast · April 23, 2018, 9:51pm

Thank you for your informative reply, sqrMin1…

So then, if I am ever able to complete my military simulation, I could then use this library to create, for example, a scenario editor. Is this a better understanding of your software?

BlizzCrafter · April 23, 2018, 11:45pm

Yes, you could do that, but it realy depends on your needs.

For example: it’s also possible to create a scenario editor without the need of a rendering window, as long as such an editor only needs to process and handle plain data.

But if you need a graphical / rendered representation of such data (which includes realtime updates), then MonoGame.Forms is there to help you with that.

BlizzCrafter · April 28, 2018, 9:26pm

MonoGame.Forms 1.6.5.3 - MSAA Accessibility

The maximum MultiSampleCount (MSAA Antialising) of the users GraphicsDevice is now cached in PresentationParameters.MultiSampleCount, so this information becomes easy to access in custom controls, which is useful when working with custom RenderTargets.
It’s now possible to get the clamped MultiSampleCount in custom controls by calling GetClampedMultisampleCount(int).
This function always returns the desired MultiSampleCount clamped to the nearest power of two in a descending order (e.g.: input = 7; output = 4).

NuGet: NuGet Gallery | MonoGame.Forms 1.6.7.1

Easy to work with MultiSampling in MonoGame.Forms:

BlizzCrafter · April 29, 2018, 6:18pm

MonoGame.Forms 1.6.6.0 - MSAA Accessibility (Refreshed)

GetClampedMultisampleCount is now internal.
Added public void SetMultiSampleCount(int) which calls the new internal event Action<int> UpdateMultiSampleCount, so the wanted MultiSampleCount will be available in all editor service classes.
Added internal AntialisingRenderTarget and internal void RefreshAntiAlisingRenderTarget, which automatically updates itself based on ClientSize and WantedMultiSampleCount.
GraphicsDeviceService is now internal.
as well as the corresponding field in GraphicsDeviceControl.
Added the internal int MaxMultiSampleCount and cache the value there instead of in the presentation parameters, to make this value save from manipulation, because it is used by the GetClampedMultisampleCount in GraphicsDeviceControl as a fallback.

Use Antialising (MSAA) in your custom controls like this:

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

   SetMultiSampleCount(8); //Usual numbers are 0, 2, 4, 8
}

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

   Editor.BeginAntialising();

   Editor.spriteBatch.Begin();

   //Your drawings

   Editor.spriteBatch.End();

   Editor.EndAntialising();
}

As you can see, everything between BeginAntialising() and EndAntialising() will be affected by MSAA.

NuGet: NuGet Gallery | MonoGame.Forms 1.6.7.1

BlizzCrafter · May 7, 2018, 4:33pm

MonoGame.Forms 1.6.6.2 - Antialising Fixes

Added missing nuget references to SharpDX.dll, SharpDX.DXGI.dll and SharpDX.Direct3D11.dll.
Added public int GetFrameRate to get the current frame rate of a custom control.
Changed internal event Action UpdateMultiSampleCount to public so the user can react to multi sample changes in custom controls.
The AntialisingRenderTarget now correctly gets disposed on refreshing.
Fixed a NullReferenceException when the SwapChainRenderTarget is null.
Rethought the disabling of the AntialisingRenderTarget after a ControlResize event. It automatically reactivates itself after 500 milliseconds after a ControlResize event occours.
This prevents OutOfMemoryExceptions on recreating the AntialisingRenderTarget as well as NullReferenceExceptions if the current internal Rendertarget is lost, when switching from the AntialisingRenderTarget to the SwapChainRenderTarget.

Dev Note for the next Build (1.6.7.0):
Planning to implement a RenderTarget Manager where users can add their custom RenderTargets to, so they becoming automatically updated internally (based on the ClientSize for example).

NuGet: NuGet Gallery | MonoGame.Forms 1.6.7.1

BlizzCrafter · May 17, 2018, 4:53pm

MonoGame.Forms 1.6.7.1 - Render Target Manager

Added a RenderTargetManager to fully manage custom RenderTarget2D’s internally - based on ClientSize and MultiSampleCount.
Fixed memory leaks on reinitialization of custom controls.
Added public event Action RenderTargetsRefreshed so the user can get notified when the RenderTarget2D’s, hold by the RenderTargetManager, got refreshed.
Renamed events to make it more clear what they are meaning:
UpdateSwapChainRenderTarget -> SwapChainRenderTargetRefreshed
UpdateMultiSampleCount -> MultiSampleCountRefreshed
Made SwapChainRenderTargetRefreshed internal.
Changed some XML comments so they are better understandable.

Using the RenderTargetManager

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

    // Adding a new Rendertarget2D with the keyname "MyTarget" to the Manager
        Editor.GetRenderTargetManager.CreateNewRenderTarget2D("MyTarget", false);
}

public override void Draw()
{    
    // Set the new RenderTarget
    Editor.BeginRenderTarget("MyTarget", clearColor: Color.Transparent);

    // Your Drawings ...

        // Automatically revert to the SwapChainRenderTarget
        Editor.EndRenderTarget("MyTarget", drawToSpriteBatch: false, clearGraphics: false); 
}

NuGet: https://www.nuget.org/packages/MonoGame.Forms/