As I mentioned before, I've left Microsoft and joined Google. While I hope to continue playing with games and game technologies, I probably won't be posting as much on Xbox topics.

Because of my new job, I've decided to switch my main programming blog to http://grammerjack.blogspot.com/ . Nothing wrong with spaces.msn.com, I just thought it would be best if I learned how to use my new employer's blog software.

I recently bought a Mac Mini to hook up to my HDTV, so that I could watch TV and videos that I recorded on my Media Center PC. I had been using an Xbox 360 to do this, but it died from the "Red Ring of Death", and while the 360 was being repaired I thought I would try the Mac Mini.

On paper the Mac Mini seemed to be a good choice:

• Very small
• Fairly quiet
• Very powerful Core 2 Duo CPU.
• Not too expensive
  
• Comes with a cute little Apple remote control
• Can run Mac OS or Vista, or both.

Why not an AppleTV?

The AppleTV is specifically designed for the purpose of connecting a computer to the TV and playing back videos. Why didn't I choose it?

• Primarily intended for buying TV shows through iTunes.
  
• Only a few codecs are supported, so you are restricted as to which downloaded videos you can watch.
  
• No integration with Windows Media Center.
  
• Not expandable
• Difficult to program.
  

Connecting the Mac Mini to an HDTV:

• It's easy to hook up the Mac Mini's DVI to a HDMI-compatible HDTV. (I bought a $7 DVI-to-HDMI cable with free shipping from an Internet store - it works great. I also used an old PC audio jack to RCA converter cable I had laying around.)
  

I tried using it with the Apple OSX operating system, but it was frustrating for these reasons:

