7 Comments

Trying out MonoGame

This post (probably the first in a series) will describe my experiences trying to convert an existing XNA project to MonoGame. My intention is to port my (previously WP7) game to iOS, while at the same time keeping a Windows version working. I don’t really care about the Windows Phone version anymore.

My current understanding is that to accomplish the above, I’ll need 3 projects:

  • The original VS2010 XNA project (or perhaps just the content project?)
  • A VS2010 MonoGame project for Windows
  • A project for MonoDevelop on my Mac

I use SVN for source control, and this is likely how I’ll keep files in sync between my PC and my Mac.

My worry is the work required to maintain all these projects through changes. If I’m on iOS and I need to add a texture or something, the workflow will look like:

  • On the PC, add the texture file to the XNA content project and rebuild
  • Add the resulting xnb file to the Windows MonoGame project
  • Commit to SVN
  • On Mac, update the project to the latest version on SVN
  • Add the new xnb file to the iOS project in MonoDevelop
  • Rebuild an deploy to iPad

This is a pretty ridiculously inefficient workflow. It’ll be almost as much work adding a new code file, except that at least I don’t need to leave the Mac to do that. I should be able to add it and push it back up to my repository  However, I’m worried about how adding new files on the Mac will work with VisualSVN (I use VisualSVN (a VS plugin), which automatically adds any project files to the repository. It’s great!)

Installation

There are conflicting descriptions of the necessary prerequisites on the MonoGame site, but this is what I’m trying (I already have VS2010 and XNA 4.0 installed): Windows Phone 7 SDK (needed for content building in MonoGame!) and OpenAL (an audio layer), and of course the MonoGame libraries and VS templates themselves.

I would kind of like to just modify the XNA project files and convert them into a MonoGame project, but I don’t see anyone doing that. The recommended method seems to be to create a new MonoGame project and re-add all your code files manually.

The first issue I encountered is that the MonoGame VS templates didn’t show up, so I could not create a new MonoGame project. This turned out to be a Visual Studio bug, where it was looking the wrong Documents folder (I moved my Documents folder from it’s default location when I set up my machine 6 months ago. Visual Studio still hasn’t realized this).

New MonoGame project

I created a new blank MonoGame (Windows OpenGL) project and successfully built it.

Next, I manually added links to all my game files to it. I’m lucky that this is a very small game, or else this would be really complicated. As it stands, I still have 7 subfolders for my game files, all of which needed to be added manually. Very tedious.

 

Untitled-2

AddLink

 

Next, I had to delete the Game1.cs that was added by default to the MonoGame project and add a link to the real Game1.cs. Then I had to modify Program.cs slightly in order so it used the correct namespace.

I only had a single build error after this, so that’s pretty promising. Apparently MonoGame adds an Input class to Microsoft.Xna.Framework.Input, which resulted in an easy-to-fix name conflict.

Just for kicks, I ran the MonoGame version to see if it would make it as far as the content loading, and it did! Promising so far.

Content

Time to add content. The MonoGame template has a Content folder in it by default. I also added subfolders under that in order to mimic the file structure in my XNA content project.

Then I added all my content xnb files as links. These are of course files generated by building the original XNA project, and exist under the bin\x86\Debug or bin\x86\Release output directories there. I chose to add the xnb files generated in the Debug version. This whole thing is kind of messy, but I believe the MonoGame folks are working on a fix for this.

I’m also going to do some extra work to ensure all these files get added to the subversion repository, but I’ll worry about that later (once I try to get stuff running on Mac/iOS). Needless to say, it will result in some manual labor every time I add a file.

Next, as per some tutorial I saw, I set the properties of all the content file links to Build Action: Content and Copy to Output Directory: Copy if newer. You can select multiple files at once to do this, so it isn’t too bad.

Then, I built and ran the project, and it “worked”!

First run

Well it worked insofar as it didn’t crash. The immediate obvious issues were that some audio didn’t work, and some of the graphics blend modes (and z-order?) seemed to be incorrect.

 

Probs

XNA on the left, MonoGame on the right.

Audio problems

At first it looked like SoundEffect.Play was broken, but SoundEffectInstance was fine (since the only sound that worked was the one played through SoundEffectInstance). But upon further investigation, it seems to be dependent on the particular wav file.

The broken ones (which is all but one of my sounds) have a size of 0 in the SoundEffect.Size, despite SoundEffect._data having apparently valid-looking data.

After about an hour of poking around trying to figure out what was unique about the one sound that worked, I stumbled upon it. It was built using “Best” for the compression settings. So it looks like MonoGame doesn’t work with compressed wav files.

I’ve found some mention that you need to use MonoGame-specific content pipeline processors (MonoGame.ContentPipeline.Processors.dll), but there is no such assembly included in the MonoGame install.

Graphics problems

Next it was time to tackle the graphics issues. I was hoping perhaps it was just some uninitialized state of mine, but unfortunately it’s related to the stencil buffer.

