I started looking up methods of doing rapid pixel calculations in Flash, and from there I found Pixel Bender. Pixel Bender is a fragment shader language that, as I understood it at the time, compiled to machine-code, making it run much more rapidly than other per-pixel operations in Flash. This sounded like a dream come true, to me, not only as a solution to the particular problem I was then working on but as a way to get the kind of post-processing shaders into the game which I’d wanted for a long time.
I spent a couple of days experimenting with Pixel Bender, learning it, and building an environment to test shaders out in, before I found out that the Flash environment had been revised such that Pixel Bender shaders no longer ran in machine code and, as such, currently ran at 1/10th the speed that many had come to expect. Explanations as to why have not been forthcoming, aside from a vague suggestion that it was due to some manner of security issue. Adobe has no intention of revising Flash so that Pixel Bender shaders run at full speed.
This frustrated and upset me, and brought certain questions to mind: Why am I still working on this platform? Might I be better served by moving over to another, where I have more power and technical freedom? Why am I working so hard to get the most out of a platform when the owners treat it so flippantly?
Well… I still don’t know any of the answers, but I didn’t want to keep myself chained to a platform at a point where the developers of that platform had set a precedent of actively sabotaging its capabilities, even if, as yet, only slightly. Thus, I’ve decided to port the project over to Haxe. Haxe is a multi-platform open-source language. I can publish from Haxe to Adobe Flash/AIR, the same platform I’ve been using all along, so most of my code should work just fine once I edit it for syntax. In fact, for whatever reason, Haxe’s compiler seems to produce much more efficient code, making a difference of about 10 frames-per-second in my graphics test program (originally developed to experiment in Pixel Bender). Also, since it can target multiple platforms, if I need to switch over to something like C++ and OpenGL, either during this project’s development or enhancing the engine for use in future projects afterwards, I will be in a much stronger position to do so.
As to what originally brought me to Pixel Bender, then to Haxe, I’ve tabled the collision detection item for the moment. When it comes to whether I can start implementing post-processing filters… I’m not sure. I’m going to have to experiment and see what works. I was hoping that the change of platforms might make this easier, but since I’m still stuck with a lot of Flash’s API’s so I’m not sure how much I can do.
It’s pretty frustrating. Oh well.
While I was figuring all of this out – there was a lot of decision-making process I’ve glossed over here – I started thinking about the title of the game. Again. It seemed to just make sense to, when I’m having to redefine something as fundamental as the code it’s written in, go ahead and finally change the title, something which I’ve been meaning to do for a long time. The reasons I felt this way were somewhere in between pragmatic and symbolic, having properties of both but resembling neither. It just seemed like the right time. And, just on cue, by which I mean after several hours of brainstorming, a title arrived.
I think this is probably the one.