.NET Version of Quake II

MSwanson writes "It seems that Vertigo Software has ported the Quake II source code to Microsoft's .NET platform. Not only did they add a heads-up display in the .NET managed version, but they also say that the managed version initially ran faster than the native version. After changing some optimization settings, the native version now runs 15% faster than managed .NET code. Still pretty impressive. Download the ported version along with source code at the Vertigo site."

Comments

Using the term "ported" loosely

[Dr. Bent]

So they're still using some native C++ code? Big deal. Sounds like they just put a .NET wrapper around the QuakeII Engine, and they're still using native code to do all the heavy lifting. So you're still tied to Windows, and it runs 15% slower....fantastic.

Now, when they have a version written purely in managed code than can run on any .NET implementation (and runs only 15% slower), then I'll be impressed.

Re:Using the term "ported" loosely

[kasparov]

Quake II, if I am not mistaken, was written in C (not C++). So it looks like they ported the code to C++ and used .NET so that you can run the engine as a managed app. Should make it pretty easy to add new features.

Re:Using the term "ported" loosely

[thing12]

You are mistaken. Quake I was written in C with extensions in "QuakeC". Quake II is C++

Nope, you're mistaken... Quake II is written in C.. which is why it had to be ported to C++ for this project - they use c++ reserved words as variables and what not. And I may be mistaken, but I thought QuakeC was introduced in Quake II.

Re:Using the term "ported" loosely

[thing12]

Sounds like they just put a .NET wrapper around the QuakeII Engine, and they're still using native code to do all the heavy lifting.

Not quite -- if you download it and run the code through a .net disassembler you'll see that it can be converted to msil or higher up to C#. I haven't done a detailed analysis of it, but on the surface it looks like a complete conversion. Of course that doesn't count calls to COM objects and any 3rd party DLL's that are called via platform invoke's. But it looks like the "heavy lifting" is being done inside the confines of the .NET Framework.

Re:Using the term "ported" loosely

[irix]

looks like they ported the code to C++

Getting C code to compile with a C++ compiler is hardly a difficult task. QuakeII compiles with Visual C++ out of the box for starters.

Should make it pretty easy to add new features.

I'm sorry, but I don't see how getting this to compile under the bastardized piece of crud that is "managed C++" would make it easier to add new features.

All this does is show you can port a C app to C++ on .NET. Yay. What are their supposed advantages to having Quake II run under .NET?

* Manage memory allocations yourself or use CLR garbage collection.
* Call Window APIs directly or use .NET methods.
* Use existing libraries or .NET classes.
* Easily expose or consume other .NET assemblies written in different languages.

All while losing 15% performance and throwing the portability of the code out the window. Wow, sure sounds persuasive to me! </sarcasm>

Re:Using the term "ported" loosely

[irc.goatse.cx troll]

It's in C. I had to check though.

Re:Using the term "ported" loosely

[z01d]

Quake II, if I am not mistaken, was written in C (not C++).

that's right. and although we don't have quake3 engine source code, but it's safe to say that all id games so far are using C (or QuakeC for mod making of Q1). but not any more, here is a quote from JC about D3:

I did most of the early development work with a gutted version of Quake 3, which let me write a brand new renderer without having to rewrite file access code, console code, and all the other subsystems that make up a game. After the renderer was functional and the other programmers came off of TA and Wolf, the rest of the codebase got rewritten. Especially after our move to C++, there is very little code remaining from the Q3 codebase at this point

http://www.gamespy.com/e32002/pc/carmack/

Re:Using the term "ported" loosely

[irix]

it looks like a complete conversion

They converted the code to compile in Visual C++ .NET. If you run with managed extensions on, they hook in a class that does the radar using .NET APIs (Windows forms and such). By the way - look at their code for the radar - it is hideous. Everything in the .h file in true "lets make the users of our class import all sorts of useless dependencies" style. Ugh.

If you diff through the code, you'll notice about 800 lines in their radar implementation and only minor differences elsewhere (don't name variables after C++ reserved words, etc.).

It is a proof of concept, but a none too impressive one. It is made even less impressive by the MicroSoft cheerleading found all over their description of the port.

Re:Using the term "ported" loosely

[drinkypoo]

QuakeC was a Quake1 item, since then you've had to program in C, or at least you have to be able to come up with a DLL. I guess you could probably do it all in some other language with a C stub library to appease q2, q3, whatever. Unreal also operates in this fashion.