In short, MonoGame doesn’t appear to support a stencil buffer for the back buffer. I’m able to create a RenderTarget2D with DepthFormat.Depth24Stencil8, but not the back buffer. I don’t know if this is a bug, or some limitation of OpenGL. To work around it I had to render to an intermediate render target and then to the back buffer. That’s pushing a lot of extra pixels though (a problem when I port to iOS).

An additional bug (or different behavior to XNA) is that the GraphicsDevice.PresentationParameters retain the default settings for BackBufferWidth and BackBufferHeight at the time of the Game.Initialize() method (480 x 800). They only get set to the actual back buffer size after the call to base.Initialize().

After dealing with those issues, things were still not quite right.

 

XNA on the left, MonoGame on the right.

XNA on the left, MonoGame on the right.

 

The game elements were no longer showing where I told them not to draw (thanks to the stencil buffer working), but the Perlin screenwipe I’m using still wasn’t functioning properly.

A little bit of investigating showed that it was BlendState.ColorWhiteChannels that was essentially being ignored. Again, I’m not sure if this is an OpenGL limitation, an unimplemented MonoGame feature, or a bug. I was able to work around the problem – but, like before, at the expense of pushing more pixels.

Next up…

In my next post, I’ll talk about my experience getting it up and running on iOS. Should be interesting!

Advertisements

7 comments on “Trying out MonoGame

  1. Great post!

    > BlendState.ColorWhiteChannels that was essentially being ignored

    Make sure you report these things as the custom Effect system is still really new and we are actively fixing bugs there.

    https://github.com/mono/MonoGame/issues

  2. I have a somewhat involved graphics engine which I hope I can use for a MonoGame project later on, and re-compiling XNA game libraries will definitely add a layer of complexity here.

    How does MonoGame treat effect files? Is using MGFX a must?

    • I don’t know what MGFX is! The project I am trying to port doesn’t use any custom shaders (it was previously a Windows Phone 7 project, so I had that limitation).

      I haven’t tried a project with shaders yet, but assume you’ll need to redo your shaders in GLSL for most of the (OpenGL) platforms. I’m not sure what the workflow is like for a DirectX MonoGame project.

      • MGFX are their shader compiler tools. Currently they support HLSL natively but no GLSL. I’d imagine porting WP7 games is relatively painless compared to a higher-end PC XNA game. And I’ve recently found a big limitation in that MonoGame currently does not support hardware instancing, which I need for performance.

        The current version of MonoGame on PC uses OpenGL but there’s a branch currently in development that uses DirectX 11 (using SharpDX under the hood). Part of the workflow is, if you are using libraries compiled with XNA assemblies, you need to recompile them with a reference to the MonoGame assembly so you may use them with a MonoGame project.

    • A little late to this but….

      > How does MonoGame treat effect files? Is using MGFX a must?

      Yes it does.

      Microsoft has depreciated the FX format and runtime in DX11. To use it you have to compile the code yourself (it comes in the DX10 SDK). Worse it does not work at all on Windows 8 Metro as it depends on the d3dcompiler.dll (even if your FX is precompiled) which is not allowed in Metro.

      So armed with that information and having no love for CgFX… i decided to write my own FX-like system…. MGFX.

      MGFX works with normal Microsoft FX files… just I wrote my own parser and compiler front end which generates a binary file that the MonoGame runtime understands. There are two types of problems you can run into with it:

      1. I missed something and the parser doesn’t understand it.
      2. The library we use to automatically generate GLSL from HLSL fails.

      #1 we’re fixing all the time and we’re always moving closer to having full compatibility with MS FX.

      #2 is just a limitation of the library we’re using (MojoShader) and we have plans to replace it later this year. Luckily #2 doesn’t happen too often.

      So that is that… just use the 2MGFX command like tool or the MonoGame Effect processor in the content pipeline and things usually just work. People have ported pretty advanced stuff… deferred renderers, atmospheric scattering, etc.

  3. […] months ago I made my first post about this. Basically it described my experiences building a Windows OpenGL version of an updated version of […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Space Quest Historian

Adventure game blogs, Let's Plays, live streams, and more

Harebrained Schemes

Developer's blog for IceFall Games

kosmonaut's blog

3d GFX and more

Halogenica

Turn up the rez!

bitsquid: development blog

Developer's blog for IceFall Games

Game Development by Sean

Developer's blog for IceFall Games

Lost Garden

Developer's blog for IceFall Games

Memories

Developer's blog for IceFall Games

Casey's Blog

Developer's blog for IceFall Games

Blog

Developer's blog for IceFall Games

Rendering Evolution

Developer's blog for IceFall Games

Simon schreibt.

Developer's blog for IceFall Games

Dev & Techno-phage

Do Computers Dream of Electric Developper?

- Woolfe -

Developer's blog for IceFall Games

Ferrara Fabio

Game & Application Developer, 3D Animator, Composer.

Clone of Duty: Stonehenge

First Person Shooter coming soon to the XBOX 360

Low Tide Productions

Games and other artsy stuff...

BadCorporateLogo

Just another WordPress.com site

Sipty's Writing

Take a look inside the mind of a game developer.

Jonas Kyratzes

Writer, game designer, filmmaker.

%d bloggers like this: