Thursday, November 03, 2011

MonoGame -vs- XNA Comparison

I was toying around with switching to MonoGame earlier tonight.

First off, the transition was very simple.  I downloaded MonoDevelop, OpenTK and the MonoGame source.  I compiled MonoGame using MonoDevelop and got a dll out of it.  I then deleted all of my XNA references from AstroMiner and added a reference to the MonoGame .dll.

After trying an AstroMiner build, I noticed a couple of differences.  Texture2d.FromStream is now Texture2d.FromFile.  render.SaveAsPng (for taking screenshots) is no longer available.  Out of everything I do, that's it.  Can't really complain.

After running the game, I noticed that the first thing that was off was the window size - it was smaller.  It also didn't have the proper title or icon.  No problem.  The game wasn't using a FixedTimeStep anymore, but that's also probably a small fix.  When I went to fullscreen, I noticed that the drawing dimensions didn't adjust.  First thing that problem tells me is that the Window functionalities are different enough to throw my code off.  Things like Window.Width, .Height and others.  I then noticed that the mouse wasn't working in the game.

Next was trying to play the game.  Keyboard controls worked for the most part.  Shift, Ctrl and Alt didn't work but all the others did.  Mouse still wasn't working.

I would say that 90% of my code worked fine.  All the game logic was normal (as was expected since that was vanilla C#).  The drawing functions, for the most part, worked.  Certain sprites were flying all over the screen, but they were at least displaying in the right spot at some point.  It was pretty hectic overall.  The crazy thing is whenever I would try and take a screenshot, all would look normal.

The game ran at 59fps average.  Using the XNA framework, the same world runs at 350fps average.

So for not having to make any changes to the code (besides replacing FromStream with FromFile), I think it's a really viable solution.  I'm going to keep researching to see if I can figure out how to fix the minor issues I had.  It'd be nice to not require the XNA libraries and be able to publish to multiple platforms.

8 comments:

Anonymous said...

Sounds much easier than I would've thought. Were you doing anything more complicated than just spriteBatch.draw()? Like renderatargets or shaders?

Roy said...

Nope, the game drawing is pretty simple. That's probably what made it so easy for me.

Granted I did have a good amount of bugs, so who knows what else I'd need to do to make it fully functional.

yesimnathan said...

Interesting read. I've been thinking about switching over to monogame recently as well. It might be worth testing at least.

Laboratory Member 002 said...

From what I've found, Mouse just doesn't look like it's implemented whatsoever for Android, iOS and Windows.
The MouseState object just returns State.Released as a dummy...

;_;

Anonymous said...

Sorry, but is the game executing 6x time slower? Or just FPS cap of Monogame is lower?

Roy said...

Game is executing slower.

Brent said...

The fact that it taps out at 60fps sounds to me like its tied to your vertical refresh rate (60 is standard for most LCDs)

The fact that the game itself is slower is probably because the entire game engine probably sits locked up while it waits for each vertical refresh.

This could be good or bad really, depending on how you look at it. 60fps is a decent game experience visually. And if the whole game slows down to that speed, it will normalize it a bit so that the quality of your video card doesn't effect the game itself (or at least not drastically so).

I don't imagine that its in the engine itself. And I do imagine you can turn off vertical refresh syncing. (even if you have to tweak the source and recompile the dll).

I'm more unhappy about the idea that using a mouse in the game is a non-option.

Brent said...

The fact that it taps out at 60fps sounds to me like its tied to your vertical refresh rate (60 is standard for most LCDs)

The fact that the game itself is slower is probably because the entire game engine probably sits locked up while it waits for each vertical refresh.

This could be good or bad really, depending on how you look at it. 60fps is a decent game experience visually. And if the whole game slows down to that speed, it will normalize it a bit so that the quality of your video card doesn't effect the game itself (or at least not drastically so).

I don't imagine that its in the engine itself. And I do imagine you can turn off vertical refresh syncing. (even if you have to tweak the source and recompile the dll).

I'm more unhappy about the idea that using a mouse in the game is a non-option.