.NET and Game Programming: Will they fit together?
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.
Again...?
Once there was a time when all people believed in God and the church ruled. This time is called the Dark Ages.
Once there was a time when all people believed in God and the church ruled. This time is called the Dark Ages.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
