Friday, May 27, 2005

Adding JScript.NET Macro Support to Your Application

I always have ideas for making FlexWikiPad better kicking around in the back of my head. Of course, I'm still cranking on getting basic functionality in place, so it'll be a long time before some of these ideas get realized, but it's still fun. One of the ideas that I thought about this morning was how to add macro support to the app, so people could add a little automation if they wanted to. Having been exposed a bit to Javascript lately, I've decided that it is an excellent language, with a great balance between power and ease of use...so it seems like a good choice for a scripting language to use from within FlexWikiPad. On thinking about it a little more, I decided that an even better choice is JScript.NET, which combines the niceties of the Javascript language with the power of the .NET libraries. Sweet.


I set out this morning to see if I could figure out what it would take to weld JScript.NET into a Windows Forms application. As it turned out, it was so easy to do, I didn't even need to look on the Internet to find one of the dozens of other implementations of this that must already exist. And it's too cool not to share. So here's the code:


using System.CodeDom.Compiler;
using System.Reflection;
using Microsoft.JScript;


// Create the compiler object
JScriptCodeProvider provider = new JScriptCodeProvider();
ICodeCompiler compiler = provider.CreateCompiler();

CompilerParameters options =
new CompilerParameters();
options.GenerateInMemory =
true;
// Generating an "executable" just means that the code will have an entry point, rather than simply
// being a collection of classes.
options.GenerateExecutable = true;
// Adding references is optional - mscorlib and Microsoft.JScript are automatically referenced
options.ReferencedAssemblies.Add("System.Windows.Forms");
CompilerResults results = compiler.CompileAssemblyFromSource(options, textBox1.Text);


// Run the newly generated assembly's Main method
Assembly assembly = results.CompiledAssembly;
MethodInfo entryPoint = assembly.EntryPoint;
entryPoint.Invoke(
null, new object[] { null } );


And that's it. The code above is the handler for a button I put on a form. The only other thing on the form is a multiline text box that holds the code I want to compile. In my case, I typed in


import System.Windows.Forms;
MessageBox.Show(”Hello world”);


as a simple test, but I could have used any valid JScript.NET program. Note that one of the benefits of JScript.NET is that it doesn't require me to explicitly create a Main method - anything at global scope will automatically be stuffed into one for me automatically. This sort of brevity is a real feature in a macro language, in my opinion.


As far as how to use this to achieve automation, that's the easy part: the way I've written this, the JScript.NET code will run in the same AppDomain as the application code that's calling it. So they can both easily access static members of any types they can both access. One way to handle this is to add this line of code


options.ReferencedAssemblies.Add(Assembly.GetExecutingAssembly().Location);


just before you call CompileAssemblyFromSource. That will make the generated assembly depend on the EXE that's calling it, allowing it to use any types that are defined within the exe. So for instance, a class like this in the application


public class Context {
 
private static Context _context;
 
private string _data;

 
public static Context Current {
   
get {
     
if (_context == null) {
        _context =
new Context();
      
}
     
return _context;
    }
  }
 
 
public string Data {
   
get { return _data; }
   
set { _data = value; }
  }
}


Would let me write macro code that looks like this


Context.Current.Name = "Craig";


and after the macro ran, I could retrieve the value “Craig” from within the EXE by simply reading Context.Current.Name. Or I could do the reverse, and set values in Context.Current before invoking the macro, and it would be able to read them. The possibilities are endless.

Wednesday, May 25, 2005

The Reports of Its Resurrection May Be Greatly Exaggerated

(With apologies to Mark Twain.)


There seems to be some opinion that the new version of Managed C++ is all that an a bag of Krispy Kremes. This may well be true - I've followed MC++ a bit, and they seem to have done a great job making this latest version a very powerful and elegant language. However, via Chris I see that at least some people think this means C# is dead. With that, I cannot agree.


