By the way...
For the record, I don't believe managed code is in any way the ideal choice for developing a bleeding edge "game engine".
C++ will always out-perform C# or BlitzMax where it counts most in something like that.
The forte of languages such as C# and Blitzmax are the rapid development and ease of debugging and refactoring when it's acting as a simplified "glue language" layer between native C++/Assembler compiled code. For a "game" consuming "game engine" api's, this is probably good enough 98% of the time.
Even in XNA, C# isn't doing all the difficult, processor intensive operations. It's calling the appropriate DirectX methods (which are undoubtedly unmanaged native C++/Assembler compiled code APIs)
As processors get more powerful, and as developers see the benefit of sacrificing some clock cycles for service oriented and rapid development methodologies, managed code might find it's way up the chain someday.
So... comments such as "Garbage collection is useless" are a little too generalized. Useless for purposes of a game engine, perhaps. Maybe not so much for a client application that sits downstream.
The reality is, and I don't care if you're a game developer or a data base developer... time is money. And your boss (whether it's a manager or the end user community that buys your product) will want your application faster than you can deliver it. The trick is to choose the right tools for the job when that time comes: C++/Assembler for the high performance engine, C#/Blitz/Python/Boo/whatever for the game that glues it altogether.
Considering how many unique "script engines" (Domain Specific Language if you're using a snotty academic term) are baked right into game engines, I'd say that's a proven concept.
For the record, I don't believe managed code is in any way the ideal choice for developing a bleeding edge "game engine".
C++ will always out-perform C# or BlitzMax where it counts most in something like that.
The forte of languages such as C# and Blitzmax are the rapid development and ease of debugging and refactoring when it's acting as a simplified "glue language" layer between native C++/Assembler compiled code. For a "game" consuming "game engine" api's, this is probably good enough 98% of the time.
Even in XNA, C# isn't doing all the difficult, processor intensive operations. It's calling the appropriate DirectX methods (which are undoubtedly unmanaged native C++/Assembler compiled code APIs)
As processors get more powerful, and as developers see the benefit of sacrificing some clock cycles for service oriented and rapid development methodologies, managed code might find it's way up the chain someday.
So... comments such as "Garbage collection is useless" are a little too generalized. Useless for purposes of a game engine, perhaps. Maybe not so much for a client application that sits downstream.
The reality is, and I don't care if you're a game developer or a data base developer... time is money. And your boss (whether it's a manager or the end user community that buys your product) will want your application faster than you can deliver it. The trick is to choose the right tools for the job when that time comes: C++/Assembler for the high performance engine, C#/Blitz/Python/Boo/whatever for the game that glues it altogether.
Considering how many unique "script engines" (Domain Specific Language if you're using a snotty academic term) are baked right into game engines, I'd say that's a proven concept.