SGDK2 on Mono (Linux/Mac OS X)

[Parasyte]

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.

For point 1, it should at least clear the entire buffers (to "transparent black"; RGBA 0,0,0,0) as they are created. This is a common part of initialization of any modern graphics code. At least, in my experience it is.

Point 2 is understandable. This I could live with (until I get to the plans editor, which is a real nightmare of usability because of it). But seeing a random jumbled mess in the undefined and non-interactive portions of the layer really irks me. Especially when double buffering is enabled.

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 agree. However...

I suppose at design time it might be convenient to have some indicator since performance is not critical at design time, ...

This is the point I'm trying to make. I am most familiar with image editors such as The GIMP and Photoshop which explicitly define transparent and alpha-blended areas of an image with a hard-coded checkerboard pattern.

... but that would confuse users to see one thing at design time and another at runtime.

Yes, it probably would confuse anyone who hasn't used GIMP/Photoshop/etc to create semi/transparent images for web designs (or anyone familiar with image design and alpha-blending, at all). Surly this group of people is not your target audience. On the other hand, that group uses a similar work-flow (non-WYSIWYG) quite successfully ...

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 will leave the issue here. But consider the suggestion, anyway. It could always look better [at design-time] at the cost of possible user confusion.

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?

I haven't yet found any other OpenTK projects that run. The couple that I have tried were a bit older, and crashed on start-up. But I don't recall which platforms I tried them on.

[bluemonkmn]

If you create a new project based on the sample template, are you not even able to view it in the map editor?

[Parasyte]

Well, the large tile rendering happens to OS X/Mono, and I cannot load (or create) projects/templates on it due to the ReadXML() issue. If that's what's being referred to.

[bluemonkmn]

Okay, I implemented a default background layer for new maps.  It's a little messy, and probably introduces a lot of new bugs (if you try to do anything unexpected with the layer), but it works for the simple cases.  The code is checked in to subversion.  Wanna try?

[Parasyte]

For anyone interested in running/compiling the IDE in Mono, you will have to change the Reflect library to build for runtime version 2.0 (it defaults to version 3.5), and you will also have to apply the following patch. Keep in mind the patch is a rough hack, and I wouldn't like seeing it in the repository.

Code: [Select]