I'm sure at some point the overhead of scripting just got to be too much for iD to do scripting internally, so they just put all that functionality into the game itself through a DLL. Of course that meant all those people who learned QuakeC had to learn C... but it was a lot easier to get development tools by then.

What is the port?

[molo]

Quake II .NET is a version of the popular Quake II game, ported to native and managed C++ using Microsoft® Visual Studio® .NET(TM) 2003

Can someone fill me in here? What is the big deal? Id has always used the MS compilers for that platform. So they just updated it to work with the latest release of the compiler. Wow, fancy shit.

-molo

Re:What is the port?

[erasmus_]

The big deal is that this new version is now using managed code instead of just native C++. This company did it to illustrate how this can be done, even for large C++ projects. Managed code is run by the Common Language Runtime, allowing for a ton of useful features, which can now be used by Quake 2, or another ported project. A good overview can be found here, but here are a few from that page to get you started:

The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime.

The runtime also enforces code robustness by implementing a strict type-and-code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety. ...

In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references.

That last one means your program no longer crashes or takes over all memory resources because of bad resource management.

Re:What is the port?

[OeLeWaPpErKe]

Quake is a C project. C, not C++, as many have said. This invalidates all of the points you make. Now try again.

A C framebuffer (that means 2D, and yes quake II is an app that doesn't use any 3D api, it's all in the engine itself the magic happens) app can be ported to everything with minimal effort ( download a few demos and port them to QT, Allegro, SDL, and DirectX), it won't take you very long.

Also, as the fill rate is the limiting factor, there will not be a very big performance difference in any of the versions.

now that's optimization....

[dtfarmer]

but they also say that the managed version initially ran faster than the native version. After changing some optimization settings, the native version now runs 15% faster than managed .NET code

Anyone else misread that at first to mean they changed optimization settings on the managed code, and now it runs slower than the native version....

He was right

[BoomerSooner]

By running as managed code (this is REAL .Net) it was 15% slower. By running non-managed (no CLR) it was full speed (or 15% faster than the managed .Net code).

VC++.Net is just the same as VC++ 6 with a different IDE as long as you're not using managed code. If you are using managed code you might as well program in VB or C#, it all compiles to the same shit.

Interesting for three reasons:

[ihatesco]

1. This is a proof of concept that Microsoft's "Managed C++" stuff may be an interesting technology.

   If really Managed C++ isn't too much slower than C given the standard optimizations Managed C++ may become a viable platform for development in the end. We will see what will happen as Microsoft's JIT compiler matures.

2. If it is viable for Quake 2, it might be viable for any future game coming to PC, XBOX or even Phantom. Remember that having .NET (or Java with JNI as well, see this nice soviet Sturmovik simulator which really owns you ;D ...) allows you to access several non time-critical libraries (chat, rankings), or to prototype in an easier way several features that you wish to implement, without introducing slowdowns in the development and security issues (XBox savegame hack anyone?).

   I can remember Sony and other vendors being interested in a Java Gaming Profile for consoles... a very hefty addition to J2ME with JNI libraries for Physics, "Game Lobby" functionalities and mp3 streaming. That JCP anyway seems (in my experience) to be stalled. We will see if adoption of Managed C++/Managed DirectX will occur and will help the adoption of "Virtual Machines" technology in game consoles as well and revitalize the interest. Many titles, like Nihilistic Entertainment (of Zerstorer fame) Vampire The Masquerade use or used Java as a powerful scripting engine.

3. Anyway, remember that if you find Managed code to be too slow for your projects, you can always bridge your code with COM+, as Direct-X up to version 8 do succesfully :D... then using a COM+ component is easy as hell with .NET (let's hope that Mono makes this easy for Bonobo components too soon).

The drawbacks: don't expect this to be ported on Mono asap, Mono still lacks a Managed C++ compiler :(

+ + + +
And now imagine embedding Microsoft Flight Simulator 2004 with Excel.NET... oh WAIT!

Re:A New Cheat

[ihatesco]

It's not a cheat if everyone has it. In the very least, they should make sure that this 15 percent slower version of quake2 that everyone will be RUSHING to install, is only compatible with itself and not prior clients.

Yes, but consider this: How can you keep the 2% of people that can recompile the beast to play with the prior client/servers, since it is all GPLd code? And to share the compiled client with the others? :/

My Question...

[evil-osm]

Where can I get a copy or at least the list of updated optimizations to the native version? I'd love to get it to run 15% faster on my P200 that I have for Q2.