Scott Currie - Demo of Quake on .NET

Wow.. Try *that* in a Java Virtual Machine..

http://www.bytonic.de/html/jake2.html

http://sourceforge.net/projects/quake2java/

Manip2-

True, but did they simply add a switch to their compiler to do it?

(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?)

Great, now do that to Freelancer

This one I downloaded. I was very impressed with the CLR version of Quake and now a short documentary film goes into my collection!

Very interesting.

I'm a big Quake II player

"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.

http://www.bytonic.de/html/jake2.html

Holger

BTW, Quake2.NET is available at http://www.vertigosoftware.com/Quake2.htm

I remember eagerly waiting for quake 2, bought on the launch date and after 1 hour of playing , It did go to my cd's basket hell to never return.

mc.schroeder wrote:

BTW, Quake2.NET is available at http://www.vertigosoftware.com/Quake2.htm

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...

In the meantime, here are some instructions for building your own Quake3 mods in VC.NET:
http://guildhall.proboards15.com/index.cgi?board=Programing&action=display&num=1058561798

ok,
aq

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

One of these days, I'm going decompile it the Quake2 managed exe into C#, my preferred language.

Seriously, was there any reason for using C++ over any other language?  Aside from the fact that the original Quake code was likely C++ and porting it to C++.NET was the shortest path.

What is the deal with performance? Is C++.NET the best?

Why would there be performance hit on Pentium 4, but no performance hit on Pentium 3 or Centrino for C++ in CLR?

One would think that it would be the other way around.

"What is the deal with performance? Is C++.NET the best?"

Yes it is!

Frankie Fresh wrote:

path.

What is the deal with performance? Is C++.NET the best?

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?

Frankie Fresh wrote:

Seriously, was there any reason for using C++ over any other language?  Aside from the fact that the original Quake code was likely C++ and porting it to C++.NET was the shortest path.

Since the original source code is all C++; this was 'merely' loading that code base into a Visual C++ solution, build it (fixing some issues), test it (fixing some other issues) and TADA... Quake.NET

I would assume that taking the C++ code and converting it to C# would take as much effort as the Java implementation.

Frankie Fresh wrote:

What is the deal with performance? Is C++.NET the best?

Yes, the C++ compiler still has some very nifty tricks up its sleeve. It is still the best compiler around. But that might change when all compilers (including the JIT) move to Phoenix:

Kang Su Gatlin - "Phoenix," next-generation compiler

On a semi-related note, for those of you using managed code

http://channel9.msdn.com/ShowPost.aspx?PostID=20577

And for those of you feeling smug about having Windows XP SP2:

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. 

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.

Varsity wrote:

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.

Question to those in the know,

Scott said in the video you could get a 10% increase in performance on a Centrino by compiling to MSIL. Is this true of all .NET languages or is it only true of VC++ .NET?

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.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

KSG wrote:

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. 


Thanks,

Kang Su Gatlin
Visual C++ Program Manager

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?

I'd assume that the steps to convert this version would be much the same as for Quake 2.

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.