Hi there, looks good what you here work for. I have a Question about the programming language. Which do you use? Do you use C# cause in the system requirements .Net 1.1 is required.

i believe, but no entriely sure that it is C++.

You can write CLR (.Net) applications using Managed C++, although I'm partial to C# myself. I'd like to see more games developed in C# with Managed DirectX, as there haven't been too many, and the ones I've seen have been rather impressive.

And if I learn that Gavin has been writing this entire game in VB.NET, I will have little choice but to fly out to London and beat him mercilessly with a C# manual .

c++ woith .net support, all multimedia aspects will rquire .net, the rest is in c++ sorry but this is the way it`s been coded,for.

you are the man

*gets on knees and chants:

'we're not worthy, we're not worthy...'

w00t!

you rock!

What exactly is the benifit of using managed code?

The CLR "manages" memory allocation for you, and the garbage collector frees memory that's no longer being used. In C (and to a lesser extent, C++), you generally have to allocate your own memory and then free it when you're done. This is relatively painless for managing items with a short lifecycle, but for long-term objects with a wide scope, it becomes much easier to allocate memory and forget to ever free it. C and C++ are unsafe, so it's also possible to have pointers to objects that have already been freed and therefore don't exist anymore. The results of referencing a freed chunk of memory are unpredictable--the program may run properly, it may produce unintended results, or it may cause a core dump. Usually, a Virtual Machine's garbage collector is smart enough not to free the memory used by an object if there are still active references to that object in another part of the program. So while you can still waste memory, it usually means you've just been careless.

Another benefit to Virtual Machines is that they allow for reflective programming languages like C# and Java. Reflection, in short, allows a program to observe and perhaps modify its high-level behavior. This means you can perform some incredibly handy operations that you could never do in a lower-level language, like resolve and modify code constructs at runtime. For instance, you could use a string representation of a class name to look up and view that class' structure, including all of its properties and and methods, and invoke them dynamically. This makes it much easier to serialize program structures to some external medium (like XML) and then deserialize them back into the program later, because you now have a way of dynamically resolving and instantiating program structures at runtime--even if you had no knowledge of those structures at the time you wrote the program (hello, 3rd party extensions).

Hopefully some of that made sense... it's been a long day :-/

I think it make sense and describes the benefits of using managed code .

thank you, that does make a lot of sence,

also is managed code (for c/c++) going to become an ANSI standard or just a microsoft proprietary thing?

Well, there's a couple things to understand about managed code--it doesn't necessarily impact the language syntax, moreso how certain language constructs are (or are not) used. Managed code implies a virtual machine (or at least an active memory management system w/ garbage collection). While there may be some minor syntactic differences between Microsoft's Visual C++ when writing .Net applications vs. legacy unmanaged applications, it's still essentially the same language. Managed C++ is just used to describe Visual C++ code that runs in the .Net CLR and has full access to the .Net base class library assemblies. Visual C++ is still just Microsoft's own variation of C++, and while my experience in this area is limited, I believe it varies from ANSI C++ in several important ways. So, Managed C++ will likely never be standardized by anyone other than Microsoft. It only really exists to appease all the C++ programmers who wanted to write applications for the .Net CLR in their preferred language. C++ was never intended to be fully managed, and it was not designed to be reflective, so Managed C++ doesn't fully take advantage of all the great features that the CLR has to offer. The same is true for the horrific hack that is VB.NET. In order to take full advantage of a fundamentally different kind of programming, a new language is needed that has been designed with reflection and a VM in mind. Some of the first examples I can think of are Smalltalk and Java. Microsoft, however, decided to develop a new language with a more flexible syntax to take full advantage of the CLR's managed execution environment. This language was called C#. The C# language takes all the best qualities of C++, Java, Objective-C, and Smalltalk, throws out junk, and includes some very clever constructs intended to make programming less tedious than in similar languages like Java. I could go on for hours about events and delegates, properties, operator overloading, code security, etc., but I won't bore you with that. Returning to your question about standardization, Microsoft did something very smart--they submitted the C# language specification to the EMCA for standardization. Even though Microsoft is really the only drivng force behind C#'s evolution, they knew that if they were going to succeed in killing off Java, they were going to have to create a standardized alternative--and they did just that. The Mono Project developed its own VM conforming to the Microsoft .Net CLI, and they also built their own EMCA-compliant C# compiler. Mono allows you to run your managed .Net applications on other platforms--at least in theory. You run into trouble with all the Windows.Forms GUI classes, but I believe the current development version of Mono runs at least some Windows.Forms applications by writing a Cairo implementation of GDI+. The point is that both .Net and C# are gaining serious momentum, even outside of the Microsoft Windows world. By the end of the decade, there will be substantially fewer Java and C++ prorammers out there.

Sorry I did misread that? Your gonna make a mac version? I would be a happy man if you did since I long ago gave up on pc's.

yay! Lets code a game that runs in a virtual machine, may as well code in Java if you care about portibility.

Multiplatform software comes at the price of efficentcy. You can't make it run at optimum speed on one platform you need to make it run at an average speed on all platforms. There is realy little value in making games multiplatform, multiplatform software is better suited to applications where speed is not critical. what gamer dosen't have access to Win32 for games? Even amongst none-gamers it's probably 95%+ home users run windows. The vast majority of games require directx and if your into games you can hardly not run windows.

Virtual Machines aren't too much slower than executing native code. Granted, code written in Java or C# usually won't be as fast as code written in raw C, but it will generally be safer and more stable. There's an additional benefit to VMs, and that's optimization. Consider for a moment that when someone writes a game in C++, it gets compiled to native code. Keep in mind that every processor executes differently, even if they have the same instruction set--even the Pentium M and Pentium 4 are fundamentally different CPUs, despite the fact that they're both based on the i686 architecture with the SSE/MMX families of extensions. When you compile native code, you can perform certain optimizations so the code executes better on your particular processor, but performance may suffer on other processors as a result of those same optimizations. This is the reason why compile-your-own Linux distributions like Gentoo tend to perform better than the prepackaged binaries released by the likes of Debian or Red Hat, which are compiled for generic i686 CPUs. When you use a Virtual Machine, your code doesn't get compiled to native code--at least not right away. It gets compiled to an intermediate language like Java bytecode or the .Net CIL. The VM includes a Just-in-Time Compiler that compiles this bytecode to native code on-the-fly, optimizing the code for your architecture as it goes. This obviously causes an initial increase in the time required to load a program, but general runtime performance can be pretty quick.

Now, you do raise a good point about games. Java is painfully slow for anything graphical, even though Java2D and Java3D both use Direct3D for rendering on the Windows platform. It's less of a problem for the .Net platform, as the DirectX libraries get directly marshaled into the Managed DirectX assemblies. I downloaded a demo of the first 3D game I saw that was coded entirely with C# and Managed DirectX (see screens here), and it ran better than I expected. Keep in mind the CPU is doing a lot less work than it used to, with so much of the graphics and audio processing being offloaded onto specialized hardware. I think in a few years, we'll start to see more games written in managed code, especially since so many of Windows Vista's APIs are written largely in managed code.