Make Flixel GPU accelerated

[Dovyski]

Flixel should move away from the CPU and become GPU accelerated. There are some projects to use as starting point:

• https://github.com/arkeus/Axel/
• https://github.com/PrimaryFeather/Starling-Framework

[Dovyski]

These are my current approaches to bring Flixel to the GPU world:

Approach 1: use Starling as the rendering backend

Starling is a well known and consolidated Stage3D framework. It has a lot of useful features, such as ATF files support, multi-resolution, etc. Additionally Adobe sponsors the project, which ensures it evolves continuously.

The idea is to use Starling without any modifications. Flixel would be refactored to work on top of Starling.

_PROS:_ "outsourcing" the rendering pipeline and delegating it to a stablished and sponsored project will make Flixel's Stage3D evolution easier and faster. Every new enhancement made to Starling can be easily made available in Flixel.

_CONS:_ Starling does a lot of heavy lifting to mimics the usual Flash API, abstracting all the State3D calls. We can't tweak it to the bones according to Flixel needs, because we are just using the Starling API.

Approach 2: merge Starling rendering pipeline into Flixel

Extract the Starling rendering pipeline code and port it to Flixel. While we do that, some nice features can be ported as well, e.g. multi-resolution.

_PROS:_ we base our work on top of a stablished framework, extracting the extremely needed code to make Flixel GPU capable. The code can be tweaked depending how deep we dig or how much we change the original code.

_CONS:_ even though the staring point was Starling based, probably the code will change a lot when it lands on Flixel. New versions and features developed for Starling will be difficult to port/merge to Flixel.

Approach 3: port Axel Stage3D code to Flixel

Axel is extremely similar to Flixel. I think we could port its rendering core to Flixel without much trouble.

_PROS:_ the similar structure makes it easier to port and adapt.

_CONS:_ I can't see any.

Approach 4: implement from ground up

_PROS:_ total control over the rendering pipeline, which allow us to make deep and heavy optimizations.

_CONS:_ it will take more time, since we need to study and solve a lot of problems others already solved.

[Dovyski]

After a lot of time thinking about the subject, I guess 1 is better, than 3, 2 and finally 4. Starling already handles several problems, e.g. context lost in mobile devices, which will help us focus our time on new Flixel features instead of fighting against Stage3D.

What do you guys think?

[moly]

I would definitely recommend using Starling. Trying to do it all on your own will be far too much work, and I don’t think Axel is nearly as mature as Starling is.

[flunardelli]

+1 to first approach.

On 13/12/2013, at 19:56, Fernando Bevilacqua [email protected] wrote:

These are my current approaches to bring Flixel to the GPU world:

Approach 1: use Starling as the rendering backend

Starling is a well known and consolidated Stage3D framework. It has a lot of useful features, such as ATF files support, multi-resolution, etc. Additionally Adobe sponsors the project, which ensures it evolves continuously.

The idea is to use Starling without any modifications. Flixel would be refactored to work on top of Starling.

PROS: "outsourcing" the rendering pipeline and delegating it to a stablished and sponsored project will make Flixel's Stage3D evolution easier and faster. Every new enhancement made to Starling can be easily made available in Flixel.

CONS: Starling does a lot of heavy lifting to mimics the usual Flash API, abstracting all the State3D calls. We can't tweak it to the bones according to Flixel needs, because we are just using the Starling API.

Approach 2: merge Starling rendering pipeline into Flixel

Extract the Starling rendering pipeline code and port it to Flixel. While we do that, some nice features can be ported as well, e.g. multi-resolution.

PROS: we base our work on top of a stablished framework, extracting the extremely needed code to make Flixel GPU capable. The code can be tweaked depending how deep we dig or how much we change the original code.

CONS: even though the staring point was Starling based, probably the code will change a lot when it lands on Flixel. New versions and features developed for Starling will be difficult to port/merge to Flixel.

Approach 3: port Axel Stage3D code to Flixel

Axel is extremely similar to Flixel. I think we could port its rendering core to Flixel without much trouble.

PROS: the similar structure makes it easier to port and adapt.

CONS: I can't see any.

Approach 4: implement from ground up

PROS: total control over the rendering pipeline, which allow us to make deep and heavy optimizations.

CONS: it will take more time, since we need to study and solve a lot of problems others already solved.

—
Reply to this email directly or view it on GitHub.

[olsonjj]

I'd go for option #1 using Starling. Its highly used, tested and has some level of support from Adobe.

[pshtif]

It was quite some time ago that I proposed on flixel forum that you can use Genome2D low level api and keep the other high level stuff to flixel. Basically all you need is create textures and initialize context and than just call context.draw where you want to render them, the hierarchy, interaction etc. everything would be left to you to implement, if you want to obviously.

[WingEraser]

I haven't heard of Genome2D before. According to his http://blog.flash-core.com/?p=3070 it out performs Starling 1.4 (latest is 1.4.1). However the community is not very active judging from the latest topics.

[pshtif]

I wouldn't measure it by bechmarks its always very dependant on use case, in classic Starling benchmark Genome2D is over 5 times faster than default latest Starling http://prntscr.com/25cuu0 Community is quite all over the place, people write me on facebook, google, skype, twitter... There is no central point and the forum is blocked and every single one needs authentification manually by me, but in near future there will be a lot of changes to web, documentation and forum approach as well.