• I have a Windows Media Center that I use as a Tivo to record and watch TV. Apple OSX doesn't interoperate with Windows Media Center very well.
  • First try was Front Row
    • Front Row has a nice UI, and works with the nifty Apple Remote control, but has two fatal flaws
    • Takes a very long time to enumerate media on remote disks. (45 seconds for 100 files)
    • No out-of-the-box Quicktime support for many codecs.
    • The Perrin plugin helps a lot with most codecs
      
    • Couldn't find any way of playing ms-dvr files in QuickTime
  • Second try was VLC
    • Good news: supports all media types, including ms-dvr
    • Does not work well with Apple Remote Control. (Can't easily browse file system, choose media.)
    • Fundamentally the Apple Remote Control has too few buttons to be useful.
    • And the shareware apps for using the Apple Remote are not very good.
  • Third try was Elgato's Mac specific DVR software
    
    • For this I was going to bypass Media Center, and use the Mac Mini as its own DVR
    • Lacks a 10-foot UI, designed mostly to be used with a mouse.
      
    • Biggest problem: no keyword recording. (i.e. can't say "record all occurrences of figure skating")
  • I briefly considered alternative DVR products like Myth TV and Sage TV
    
    • Complicated to install and maintain.
    • No record-by-keyword feature
    • Concerns about having to pay a fee for TV listings, or have to futz endlessly with screen-scrapers.
• OS X talk to my existing CX-3800 All-in-one scanner/copier/printer.
  • The Epson site claims to have Mac support the CX-3800, but upon closer inspection the support is only for a utility program, not for a printer driver or a scanner driver.
  • Apple's printer drivers don't support this model.
• I briefly considered ditching Vista Media Center in favor of DVR software that would run on Mac or Linux. But that didn't work out either:
  • It's very difficult to get a free TV listing service for OS X or Linux DVR applications
  • Apple OS X and Linux support for the HD Home Run remote HDTV tuner is weak.
  • Even the best Mac DVR software, from ElGato, is feature-poor compared to Vista Media Center Extender.
    • In particular it's missing the keyword recording feature that allows me to record any occurence of "Skating" or "Gymnastics" for my wife, who is a big fan of these sports.
      

In the end I gave up on using OS X for a DVR. I went back to using an Xbox 360 and Vista Media Center.

I need to use Linux for my new job, so I decided to try and install it on one of my home computers. I chose my Apple Macbook as my test platform, which was risky because Linux is much more mature on desktops than on laptops. Since I'm addicted to beta software, I tried the latest Ubuntu 7.10 Tribe 5, which is a beta version of the popular Ubuntu distribution.

Some good impressions

• The new Compiz window manager is enabled by default and is very nice. Like Vista Aero, but simpler.
• The Macbook was almost completely supported out-of-the-box.
  • Both graphics and wireless worked.
    
  • I only had to make two changes, both related to the trackpad:
    
  • I had to turn off the tap-to-click. It's just too sensitive, kept thinking I clicked when I was just moving the mouse around the screen.
  • I had to install the mouseemu package to make F11 be the middle mouse button and F12 be the right mouse button.
• The whole Linux package installer approach is great. It makes it very easy to install software, even easier than on Windows.
  • However, it's harder to find software than on Windows. There ought to be a way of clicking on a link in a web page and automatically starting the install process, like there is on Windows or Mac.
  • And there's still too much politics about licenses - it's more difficult to install Java, Flash, and media codecs than it should be because of this.
  • Speaking of codecs, I liked how the Ubuntu media players would try to find and install codecs to play unknown media file types.
    
• I was able to find Linux programs for most of my needs:
  • Web surfing / Email / Documents: Firefox with Google apps
    
  • Bit torrents: ktorrent
  • CBR reader: qcomicbook
  • IDE: Eclipse
  • Videos: VLC
  • Photo editing: Nothing good here yet. Gimp sucks. Paint .NET may be my best bet.
  • I haven't tried printing yet. We'll see how it goes.
• So far I haven't had to edit a single text configuration file, and I only had to mess with the command line a couple of times. It's almost possible for a non-programmer to configure Ubuntu, at least if nothing goes wrong.
  

Some bad impressions:

• There's lots of out-of-date information on configuring Ubuntu the web. I guess this is the unavoidable result of frequent releases, but it makes solving problems much more difficult than it needs to be.
  
• The Ubuntu brown color scheme is ugly. It's too bad it's such an integral part of their branding, because it is a huge turn off.
• The Ubuntu gnome desktop menus are poorly organized. They're also full of crapware applets.
  
• The default Ubuntu desktop UI has bars on both the top and the bottom of the screen, which steals too much vertical screen space on an 800-pixel-high laptop screen.
• The synaptic application installer sometimes puts up dialogs that are more than 800 pixels high, making it impossible to hit the OK or Cancel buttons on a small screen.

Conclusions

In 12 to 18 months I think Ubuntu is going to achieve usability parity with Vista. There are already ahead in some areas, such as application installation. Of course, that won't do anything to help with compatibility with Windows applications, so Vista will remain the OS of choice for many people. But if the trend towards web-based applications continues, I can see Ubuntu becoming a viable choice for many computer users in the next two to five years.

Right now, if I were a Linux zealot, I think I would work on

• Improving laptop features, specifically power management, and suspend/resume, and trackpad support.
• Providing a good-UI free alternative to PhotoShop, possibly based on Paint .NET
• Continuing to improve the desktop UI experience.
  

My Xbox 360 is back, or rather, they sent me a new Xbox (built in May 2006, so no Falcon HDMI love), which unfortunately means my cool green side panels are lost forever.

The new box seems louder to me, but my wife says the old one was just as loud. She may be right.

...just in time for Halo 3 (Woot!)

Hah, poetic justice. I worked on the Xbox 360 launch team, and today my Xbox 360 Launch Console died with the "Red Ring of Death". It actually started freezing  during game play last week, and the freezes just got worse and worse, until today it wouldn't even turn on.

I am very happy that Microsoft recently decided to extend the Xbox warranty program to cover the "3 red lights" error code problem for three years rather than the original one year.

Now I just have to live without my Xbox 360 for the 6-8 weeks it takes to repair it. (The Xbox customer support rep said it was pretty likely that I would get my original plastics back, which I hope is true because I have a special "launch team" case.)

I should hopefully get it back in time to play Halo 3. :-)

I was stumped for an hour today by trying to get a C++ OpenGL GLUT application to compile on OS X using the Eclipse CDT IDE. (Is that a lot of acronyms, or what? :-) )

