Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


.NET and Game Programming: Will they fit together?

This topic is 6005 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

Ive been wondering whether or not .NET would really be something useful for game programming. I dont know too much abou NET, but i think some parts of it will be cool: You can write a single project in multiple languages(or so im told). You could start writing GL functions in a project in...immediately. You could write the entire front end in VB, which is really cool. C# COM wrappers are also cool. No more having to write headers with all those horrid macros--just se a reference, like we do in VB now. What is not cool: COM behavior changed to an extremely moronic method. A "Garbage Collector" thread will run periodically and find unreferenced COM memory blocks and delete them. That is not cool for games. We can''t just have a seperate thread running through and sucking off our processor cycles! WTF was wrong with the current method that they went and did that? MS morons... We have to download the entire framework? And keep track of its version... the only reason i know what version of DX is because i have it. I think that the COM thing is such a painfully major drawback that it alone will kill game programming on .NET. ----------------------------- The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.

Share this post

Link to post
Share on other sites
With regard to the garbage collector. Yeah, the GC is a little slower than no GC at all (i.e. having to free your own resources) But the thing to keep in mind is that the GC only runs when the managed heap gets full.

Until this point, the managed .NET heap blows the C heap out of the water for allocations do to the fact that the C heap needs to walk a list to find available memory to allocate. The managed heap maintains a pointer to the next available block in it's already reserved contiguous section of memory. Allocating memory (calling the new operator) is just adding to a pointer. Blazingly fast and you never ever have to write (or forget to write for that matter) resource cleanup code.

I think you're a little confused about COM. You may be talking about .NET CLR managed "objects". If you create a managed COM wrapper around an old COM object, the COM wrapper is cleaned up by the .NET GC. When that's cleaned up, ->Release() is called. So, old school COM reference counting is still happeneing under the covers.

Not trying to be a devil's advocate here...just giving more detail on another way to look at it.

Edited by - jbattist on February 6, 2002 3:40:15 PM

Share this post

Link to post
Share on other sites

  • 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!