(Note: I do know why you posted that comment. It was in response to the comment insinuating that you couldn't do such a feat inside the Java Virtual Machine. Your comment made no reservations about the way the program was ported, only that it is indeed possible
to run Quake II inside the Java Virtual Machine. I am merely saying that the .NET version was a quick add-a-switch-and-fix-a-few-bugs addon, while the Java version required rewriting portions of the code in Java.)

(Note: Did you see that the quake2java link is in fact pointing to a project with an empty CVS and no released files?)

This so great. I think the C++ team is leading the way into the future. It's all about extending your current code base, the one that you worked so hard to perfect, the one that your customers love, the one, if it is an application that runs on Windows, is
most likely written in C++, to work seamlessly with our managed platform, paving the way for the advent of great features that are quick to produce and are also safe by default thanks to the CLR and associated technologies. Fantastic work. I am amazed.

"Porting" Quake to the .NET platform is no big deal. For the Java port we had to rewrite major parts of the code. We build a comletly new sound engine based on OpenAL which makes true 3D sound possible. And the best thing is Jake2 runs on Linux and OS
X too.

We tested this when it came out, I think last summer, and found less than 10% performance penalty on a base machine (1Ghz Athlon, 256Ram, TnT2). Ballpark 50 fps vs. 45 fps. Barely noticable to the user.

This demo was a major factor in our decision to use .NET for online game development.

Sooo, id Software recently announced that following the release of Doom3 they would open their Quake3 code base to developers. The Quake2 port took, I believe a few days? Can it be long before we see Quake3.NET...

Well Frankie, I'm a C-Sharper too. But AFAIK C++ .NET ability to having managed and non-managed clases within the same assembly, Now I've never seen the source code to Quake II, But that feature surely allows to do a lot of performance tunning. For instance,
non-managed arrays do not have all the boundary checks that the managed version sports... that can make the difference, don't they?

What is the difference between the .NET Framework service packs and Windows XP Service Pack 2?

The .NET Framework service packs are not the same as Windows XP Service Pack 2. Both the .NET Framework Service Packs and Windows XP Service Packs are part of a global Microsoft effort to make its products more secure. The .NET Framework Service packs are providing
security enhancements and bug fixes to the .NET Framework bits (that are compatible with several versions of the Windows client and Windows server operating systems). Windows XP Service Pack 2 is providing security enhancements and bug fixes to Windows XP.

"Porting" Quake to the .NET platform is no big deal. For the Java port we had to rewrite major parts of the code. We build a comletly new sound engine based on OpenAL which makes true 3D sound possible.

I think the point of the video is exactly that: that it wasn't a big deal. It was easy.

hoz wrote:"Porting" Quake to the .NET platform is no big deal. For the Java port we had to rewrite major parts of the code. We build a comletly new sound engine based on OpenAL which makes true 3D sound possible.

I think the point of the video is exactly that: that it wasn't a big deal. It was easy.

So it is not worth mentioning. It is still C++. As a matter of fact every C++ compiler should accept C code with minor modifications. The whole message is "The .net C++ compiler behaves in some way like a C++ compiler."

I remember looking at that and I was amazed that managed code could run that fast.

I don't think this is managed code, I think he said this is compiled with the /clr switch. Which means it can make calls to MSIL code, not that it's own objects are under control of the GC. I'm no C++ guru though, so take my comment with the appropriate
salt lick block.

That being said, the next versions ability to put any C++ type under GC controls using the GC new sounds very cool.

So it is not worth mentioning. It is still C++. As a matter of fact every C++ compiler should accept C code with minor modifications. The whole message is "The .net C++ compiler behaves in some way like a C++ compiler."

Hoz, I think you misunderstand the point. Moving legacy code to .NET or the JVM is one of the big pain points for anyone with a big app. In .NET with C or C++ code you add the /clr switch and now your app is a .NET application.

I think you're under the incorrect belief that this compile of Quake resulted in just normal native code. No the result of the recompile with the /clr option was MSIL (similar in some ways to Java bytecode). You can run ILDASM on the .exe to look at the MSIL
code.

Most importantly though is that now you can seamlessly add managed code to the Quake2 application. Recompiling for the sake of recompiling means nothing. The reason you go to .NET or JVM is because now you can leverage the benefits of the platform. In the
Quake2 demo they added a Winform radar directly into the application, just as you would have done in a C# or Java application -- but this was the same code you started with. Not a complete rewrite of the project.

What if I could take Doom3... the original code, throw the /jvm switch and now it was running on the JVM at 90% of the native code speed. And then I added some Java control to the game -- all easily. Now wouldn't you agree that this would be big news? Well
that's what you just saw with .NET.

I think you're under the incorrect belief that this compile of Quake resulted in just normal native code. No the result of the recompile with the /clr option was MSIL (similar in some ways to Java bytecode). You can run ILDASM on the .exe to look at the MSIL
code.

Ah, I misunderstood. I thought it was compiled to native code but was ".net aware" and could make calls out of MSIL code. Knowing that it's actually compiled directly to MSIL is very cool. But doesn't that mean that any proprietary algorithms are pretty exposed
in the MSIL?

Also, this doesn't mean that the original C++ code, even when it's compiled to MSIL, is managed it just means that it can make calls to other MSIL code right? The original C++ code is "unsafe" and is not under the control of the GC?

KSG wrote:

What if I could take Doom3... the original code, throw the /jvm switch and now it was running on the JVM at 90% of the native code speed. And then I added some Java control to the game -- all easily. Now wouldn't you agree that this would be big news? Well
that's what you just saw with .NET.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

Yeah, this was big news a year or so ago. I'm more excited by the managed DirectX demos that I see coming out with the SDK and from third parties.

But doesn't that mean that any proprietary algorithms are pretty exposed in the MSIL?

Yes and no. You can always obfuscate the generated MSIL. Also, remember that obfuscation of only sort only keeps honest people honest. The people who want to rip you off (and if their good engineers) will be able to do so. There's also an interesting paper
on code obfuscation, which proves that it's impossible to do a really good job on it (from a theoretical perspective).

The original C++ code is "unsafe" and is not under the control of the GC?

Correct. This does not make unsafe code become safe. Nor does it make the code GCed.

But, it does allow you to start directly using managed DirectX in your current C++ code base.

I seriously doubt that current games can be ported to "managed" code without performance loss: it would result in a game with a very low FPS and therefore not be playable. Games are performace based, and (native) c++ is faster then .net c++, as you can't
tweak .net code that much as you can do in c++. Thought, it could work on some higher level, so a mix could work, I think. But isn't your footprint larger if you mix it?

WOW, the "Mixed-Type" technology sounds..... amazing. Did that make it into Orcas? Or, 3.5 I assume is the .NET release for Oracas? How does the managed runtime handle things like free/delete's, etc in the mixed typing scenario? Would I need to manually
remove those or does it catch the call to free and handle it differantly? I would assume that I need to recompile against a 3.5 SDK to get this functionality, will any code changes be required?

In thinking about how you would do this in a way that doesnt require you to hack the entire os/stack... It sounds like the managed runtime would be starting up "native" processes in a Native-VM within the Managed VM? And then the new/malloc/free/delete's are
handled by that VM and proxied out to the Managed VM? Do you find that introducing GC enhances performance? I would imagine it would since you dont have to free with respect to an accessible stack (i.e. freeing a series of objects outside the loop as opposed
to handling each near the end of the loop).

Could the Quake II stuff run inside Rotor? I think it would be interesting to step through this and view the cross-system behaviour.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.