Jump to content
  • Advertisement
Sign in to follow this  
ChiefArmstrong

future of .NET

This topic is 4965 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just a general question, the next release of Windows is supposed to include the .NET framework already integrated into the OS, right? So I'm assuming that performance wise, we should see an increase (maybe just slightly) in the speed for which .NET programs execute? The reason that I ask is because I am planning on possibly developing my 3D game in C#, and there are currently a lot of naysayers about doing this that I have seen. But by the time that my game is done, Microsoft's Longhorn should be out, with it's integrated .NET runtime (they might even have 2.0 imbedded by then), so I assume that there should be some performance increases and it should not be so bad to have a full 3D game developed for .NET. Opinions, predictions, ect. welcomed.

Share this post


Link to post
Share on other sites
Advertisement
If you're making Doom 3 or Half-Life 2 then stick with C/C++ (for now). For smaller arcade games that don't require so much power, I suggest you use C# as the performance tradeoffs are well worth the productivity gains.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The problem in my opinion is not performance of managed code per se, because the rewards can be arguably worth any slight degridation.

The bigger problem is the non deterministic nature of the CLR's Garbage Collection. Personally, a non deterministic GC has absolutely no place in the architecture or codebase of any potentially commercial title. That means absolutely not in my engine code.

Others may differ on this extreme view and point out that with a lot of care it can be worked around. Personally I see this as a waste of time and any paranoid developer should want to avoid having to wonder when a GC will kick in during the middle of gameplay, causing animation to stutter.

If forthcoming versions of .NET can offer deterministic GC, then I think you can be much closer to a viable .NET based commercial game architecture.

Share this post


Link to post
Share on other sites
Well, I knew that Doom 3 and Half Life 2 games are very much beyond the capabilities of the current .NET framework, which is understandable. I was just curious to see if future versions of .NET would even get halfway there to being able to handle such projects.

As for the garbage collection, I knew that it was there, I just didn't know that it was prone to just jump in and work when it wants too. That would be very annoying for that to occur in a 3D app. I did not think of that.

Good comments!

Share this post


Link to post
Share on other sites
Quote:
The bigger problem is the non deterministic nature of the CLR's Garbage Collection. Personally, a non deterministic GC has absolutely no place in the architecture or codebase of any potentially commercial title. That means absolutely not in my engine code.


I think you're drastically overestimating the frequency with which the GC runs and the amount of resources it uses while running. Both numbers are quite low (though admittedly not insignificant). If your GC is running frequently, then there's definitely other factors at work.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Others may differ on this extreme view and point out that with a lot of care it can be worked around. Personally I see this as a waste of time and any paranoid developer should want to avoid having to wonder when a GC will kick in during the middle of gameplay, causing animation to stutter.


I hate to say you're wrong.. but..

Considering there are already commercial games out there running on the .NET framework, plus the fact that I have first hand experience in commercial C# game development, I can say that your worries about the GC are legit but that you vastly overstate the issue with the GC.

Sure if you have bad code than you can bog down the GC, but well written code shouldn't bog the GC unless you are doing some very heavy object creation, etc. I mean we haven't run into a problem at all I would really like to know where you are bogging down and hitting the GC heavy honestly.

Sure you wouldn't write Doom3 or HalfLife2 using the framework.. but you wouldn't without a company of 15+ and existing tools/basecode anyways. Using the .NET framework to write commercial games is perfectly viable, and only gets better as Longhorn is released, the JITer starts performing better optomizations, and the GC is improved.

Share this post


Link to post
Share on other sites
Actually I've run into the opposite problem: sometimes it does not run often enough :-)

ChiefArmstrong - as with evaluating all technology I suggest you prototype. Try to cook up a simple renderer that uses something close your expected polygon/texture budget, maybe a big room with a bunch of bouncing cubes, and make the cubes bounce off of each other to simulate simple collision detection. See if you can get it to run smoothly with your target technology. If you can then add more complexity to the renderer or to other resources that are critical for your game and iterate.

Pretty quickly you should be able to tell if the technology will or will not be able to support your game. If it doesn't then you can decide whether or not to continue with the technology or change your game to allow you to keep using the technology.

I would not count on .Net getting much faster in the future. It may but I would not count on it. Given the current state of Microsoft's plans it looks like WinXP is going to be around for quite a bit longer with several Longhorn technologies grafted on it. So if you're planning to produce a .Net game in the next few years I'd target .Net 2.0 on WinXP as your main platform target.

Share this post


Link to post
Share on other sites
Quote:
Original post by antareus
It amazes me that people are okay with the GC pausing their apps while it collects.

It amazes me that people are okay with the OS pausing their apps while executing other tasks.

Share this post


Link to post
Share on other sites
As far as the garbage collector, there are really only two collections that you need to worry about: GC(0) and GC(2).

GC(0) is the most common GC in the framework. It occurs on a regular basis and sweeps out any recently allocated objects. It's a little more expensive than a page fault.

GC(2) is rarely called. If your application is minimized or system memory is running out or if you're doing a ton of large allocations, GC(2) will be called. GC(2) can take a couple of seconds, depending on how many objects are "live" in your system.

As a side note, any object that gets created that is over 80 kilobyes in size is automatically a GC(2) object.

So, easy GC performance tips: create your large objects at application startup and maintain references to them, and drop references to small objects quickly so that they'll stay in GC(0).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!