Index: branches/SGDK2IDE2.1/SplashForm.cs
===================================================================
--- branches/SGDK2IDE2.1/SplashForm.cs (revision 157)
+++ branches/SGDK2IDE2.1/SplashForm.cs (working copy)
@@ -104,6 +104,8 @@
 
       protected override void OnLoad(EventArgs e)
       {
+         try
+         {
          BLENDFUNCTION bf;
         
          String strAppDir = Application.ExecutablePath;
@@ -132,6 +134,11 @@
          m_SplashImage = null;
          ReleaseDC(IntPtr.Zero, hdcScreen);
       }
+      catch
+      {
+         Console.WriteLine("GetDC() failed.");
+      }
+      }
 
       protected override CreateParams CreateParams
       {
Index: branches/SGDK2IDE2.1/MainWindow.cs
===================================================================
--- branches/SGDK2IDE2.1/MainWindow.cs (revision 157)
+++ branches/SGDK2IDE2.1/MainWindow.cs (working copy)
@@ -927,7 +927,14 @@
          {
             SGDK2IDE.PushStatus("Loading " + projectFile, true);
             DataSet dsLoad = new DataSet();
+            try
+            {
             dsLoad.ReadXml(projectFile);
+            }
+            catch
+            {
+               Console.WriteLine("dsLoad.ReadXml() failed.");
+            }
             ProjectData.Clear();
             InitializeTree();
             ProjectData.Merge(dsLoad);


bluemonkmn: I pulled in the SVN changes, and the only trouble I'm seeing with your patch is when accepting the default values for creating a new layer, it complains that a layer with that Z-index already exists. And of course, I can clearly see the "Designer Layer" in the list after creating a new Map.

That said, the rendering is much improved with it!

[bluemonkmn]

Yes, the designer background layer is supposed to be visible in the tree.  That way the user can easily see how the background is formed and how to replace it when they're ready to define their own background.  It's just like having your first layer automatically added for you when creating a map (except that it won't be visible at runtime because it gets excluded when the project is compiled).  I figured that would be the best compromise all around: don't add unnecessary overhead, make sure the user has full control over all the layers that are being drawn, but don't let the default behavior make a mess so easily.  Oops, I forgot one -- runtime and design time appearance should be the same.  What do you think?  Is that important?

[bluemonkmn]

I uploaded fixes to:
1. Automatically select the next available Z-Index when adding a new layer.
2. Use .NET 2.0 for Reflect.dll (I think it was just an overlooked default -- didn't need 3.5).

Maybe I should get you doing code review for me

[Parasyte]

Re: Design time and Run time appearance should be the same:

WYSIWYG is certainly a good model for editors. In my own opinion, SGDK2 is an editor which would strongly benefit from it. Beginning users (like me) and advanced users will both get a lot out of it.

And code review is popular in a lot of the open source projects that I follow. I haven't necessarily been a reviewer before, but then again if it's just peer review and you think it will help create an overall better product, I would be glad to help out. You could also encourage others to get involved with peer reviews and such.

Late last night, I got Visual C# Express 2008 installed on my VirtualBox/Windows XP, and compiled the latest SVN changes. The project wouldn't even build for me with the Reflect.dll version 3.5 configuration. Your newest changes with the layering are looking great on Windows, too. The Plans editor (as detailed in the first tutorial) is much much easier to work with, now. The main problem with the plans editor on a totally empty/clear overlay layer was that drawing the semi-transparent blue box and white dashed arrow over "nothing" made it difficult to see what you were really doing (or supposed to be doing, for that matter). With the new background pattern layer, all that is totally cleared up, and it even looks like there was never a problem to begin with! Haha

I was planning to spend part of today looking at that ReadXml() problem. Maybe writing a minimal test case app to see if it's reproducible in Mono, and giving it to Ximian. There might not be an effective work-around, but if there is, I'll definitely write a patch for it. And I need to start using the bug tracker on sf.net to help keep track of some of the problems with the port. There's a lot of little small things that just aren't right, but then there's also this ReadXml() thing which is pretty much a show-stopper for the whole project.

[bluemonkmn]

So do you think instead of having that background layer only there at design time, it would be good to compile it to be visible at runtime too?  In order to do that, I would probably want to make the checkered pattern into a regular graphic sheet, frameset and tileset.

Oh, and if you see any irregularities in the code (like Reflect.dll requiring .NET 3.5), do point them out.  The code review doesn't have to be entirely formal.

[durnurd]

WYSIWYG is grand and all, but it need not be exact.  Having an exact WYSIWYG editor would be very unhelpful in many cases I can think of.  If, for example, you're editing a webpage, and you want to resize a DIV, show resize controls around the box.  Makes sense!  But don't show them at runtime.  If you're editing an image in Photoshop, and you want to determine where the image is transparent, show a checkered background, but don't export that background when you save the image.  Makes sense!  If you're placing tiles in a layer, and you want to know which tiles in this layer are transparent, show a checkered background, but don't export that background when you save the layer.  Makes sense!

[Parasyte]

durnurd, yeah. I'm a fan of the GIMP/Photoshop method of editing with transparencies.

I wasn't aware that the pattern backgrounds created in current SVN weren't exported as part of the final product. The layer shown in the tree gave me the idea that it was. Anyway, as far as the editing aspect goes, the current implementation is a nice improvement already. It probably wouldn't make much sense allowing users to create games utilizing the pattern as an actual background. The alternatives are showing the same "undefined" areas at runtime, or just solid black.

[Parasyte]

I've added some bug reports to the tracker on sf.net. These are mostly there for me to keep track of porting progress, but could be useful info for others as well.

On a different note, what does everyone think about replacing FMod with OpenTK's implementation of OpenAL? That will allow mixing uncompressed PCM audio without any additional libraries. Compressed audio could be handled by (for example) libvorbis. There's a "vorbis dot net" project on SF, but it hasn't been updated in years. As for MP3, meh... Vorbis is comparatively unknown, but has been shown to produce higher quality audio reproduction. There's also the lack of MOD (and other tracker formats) support. I have yet to find a truly free "replacement" for FMod.

[SmartBoy16]

i

On a different note, what does everyone think about replacing FMod with OpenTK's implementation of OpenAL? That will allow mixing uncompressed PCM audio without any additional libraries. Compressed audio could be handled by (for example) libvorbis. There's a "vorbis dot net" project on SF, but it hasn't been updated in years. As for MP3, meh... Vorbis is comparatively unknown, but has been shown to produce higher quality audio reproduction. There's also the lack of MOD (and other tracker formats) support. I have yet to find a truly free "replacement" for FMod.

I agree with this. having a choice of sound devices isn't a bad idea.

[bluemonkmn]

Why are you trying to replace FMod?

[Jam0864]

Perhaps if you find one capable of changing pitch in real time and positional effects it would be worthwhile, but otherwise fmod does the job.