It turns out that if you use a web search engine, you can find several other people plaintively asking how to do this, but no actual answers. (This is apparently because most Macintosh C/C++ developers use the Macintosh-specific XCode IDE instead.)

In the hopes of helping out future web searchers, here's the answer:

There are two issues:

• On OS/X the GLUT headers are in a non-standard directory, so you must use:

• On OS/X the way you specify libraries to the linker is to use "-framework NAME".You do this in Eclipse by:
  1. Right-click on your Project's icon in the "Project Explorer" pane.
  2. Choose "Properties" from the context menu
  3. Choose "C/C++ Build:Properties" from the dialog box tree view.
  4. Choose "Tool Settings" from the tab list
  5. Choose "Mac OS X C++ Linker : Miscellaneous"
  6. Add the following text to the "Linker flags" field:

The only thing I haven't figured out yet is how to get the "Outline " browser to understand where the OpenGL and GLUT include files are located.

I finally got my first HDTV. It's a Sony 40V2500, which is Sony's cheapest 1080p model. I paid $1525 from an online computer retailer. I've had it for a week now, and so far I like it a lot.

The reason I chose this model was:

• I wanted a display in the 40 to 42 inches range, because my main TV watching room is not very big.
• I wanted an LCD display because I have a very bright room, and I don't want to bother with blackout curtains.
  
• I wanted 1080p for high-end video games and computer use.
• I wanted a Sony because I like their attention to details in terms of signal processing, analog tuning, and display quality.
• I wanted to spend about $1000. (OK, I went over budget by 50%. :-) )

Things I like about this TV:

• Very nice picture
• It just works.
• Light enough to move by myself.
• The menu is good. This is is the last generation of Sony TVs that doesn't have the pretty-but-hard-to-use "cross-bar" menu UI.
• Nice simple remote control.
  

Things I don't like about this TV:

• Doesn't do 1080p over component inputs, just over VGA/HDMI.
• Doesn't have two antenna/cable inputs; you have to switch between cable and antenna decoding.
• It runs Linux. (Oh, wait, I don't work for Microsoft any more, so it's OK to use Linux. :-) )
  

My tips on online HDTV shopping:

• Information
  • avsforum.com is a great source of advice and tips on the latest models.
  • hdtvtest.co.uk has some good in-depth reviews of HDTVs,
  • cnet.com does good not-in-depth reviews of HDTVs.
  • Unfortunately there are so many HDTV models that nobody is able to review them all.
• Prices:
  
  • nexttag.com is good for finding a low price.
    • I especially liked the graphs they have showing how the lowest price has changed over time.
  • pricewatch.com and pricegrabber.com are good alternatives to nexttag.com, that sometimes include stores that aren't on nexttag.com. (I happened to find the lowest price on pricegrabber this time.)
    
  • Be sure to look at the total price, including shipping and tax. Most of the online price web sites let you enter your zip code and then automatically compute the total price for you.

My Macbook battery died this week. No advanced warning, it just wouldn't charge. As a result my Macbook thought it didn't have any battery installed. I took my Macbook to the Genius Bar at the Apple Store, and they replaced the battery, free of charge, even though my Mac was purchased 13 months ago. They did ask me if I had installed the Macbook Battery Update, but alas I hadn't. (I wonder why they didn't make it a standard download, as part of their system software update.)

I think the Apple Genius Bar is worth it's weight in gold, especially to non-technical users. It's so much easier than mail-in or home service, at least if you live near tan Apple Store. I happen to live 1.5 miles from my Apple Store, which I suspect is closer than most Apple owners. :-)

