Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Flixel GPU accelerated #90

Closed
Dovyski opened this issue Sep 17, 2012 · 31 comments

Comments

@Dovyski
Copy link
Member

commented Sep 17, 2012

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

@Dovyski

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2013

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

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2013

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2013

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

This comment has been minimized.

Copy link

commented Dec 13, 2013

+1 to first approach.

On 13/12/2013, at 19:56, Fernando Bevilacqua notifications@github.com 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

This comment has been minimized.

Copy link

commented Dec 13, 2013

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

@pshtif

This comment has been minimized.

Copy link

commented Dec 14, 2013

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

This comment has been minimized.

Copy link

commented Dec 14, 2013

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

This comment has been minimized.

Copy link

commented Dec 14, 2013

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

This comment has been minimized.

Copy link
Member Author

commented Dec 15, 2013

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

This comment has been minimized.

Copy link
Member Author

commented Feb 6, 2014

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

This comment has been minimized.

Copy link

commented Feb 8, 2014

@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

This comment has been minimized.

Copy link
Member Author

commented Feb 8, 2014

@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

This comment has been minimized.

Copy link

commented Feb 8, 2014

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

@pshtif

This comment has been minimized.

Copy link

commented Feb 9, 2014

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

This comment has been minimized.

Copy link

commented Feb 9, 2014

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

@pshtif

This comment has been minimized.

Copy link

commented Feb 26, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Mar 3, 2014

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

@Tiago-Ling

This comment has been minimized.

Copy link

commented Mar 17, 2014

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

https://github.com/bwhiting/b2dLite

@pshtif

This comment has been minimized.

Copy link

commented Mar 17, 2014

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

This comment has been minimized.

Copy link

commented Mar 17, 2014

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

This comment has been minimized.

Copy link

commented Mar 17, 2014

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

This comment has been minimized.

Copy link

commented Mar 17, 2014

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 Dovyski self-assigned this Aug 25, 2014

@Dovyski

This comment has been minimized.

Copy link
Member Author

commented Aug 28, 2014

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

This comment has been minimized.

Copy link

commented Nov 10, 2014

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

@Dovyski

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2014

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

This comment has been minimized.

Copy link

commented Nov 10, 2014

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

This comment has been minimized.

Copy link

commented Nov 10, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Nov 15, 2014

@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

This comment has been minimized.

Copy link

commented Nov 15, 2014

Yes of course, go ahead.

@Dovyski

This comment has been minimized.

Copy link
Member Author

commented Nov 15, 2014

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

@Dovyski Dovyski closed this Nov 15, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.