Linux

[boogerlad]

hey. I just had an idea. There is a linux c# compiler that has links to net 1-3, named Mono, so wouldn't you be able to use that, get sgdk2's sourcecode, and compile it there to make a native linux version. Also, wouldn't you be able to compile the actual game? doesn't sgdk2 output all the sourcecode to a file that's all c#? assuming you remove all directX dependencies from sgdk2 and games created from it.

[Jam0864]

SGDK2 is being converted to opengl right now. And Durnurd made the sample project run on linux. 

OpenGL Conversion:
http://gamedev.comdel.net/index.php?topic=1151.msg7197#new

Running on Linux:
http://gamedev.comdel.net/index.php?topic=1236.45

Obviously it's not quite done yet, but it seems linux support will be here in the future.

[durnurd]

Right now games created using SGDK2.1 can run under Mono with a necessary removal of a few lines of code that don't work under Linux (native Windows DLL calls to interface with joysticks) and a recompilation, the linux versions of OpenTK and FModEX, and two configuration files to tell the game executable where to find FModEX and to tell OpenTK where to find OpenGL.

The IDE can run under Mono, but Mono doesn't yet support the way SGDK2.1 reads .sgdk2 files, and so it cannot actually make, load, or save games.  If SGDK2.1's handling of XML data were regressed back to the way SGDK2 did it, it might work.

[boogerlad]

SGDK2 is being converted to opengl right now. And Durnurd made the sample project run on linux. 

OpenGL Conversion:
http://gamedev.comdel.net/index.php?topic=1151.msg7197#new

Running on Linux:
http://gamedev.comdel.net/index.php?topic=1236.45

Obviously it's not quite done yet, but it seems linux support will be here in the future.

wasn't the sample project ran by Durnurd on Wine? what i mean is if i can use Mono to compile the games in c# code to a native .deb or whatever for linux. I know of the opengl port though. Btw, is there anyway to program video files in for cutscenes?

[durnurd]

wine doesn't support .NET.  Everything was running using mono and native Linux libraries.   Mono is required to run the executable just as the .NET framework would be required on a Windows platform.

[boogerlad]

wine doesn't support .NET.  Everything was running using mono and native Linux libraries.   Mono is required to run the executable just as the .NET framework would be required on a Windows platform.

Thanks for clearing it up. i thought it was just wine lol.

[boogerlad]

btw, when you compile your game, do you still need sgdk2? or is it standalone? as in, if i make a game at my house, compile and burn it to a cd, bring it to my friends house and use his computer without sgdk2 and play it. Would it work, or would i need sgdk2?

[Tanja]

it would work, because you compile the files into an exe.

[bluemonkmn]

The other computer would have to have the right version of the .NET Framework installed, though, and DirectX if you're using SGDK 2.0.

[boogerlad]

in general, how memory hungry are games made from sgdk2? is it as memory intensive as games made by Game Maker? i hope not, because games there are MEMORY HOGS! will sgdk2.1 still use .net framework?

[durnurd]

I don't think that any fair amount of testing has been done in the ways of memory usage.  One thing to mention however is that the games are compiled C# .NET executables (answering your second question: yes)  which means that the memory is mostly managed, which could lead to some slow-down, along with the fact that the programs are compiled at runtime.  These facts have been overlooked since the slowdown isn't really noticeable on current hardware, and generally create a minute difference as compared to the graphics rendering processing and framerate limiting.

I haven't heard of any problems with Game Maker's memory issues.  Are the executable files large?  Or do they run slowly?  Or is it just that they have so much data in memory at once?  SGDK2 can easily hold large maps in a small amount of memory, due to the ability to store a tile in as little as one byte, and sprites require very few values as well (unless you add your own fields).  The graphics portion of the game is all handled in the graphics card memory, so that's out of the scope of examination.

[bluemonkmn]

I can't answer conclusively, but I have a feeling that compiled SGDK2 projects are lighter weight than compiled Game Maker projects because compiled SGDK2 games are merely compiled .NET executables, and .NET has been reasonably well optimized on the Windows platform at least.  So the games don't require any runtime the way version 1.x projects and Game Maker projects do (Game Maker has a "runner" program as I understand it from the Wikipedia article).  If a game has a runtime component like that, it implies that it's interpreted rather than actually compiled.  Compiled .NET programs, on the other hand, while they do rely on the "Common Language Runtime" (CLR) are compiled to native code.  Compiled .NET code is represented in an intermediate language (Common Intermediate Language), which would be similar to an interpreted language/project, however, rather than interpreting the code at runtime, as SGDK 1.x (and presumably Game Maker) does, the program is compiled to native code (by the CLR) before running it, which highly optimizes the runtime execution of the program as compared with interpreted code.  Furthermore, this allows processor-specific optimizations because the program is compiled on the system where it will run instead of by a developer on a separate system whose configuration may not match the target system (though I don't expect much is gained by that kind of optimization these days since most environments are 32-bit and I can't think of many other processor-specific optimizations).

To read more about the CLR, see http://en.wikipedia.org/wiki/Common_Language_Runtime

There are many other benefits of relying on the CLR and "managed code", and one more worth mentioning is stability.  Compiled .NET code is not nearly so prone to memory errors the way "un-managed" code is.  So, although errors may occur in a .NET application, they are not usually related to memory management the way errors in programs written in older languages are.  Practically eliminating a whole category of errors means significantly more stable applications in general.

Edit: I just looked at the Game Maker 7.0 documentation and confirmed that it is interpreted.  In the section on speed considerations is the following statement implying that Game Maker projects are interpreted:
"Interpretation of code is reasonably fast, but it is interpreted."
That doesn't speak much about memory use, but is still an important consideration.

[boogerlad]

so is it safe to assume that sgdk2.1 work on linux? when you compile stuff in mono, does it spit out the inputed c# to a .deb file for debian based linux distrubutions, etc?

[bluemonkmn]

Not yet.  Version 2.1 has not been released, and most of the development has been on Windows.  But it's pretty close.  It might work on Linux.  But the intention of the initial 2.1 release was just to get one step closer by converting to OpenGL instead of DirectX.  The goal was not necessarily to make it work on Linux in the same release.  I've been surprised, though, by some of the tests performed by Durnurd.  He has gotten SGDK2.1 code to work on Linux to a limited extent.  So it may be closer than I realized.

Edit:  I'm not familiar with .deb files, but I think compiled SGDK2 projects only require the .NET (mono) framework and OpenGL to be installed.  Then they only need to deliver the game executable and fmod and OpenTK (OpenGL wrapper) libraries.  Does a .deb file somehow keep information about these dependencies so that installing the game would automatically ensure the dependencies were installed too?

[durnurd]

Compiling in Mono is essentially the same as compiling using Microsoft's distributed compiler.  There should be no difference.  It runs using the Mono framework on Linux.  It's not "native" in the same sense that compiled .NET assemblies are not "native" to Windows, but at runtime they are converted to native code.