September 30th., 2004
gameSWF is a promising open source project focused on bringing more rendering speed to Flash interfaces and animations.
By leveraging the power of 3d hardware accelerated videocards gameSWF is capable of running fullscreen SWFs at top speed leaving the standard Flash player in the dust.
Here follows an interview with its creator: Thatcher Ulrich.

Q:Could you describe what the gameSWF project is about?

It's about improving the quality of GUI's for console-type games,while reducing the programming effort required to build them.

Q: Can you tell us a little about your background as game developer and how did you come up with this project?

I spent a few years in the 90's making 3D games/simulations for exercise bikes. This was on 486's and early Pentiums, doing software rendering. There's a little bit of info on the products here:

Then I spent a couple years making a snowboarding sim, Soul Ride ( )

Three years ago I joined Oddworld Inhabitants ( ) and have worked on Munch's Oddysee and the
upcoming Oddworld Stranger.

Over the years I've implemented a bunch of simple menu systems for games I've worked on, as well as text/font rendering and 2D overlays. It's always been a pain in the neck to coordinate the programming work with the work of talented visual designers, and usually the results are a compromise.

Q: When did the project start and how many people initially worked on it?

I started by myself, around two years ago. I had casually thought about making some kind of SWF rendering library for some time before that, ever since I saw the spec at . Once I started, within a couple months I had a basic implementation of animated filled shapes, sprites and buttons.
I worked on it completely alone in the early going, and then I started to get patches and bug reports from Ignacio Castaño in early 2003. Since then I have still been responsible for the bulk of the code, but there has been a steady stream of patches from other programmers. All told around a half-dozen people have contributed code directly, and another half-dozen or so have sent in bug reports or small fixes.

Q: What is the current status of the project?

The project is usable, but has rough edges. I consider it pre-alpha. I will consider it "alpha" when most of the unneccessary overhead is eliminated, and when/if it can correctly render most random Flash 6 content off the web.

Q: Could you explain a little how the Macromedia Flash player renders the graphics and how gameSWF is different?

The most important difference is that the Macromedia player draws each pixel in software using the CPU. On the other hand, gameswf hands off all rendering to OpenGL, or a user-supplied rendering driver, which ends up using 3D accelerator hardware to actually draw the pixels. This means that on machines with 3D hardware, gameswf has much higher fill-rate compared to the Macromedia Flash player. Using gameswf on a modern PC, you can render large movies with lots of motion and lots of
transparent overlays. The Flash player will bog down pretty badly in those situations.

There are some drawbacks to the way gameswf handles things; it requires 3D hardware for decent performance, it does not normally
antialias the edges of shapes, text rendering is slightly fuzzier than with Flash, and there is extra overhead in preparing shapes to be rendered using 3D hardware.

Q: Are there any other accelerated players such as gameSWF available (both opensource or commercial)?

I've heard rumors of other accelerated players, for example in the Renderware package, but nothing I've been able to pin down to a webpage or see in action. Certainly no open source projects that I'm aware of.

There is a very nice open-source player under the GPL, called FlashSource, but it is software only, along the lines of the Macromedia player, and as far as I know it has not been actively updated for a while.

Q: What were the most difficult part of the project you had to deal with?

Compatibility. When I started, I thought that everything I needed to know was nicely described by . I was so wrong! There are endless details that are not captured in the spec. Granted, the openswf spec seems like it was written with SWF generators in mind, and for that purpose it served its purpose. A SWF renderer on the other hand needs to have very complete and exact behavior in order to deal with the variety of SWF content that's out there.

Some time after I started, I discovered Alexi's SWF Reference, at, which is more detailed and more up-to-date than

Nevertheless, a lot of the effort in gameswf has been generating test cases and trying them against the Macromedia player, to determine the exact behavior that's required.

Q: What part of the Actionscript set of instructions is currently supported?

There are a few missing opcodes, like "declare object", "type of", "get target", "enumerate", "new method", "instance of", "delete",
"multibyte char", "multibyte substring", "multibyte length", "set target expression". Many of those would be trivial to add, but I haven't run into them in my work so I haven't gotten around to doing the implementation, generating the test cases, and making them work.

