Month: January 2007

The game code was heavy on maths, so I have decided to pinpoint where the difference in performance is coming from. I found an AS3 performance test on [AS3 performace test](http://www.onflex.org/perf/) and ported it to hAxe – again, not necessarily perfectly.

You can check out the results here:

* [AS3 test](/?page_id=11)
* [haXe test](/?page_id=8)

The tests can be seen at [http://www.onflex.org/perf/srcview](http://www.onflex.org/perf/srcview).

As you can see, the haXe code is slower – sometimes a lot slower – than the AS3 code. Of note:

* Test 2 : sort. This is perhaps not surprising because the haXe version is using a custom string compare function, rather than a built-in one.
* Many of the functions are to do with string manipulation. I suspect the probelms here are introduced though the layering of the library via “Std.” and the internal string functions.
* Function 9, the loop code, shows a huge difference. Here I think there must be some loop optimisation that hAxe is missing out on.
* Function 12, a subroutine call, is also very very slow. I think there may be something simple that haXe is not doing.

So there you have it. Loops and function calls – building blocks of most programmes, are very slow.

These differences are way bigger than the file-size differences would suggest, so I think there is still hope that haXe speed can be greatly improved.

Well, as the URL of the site may suggest, my initial plan is to use the “haXe” programming language. And I plan to do this by generating byte-code for flash-player 9 for the web, and linking the neko virtual machine to a suitable “engine” for the stand-alone executables.

The possibilities I see are:

1. Use haXe to generate flash9 and neko code. All logic written in haXe. Plus a simple C++ engine to link the neko into.
2. If haXe is not fast enough on flash9, write performace code in AS3, and replicate this in C++. Then use haXe for more high-level scripting.
3. Write all in AS3, and buy a stand-alone flash player.
4. Write in Java for the web and link a JVM into a C++ executable.
5. Write all in Java and simply bundle it into a stand-alone player.

This is pretty much the order I think I will try things. I’m hoping I can get point 1 to work – this will give the greatest ability to get a simple web version going, with the ability to download a stand-alone version that is far more complex and not performance bound.

I prefer Flash to Java mainly because of end-user acceptance.

Hi Everyone. This is my site chronicling my efforts in web game development.

I have been programming since command-line was the way to programme. A simpler time when anyone could boot up his computer and start typing a game.

But nostalgia is a thing of the past, and advances, such as C++, means that you can write bigger and better programmes than when you typed in your Apple-basic code and saved it on your floppy.

I’ve done my fair share of writing big C++ programmes and the idea of writing some smaller, web based games has a great appeal. I think it’s the simplicity – and the immediacy of just plonking it on a website and people can play it straight away – no installs, no downloading just one click.

I have already published a game, FreeRange , written in C++. It occurred to me it would be good to convert it to a web game – but the syntax and structure was all wrong. This got me thinking about how I could have structured it to allow for co-development of an compiled executable and a web-based application.

So that is what this site is all about. The quest to discover the best way of developing a game, using one code base, that will work on both the web and a stand-alone application.

I’m not exactly sure where this will go, but I do know that it will involve either Flash or Java and will use some for of virtual machine in the executable.