[Dovyski]

I've been following Genome2D since I added it to As3GameGears back in Dec/2011. It seems a great Stage3D engine with some interesting features.

@pshtif I thought about using Genome2D as a rendering backend, specially after I saw your talk at the last Flash Online Conference (amazing, btw!). What confuses me is the closed-source part of the engine. Isn't Genome2D low level API a closed thing?

[Dovyski]

After reading this post by @pshtif, I can't ignore Genome2D as a rendering backend for Flixel. It's really powerful and its direct GPU drawing capabilities fit quite well to our case.

I will start with Genome2D instead of Starling. Let's see how it goes.

[Beeblerox]

@Dovyski have you started work on this mega feature? i'm asking since i'd like to try to add it to flixel also

[Dovyski]

@Beeblerox no, I haven't. I've just read and did some research, but no code yet. It would be awesome if you could help :)

[Beeblerox]

@Dovyski ok, i'll start working on it tomorrow

[pshtif]

Nice to hear you are going to try out Genome2D guys, let me know if there is any problem at the new google group https://groups.google.com/forum/#!forum/genome2d

[Beeblerox]

@pshtif thanks, will ask you if there will be any problems

[pshtif]

Guys just wanted to let you know I released AS3 sources of the high level stuff with the low level haxe optimized SWC separately so you can use just the context if you wanted to http://www.genome2d.com/?p=159

[Dovyski]

Thanks for the heads up, @pshtif That's amazing!

[Tiago-Ling]

What about a minimalistic stage3D approach for preliminary testing? I thought about it after seeing this:

https://github.com/bwhiting/b2dLite

[pshtif]

Why? Genome2DContext is quite minimalistic as its stripped down of all the display list node/component stuff just the actual drawing going on. And it offers things that you would need to implement into b2dLite like texture management, pivots, context loss invalidation etc. Not to mention G2D is faster. ;)

[Tiago-Ling]

Sure, but if i understood correctly, with Genome2D we'd be using a black
box right? The swc would have to be included, as opposed to an open source
lib.

Having said that, i'm sure Genome2D has a lot more features and is also
faster than b2dLite (it's supposed to be very simple and bare-bones). I'd
love to see updates regarding HaxeFlixel + Genome2D for hardware
acceleration in Flash.

[pshtif]

Genome2DContext will be fully opensourced (Haxe). Secondly its way better to use SWC as it has a lot of low level optimization that you would not get if you compiled it yourself. The Genome2D is barebones as well it contains pretty much just drawing its not the whole Genome2D framework. And there are people out there using it with their blitting frameworks already.

[Tiago-Ling]

Well, in this case it seems pretty good. I didn't know you planned on "open sourcing" it. Also, the fact that there's other blitting libs using it as a backend is very reassuring! Maybe by looking at how they did it could help when doing the same with HaxeFlixel. Do you know which libs are doing it? Thanks!

[Dovyski]

I have an update for this issue. I've been following the work that @Beeblerox has been doing on refactoring the HaxeFlixel rendering pipeline. It's an awesome and monumental job, well done! :)

At first I thought we could easily port his work to Flixel Community, but it will take a lot more than I previously thought (there are some deep changes happening there). For that reason I decided to anticipate our work and implement a simpler approach based on Genome2D (following some of the ideas @Beeblerox already implemented).

I have a working prototype so far. I can run FlixelSandbox, Mode and a couple demos from Flixel website. I'm currently working on multiple cameras. Anyone interested can follow my progress here.

As HaxeFlixel`s and our approach evolve, we can exchange ideas and improve both projects.

[WingEraser]

I couldn't find texture atlas support in the code. Is it supported? if not, do not merge until this is supported.

[Dovyski]

There is no texture atlas support at the moment. I thought about that during development, but it requires a lot of API changes to accommodate such feature, e.g. assets manager and an improved cache system (currently Bitmap based).

I decided to left texture atlas support out of this pull request to make this GPU release a "drop in" replacement for already existing Flixel projects. Atlas support is on my TODO list though.

[WingEraser]

it shouldn't be too hard I think (because we are using it in flixel-gdx). The changes that are required
New classes

• TextureRegion
• AssetsManager
• Class that reads the atlas pack file.

Changes

• FlxG::createBitmap()
• FlxSprite::loadGraphic() and draw(), needs to get the region.

Have you tested on your phone (not OUYA) with 1k - 10k sprites? How did it run?

[WingEraser]

Use
libgdx-texture-packer: https://code.google.com/p/libgdx-texturepacker-gui/
or
code and web TexturePacker: https://www.codeandweb.com/texturepacker
I got open source license. Ask him for a license because you're working on an open source project.

[Dovyski]

I estimated those changes too, but I didn't want to dig that deep :D

I've ran BunnyMark on my Galasy S2 with 1k bunnies and FPS was 18. It can be drastically improved if I use the same texture for all bunnies because Genome2D will batch the drawing calls.

[Dovyski]

@WingEraser I will work on the changes you mentioned, but I would like to merge this pull request to avoid any conflicts when @IQAndreas starts merging Flixel Power Tools. Is it ok?

[WingEraser]

Yes of course, go ahead.

[Dovyski]

Landed in 0e27aa7. Please open a new issue for each bug/problem/suggestion regarding the new GPU render.