A lot of the Flash library is missing. Again, this is mainly a matter of what I personally needed to get my work done.

Q: How much more speed is obtained using gameSWF? Did you do some benchmarks?

I haven't bothered with benchmarks so far, but that would be a useful thing in the future. Using 3D hardware, the fill rate of gameswf is so much faster than the Macromedia player that a comparison is kind of silly. Other things may be slower in gameswf; for instance, I need to preprocess fonts at startup time, which is not fully optimized and can cause some initial delay.

Q: What operating system is needed to run gameSWF?

I has been compiled and tested on Linux, Windows, and Mac OSX. It has been incorporated into an Xbox project also. The code is designed to be as portable as possible.

Q: What language was used to write gameSWF?


Q: Did you use any other open-source libraries in the project?

gameswf uses the zlib library and the Independent JPEG Group's jpeglib library to parse compressed parts of SWF files. It is possible to remove the hooks to these libraries, if you are going to preprocess your content to run on a game console, for example.

The sample player app uses SDL for rendering and sound output, and optionally libmad for parsing embedded mp3-format sounds.

At some point I may add optional FreeType support, so that gameswf can render "system fonts", i.e. fonts that aren't embedded in the SWF.

Q: In the gameSWF site you say that the tool can help in creating game UIs by using the SWF format. However many flash game developers are dreaming of creating full flash standalone games with it. Do you think it's possible to achieve it?

Sure; in fact if you can make your game run in gameswf's sample player, it would be pretty straightforward to bundle the content and
the player together. You could do it today with a .bat file to start up the sample player.

Doesn't Macromedia offer a product that does this? Called "Projector" or something like that? What would be the disadvantage of that?

Q: Many Flash game developers are pretty scared to use other tools/languages to create small standalone, downloadable games. However sometimes Flash is just not enough. What would you suggest as an alternative? Maybe Python or Java?

Hm. I've dabbled in scripting languages but at heart I'm a hard-core C++ person. I've been pretty impressed with some games written in Python using the Pygame library. I've never used Pygame itself, but Python is a very usable language so I might recommend trying Pygame first.

I've done some work with Lua in the past, and even wrote a little game to demonstrate an SDL binding. The game, "Meteor Shower", and the interpreter and libraries necessary to make your own games, is included in the LuaCheia project, at . Lua is a nice language, but the SDL bindings for Lua have not been around as long as Pygame, so this is going to have more rough edges.

I don't know if I would recommend Java for a standalone game. IMO the big problem with Java for that purpose is making sure you have the right Java runtime for the target machine. Making your users chase down a separate download is a bummer. And the runtime is very large, so it would bloat your download if you wanted to include it with the game itself.

Q: Is Flash popular among traditional(non web-based) game developers?

Well, everybody loves fun Flash games on the web, and a few game designers are comfortable using Flash to lay out prototypes of UI's. But I've discovered that few professional game programmers have tried Flash, because they already are comfortable with C/C++, which is usually more appropriate for their projects. And most game artists I know prefer to use Photoshop and Illustrator for 2D elements, and Max or Maya for animation.

But hopefully gameswf will enable more use of Flash.

Q: What are the future plans for gameSWF?

1. Better performance, both in speed and memory use. I want to eliminate most of the overhead of preparing shapes for rendering,
and tighten up the implementation in general.

2. Better output quality. Flash has really beautiful output with its antialiased shapes and text. gameswf needs a few improvements here and there to match or exceed this quality.

3. Compatibility.

On another note, I'm kind of baffled that there is no viable 3D alternative to Flash. Perhaps in the future I will experiment along
those lines.

back to SpotLight index

Have you played one of the best web games ever ?
Did you create the latest kick-ass flash game and would you like to seen it reviewed in these pages ?
Suggest us some high quality games to feature in our SpotLight!

Game suggestions HERE
| Homepage | News | Games | Articles | Multiplayer Central | Reviews | Spotlight | Forums | Info | Links | Contact us | Advertise | Credits |

| | | |

gotoAndPlay() v 3.0.0 -- (c)2003-2008 gotoAndPlay() Team -- P.IVA 03121770048