.NET and games
Author
Hi,
Anyone knows how .NET can affect game industry? if, it will affect...?
Thank You,
Cherub
Well, Java hasnt really seemed to affect gaming, so i cant see why .NET should.(but of course at some point C++ will have to give way to higher level languages with garbage collection etc, simply because of development time).
At least for a while, .NET should have a negligable impact, except in the area of web games. Of course, after some time, people might start to try it out, much like the move from C to C++ took some time. Game development is effectively closer to system programming than to applications programming, and since .NET is rather poorly-equipped for the former... So, I doubt that it will ever be much more than a novelty to game developers, on the whole.
If C++ programmers would use their language more effectively and correctly, there''d effectively be no need for garbage collectors to clean up after them.
it would be fine for things that require fast dev time, however for things such as games I dont see .Net (and C#) making a great impact.
A well written game shouldnt need garbage collection etc as automatic collection could effect performance and handling memory alloc your self is faster and easier.
Yes, C# and .Net will have its place, but I dont see it making a huge impact on the gaming industry.
A well written game shouldnt need garbage collection etc as automatic collection could effect performance and handling memory alloc your self is faster and easier.
Yes, C# and .Net will have its place, but I dont see it making a huge impact on the gaming industry.
quote:Original post by merlin9x9
If C++ programmers would use their language more effectively and correctly, there''d effectively be no need for garbage collectors to clean up after them.
Development in a GC''d language would still be faster. There is a reason why Bruce Eckel claims moving to Java from C++ gave him a 100% increase in productivity.
Besides, all OO languages(AFAIK) are GC''d.
The world holds two classes of men -- intelligent men without religion, and religious men without intelligence. Abu''l-Ala-Al-Ma''arri (973-1057; Syrian poet)
Bruce Eckel is not a game programmer, nor does he write operating systems or drivers. That makes a world of difference.
"Normal" applications benefit greatly from pure OO languages which, yes, do almost intrinsically contain garbage collectors. But for real-time programs, they impose too much overhead. Okay, so we have processors these days that make that overhead comparatively trivial. But all of that "trivial" overhead starts to add up, and that''s why we still don''t see, say, operating systems written in languages like Smalltalk. And I doubt that we will for quite some time.
"Normal" applications benefit greatly from pure OO languages which, yes, do almost intrinsically contain garbage collectors. But for real-time programs, they impose too much overhead. Okay, so we have processors these days that make that overhead comparatively trivial. But all of that "trivial" overhead starts to add up, and that''s why we still don''t see, say, operating systems written in languages like Smalltalk. And I doubt that we will for quite some time.
Phantom, you''ve been the victim of the biggest misconception regarding the .net framework.
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. So the GC might not even ever run until the process exits.
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. Nothing is easier than not writing something. :-)
It comes down to a wash. Write some code and test it yourself and read the .NET spec before you propogate false information.
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. So the GC might not even ever run until the process exits.
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. Nothing is easier than not writing something. :-)
It comes down to a wash. Write some code and test it yourself and read the .NET spec before you propogate false information.
There's no reason the C heap should require a walk and couldn't just keep a pointer to the next available block, particularly on Win32 since each process gets its own virtual address space, so it doesn't have to worry about trampling other processes. Beyond that, the true limiting factor is the memory allocation scheme "under the hood," which is invariably the same between both .NET and the C heap.
Edited by - merlin9x9 on February 17, 2002 9:03:01 PM
Edited by - merlin9x9 on February 17, 2002 9:03:01 PM
quote:Original post by merlin9x9
There's no reason the C heap should require a walk and couldn't just keep a pointer to the next available block, particularly on Win32 since each process gets its own virtual address space, so it doesn't have to worry about trampling other processes.
Edited by - merlin9x9 on February 17, 2002 9:03:01 PM
The C heap needs to walk a list of structures till it finds a block thats big enough to satisfy the request, and then partition this block - this causes heap fragmentation.
This article by Mickey Williams on the implementation of the .NET Managed heap might be of interest: http://www.codeguru.com/columns/DotNet/DotNet082001.html
EDIT: Found another article on the .NET heap, by Jeffrey Richter(you all know who that is, right?): http://msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp
The world holds two classes of men -- intelligent men without religion, and religious men without intelligence. Abu'l-Ala-Al-Ma'arri (973-1057; Syrian poet)
Edited by - Arild Fines on February 17, 2002 9:42:59 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
