Announcement

Collapse
No announcement yet.

Miguel de Icaza Calls For More Mono, C# Games

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BlackStar
    replied
    Hey, an actual language discussion without a flamewar! Who would expect that on Phoronix?

    Well that's your subjective opinion and obviously I won't argue against that. I find myself fully comfortable with a combination of C/C++ and Python and that too is a subjective opinion, I do like to peek outside my comfort zone from time to time though as I think it's fun and out of the last four or so languages I've tried (OCaml, C#, Go and D) I'd say Go was the only one I'd see myself spending real time learning mainly due to it's concurrency properties which I find interesting and to a lesser extent other things in the language syntax/command repertoire which clicks with me. That said I've been holding off trying something 'serious' with it until the first stable release is out.
    C++ with Python is pretty awesome, indeed.

    Haven't tried Go yet, but I've read its samples and I wasn't too impressed (like I was with Ocaml and its F# offspring, for instance). What is its "killer" feature that would convert people?

    Code:
    C/C++
    
    float data[] = {1,2,3};
    glBufferData(GL_ARRAY_BUFFER, data, GL_STATIC_DRAW);
    glCreateShader(GL_FRAGMENT_SHADER);
    glBegin(GL_TRIANGLES);
    glVertex(0.0f, 0.0f, 0.0f);
    
    Go
    
    var data = [...]float32 {1,2,3}
    gl.BufferData(gl.ARRAY_BUFFER, gl.STATIC_DRAW)
    gl.CreateShader(gl.FRAGMENT_SHADER)
    gl.Begin(gl.TRIANGLES)
    gl.Vertex(0.0, 0.0, 0.0)
    Again this is all a matter of taste and likely depends on what you are used too, like the aforementioned Java example will likely look great for someone who is very used to programming in that language.
    There's one specific problem in this code (both C and Go): lack of error checking by the compiler.

    Code:
    glBufferData(GL_ARRAY_BUFFER, data, GL_STATIC_DRAW);
    glBufferData(GL_FRAGMENT_SHADER, data, GL_STATIC_DRAW);
    The compiler will happily accept both versions and the error will go unnoticed unless you call glGetError() - which most people don't do, since it kills performance.

    That's not the case in the C# version (OpenTK):
    Code:
    GL.BufferData(BufferTarget.ArrayBuffer, data, BufferUsageHint.StaticDraw);
    GL.BufferData(ShaderType.FragmentShader, data, BufferUsageHint.StaticDraw); // compiler error, cannot convert ShaderType to BufferTarget implicitly
    This is actually caused by design limitations of C and C++ in regards to enums (enums are implicitly convertable to numbers and they litter the parent namespace - so noone uses them).

    A proper C++ version would look like this:
    Code:
    GL::BufferData(BufferTarget::ArrayBuffer, data, BufferUsageHint::StaticDraw);
    GL::BufferData(ShaderType::FragmentShader, data, BufferUsageHint::StaticDraw); // compiler error
    I have tried to do just this in glplusplus, but unfortunately it's impossible without C++11 strong enums (which instantly throw portability out the window) or a runtime performance penalty.

    This is actually a case where C# is strictly superior to C++ both in performance and functionality. OpenGL code is a joy to ride in C# (just try it!), which is kind of important for game programming.

    Leave a comment:


  • XorEaxEax
    replied
    Sorry for the late reply, I was suckerpunched by the flu (I was soo close to going through an entire winter without one and then bam!)

    Originally posted by BlackStar View Post
    They are great solutions, nothing against them. C# is yet another great solution.
    All solutions have their drawbacks, native code has it's drawbacks, managed code has it's drawbacks, the pro's and con's of the different languages often make them particularly suited for different aspects of computing, however there are also large areas of computing where their pro's and con's have little impact and in those areas it's mainly a matter of preference (as in the language(s) you are comfortable with).

    Originally posted by BlackStar View Post
    In the sense, why would you ever learn any language other than C++?
    You could certainly get by with just C++ (and some assembly) for where you need the performance aswell as for non performance dependant tasks. However, the latter is an area where scripting has always had a strong presence, often as glue code managing data flow between fast native code components. This is primarily how I've used Python at work.

    Originally posted by BlackStar View Post
    Every language has its advantages. I find that C# has a great combination of code expressiveness, performance, supporting tools and documentation. Other languages have these features in different combinations but, as a whole, I find C# ranks among the best.
    Well that's your subjective opinion and obviously I won't argue against that. I find myself fully comfortable with a combination of C/C++ and Python and that too is a subjective opinion, I do like to peek outside my comfort zone from time to time though as I think it's fun and out of the last four or so languages I've tried (OCaml, C#, Go and D) I'd say Go was the only one I'd see myself spending real time learning mainly due to it's concurrency properties which I find interesting and to a lesser extent other things in the language syntax/command repertoire which clicks with me. That said I've been holding off trying something 'serious' with it until the first stable release is out.

    Originally posted by BlackStar View Post
    And not only for XNA. C# has much cleaner OpenGL bindings than Java or even Python.

    Code:
    // C# (OpenTK)
    var data = new float[] { 1, 2, 3 };
    GL.BufferData(BufferTarget.ArrayBuffer, data, BufferUsageHint.StaticDraw);
    GL.CreateShader(ShaderType.FragmentShader);
    GL.Begin(BeginMode.Triangles);
    GL.Vertex(0.0f, 0.0f, 0.0f);
    I'll pretty much chalk this up to preference, granted the GL version prefix in Java is pretty ugly to me aswell but for me personally I find both these slightly verbose for my own taste. Here is how they would look in C/C++ and (I assume given my very limited testing) Go:

    Code:
    C/C++
    
    float data[] = {1,2,3};
    glBufferData(GL_ARRAY_BUFFER, data, GL_STATIC_DRAW);
    glCreateShader(GL_FRAGMENT_SHADER);
    glBegin(GL_TRIANGLES);
    glVertex(0.0f, 0.0f, 0.0f);
    
    Go
    
    var data = [...]float32 {1,2,3}
    gl.BufferData(gl.ARRAY_BUFFER, gl.STATIC_DRAW)
    gl.CreateShader(gl.FRAGMENT_SHADER)
    gl.Begin(gl.TRIANGLES)
    gl.Vertex(0.0, 0.0, 0.0)
    Again this is all a matter of taste and likely depends on what you are used too, like the aforementioned Java example will likely look great for someone who is very used to programming in that language.

    Originally posted by BlackStar View Post
    The problem is that you can't use very valuable features of C99 and C++11 because the compiler support simply isn't there.
    I'd say the most sought after and thus used parts of the C99 standard are supported by GCC (and many of these have been available long before C99 standarized as compiler extensions) and given that GCC is available on just about every platform there is out there then yes, you can use these features. Clang/LLVM is also continously increasing their C99 support, Intel Compiler aswell, in fact the only compiler that I can think of which isn't is Microsoft's Visual Studio and this is likely due to them focusing 100% on C++ with their upcoming C++11 support, along with their 'going native' push for Visual Studio 2012. And there's alot of software out there which requires atleast rudimentary C99 support in order to compile, like x264.

    Originally posted by BlackStar View Post
    The journey is the destination, my friend.
    Indeed my friend!

    Leave a comment:


  • ciplogic
    replied
    Originally posted by Togga View Post
    Stack-space is in kilobytes range which includes all recursive subroutine calls. Dont use strings? What you're saing is that if you have a GC, you do not know what your doing anyway, so just dont use memory at all...
    The reason to not use strings, is practical one. They are slow most of the time, they give a lot of pressure on memory allocator (either is it a GC or not), like in this C++ tutorial. STL string operator += is really very slow and if the code is not written well, would simply make your game to freeze. It also hides heap allocations and as strings can be of multiple lengths, can lead to memory fragmentation, the worst of C++ allocator world.
    Yet is also slow in .Net and for fast build of strings is recommeded to use a StringBuilder, but as is taken in the context of a beginner, maybe it would not use it, and the game would work too slow.
    This is not about to say: never display a string with the score, but to be seen as a performance issue on some devices/platforms.
    The rest I think still remains valid, isn't so?
    You can iterate over strings (that mat be preallocated), but try to not do math with them, a lot of conversions, that can be really the bottleneck in real world applications (and in context of games, could be really bad). And the idea to use stack is that heap is slower, and it expands dynamically in .Net/Mono world to some megabytes (depends in platform still), so you can make fairly good computations with just stack world.

    Leave a comment:


  • Togga
    replied
    Originally posted by ciplogic View Post
    Would you want to learn C# for making a game? (if the company pays the licenses) than C++. C# is basically free on three platforms, if you take better tools, and around of the price of the IDE in Windows (the price of Visual Studio), you will get the Mono tools for iOS and Android.
    C++ is painful to use it with new features (OpenMP for example is not supported on Android, like described here), the Visual Studio is using Microsoft compiler, the Linux and Android GCC, OS X and iOS would use CLang/LLVM, every with small incompatibilities.
    You have still Lazarus (said in the previous post), if you like Pascal, and you don't want a GC based language. But you cannot use for scripting, but all the rest are fine.
    Originally posted by ciplogic View Post
    allocate most objects on stack
    Originally posted by ciplogic View Post
    I am almost certain you will not face breaks on GC (don't use strings, are unlikely needed anywhere in a game).
    Stack-space is in kilobytes range which includes all recursive subroutine calls. Dont use strings? What you're saing is that if you have a GC, you do not know what your doing anyway, so just dont use memory at all...


    Originally posted by ciplogic View Post
    If you have 5 platforms to support: Windows, Linux, OS X, iOS and Android (to not say WP7, that you have no choice), most likely the answer would be, it makes more sense to use C#
    This sounds good in theory, the VM will take care of platform details and you dont have to worry about anything. But in practice, it's really the other way around.
    1. You have to make sure all libraries you're using in .NET is implemented and fully functional
    2. If you must use anything that is not part of .NET (new HW,new OS features,...) your smoked and has to do special solutions on each platform
    3. For performance problems, you do not have just one setup to work around, you will have different problems on different platforms, just with .NET alone

    THe rule I learned is, the more baggage you drag with you, the more possible problems you face and .NET is the biggest black sheep of them all out there.

    If you really want to be multi-platform, use C and as many standard components as you can. Every platform I know have a well tested and fully functional C library. Of course, on platforms where some components are not available you have to implement additional support anyway. WP7 should be the last thing to implement for since WP8 is going to target C++/js/html5 as their prime platform anyway and .NET will then fade away. The market for WP7 is pretty marginal to begin with and is most likely only people whos only interested in mail, facebook,etc and not 3rd partt applications (if they were they would have gone for iOS or Android).

    Leave a comment:


  • ciplogic
    replied
    Originally posted by XorEaxEax View Post
    Well, I never said (did I?) that C# can't be used for games, my point was that if you are a C# programmer then using it to write games makes perfect sense, what I disagreed on is the idea that C# has some properties making it particularly appropriate for game writing as opposed to many other languages. Again, the only reason I see for 'choosing' C# for game programming if you are not already fluent in the language and love coding in it is if you target the XNA platform as there are IMO no inherent game programming advantages in the C# language itself.
    (...)
    No but in order to ensure it you need to code around the GC, thus making it a burden rather than something which supposedly allows you to ignore memory management altogether.
    (...)
    Sure but in unmanaged code you can fully control the allocation/deallocation of objects during game loop and spread them out so as not to impact updates per frame, you don't have this control over the GC which is why you need to code around it so that it won't slow your game down by triggering unwanted garbage collecting sweeps or compactions.

    Of course then there's languages directly targeting indie game development which is much easier still when targeting multiple platforms, and programming with games in mind. Monkey springs to mind as something new I came across which allows you to write code in a language tailored for game programming and then have that code translated to C++, Java, C#, Actionscript, Javascript depending on your needs.

    Again I fail to see what would make C# a language which you'd want to _learn_ in order to write games as opposed to tons of other languages, again unless you are specifically targeting the XNA platform.
    I'm fluent in C++ (in fact I think almost everyone in this forum knows a form of C/C++), and I see C++ particularly good for a lot of games. And Miguel's point was that when used as defining logic (that is most of the times defined in scripting), you should write in Mono/C# that makes a lot of sense, both performance wise (at least compared with any other mainstream scripting in games, that is basically a CompanyTmScript or Lua) and as quality of language.
    As I think everyone that uses both C# and C++, C# is nicer to work with, is more forgiving of double deletion pointers and circular references and use boost::smart_ptr templates.
    If compared with Lua, it gets even better, as Lua is slower performer (at least in interpretation form), have no big advantage excluding a very small runtime, and it offers the same memory management, using a GC, like is described here: "Lua does automatic memory management. A program only creates objects (tables, functions, etc.); there is no function to delete objects. Lua automatically deletes objects that become garbage, using garbage collection. "
    Both Mono (SGen) and Microsoft's .Net allow to set memory pressure limits so you can have predictible GC. From .Net 3.5 SP1, you can gen notifications on Full GC (like described here), so you can do something just before "unexpected" breaks may occur.
    MovEaxZero, I noticed that you are really strict on break times that GC would do, why you don't take in account that once when you allocate with malloc/new, the OS may swap on disk, and this would be in times similar with full GC. If the disk was in standby, it can take even seconds (the games rarely use disk drives, but if the OS would find that would have to swap, and your game would freeze for 0.5 seconds everyone would notice). What an user would do!? Maybe would delete the game because of this? I don't think so.
    Instead of thinking how to handle full GC, simply avoid this! Is easy: allocate most objects on stack, the heap allocated objects, make them small and with few dependencies, so are entering in first generation GC, to not fill the old generation GC, and affect full GC time, if ever is occurring. If you need to allocate a huge block of objects, preallocate them in object pools. Do you want to avoid the full GC? When an user enters in menu, just before, do a full GC, an user will notice a small lag in loading the menu, but it would wait anyway, and will have a "Loading..." text, so he can expect for this.
    What I say, are common sense advices, and following them, at least in the game loop logic kind of way, I am almost certain you will not face breaks on GC (don't use strings, are unlikely needed anywhere in a game).
    Would you want to learn C# for making a game? If you have 5 platforms to support: Windows, Linux, OS X, iOS and Android (to not say WP7, that you have no choice), most likely the answer would be, it makes more sense to use C# (if the company pays the licenses) than C++. C# is basically free on three platforms, if you take better tools, and around of the price of the IDE in Windows (the price of Visual Studio), you will get the Mono tools for iOS and Android.
    C++ is painful to use it with new features (OpenMP for example is not supported on Android, like described here), the Visual Studio is using Microsoft compiler, the Linux and Android GCC, OS X and iOS would use CLang/LLVM, every with small incompatibilities.
    You have still Lazarus (said in the previous post), if you like Pascal, and you don't want a GC based language. But you cannot use for scripting, but all the rest are fine.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by XorEaxEax View Post
    Sure, but if you are to offshore everything performance-bound to native code libraries then there's a ton of other 'glue' languages you could use just as well as C#, which has just as much and likely more platform support and are easier to develop in. I've personally played around with both l?ve (lua) and pygame (python) and find them to be great such solutions, particularly for prototyping stuff.
    They are great solutions, nothing against them. C# is yet another great solution.

    Of course then there's languages directly targeting indie game development which is much easier still when targeting multiple platforms, and programming with games in mind. Monkey springs to mind as something new I came across which allows you to write code in a language tailored for game programming and then have that code translated to C++, Java, C#, Actionscript, Javascript depending on your needs.

    Again I fail to see what would make C# a language which you'd want to _learn_ in order to write games as opposed to tons of other languages, again unless you are specifically targeting the XNA platform.
    In the sense, why would you ever learn any language other than C++?

    Every language has its advantages. I find that C# has a great combination of code expressiveness, performance, supporting tools and documentation. Other languages have these features in different combinations but, as a whole, I find C# ranks among the best.

    And not only for XNA. C# has much cleaner OpenGL bindings than Java or even Python.

    Code:
    // Java (LWJGL)
    float[] dataArray = { 1, 2, 3 };
    FloatBuffer data = ByteBuffer.allocateDirect(vertexBufferDataArray.length * 4).asFloatBuffer();
    GL15.glBufferData(GL15.GL_ARRAY_BUFFER, data, GL15.GL_STATIC_DRAW);
    GL20.glCreateShader(GL20.GL_FRAGMENT_SHADER);
    GL11.glBegin(GL11.GL_TRIANGLES);
    GL11.glVertex3f(0.0f, 0.0f, 0.0f);
    
    // C# (OpenTK)
    var data = new float[] { 1, 2, 3 };
    GL.BufferData(BufferTarget.ArrayBuffer, data, BufferUsageHint.StaticDraw);
    GL.CreateShader(ShaderType.FragmentShader);
    GL.Begin(BeginMode.Triangles);
    GL.Vertex(0.0f, 0.0f, 0.0f);
    I don't know about you, but I find the second has significantly less visual noise and is much easier to use (with strongly-typed parameters, that get autocompleted by the IDE). The Java code is simply painful, in comparison: it repeats "gl" and "GL" up to six times in a single line, it destroys autocomplete ("GL11." will bring up a list ~800 symbols), it doesn't offer any semblance of type safety (you can pass GL_TRIANGLES to glCreatShader() and the compiler won't object).

    I simply don't know how people put up with this madness in 2012. I've actually written (and released) my own C++ header to take care of the problem and I'm now working on Java and Python bindings.

    Well, granted I'm only compiling code between Linux and Windows at work but since we use GCC on both architectures it's not a problem, and it's not as if you can't specify a targeted standard C89/C99/C++98/C++/C++11 -pedantic etc which you know is supported across the compilers you want to use. I don't see that as a general problem at all, which is further backed up by all the C/C++ code flowing between platforms like Linux/Windows/OSX etc.
    The problem is that you can't use very valuable features of C99 and C++11 because the compiler support simply isn't there. Contrast with C#/Mono that has already implemented the C# 5.0 feature-set (async, etc) *months* before the official 5.0 release.

    I guess we have to agree to disagree, as it seems this discussion is going nowhere (again?). We'll simply have to see what happens.
    The journey is the destination, my friend.

    Leave a comment:


  • XorEaxEax
    replied
    Originally posted by BlackStar View Post
    @XorEaxEax, this is a recurring discussion happening roughly every 6 months.
    Ahh, so chances are there's a reason I'm starting to feel like Bill Murray in Groundhog day, I suppose you are too

    Originally posted by BlackStar View Post
    We don't really disagree in essence, C++ is a faster language than C#. What we disagree on is the conclusion: C++ is faster than C#, so C# can't be used for games.
    Well, I never said (did I?) that C# can't be used for games, my point was that if you are a C# programmer then using it to write games makes perfect sense, what I disagreed on is the idea that C# has some properties making it particularly appropriate for game writing as opposed to many other languages. Again, the only reason I see for 'choosing' C# for game programming if you are not already fluent in the language and love coding in it is if you target the XNA platform as there are IMO no inherent game programming advantages in the C# language itself.

    Originally posted by BlackStar View Post
    1. the existence of the GC does not preclude smooth performance.
    No but in order to ensure it you need to code around the GC, thus making it a burden rather than something which supposedly allows you to ignore memory management altogether.

    Originally posted by BlackStar View Post
    Essential memory management optimizations apply equally well to C# as to C++ (i.e. stack allocations, memory pools). Memory mismanagement will cause problems in both cases (i.e. frequent new/delete objects during the game loop).
    Sure but in unmanaged code you can fully control the allocation/deallocation of objects during game loop and spread them out so as not to impact updates per frame, you don't have this control over the GC which is why you need to code around it so that it won't slow your game down by triggering unwanted garbage collecting sweeps or compactions.

    Originally posted by BlackStar View Post
    3. Indie games are usually GPU-limited not CPU-limited. By far the most CPU-intensive part is physics, and you can always use a C++ library for that. No reason to implement your whole game in C++!
    Sure, but if you are to offshore everything performance-bound to native code libraries then there's a ton of other 'glue' languages you could use just as well as C#, which has just as much and likely more platform support and are easier to develop in. I've personally played around with both l?ve (lua) and pygame (python) and find them to be great such solutions, particularly for prototyping stuff.

    Of course then there's languages directly targeting indie game development which is much easier still when targeting multiple platforms, and programming with games in mind. Monkey springs to mind as something new I came across which allows you to write code in a language tailored for game programming and then have that code translated to C++, Java, C#, Actionscript, Javascript depending on your needs.

    Again I fail to see what would make C# a language which you'd want to _learn_ in order to write games as opposed to tons of other languages, again unless you are specifically targeting the XNA platform.

    Originally posted by BlackStar View Post
    And a final point I haven't raised till now:
    4. Recompiling C# code on a different platform is much easier than porting C++ code. Anyone who has had to port between Linux/GCC, VisualC and Mac (either compiler) will readily atest to this. The more compilers you add and the more features you use, the worse the situation becomes (use C++11 and you are SOL). C# is a walk in the park in comparison, which is a pretty nice for cross-platform games.
    Well, granted I'm only compiling code between Linux and Windows at work but since we use GCC on both architectures it's not a problem, and it's not as if you can't specify a targeted standard C89/C99/C++98/C++/C++11 -pedantic etc which you know is supported across the compilers you want to use. I don't see that as a general problem at all, which is further backed up by all the C/C++ code flowing between platforms like Linux/Windows/OSX etc.

    I guess we have to agree to disagree, as it seems this discussion is going nowhere (again?). We'll simply have to see what happens.

    Leave a comment:


  • ciplogic
    replied
    Originally posted by MistaED View Post
    Not to burst anyone's ideological open-source bubbles here but using C# or Vala (if you use the mono for C# or glib for Vala implementations) means LGPL in your codebase which is usually a non-starter due to these platforms not supporting dynamic linking only static linking so you'd have to source out exceptions for when you port to iOS or embedded game consoles as most game code is self-contained and are better suited for BSD/MIT/ZLIB style licenses. You need to purchase monotouch for a commercial license, you can't just embed the mono stack into your app yourself statically sadly without falling into the LGPL for your other parts of the codebase.

    I'd like to be proven wrong (can I use Vala when compiled in posix mode only without falling under the LGPL? That would rock!), but this is the reason why Ogre and Bullet (hell even SDL 1.3 moved to ZLIB) are under these more liberal licenses, it's more practical for when you want to port your game to consoles/embedded platforms. I'm sticking to my own C++ codebase with SDL and Lua for light scripting C++ game objects like everyone else. WinMo 8 I'm guessing will have P/Invoke so you'd just treat it like Android, JNI + NDK, static compiled C/C++ still wins.

    -MistaED
    I think that no one disputed that C# is not the fastest, the issue I think is simply: fast-enough. When Android 2.2 appeared with a JIT, a LOT of indie games did not bother to use JNI. The presentation of how JIT was made (a Google IO talk: http://www.youtube.com/watch?v=Ls0tM-c4Vfo ) explains why: their JIT was a bit simplistic, but good enough. They also explained how the code grow is more important for limited memory devices, and that the Dalvik bytecode is at least 6x smaller in memory than the full ARM code that it replaces.
    I think we all agree that C++ is the fastest, for maturity and the capability of C++ to perform more optimizations, including a better register allocator (which is expensive to do it on runtime by JITs, that's why LLVM is "too slow" for JIT purposes), loop unrolling (which is great on paper, but JITs that do it, they do it after it found that is worthwhile (I mean on Java -server) as it expands the code and will mean even more register pressure sometimes, and will increase also code cache pressure).
    But I am not sure about you, but most games I am used to play on my Android device (most of them are casual), they could run just fine with Dalvik JIT, and at least on that specific device, the limitation seem to be the "GPU" (I put between quotes as is a bit underpowered). If supposedly the game I play renders like 60% of game time waiting for GPU, my best optimization work could increase let's say from 20 frames, by improving the CPU code like: 60% GPU + 40% Dalvik JIT to 60% GPU + 20% C++ will be basically like 24 frames per second. Visible, and great to have altogether. But of course, if the person profiles the code, and write just a critical code in C++, will be more or less that at least it will gain like 2 frames from those micro-optimizations and the code will be 22 frames (90% Java/Dalvik + 10% C++ to hot code) vs 24 frames per second (all C++).
    In most cases Mono would perform closer to C++ code (even faster with LLVM backend in mathematical code), in fact so close (my experience is around 10-20% in all integer based code, and maybe 50-60% in FPU based code - all without LLVM backend), that doesn't even make sense to talk of 100% theoretical speedup, that sometimes may not happen, simply because the generated image it grows too big for real life, and will not fit in CPU cache, that is a bigger performance killer (orders of magnitude is a cache miss, than some instruction arrangement that C++ provide).
    What I think that for most people think about Mono, they think like a slower Java. And Java was used to be slow, so who would want a slow, weak Java, Microsoft-backed in Linux. This is an urban myth, because sometimes Mono is faster than Java, at least because can use structs (to do stack allocations instead of heap allocations), it have a free AOT (that makes the application to run as a fully statical compiled code), so big applications start faster if they are written in Mono than in Java.
    At the end I'm not a Mono/.Net apologist, I think that people got wrong values by taking myths and others opinions and are not realistic about what to expect. In fact there was always a project close to Mono, that have a visual designer, that was pre-compiled and no-one here talks. It supports Android, iOS, Windows, Linux. For the ones that did not already have the answer, is FreePascal/Lazarus. It is a some-what clone of old Borland Delphi. No one brags about its advanced code generator (which is just marginally faster than Mono's but slower than GCC), or about how Embarcadero would attack Lazarus and kill it for a patent war.
    Also is amazingly easy to simply run a program, see if it fits your needs and if it does, use it, if it doesn't, skip it. I am using RubyMine (a Java based IDE) for Ruby for most small tasks of processing things (I don't use Rails). And I use JRuby as the VM. I never made a comparison how slow is Java in and IDE, because after is warmed up (which means like let's say 5-10 seconds of CPU time), everything really works smooth. JRuby/and Ruby too are somewhat slow, certainly slower than Mono, but amazingly good enough.

    Leave a comment:


  • MistaED
    replied
    Not to burst anyone's ideological open-source bubbles here but using C# or Vala (if you use the mono for C# or glib for Vala implementations) means LGPL in your codebase which is usually a non-starter due to these platforms not supporting dynamic linking only static linking so you'd have to source out exceptions for when you port to iOS or embedded game consoles as most game code is self-contained and are better suited for BSD/MIT/ZLIB style licenses. You need to purchase monotouch for a commercial license, you can't just embed the mono stack into your app yourself statically sadly without falling into the LGPL for your other parts of the codebase.

    I'd like to be proven wrong (can I use Vala when compiled in posix mode only without falling under the LGPL? That would rock!), but this is the reason why Ogre and Bullet (hell even SDL 1.3 moved to ZLIB) are under these more liberal licenses, it's more practical for when you want to port your game to consoles/embedded platforms. I'm sticking to my own C++ codebase with SDL and Lua for light scripting C++ game objects like everyone else. WinMo 8 I'm guessing will have P/Invoke so you'd just treat it like Android, JNI + NDK, static compiled C/C++ still wins.

    -MistaED

    Leave a comment:


  • BlackStar
    replied
    Apparently WP8 is supposed to support C++ (finally!), so scratch that advantage.

    @XorEaxEax, this is a recurring discussion happening roughly every 6 months. We don't really disagree in essence, C++ is a faster language than C#. What we disagree on is the conclusion: C++ is faster than C#, so C# can't be used for games. Ciplogic and I tried to argue why we believe this is wrong.

    In short:
    1. the existence of the GC does not preclude smooth performance. Essential memory management optimizations apply equally well to C# as to C++ (i.e. stack allocations, memory pools). Memory mismanagement will cause problems in both cases (i.e. frequent new/delete objects during the game loop).

    2. C++ can achieve better performance than C# given proper optimization, sometimes significantly so. However, it is easier to achieve adequate performance in C# due to many factors, an important one being the ease of parallel processing (Parallel.ForEach and the Task Parallel library, the new 'async' primitives). Implementing the same optimizations in C++ requires significantly more effort (OpenMP, etc etc).

    3. Indie games are usually GPU-limited not CPU-limited. By far the most CPU-intensive part is physics, and you can always use a C++ library for that. No reason to implement your whole game in C++!

    And a final point I haven't raised till now:
    4. Recompiling C# code on a different platform is much easier than porting C++ code. Anyone who has had to port between Linux/GCC, VisualC and Mac (either compiler) will readily atest to this. The more compilers you add and the more features you use, the worse the situation becomes (use C++11 and you are SOL). C# is a walk in the park in comparison, which is a pretty nice for cross-platform games.

    Leave a comment:

Working...
X