Game Programming with C#
-
Hello everybody... Im used to program my games and stuff with C++ and WinAPI with OpenGL and/or GDI, GDI+... My questions and thoughts is as follows: 1. Game programming with C# Advantages and so on...? 2. Is it possible to implement OpenGL to C#? 3. Why should I start to program in C#? Is thear any or many Advantages? Or not...:confused: Marcus Grenängen Lead programmer at MO Software Sweden.
-
Hello everybody... Im used to program my games and stuff with C++ and WinAPI with OpenGL and/or GDI, GDI+... My questions and thoughts is as follows: 1. Game programming with C# Advantages and so on...? 2. Is it possible to implement OpenGL to C#? 3. Why should I start to program in C#? Is thear any or many Advantages? Or not...:confused: Marcus Grenängen Lead programmer at MO Software Sweden.
Snews wrote: 1. Game programming with C# Advantages and so on...? Easier to write but lacks the performance of native language applications. Snews wrote: 2. Is it possible to implement OpenGL to C#? Yes, but you must wrap OpenGL. There are some implementations of this already (even here on CodeProject, so just try a search), but some are good and some are not. In either case, considerable time is spent marshalling data across platforms. Depending on your requirements, this may not be desirable either. Snews wrote: 3. Why should I start to program in C#? Is thear any or many Advantages? Or not... The learning never stops. If you like to learn as much as you can, there's one good reason. You should really take a look at Managed DirectX at http://msdn.microsoft.com/directx[^], which is managed code for DirectX and written from the ground-up - it's not a wrapper. There's a couple good books that cover game development using Managed DirectX (using both C# and VB.NET) from Amazon that are pretty good and also discuss the ads/disads:
- Managed DirectX 9 Kick Start: Graphics and Game Programming[^]
- Introduction to 3D Game Engine Design Using DirectX 9 and C#[^]
Microsoft MVP, Visual C# My Articles
-
Snews wrote: 1. Game programming with C# Advantages and so on...? Easier to write but lacks the performance of native language applications. Snews wrote: 2. Is it possible to implement OpenGL to C#? Yes, but you must wrap OpenGL. There are some implementations of this already (even here on CodeProject, so just try a search), but some are good and some are not. In either case, considerable time is spent marshalling data across platforms. Depending on your requirements, this may not be desirable either. Snews wrote: 3. Why should I start to program in C#? Is thear any or many Advantages? Or not... The learning never stops. If you like to learn as much as you can, there's one good reason. You should really take a look at Managed DirectX at http://msdn.microsoft.com/directx[^], which is managed code for DirectX and written from the ground-up - it's not a wrapper. There's a couple good books that cover game development using Managed DirectX (using both C# and VB.NET) from Amazon that are pretty good and also discuss the ads/disads:
- Managed DirectX 9 Kick Start: Graphics and Game Programming[^]
- Introduction to 3D Game Engine Design Using DirectX 9 and C#[^]
Microsoft MVP, Visual C# My Articles
Like the anser on 3... :laugh: Thats right... How does it work with the memmory processing and handling in C# then? Better and easier then in C/C++? or is it just crappy? This Managed DirectX? I will take a closer look at it, even if I never have liked DirectX :~ Tanks for your time Mr... Marcus Grenängen Lead Programmer MO Software Sweden
-
Hello everybody... Im used to program my games and stuff with C++ and WinAPI with OpenGL and/or GDI, GDI+... My questions and thoughts is as follows: 1. Game programming with C# Advantages and so on...? 2. Is it possible to implement OpenGL to C#? 3. Why should I start to program in C#? Is thear any or many Advantages? Or not...:confused: Marcus Grenängen Lead programmer at MO Software Sweden.
Use managed DirectX instead. It's not at a very mature state yet (lacking some documentation and still have annoying bugs), but I'm sure it will become the preferred way of using DirectX pretty soon. Just compare managed vs unmanaged DirectX code (C++ vs C#) and you will notice the great improvement in readability and the superior object oriented model. Even though I'm used to coding C++, I find C# code so much more readable, and more productive to use. Since the framework includes a compiler you can even use C# for the scripting part of the game (or JScript if you like that better). Your ideal game project would be 95% C# code, and 5% C/C++ code mixed with assembler for the most performace critical parts. In some years, most people in game industry will use this model I think and hope. Regards, /Björn Morén
-
Hello everybody... Im used to program my games and stuff with C++ and WinAPI with OpenGL and/or GDI, GDI+... My questions and thoughts is as follows: 1. Game programming with C# Advantages and so on...? 2. Is it possible to implement OpenGL to C#? 3. Why should I start to program in C#? Is thear any or many Advantages? Or not...:confused: Marcus Grenängen Lead programmer at MO Software Sweden.
1. The advantages include less amount of code to write, cleaner syntax, no manual memory management, faster development cycles. Disadvantages include slower performance, access to platform level services only via P/Invoke. 2. You can use OpenGL in C#. As Heath mentioned, it's already been done. See CsGl[^], the Exo Engine[^], or the cross-platform Tao OpenGL library[^]. 3. It's has simpler language syntax than traditional C++, which translates into code that's easier to read, write, and find bugs. Memory management is taken care of for you, preventing many pitfals of C including memory leaks and circular references. It generates verifiable 'safe' code which could be quite important when Microsoft's ClickOnce deployment rolls around. It interoperates with other .NET languages seamlessly without any extra effort; write a public Test() function in a dll and I'd be able to use it from VB.NET, managed C++, JScript.NET, or any other language targetting the .NET platform. Dlls can be stored in the Global Assembly Cache in which dll versions do not overwrite one another, potentially preventing the problems associated with 'dll hell'. See Microsoft's .NET overview[^] for a list of their benefits to using .NET. Hope that answers some of your questions. To be honest, I don't know if C# is right for game development; C#, while theoretically faster than Java (due to being 'designed for JIT compiling') isn't as fast as C++, and doesn't directly give you access to low-level services in the same flavor as traditional C or C++ does. On the other hand, C++ is not as fast as C, and C is not as fast as pure x86 ASM code, yet that has not stopped developers historically from writing games in C++. I guess it's a tradeoff - speed for RAD. If you are more focused on finishing a game faster than writing a game that runs faster, use C#. If you are more focused on writing a game that squeezes every last drop of performance out, use
-
1. The advantages include less amount of code to write, cleaner syntax, no manual memory management, faster development cycles. Disadvantages include slower performance, access to platform level services only via P/Invoke. 2. You can use OpenGL in C#. As Heath mentioned, it's already been done. See CsGl[^], the Exo Engine[^], or the cross-platform Tao OpenGL library[^]. 3. It's has simpler language syntax than traditional C++, which translates into code that's easier to read, write, and find bugs. Memory management is taken care of for you, preventing many pitfals of C including memory leaks and circular references. It generates verifiable 'safe' code which could be quite important when Microsoft's ClickOnce deployment rolls around. It interoperates with other .NET languages seamlessly without any extra effort; write a public Test() function in a dll and I'd be able to use it from VB.NET, managed C++, JScript.NET, or any other language targetting the .NET platform. Dlls can be stored in the Global Assembly Cache in which dll versions do not overwrite one another, potentially preventing the problems associated with 'dll hell'. See Microsoft's .NET overview[^] for a list of their benefits to using .NET. Hope that answers some of your questions. To be honest, I don't know if C# is right for game development; C#, while theoretically faster than Java (due to being 'designed for JIT compiling') isn't as fast as C++, and doesn't directly give you access to low-level services in the same flavor as traditional C or C++ does. On the other hand, C++ is not as fast as C, and C is not as fast as pure x86 ASM code, yet that has not stopped developers historically from writing games in C++. I guess it's a tradeoff - speed for RAD. If you are more focused on finishing a game faster than writing a game that runs faster, use C#. If you are more focused on writing a game that squeezes every last drop of performance out, use
CsGL is obsolete. Tao framework is it's "child" and is fully functional. And my friend has just finished wraping the CG so I think it will be aded in the next realese. Q:What does the derived class in C# tell to it's parent? A:All your base are belong to us!
-
Hello everybody... Im used to program my games and stuff with C++ and WinAPI with OpenGL and/or GDI, GDI+... My questions and thoughts is as follows: 1. Game programming with C# Advantages and so on...? 2. Is it possible to implement OpenGL to C#? 3. Why should I start to program in C#? Is thear any or many Advantages? Or not...:confused: Marcus Grenängen Lead programmer at MO Software Sweden.
Have a look at Purple# too. They have a project hosted on SourceForge.
-
Have a look at Purple# too. They have a project hosted on SourceForge.
-
1. The advantages include less amount of code to write, cleaner syntax, no manual memory management, faster development cycles. Disadvantages include slower performance, access to platform level services only via P/Invoke. 2. You can use OpenGL in C#. As Heath mentioned, it's already been done. See CsGl[^], the Exo Engine[^], or the cross-platform Tao OpenGL library[^]. 3. It's has simpler language syntax than traditional C++, which translates into code that's easier to read, write, and find bugs. Memory management is taken care of for you, preventing many pitfals of C including memory leaks and circular references. It generates verifiable 'safe' code which could be quite important when Microsoft's ClickOnce deployment rolls around. It interoperates with other .NET languages seamlessly without any extra effort; write a public Test() function in a dll and I'd be able to use it from VB.NET, managed C++, JScript.NET, or any other language targetting the .NET platform. Dlls can be stored in the Global Assembly Cache in which dll versions do not overwrite one another, potentially preventing the problems associated with 'dll hell'. See Microsoft's .NET overview[^] for a list of their benefits to using .NET. Hope that answers some of your questions. To be honest, I don't know if C# is right for game development; C#, while theoretically faster than Java (due to being 'designed for JIT compiling') isn't as fast as C++, and doesn't directly give you access to low-level services in the same flavor as traditional C or C++ does. On the other hand, C++ is not as fast as C, and C is not as fast as pure x86 ASM code, yet that has not stopped developers historically from writing games in C++. I guess it's a tradeoff - speed for RAD. If you are more focused on finishing a game faster than writing a game that runs faster, use C#. If you are more focused on writing a game that squeezes every last drop of performance out, use
C#, while theoretically faster than Java (due to being 'designed for JIT compiling') I love how Redmond constantly tries to imply that JIT compilation is their bright idea. Java had JIT compilers long before the .NET brand was being marketed to the world. The execution speed of Java code, according to an IBM study, is about 1.7 times slower than equivalent Fortran code. Deep compilers, similar to ngen.exe for .NET, exist for Java and work well. JIT compilation doesn't really say anything about the runtime speed of code, by the way. A good JIT compiler will compile code that runs faster than the output of a worse compiler. JIT compilation does, however, introduce some unavoidable slowness when something is first run, due of course to the compilation time required. I implemented several applications side-by-side in C# and Java a while back, and they ran neck-and-neck on my setup. Java is faster in some respects, and .NET is a little faster in others. I agree with everything you wrote except that; chalk this post up to having too much time on my hands on a Sunday afternoon. Regards, Jeff Varszegi
-
C#, while theoretically faster than Java (due to being 'designed for JIT compiling') I love how Redmond constantly tries to imply that JIT compilation is their bright idea. Java had JIT compilers long before the .NET brand was being marketed to the world. The execution speed of Java code, according to an IBM study, is about 1.7 times slower than equivalent Fortran code. Deep compilers, similar to ngen.exe for .NET, exist for Java and work well. JIT compilation doesn't really say anything about the runtime speed of code, by the way. A good JIT compiler will compile code that runs faster than the output of a worse compiler. JIT compilation does, however, introduce some unavoidable slowness when something is first run, due of course to the compilation time required. I implemented several applications side-by-side in C# and Java a while back, and they ran neck-and-neck on my setup. Java is faster in some respects, and .NET is a little faster in others. I agree with everything you wrote except that; chalk this post up to having too much time on my hands on a Sunday afternoon. Regards, Jeff Varszegi
I did say 'theoretically', eh? :) Yes, Java has had JIT compiling for awhile I know, however, Java is more or less an interpreted language out of the box, with some so-called 'hot spot' JIT compilation as needed. Yes, Java and C# are very close performance wise. I'd be willing to bet, though, that as C# matures, .NET will eventually outpeform Java evidently as the great compiler teams at Microsoft focus their brilliant brain-heads on it. :) --------------------------- He who knows that enough is enough will always have enough. -Lao Tsu
-
I did say 'theoretically', eh? :) Yes, Java has had JIT compiling for awhile I know, however, Java is more or less an interpreted language out of the box, with some so-called 'hot spot' JIT compilation as needed. Yes, Java and C# are very close performance wise. I'd be willing to bet, though, that as C# matures, .NET will eventually outpeform Java evidently as the great compiler teams at Microsoft focus their brilliant brain-heads on it. :) --------------------------- He who knows that enough is enough will always have enough. -Lao Tsu
The "HotSpot" compiler is just the name brand for Sun's compiler, which many people don't even prefer to use. All of the major compilers in use today are JIT compilers. "More or less interpreted" is a phrase that applies exactly as much to .NET as it does to Java. There are also "brilliant brain-heads" at work trying to make Java run faster all the time. Every version has included speed improvements, just as is true between version 1.0 and 1.1 of .NET. I wouldn't be willing to bet that .NET will outperform Java eventually, because they're way too similar, and there's no magic. As they both creep more and more towards optimal implementations, their performance will probably become closer to identical. I'm not arguing just to argue, but I wouldn't bet that Microsoft stuff will kick ass just because of the brand. :) Regards, Jeff Varszegi EEEP!