The Mac store was crowded, as was the whole mall, due to a local heat wave. There was a small crowd around the new iPhone. People seemed to like it. I played with it for a few minutes on the way out. My impressions:

• The UI is great, especially
  • The very flat menu system. One click gets you into most apps.
  • The two-fingered pan/zoom works great for photos and browsing.
  • Snappy response to most user actions. Oddly, launching the video player takes a long time. (Maybe they're doing a pre-roll before showing the UI?)
    
• The touch screen typing works OK, but it's not great. I made plenty of mistakes, especially in the portrait mode with the smaller buttons. None-the-less I think it's adequate.
  
• The screen is very nice. Very good off-angle viewing. No ghosting. Nice contrast.
  
• The physical design is very nice, but I think there are a few problems:
  • It's too slippery. I dropped the phone within the first 20 seconds of holding it. (Admittedly it was greasy from all the other customers.)
  • The phone screen gets smeared up from touching it.
    
  • It's thinner than it needs to be. I think it could be fatter/cheaper and people would be just as happy with it.
• I didn't get to try real web browsing or phone. So no idea how bad the EDGE wireless speeds are.
  

Kyle Wilson wrote a very good GDC 2007 trip report. (The kind I would have liked to have written, had I attended this year):

http://gamearchitect.net/Articles/GDC2007.html

Well, now that I've spent a couple of months coming up to speed in the non-Windows world, here are some of my impressions:

• Firefox with addons is tolerable for web browsing. I use these addons:
  • AdBlockPlus - superb ad removal tool. If everyone used it the web economy would collapse due to no more advertising revenue, but it sure makes web surfing nicer.
  • myFirefox - a theme that makes Firefox almost look and feel like IE7.
  • The Google toolbar - helps make searching better with auto-suggest, shared bookmarks, click-on search terms.
• XCode and Eclipse are tolerable alternatives to Visual Studio + VisualAssist
  • They are pretty clunky, buggy, and feature poor, but they're better than Emacs + gdb.
• Java is a tolerable alternative to C#.
  
• GMail is actually pretty good, especially at dealing with threaded conversations.
  • I wish you could automatically sort searches by sender -- it would make dealing with checkin mailing lists much faster.
• Google Notebook is a good replacement for OneNote for me.
• Google docs are a good replacement for Office for me. But I hardly write any docs any more.
  

I have Parallels, which allows me to use Windows XP on my Mac. So far the main use I have for XP is to run "Paint .NET" when I need to create icons. There doesn't seem to be a good free paint program on Mac/Linux -- I assume the Mac paint program world is a wasteland due to the ubiquity of Photoshop.

Some things I like about Macs:

• They really are simpler to administer.
• The whole UI experience seems "quieter". Many fewer dialogs popping up.
  
• My MacBook Pro goes into sleep and comes out of sleep pretty reliably. I get about one crash a month. That's better than any Windows laptop I've used.
• Darwin Ports (an app-get utility) makes it relatively easy to install new software packages.
  

Some things I don't like about Macs:

• The wireless networking UI is clunky and error-prone. It has 30 second delays built into it, without any user feedback.
  
• The anti-aliased font rendering sucks compared to Windows. It's too fuzzy, especially on small-sized fixed-width fonts.
• Putting the application menu bar on the top of the screen is a dumb idea in today's world of giant screens.
  • Similarly, click-to-receive focus rather than click-thru is a poor UI choice once you are running multiple apps.
    
• One button mice and track pads are hard to use. The two-finger partial work-around for trackpads helps a little.
  
• The dock takes up too much space. And you can sort-of hide it, but you can't turn it off.
• Only being able to resize a window from the bottom right is a pain.
• The Mac distinguishes between multiple windows in one app and multiple apps. The Alt-Tab feature only switches between apps. You have to use Alt-back-quote to cycle within one App. This is dumb in the age of web-based apps because, to the user, each separate browser window is a separate App.
  

All in all I still haven't adjusted completely, especially in the IDE area. Unix users seem to revel in hard-to-use IDEs. But I am gradually getting used to the new world order. For example I no longer have trouble using "Command" rather than "Control" to copy-and-paste text or close windows.

I finally got a chance to try out the Nintendo Wii. (No, really! Many Xbox team members own Wiis, but they never brought them into the office. As opposed to PS3s, which were brought in immediately. I think this is because the PS3 is more direct competition to the Xbox 360, and also because people were playing their Wiis much more than their PS3s.)

I played about an hour of Wii Sports with my kids and nephews. The bowling game was very accurate. I had the same problems in Wii-land that I do in real life, namely putting too much spin on the ball, so that it curved to the right.

The relatively low-quality Wii graphics are good enough for "symbolicly rendered" games like Wii Sports, even on a large screen TV. If I had a Wii and played a lot of Wii Sports, then I would want a large screen TV, just so my real-world field-of-view matched the game graphics. I bet Wii motivates quite a few HDTV purchase for this reason. It is unfortunate that so many Wii owners will be watching the Wii stretched horizontally, due to playing 4:3 aspect ratio games on 16:9 screens.

The Mii avatar system is a killer feature. The other consoles should copy it.

The sound-in-the-controller feature is not very useful, as the speaker is too quiet to hear during normal play.

I bet next-gen Wiis will have LED sensors on both ends of the controller, to allow 360 degree position sensing, rather than the 180 degree position sensing in the current system.

And finally, I'm not sure I'm going to get a Wii for my family -- my kids loved it, but they kept accidentally whacking each other and the furniture with the Wiimotes when they got excited while playing the games. Maybe when they're older.

I'm using Macs a lot at my new company, and one thing that really bugs me is the relatively poor quality of anti-aliased fonts on OSX, compared to recent versions of Windows. I found this to be especially true for fixed-width fonts used in programming IDEs. The default fixed-width font, Monaco is just a blurry mess at small point sizes, especially for characters like "=".

A bit of web searching brought me this excellent web page that describes a variety of alternative fixed-width fonts available for the Mac, with some handy screen shots to make it easier to choose one:

http://www.cfcl.com/vlb/h/fontmono.html

After viewing that page I was almost tempted to use one of the gaudy Celtic or pseudo-handwriting fonts listed there, but in the end I chose the Osaka regular-mono font, because it looks good and it's actually installed by default on Macs, as part of the Japanese language support.

Osaka seems to rasterize much more cleanly than Monaco at equivalent point sizes. Osaka does have the down-side of being very tightly packed vertically, so you might want to add some extra space vertically if your program lets you do that.

(I like using Anadale Mono on Vista, but it just doesn't look as good on the Mac as it does on Vista. This would seem to indicate that Microsoft's font renderer is better than Apple's, at least at small font sizes. Good for them!)

Now to run on the 360. First, you need to set up your Xbox 360 and PC to run regular C# XNA games. That's beyond the scope of this article, but you should be able to find directions on the XNA Game Studio Express web site. I'm going to assume you've already created and run the sample C# games on your Xbox 360, so that you have everything configured correctly.

Now, in order to run your F# game on the Xbox 360, you'll need to make these changes:

• Your F# source file will need to reference the Xbox 360 versions of the XNA GSE DLLs.
• You'll need to compile your F# game DLL as a standalone DLL so that it doesn't try to reference other F# support DLLs that haven't been copied to the 360
• You'll need to create an "Xbox 360 Game" XNA GSE project rather than a "Windows Game" XNA GSE project.

Let's go over that process in detail:

Step 1: Modify the F# game.fs file you created in Part 2:

Change this line (that's near the beginning) from the Windows path:

#I @"C:\Program Files\Microsoft XNA\XNA Game Studio Express\v1.0\References\Windows\x86"

To the following lines, which conditionally use the correct path, depending upon whether we're compiling for Windows or for Xbox 360:

#if XBOX360
#I @"C:\Program Files\Microsoft XNA\XNA Game Studio Express\v1.0\References\Xbox360"
#else
#I @"C:\Program Files\Microsoft XNA\XNA Game Studio Express\v1.0\References\Windows\x86"
#endif

 Step 2: Compile the F# DLL as a standalone DLL:

• Add the --standalone option to compile the DLL as a single DLL that doesn't need any F# runtime DLLs.
• Use --define to define the symbol XBOX360 so that the proper #I path is referenced.
• Use -o to give the Xbox 360 game DLL a different name. This makes it easier to develop for both platforms at once.

"C:\Program Files\FSharp-1.1.13.8\bin\fsc.exe" -a -g --standalone --define XBOX360 -o game360.dll game.fs 

 Step 3: Create an Xbox 360 Game XNA GSE project:

1. Choose the menu item Start:All Programs:Microsoft XNA Game Studio Express:XNA Game Studio Express
2. Choose "File:New Project"
3. Choose "Xbox 360 Game"
4. Click "OK"

Step 4: Add your F# DLL to the Xbox 360 Game XNA GSE project

1. Choose the menu item "Project:Add Reference..."
2. Choose the "Browse" tab from the "Add Reference" dialog
3. Use the file dialog to select the "game360.dll file that you created in step 2.
4. Press the "OK" button to dismiss the "Add Reference" dialog.

Step 5: Write some C# code to call your F# game

1. Remove the "Game1.cs" file that was automatically added to your F# project. Do this by
   1. Right-click on "Game1.cs" in the "Solution Explorer" window, and choose "Delete" from the context menu
   2. Press the "OK" button in the delete confirmation dialog.
2. Replace all the text in the Program.cs file. Do this by
   1. Double-click on "Program.cs" in the Solution Explorer
   2. Choose menu item "Edit:Select All
   3. Choose menu item "Edit:Delete"
3. Add the following text:

namespace MyGame
{
    static class Program
    {
        static void Main(string[] args)
        {
            Game.main(); // Call our F# "main" function.
        }
    }
}

Step 6: Compile and run your game on the Xbox 360

1. Choose the menu item "Build:Build Solution"
2. Choose "Debug:Start Debugging"

That's all there is to it!

I hope you've enjoyed these posts. If you're interested in the F# language, a good resource is hubFS: THE place for F#

FAQ

Q: Can I use this call-a-DLL approach to write Xbox 360 XNA Game Studio Express games for other non-C# CLR languages like Iron Python or Visual Basic?

A: Unfortunately no, not for those two specific languages. (Sorry!)  The reason is that the Xbox 360 version of the XNA GSE CLR is based on the .NET Compact Framework 2.0. This is a problem for Iron Python and Visual Basic because those particular languages rely on CLR features that are not present in the .NET Compact Framework 2.0. Therefore you will get a runtime error when you try and run your Iron Python or Visual Basic code on the 360. It's possible that future versions of either the languages or the Xbox 360 GSE runtime will fix this problem. (But don't hold your breath -- nobody has promised anything in these areas. Only C# is officially supported for XNA GSE games.)

Note that this limitation to run on top of the .NET Compact Framework only applies to the Xbox 360 version of your game. Although I have not tried it, I believe that it should be possible to use a variation of the techniques in Part 2 to run Iron Python and/or Visual Basic XNA GSE games on Windows.

Alan Phipps has written set of tutorials on Using Visual Basic with XNA GSE on Windows

Q: Have you written an Xbox 360 game in F#?

A: Yes, a small game "Dandy Dungeon". I haven't had time to clean up the sources for publication yet. You can find the sources to an early non-XNA version of this game on hubFS.

Q: Why are you messing around with F# anyway? Isn't C# cool enough for you?

A: I love C# (and I do most of my day-job programming in either C# or C++), but I'm attracted to F# for it's brevity and its neat-o functional programming language features. It's also a lot of fun to watch the language evolve and improve.

In Part 1 we saw how to create a simple stand-alone F# game based on XNA GSE. But the stand-along game had two limitations:

• It couldn't use the XNA GSE Content Pipeline to build art assets.
• It couldn't be deployed to the Xbox 360.

The reason for both of these limitations is that the approach we took avoided using Visual C# Express. In order to get around the limitations, we have to bring Visual C# Express into the picture.

Unfortunately, we can't just create an F# project in Visual C# Express. For one reason or another, Visual C# Express only supports compiling C# source files. However, there is an escape hatch: Visual C# Express allows you to reference any number of DLLs, and those DLLs can be written in any language. Even better, the Visual C# debugger works fine with DLLs written in any .NET language. So our strategy is:

• Compile our F# code as a DLL.
• Create a Visual C# Express XNA GSE project
• Add a Reference to our F# game DLL
• Call the F# game code from the main C# file.

That's all there is to it! Let's go through the process step by step in more detail:

Step 1: Configure Visual C# Express to expose advanced features:

1. Choose the menu item Start:All Programs:Microsoft XNA Game Studio Express:XNA Game Studio Express
2. Choose menu item "Tools:Options"
3. Choose "Projects & Solutions:General"
4. Check the "Show advanced build configurations" checkbox
5. Press the "OK" button
6. Choose the menu item "File:Exit"

Step 2: Write our F# code. Use the text editor of your choice to write the following F# code.

NOTE: This version of game.fs is slightly different than the game.fs file in the previous post. The difference is that we do not call the main() function at the end of the file. (Instead we will call it from the C# code in a C# project that we create in a later step.)

// An XNA game in F#. Part 2: As a DLL

#light

#I @"C:\Program Files\Microsoft XNA\XNA Game Studio Express\v1.0\References\Windows\x86"

#r "Microsoft.Xna.Framework.dll"
#r "Microsoft.Xna.Framework.Game.dll"

// Not all of these opens are required for this sample, but you will need them to write a full game

open Collections
open Compatibility 
open Idioms
open Microsoft.Xna.Framework
open Microsoft.Xna.Framework.Audio
open Microsoft.Xna.Framework.Content
open Microsoft.Xna.Framework.Graphics
open Microsoft.Xna.Framework.Input
open Microsoft.Xna.Framework.Storage
open System
open System.IO

type MyGame = class
    inherit Game as base
    
    val mutable graphics : GraphicsDeviceManager
    val mutable content : ContentManager
    
    new() as this =
        {
            graphics = null
            content = null
        }
        then
            this.graphics <- new GraphicsDeviceManager(this)
            this.content <- new ContentManager(this.Services)
    
    override this.Draw(gameTime) =
        let gd = this.graphics.GraphicsDevice
        gd.Clear(Color.Green)

    end
    
let main() =
    let game = new MyGame()
    game.Run()

Step 3: Save the F# file as "game.fs", and then open a cmd.exe shell window and compile the game as a DLL using the F# compiler:

"C:\Program Files\FSharp-1.1.13.8\bin\fsc.exe" -a -g game.fs

The -a flag means "create an assembly", which is the CLR name for a DLL. The -g flag means "add debugging information", which lets you step through your F# code in the debugger.

Step 4: Create a Visual C# XNA Game Studio Express project

1. Choose the menu item Start:All Programs:Microsoft XNA Game Studio Express:XNA Game Studio Express
2. Choose "File:New Project"
3. Choose "Windows Game"
4. Click "OK"

Step 5: Add your F# DLL to the XNA GSE project

1. Choose the menu item "Project:Add Reference..."
2. Choose the "Browse" tab from the "Add Reference" dialog
3. Use the file dialog to select the "game.dll file that you created in step 2.
4. Press the "OK" button to dismiss the "Add Reference" dialog.

Step 6: Write some C# code to call your F# game

1. Remove the "Game1.cs" file that was automatically added to your F# project. Do this by
   1. Right-click on "Game1.cs" in the "Solution Explorer" window, and choose "Delete" from the context menu
   2. Press the "OK" button in the delete confirmation dialog.
2. Replace all the text in the Program.cs file. Do this by
   1. Double-click on "Program.cs" in the Solution Explorer
   2. Choose menu item "Edit:Select All
   3. Choose menu item "Edit:Delete"
3. Add the following text:

namespace MyGame
{
    static class Program
    {
        static void Main(string[] args)
        {
            Game.main(); // Call our F# "main" function.
        }
    }
}

Step 7: Compile and run your game

1. Choose the menu item "Build:Build Solution"
2. Choose "Debug:Start Debugging"

That's all there is to it!

The benefits of this round-about approach are

• You can use the Visual C# Express debugger to debug your F# code.
• You can use the Content Pipeline in to build and load your art assets.
• You can deploy to the Xbox 360.

Coming in part 3: Changes needed to support Xbox 360 development.

This blog entry explains how to write XNA Game Studio Express games in the F# programming language. To begin, let me explain what "XNA GSE" and "F#" are:

• XNA Game Studio Express is a product from Microsoft that enables you to write video games for the Windows and Xbox 360.
  • The tools are free.
  • Running XNA GSE games on Windows is free.
  • The only thing that's not free is that you need a "XNA Creators Club" subscription to run games on the 360.
• F# (pronounced F-sharp) is a new programming language being developed by Microsoft Research
  • It's based on the ML language family, specificly the O'Caml dialect.
  • It runs on the .NET Common Language Runtime, the same as C# or Visual Basic.
  • It's briefer and more expressive than C#.
  • It's free, and it's regularly updated with powerful new features.

In this series of articles, I'm going to show how to:

1. Part 1: Create a trivial F# XNA game that runs on Windows
2. Part 2: Modify the game to work with the XNA Game StudioExpress IDE
3. Part 3: Modify the game to on both Windows and Xbox 360

Let's get started with creating a trivial F# XNA game that runs on Windows. (And by trivial I mean really trivial: the game just draws a blank green screen.)

Step 1: Download and install Visual C# Express: Visual C# Express Home Page

Step 2: Download and install XNA Game Studio Express: XNA Game Studio Express Home Page

Step 3: Download and install F#: F# Home Page

Note: These articles are for F# version 1.1.13.8. Earlier version's won't work, later versions might work.

Step 4: Create an F# source file using your favorite text editor:

// An XNA game in F#

#light

#I @"C:\Program Files\Microsoft XNA\XNA Game Studio Express\v1.0\References\Windows\x86"

#r "Microsoft.Xna.Framework.dll"
#r "Microsoft.Xna.Framework.Game.dll"

// Not all of these opens are required for this sample, but you will need them to write a full game

open Collections
open Compatibility 
open Idioms
open Microsoft.Xna.Framework
open Microsoft.Xna.Framework.Audio
open Microsoft.Xna.Framework.Content
open Microsoft.Xna.Framework.Graphics
open Microsoft.Xna.Framework.Input
open Microsoft.Xna.Framework.Storage
open System
open System.IO

type MyGame = class
    inherit Game as base
    
    val mutable graphics : GraphicsDeviceManager
    
    new() as this =
        {
            graphics = null
        }
        then
            this.graphics <- new GraphicsDeviceManager(this)
    
    override this.Draw(gameTime) =
        let gd = this.graphics.GraphicsDevice
        gd.Clear(Color.Green)

    end
    
let main() =
    let game = new MyGame()
    game.Run()

[<STAThread>]
do main()

 Step 5: Save the F# file as "game.fs", and then open a cmd.exe shell window and compile the game using the F# compiler:

"C:\Program Files\FSharp-1.1.13.8\bin\fsc.exe" game.fs

Step 6: Run the game by double-clicking on the "game.exe" or by typing "game.exe" at the command line.

That's all there is to it! However, is are some drawbacks to this approach. By bypassing Visual C# Express:

• We lose the ability to use the Content Framework to build our game's art assets.
• We lose the ability to run our game on the Xbox 360.

In the Part 2 of this article I will explain how to work around these problems.