Scrolling Game Development Kit Forum

The FMOD license says FMOD is free if the product is free.  Are you concerned that people may want to be able to use SGDK2 to create commercial games and will then have to pay for FMOD?  I wonder if it would fly to license FMOD for SGDK2 itself as a hobbyist/shareware author ($100) and then all the games created with it could include it.  Probably not, but maybe .

Well, I imagine there is a probability. I've seen stranger things. If game developers using SGDK2 wanted to sell their creations for $5 (or less) they should probably not be hindered by the audio library license. Then again, I suppose nothing is stopping them from just not using FMOD.

The reason I'm not thrilled with FMod is the licensing.

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.

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.

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!

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.

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

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#.