Quote:Original post by howie_007
C#, as part of the .NET framework, is compiled to Microsoft Intermediate Language (MSIL), which is a language similar to Java's bytecode. MSIL allows C# to be platform independent and runs using just in time compiling.

Alright, C# is similar to Java's bytecode. So let's look at Java performance then.

Quote:from the link
The average performance of Java programs has increased a lot over time, and Java's speed might now be comparable with C or C++. In some cases Java is significantly slower, in others, significantly faster

Hence the need to qualify your statements. There are few absolutes in computing.

I was probably a bit too harsh with my response and I am rating you back up!

I did find learning the low level parts of windows, message dispatch and the game loop to be inspiring. You can at least be able to appreciate the wrapping C# does to these concepts. In addition, in C/C++, you know exactly what's running around in the target PC. Again, this might not be necessary if you're making just another game, but if you make games because of the technical challenge, there is indeed a lot to learn.
If you're not interested, well, you've made the right choice then sticking to what you know for now.

Quote:Original post by howie_007
The reason is if you're making library calls in Java or in the case of C# .NET framework, you're executing compiled native binaries. Back during the early days of Java and C#, the native binaries were few and far in between. Games are very unique and the more code you have to write specific to your game, the slower your game gets.

I'd love to see a citation for this.

edit: Don't get me wrong I'm sure that is part of it. But how much of a part is it?

Quote:Original post by howie_007

Quote:Original post by nobodynews
The average performance of Java programs has increased a lot over time, and Java's speed might now be comparable with C or C++. In some cases Java is significantly slower, in others, significantly faster

This is true. You now have to ask the question why is this? How did it get faster? Did the Java people somehow figure out the error of their ways? It's the same answer for C#. The reason is if you're making library calls in Java or in the case of C# .NET framework, you're executing compiled native binaries. Back during the early days of Java and C#, the native binaries were few and far in between.

That is not the primary factor. It's definitely not the reason that C# and even Java outperform C++ at some tasks. No, the main performance gains have been JIT compiler optimizations. It's a relatively new field that has grown steadily over the past 20 years. Some things are faster or slower between JIT compilation and native compilation simply because they have different performance profiles. Different programs will hit each's strengths or weaknesses differently.

Quote:
Games are very unique and the more code you have to write specific to your game, the slower your game gets.

Huh? Maybe if you are a fairly poor programmer compared to middleware programmers. Otherwise, code written specifically for your needs should (in general) outperform general code. Unless you're just making a blanket assumption that more features/code means less performance... though that isn't specific to games, but given the blanket ignorance you've shown to JIT languages...

Howie, you're a fountain of misinformation.

To the original poster, just some random thoughts.

C# and C++ aren't that much different. C# is just much nicer to deal with when writing programs at the application level. C# also has a great, consistent library with lots of built in functionality. It solves a bunch of problems for you instead of you having to re-invent the wheel, or link in a bunch of third party libraries to get the same functionality.

C++ is becoming a mess. I was so sick of dealing with it. There are so many obscure little rules that are impossible to keep track of. Most of it's strengths are dangerous or confusing to use, causing most to use higher level functionality, like you'd find in a higher level language anyways.

XNA GS is at it's basic level a binding to use D3D9 from C#. A lot of the functions are the same. XNA adds a content pipeline, and a math helper library. In XNA you use a handy SpriteBatch set up, but in Direct3D, you have a similar sprite class to use anyways(I forget what it's called). Other than that, you can call the same low level functions to feed raw vertices to the GPU just like in D3D.

The way the default XNA GS template works isn't that different than how you'd set up a main game loop in C++. You keep calling an Update function that progresses your game, and then render the screen when it's time.

The stuff hidden in Game's functions isn't anything to worry about. Draw will take care swapping the buffers, Update will take care of maintaining the time for you, initialize will just set up the window and initialize D3D for you.

If you want to feel like a pro, finish a decent game and RELEASE IT. It doesn't matter if you use XNA, Unity, UDK, or C++. A good chunk of AAA games released today are using engines like UDK or Unity, and all the custom game behavior is done using an in engine scripting language.