See, technologies don't succeed because they're fast, or elegant, or powerful. If they did, Windows never would have made it to 2005. (Note, I'm not saying that it sucks. Just that it used to.)


No, technologies succeed for a whole bunch of reasons that have to do with psychology, not engineering. For example, did you program in C++ for three months one time without a debugger at a job you hated? If so, you'll probably have thoughts like, “I'll never program in C++ again as long as I live.” Even C++ had suddenly turned into something that looked exactly like C#.


The fact of the matter is, people really like C#, and - as far as I can see - are rarely unable to do what they want to with the language. The libraries come up short much more often than the language, but that's to be expected, as the sorts of things we want to do move higher and higher up the abstraction stack. And people generally see C++ as hard, truthfully or not. So my guess is that C++ may have gotten a whole lot better, but it probably isn't about to get a whole lot more popular.


If the new features that C++ is sprouting really were able to determine whether it would displace C#, we'd all already be programming in LISP.

Thursday, May 19, 2005

Defrag

It often happens that I run across a little corner of Windows that I never knew was there. So with Steve Rogers' recent post: why wasn't I informed previously that there's a command-line disk defrag tool built-in?

Tuesday, May 17, 2005

Physics for Game Programmers Reviewed

A short while ago, I posted that I'd just received Physics for Game Programmers. I was on vacation last week, and it seemed like a good book to read. So I did. And I really liked it. Herewith, my review.


First of all, I should point out again that this book was sent to me by the publisher, for free, presumably in the hopes that I would give it a favorable review here. I like to think that this doesn't bias me, but I wanted to make sure I pointed this out clearly in the interest of full disclosure.


The book is divided roughly into two parts. The first part deals with general physical concepts, like what happens when two objects collide, and the equations governing projectiles. As a guy with a Masters degree in Electrical Engineering, I know a fair amount about basic physics, and am pretty comfortable with math, but even still I definitely learned a few things. I could have used the bit about how rotating objects collide a few years back when I was writing a DirectX demo. One of the more interesting topics was the aerodynamic effect of spin on projectiles (think curveball).


The second part of the book is what you might call “applied game physics”. There are chapters on things like how to model cars, boats, and various sports games, using the principles outlined in the first part of the book. I thought this was a pretty reasonable approach. Although I'm not writing a game that requires this sort of simulation at the moment, if I were I think there would be plenty here for me to make use of. For example, I liked  the presentation of damage models for armored vehicles.


As far as the style of the book goes, I think that's actually where it really shines. The author has a way of explaining things that's thorough without being verbose. He also does a good job of keeping the scope limited to what I could actually fit in my head over the course of a week of relatively relaxed reading. As a result, the book weighs in at a reasonable 400 pages or so. I like that it's not an 800-page monster that tries to address everything under the sun.


There are a couple of places where I might have liked to see a bit more treatment of a particular subject. For instance, the author punts on the topic of three-dimensional collisions of rotating objects. This is a pretty reasonable compromise, particularly in service of keeping the book manageable, but because it's a topic that I've had to address in the past, I found myself somewhat disappointed to find it elided in the text. Still, I have to admit that there's enough material in there that I could likely work it out from what was presented.


One thing I should point out is that this is more a book about physics than it is about games. Although the author includes quite a few sample applications, they're hardly the sort of thing that you'd play on a Saturday night: they're more like simple demonstration programs. But again, in the service of simplicity, I see this as a good thing.


Speaking of simplicity, let me mention math. There's a fair amount of it in the book. The integral symbol appears a few times, and differential equations make a frequent appearance. This may challenge some people, but frankly, if you can't handle some math, you can't handle game programming anyway. And I think the author does a pretty good job of explaining the basics, although I may be a poor judge, since I was already familiar with all the mathematical concepts he presented. In any event, there's code that implements most of the equations he presents, which should help most people.


As a final note, the source code presented in the book is in Java. As a C# guy, I found this to be dead easy to read, so I never even bothered to grab the C# translation that's available on the website.


In summary, I definitely liked this book. It's a nice length, the style is pleasantly clear, and the material is a pretty good balance of depth and breadth. If you're writing a program where things fly through the air, collide, explode, or fall, this is a handy resource. Like I said before: “Physics. Games. Programming. What's not to love?”

Sunday, May 15, 2005

Saturday, May 7, 2005

When You Wish Upon a Star

On Thursday, I was reading David Weller's blog. He mentioned the book Physics for Game Programmers. I thought, “Physics. Games. Programming. What's not to love?” And since I started my vacation on Friday it seemed like it might be a fun book to read, so I decided I should pick it up. Well, when I got home that day, there was a package from Apress with the book inside. It seems that since they liked the review I wrote, I'm now on some sort of list. It's a good list to be on!


Of course, this does raise some interesting ethical issues: if I hate the book and say so, will they stop sending them to me? Hopefully I won't have to find out: so far the book is good. And I haven't even gotten to the chapters entitled “Explosions” or “Lasers” yet. :)


Update: my full review of the book is here.