SGDK2 on Mono (Linux/Mac OS X)

[Parasyte]

Hi all,

I'm a hacker/developer looking at the possibility of running the SGDK2 IDE on Mono. Mac OS X, specifically.

The initial problems with the IDE under Mono have been noticed by developer bluemonkmn as early as last January: http://www.opentk.com/node/629 Mono's implementation of System.Data.DataSet.ReadXml() doesn't like the XML format for the SGDK2 projects, so it crashes on start-up.

Some good news, though! By disabling the ReadXml() call (and Windows-specific code in the slash form) you can actually get the IDE running on OS X. It probably runs on Linux with the same set of changes. (See attached screen shot!) Without the ability load projects and templates, it's kind of useless. (Also causes crashes at some points.)

This doesn't mean it actually works. On the contrary, the OpenGL drawing creates a real mess. It's probably related to not clearing the surface buffers? Unfortunately, I'm really unfamiliar with OpenGL, and even worse with C# (this is my very first expedition into C# and .NET-anything). What OpenGL actually renders resembles a buffer from video memory which hasn't been cleared; it contains pieces of icons and images from the OS. It's also apparently double-buffered, because moving the mouse over and scrolling it causes rapid flashing between two messy video buffers. This similarly happens to a friend on Windows Vista, so the OpenGL issue is probably easily resolved with a patch.

Another problem I've noticed is that Mono crashes (not just the application) when you open the About form. Mono isn't able to handle the Copyright symbol that it wants to display.

And lastly, very simple compiled games (I used Windows XP SP3 running under VirtualBox to compile) like the game from Tutorial 1 will run under Mono with some small problems: The LimitFrameRate rule does not work (runs at ~2300 fps on my Mac) and keyboard input also does not work.

That said, I think bluemonkmn has done a fine job on the initial porting steps, with the recent switch to OpenGL. If there is anything I can do to continue the progress (as I said, I'm pretty new to OpenGL, and VERY new to C#) I'd like to lend a hand. It's going to take me some time to wrap my head around the project source code and C#.

[durnurd]

Much work has already been done in this field.  I too got the IDE to run under Mono (ununtu) with those changes (I was the first to notice), and have done work to help get sgdk2 games at least compliant with how Mono works.  For a sample, search Youtube for "Technoventure on Ubuntu".  I believe at this point the IDE supports building games that run under Mono and .Net (all you "need" is a small config file).  The frame rate liter didn't work at one point due to using p/invoke on a Windows-specific API that Mono doesn't emulate. Tha has been fixed, I think, by using the System.Diagnostics.Stopwatch class instead.

[bluemonkmn]

D'oh -- did I forget to include the stopwatch implementation in 2.1.2?  It's still using QueryPerformanceCounter .

Where did the stopwatch-based implementation go -- do you have it durnurd?

[Parasyte]

I also noticed a bug with the dropper tool in the graphic editor. It refuses to choose colors from locations that are 0 on either the X or Y coordinates. (Not related to Mono.) Here's a patch!

Code: [Select]

Index: sgdk2/branches/SGDK2IDE2.1/GfxPane.cs
===================================================================
--- sgdk2/branches/SGDK2IDE2.1/GfxPane.cs (revision 157)
+++ sgdk2/branches/SGDK2IDE2.1/GfxPane.cs (working copy)
@@ -320,7 +320,7 @@
                   break;
                case DrawingTool.Dropper:
                   if ((DragStart.X < Image.Width) && (DragStart.Y < Image.Height) &&
-                     (DragStart.X > 0) && (DragStart.Y > 0))
+                     (DragStart.X >= 0) && (DragStart.Y >= 0))
                      ParentEditor.PickColor(Image.GetPixel((int)DragStart.X, (int)DragStart.Y));
                   break;
                case DrawingTool.FloodFill:

In other news, I can compile the IDE in Mono, but the executable explodes under Microsoft's .NET implementation. This is wonderful.

[durnurd]

I don't know if I have the project, but it doesn't seem like it would be too hard to reimplement

[bluemonkmn]

Looks like I have a couple updates to make for 2.1.3.

What does the "explosion" look like when you run a mono-compiled IDE in Microsoft's .NET?

[Parasyte]

It looks something like this. (Screen shot from Virtual Box, though does the same non-virtualized.)

[bluemonkmn]

Looks like it has a problem with image lists.  It might be worth trying to create a basic test application with an image list in Mono and see if it runs in .NET.  If it does, then try using the same image that SGDK2 is using in the Main form.  That should narrow down the problem a little.

[bluemonkmn]

I have made the following corrections in the subversion source tree and they will be included in the 2.1.3 release:

• Fix dropper tool to also function on row 0 and column 0 of graphic editor pane.
• Replace Win32 API implementation of LimitFrameRate with .NET-based code.
• Eliminate a couple compiler warnings on generated projects.
• Hide TestCollisionRect overload that accepts a sprite so that the other overload is exposed in the IDE.

[Parasyte]

Sounds good. I'll pull in the SVN update in a bit. In the meantime, I think MonoDevelop is still far too unstable for practical use on OS X. () The lack of the debugger Add-In for it makes debugging an unnecessary chore.

I'm downloading Visual Studio Express. Perhaps that will help me work on the graphics oddities I've been seeing. I would attach the screen shots of the problem if it meant I didn't have to try to compress them down to <128KB. So I've just uploaded them to my own host. The screen resolution is a bit large, so I'm linking to them without thumbnails. Just so you know!

Please bear with me while I try to explain what it is I'm seeing...

The first and second screens show what the IDE (layer editor) looks like on Windows under VirtualBox. Note the bottom of the OpenGL window flashes between two buffers while it updates; these screens capture both buffers at the time. Screen shot 2 even shows pieces of my OS X desktop background in that buffer "over scan" area.
http://parasyte.kodewerx.org/projects/sgdk2/graphics_bug_1.png
http://parasyte.kodewerx.org/projects/sgdk2/graphics_bug_2.png

The third screen shot is what I see on OS X/Mono. Note that the OpenGL buffer prints pieces of icons from my system in the "over scan" area.

The stars are also rendered strangely; as I scrolled the window, the sides of them get "repeated" where it should have been perfectly transparent. What you are actually seeing around the stars is the previous frame(s) during the scroll. Basically, the transparent background in my star tile is causing OpenGL to not update the area. Ideally, it should be drawing something like a checkerboard (to indicate transparency) or black background.

The third major rendering issue here is the tile selection widget. My simple 32x32 pixel solid blue background tile is drawn HUGE, taking up most of the widget space, and covering up my star tile. The widget is still functional, however: you can see I have the star tile (tile #1) selected.
http://parasyte.kodewerx.org/projects/sgdk2/graphics_bug_3.png

[bluemonkmn]

It looks like some of your issues are standard behavior.  SGDK2 does not erase or draw irrelevant parts of the map.
1. It doesn't draw in undefined areas of the map/layer, which is why you see un-cleared buffer space below the map.
2. It doesn't draw in transparent areas of the map, which is why you see trails behind the stars.

Rather than dumb-down SGDK2 to "clear" areas that are transparent (black is not transparent after all), I figure it's more optimal to not waste time drawing anything there.  After all, the game should be responsible for defining the background, not some hard-coded checkerboard pattern or black background forced upon you by SGDK.  I suppose at design time it might be convenient to have some indicator since performance is not critical at design time, but that would confuse users to see one thing at design time and another at runtime.  At runtime I really don't think it's correct to be clearing the background when they have said it should be transparent.  That is what background layers are for.  SGDK doesn't waste time drawing hard-coded background that the game should be defining (in a non-hard-coded way).

So don't go trying to solve those problems as part of the porting effort.  Those behaviors are the same in Windows.

I'm not sure about the huge tile issue.  Did you try other already-existing projects?  Did they have similarly strange behavior with giant tiles?

[durnurd]

I was going to mention the same thing.  You already have something that denotes a transparent area in the graphic sheet editor, you should use the same thing in the layer editor, so people know that what they're seeing is not a glitch but a transparent area of the map.

[bluemonkmn]

But the graphic sheet editor has no reason to allow the user to define backgrounds, the map does.  The map should not be wasting time drawing something that the user should never see in a properly implemented game.  The game should define the background, not SGDK2.  Maybe SGDK2 should just create a default background layer behind every new map?  But where will it get the image for the background tile?  Create a dummy graphic sheet, frameset and tileset too?

[Vincent]

Hi!

Well, if I may add my own comment about transparency in the layer designer, I think it may get confusing when sprites and tiles you put in the layer leave trails behind.  Its hard to place something in a pixel perfect position this way.  So, I took the habit, whenever I add a new map, to add a fake background layer to cover all transparent areas.  When the map is finished, I destroy the fake background layer.

It would be great if it was an option when creating a new map to add a fake backround layer with a checker design like in Photoshop.  I think, for someone who is used to work with graphics, it is not too confusing.  Of course, this layer must not show up at runtime.

As for creating a dummy graphic sheet, a dummy frameset and a dummy tileset...  Couldn't these things be hidden?  Could SGDK2 fake a background at priority -1 (always behind) whenever you're in a layer designer with all the necessary elements (graphic sheet, frameset, tileset) not visible in the project and not compiled when the project is generated?

Anyway all of this is a "nice to have".  Really not essential.

Thanks!

[durnurd]

The map should not be wasting time drawing something that the user should never see in a properly implemented game.

I'm referring solely to editing the layer at design time.