Chris: Eschaton meets the first consideration, and is most of the way to meeting the third. ( "Eschaton" is the name of the 3D game I occasionally mention I'm doing the low-level object management code and compiler work for. We're going to have a booth at E3 :). )
Although, we can't handle that performance hit, so we don't call it a "performance hit". You just recompile everything you need to native code before you do anything with it, and suddenly it becomes a "cross-platform performance enhancement" (as you get to take advantage of any tricks that are available for compiling on a specific platform). Obviously, however, we aren't using Rotor or .NET for any of this (as no one seems to care about processor specific optimizations...), and have been slowly writing our own compilation back-ends. Then again, we are (self-admittedly) insane. We even target the graphics card this way (and have already gotten this part working). You can write pixel and vertex shaders in C# (calling extern functions that have been flagged with special attributes) and feed them into our compiler. We then run my decompiler back-end over that, generating an in-memory operation graph (in an intermediate format we call the "ShadeOp" system that existed before we bothered trying to abstract things with a language). That graph has optimization passes performed on it and gets transformed into GPU operations. In a sense, we are compiling MSIL down to the graphics card. The plan _is_ to have our own "language" (both one for writing procedural shaders, and one for the scripting code), but to continue to use MSIL as the intermediate format. Having something with well defined semantics is quite useful, and gives you a lot of power. You can crutch existing tools to help you debug things (like ildasm or Anakrino), you can crutch existing compilers to bootstrap the process of getting things done (as we have done with the C# compiler), you can even allow people to work with existing libraries that were written in managed code. Then again, it might be that MSIL itself is overkill. I've lain awake thinking about how terribly annoying the MSIL+PE combination is, and we've discussed that this entire plan might be a "bad idea". Our solution has been to keep a complete isolation between the MSIL front-end, the ShadeOp intermediate layer, and the compiler back-ends. If we do realize this is stupid, we just replace the front-end with our own byte-code format and Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] ----- Original Message ----- From: "Chris Sells" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 14, 2002 3:04 PM Subject: Re: [DOTNET-ROTOR] Rotor as a game scripting engine > The CLR ships with VB.NET and JScript "scripting engines" today, i.e. you > can feed an instance of Microsoft.JScript.Vsa.VsaEngine or > Microsoft.VisualBasic.Vsa.VsaEngine text that it will compile and execute. > > Personally, I'm curious what kind of game is complicated enough that it > requires a scripting engine, can handle the perf hit of using managed code > and is cross-platform (which, I'm guessing, is where the need to use Rotor > comes from). > > Chris
