Hacker News Reader

Comment by crescentfresh | Hacker News Reader

> rewriting the entire codebase in ActionScript first to take full advantage of GPU acceleration, before porting it into Haxe

So let me get this straight. It was already written in ActionScript. They re-wrote the ActionScript. All of it, then ported it to the Haxe language.

So the purpose of the first "re-write" was... refactoring it to use GPU acceleration in ActionScript? I guess they just hadn't gotten around to that optimization in the first place and used this as an opportunity to do so. But was it strictly speaking, necessary?

View on HN

AS3 has 2 rendering modes:

CPU - this is an old API that can render vector based graphics. Every game before 2011 uses this API.

GPU - Adobe introduced a thin OpenGL wrapper around 2011. This is a completely new API and looks very similar to OpenGL.

I guess Haxe code looks much more similar to a game written in OpenGL, this they rewrote the rendering pipeline (and converted all assets from vector animations to sprite sheets.)

This is a most useful explanation, it explains the rewrite, thank you.

The Haxe code might even look similar to the GPU ActionScript - they're (deliberately) very similar languages.

I know a guy who worked for that company. Sounds like they had no goal beyond refactoring their ActionScript as better ActionScript as recently as a couple years ago, denying the ample writing on the wall that this was a fool's errand. I assume they pivoted and turned that into a stepping-stone for their Haxe port when it finally sunk in that Flash was getting euthanized. So they might be monkeying with the timeline and cause-and-effect in the article, but the end state is ultimately what matters.

The company chose to move to bitmap-based animation to get better performance on mobile

I'd guess that, along with converting all of their artwork to bitmaps, this was needed because Haxe+OpenFL didn't support what they were doing before. If they were going to have to change it anyway better to make that change before the port so you don't mix up two sets of bugs.

This makes a lot of sense. Doing a major refactoring while migrating to a new language/platform is much harder than refactoring a codebase so that it more closely mimics a line by line translation to a new language, and then doing the line by line translation. It may look like more work, especially since you are almost guaranteed to touch the same code twice, but the the cognitive load is so much lower each time, that the extra effort will make it all so much easier.

OpenFL does support the earlier workflow, but you are exactly correct that refactoring and porting are better done separately than at once!

Reply on news.ycombinator.com