Hey all, My current game projects are still in C++ as I'm still under the impression that the overall penetration of the .NET runtime into the "common" market is still very very small.. I know that sooner or later, .NET written games will sell but the timeline is still a bit of a mystery...so I'm just wondering what the winds are like today. Has anyone here written a game or two using .NET and are making sales with it? thanks in advance!

Depending on your distribution medium, I don't see why the .Net framework would necessarily be a problem. Pretty much the only time that the ~20 extra megs is going to be an issue is for 56kers; people with broadband and products distributed via CD should have no real issue

Arena Wars is a great commercial game written in C# + OpenGL (there was no MDX at the time of creation), then there's Tin Soldiers - also commercial, written in C# + MDX.

As for indies, there's lots of em.

Soon .NET will be the domenant platform, C# the domenant language, it's a fact, so quit fooling around with C++ - its days are soon over.

most games that are built using C# now are using C# only for creating the window and such stuff, not for any thing else.
from a performance point of view, I think C++ games have higher performance than C# games, even when usnig managed directx.
if the days of C++ were over, microsoft wouldn't make a new version of the compiler and IDE and the language extensions.

Quote:Original post by Zodiak
Arena Wars is a great commercial game written in C# + OpenGL (there was no MDX at the time of creation), then there's Tin Soldiers - also commercial, written in C# + MDX.

As for indies, there's lots of em.

Soon .NET will be the domenant platform, C# the domenant language, it's a fact, so quit fooling around with C++ - its days are soon over.

hehehehe...sorry I'm really laughing about that.

Didn't they say the same damn thing about Fortran? If you think Fortran's dead, then you're too young. ;)

That being said, I guess my question is VERY loaded to begin with. I don't want to start yet another language war...that's not my intent.

There's a *large* number of indies out there who are surviving by targeting the DX7/DX8.1 runtime (since there's still a high percentage of users using Win98). These same users will NEVER upgrade their DX runtime unless forced to. For the most part, I think of them as my parents who are deathly afraid that even changing a control panel setting will kill their machine.

HOWEVER that being said, there will come a time when those group of users:
(a) Upgrade to WinXP
(b) Upgrade said WinXP system to SP2 (which contains the MDX stuff AFAIK)
(c) Buy a new computer that already has XP SP2 installed
(d) Pay the neighbourhood 12-year old to upgrade their machine with any servic packs and/or video driver updates.

This might be the wrong forum to target this question to, but I'm still leaving it here in the hopes of hearing from others out there who are working under a business plan that targets this casual group using C#.

Yes ... C# is a wonderful GUI environment - makes great editors.

You may laugh, guys, but that's a fact. Well, except the thing about C++... I just don't like it, but that's not the point.

Next DirectX will be .NET
Windows Longhorn will be totally .NET

Like it or not, .NET is Microsofts new baby, and it's a genious one. They will do whatever it takes to make it domenant.

Thus there will be absolutely no issues of any kind with C#, MDX, and .NET as a whole.

And taking into account that C# already has no performance issues (buy a normal PC, then you'll agree with me) in games (well, in software too, obviously), imagine what would it be like in 2-3 years. Again, THERE ARE NO PERFORMANCE ISSUES IN C#, believe me, I've done some very 'heavy' demos - on Radeon 9800 everything worked like a charm. So please please quit this ****shit about C# being slow etc. etc. - IT IS NOT. It *WAS*, but not know and obviously not in the future. And C++ is slower than ASM etc. etc. Modern PC's are capable enough to handle C# or whatever, no performance is not *that* crucial. But C# is not slow... BTW, you all better install .NET Framework 2.0 Beta. Had no problems with it.

Ok, we obviuosly don't know the future, so I way be wrong, but... Everybody has to accept that .NET is the future, for Windows at least. MDX, C# etc. etc. will be no worse than C++.

And I am sorry for bashing C++ in my first post... Of course, C++ is powerful, popular, and a standard now, but... It's kinda 'old'. Languages, like C# and similar are the future, like it or not. C++ will never die same as Assembler, but it will just a good language. Everybody will remember it as something from the past. That's all. Again, I am sorry, but that's a factual info about .NET (above, I mean)

Oh, and I will never let these people with Win98, with no .NET Framework etc. etc. stand in my way. It's their problem, I don't want them to limit me and my games. I doubt that HL2 would have been what it is if Valve were to think about some poor ol' fella having a 1979 PC or something...

Ok, guys, please don't flame me, I am sceptical myself. Instead, check this thread out: http://www.gamedev.net/community/forums/topic.asp?topic_id=312624

Quote:Original post by Zodiak
Thus there will be absolutely no issues of any kind with C#, MDX, and .NET as a whole.

And taking into account that C# already has no performance issues (buy a normal PC, then you'll agree with me) in games (well, in software too, obviously), imagine what would it be like in 2-3 years. Again, THERE ARE NO PERFORMANCE ISSUES IN C#, believe me, I've done some very 'heavy' demos - on Radeon 9800 everything worked like a charm. So please please quit this ****shit about C# being slow etc. etc. - IT IS NOT. It *WAS*, but not know and obviously not in the future. And C++ is slower than ASM etc. etc. Modern PC's are capable enough to handle C# or whatever, no performance is not *that* crucial. But C# is not slow... BTW, you all better install .NET Framework 2.0 Beta. Had no problems with it.

C# performance issues and the MDX appear in the BIG projects not in a demo.here you are some of the reasons why performance is slower in a big project:
most of the MDX objects have finalizers. these are the performance issues with finalizers:
1-a finalizable object must be placed on a RegisteredForFinalization queue. In some sense, this is a bit like having an extra pointer-sized field in your object that the system initializes for you. However, our current implementation uses a slower allocator for every finalizable object, and this impact can be measured if you allocate small objects at a high rate.
this also causes an extra pointer in your cache, which is 4bytes in 32 bit system and 8 bytes in a 64 bit system.If you are alocating many finalizable objects,This can get you out of the cache on small cache processors, and make you read from the memory which is 10-50 times slower.
2-Each GC must do a weak pointer scan of this queue, to find out whether any finalizable objects are now collectible. All such objects are then moved to a ReadyToFinalize queue. The cost here is small.
3-All objects in the ReadyToFinalize queue, and all objects reachable from them, are then marked. This means that an entire graph of objects which would normally die in one generation can be promoted to the next generation, based on a single finalizable root to this graph. Note that the size of this graph is potentially huge.

the rest of the impacts of finalizables on performance are 11 pages long so I stated the most important things.there are also securtiy issues and much stuff.But SOME not ALL of the finalizer issues will be solved in .NET 2.0.
4-Dealing with garbage collection in a small project is easy.you are creating objects and the garbage collector is deleting them.
BUT in a big project, the greater the number of objects, the higher the periority of the GC thread and this will consume your processing power.In a big project you have to call dispose() your self in some situations and do some stuff.
here you are a practical example:when migrating microsoft site and the other sites related to microsft(as msdn) from asp to ASP.NET, they found that 70% of the processing power was consumed in GC.
the .NET performance team discussed and debuged this problem, and they recomended the site developers to dispose all their unwanted objects before trasfering from one server to another.after doing this, only 1% of the processing power was spent in GC, but as you can see, it is not as in small applications where you throw every thing on the GC.
I don't have enough time or space to write other performance issues related to C#,but I think this is enough for now.