DOT-43 [ENHANCEMENT] "Alpha coherent" FlxAnimate sprites

[Cheemsandfriends]

In regards of what seems popular demand, flixel-animate supports an option called "renderToTexture" which, conceptually is another layer of rendering (presumably a Movieclip) that renders all said pieces in one texture and outputs it.

Referencing When to cache bitmaps that entails my point.

I'm concerned about the performance of this, possibly this could be better improved (without having to cache the limbs) with a depth buffer?

[ACrazyTown]

I'm concerned about the performance of this, possibly this could be better improved (without having to cache the limbs) with a depth buffer?

When I was looking into the render texture stuff, the general consensus seems to be that the performance cost is negligible, at least in terms of the OpenGL side of things. Of course currently we still have the overhead from Flixel + OpenFL, but even with that the atlases seemed to run pretty well!

There's probably a lot of room for improvements, the current implementation in flixel-animate is a bit hacky because of how Flixel handles rendering. I suppose it would be easier to accomplish more advanced graphics stuff if Flixel used OpenGL directly instead of the Graphics API, which is something I've been interested in!

[Cheemsandfriends]

When I was looking into the render texture stuff, the general consensus seems to be that the performance cost is negligible, at least in terms of the OpenGL side of things

While it is true that rendering to a frame-buffer is generally considered an insignificant cost in itself, The truth relies on not the frame-buffer itself, but switching between textures and FBOs (also called state changes)

Normally you wouldn't want to switch a lot of FBOs as render targets, since they are pretty expensive. Here's a graph made by NVIDIA on the relative costs of state changes.

(or check the video made by the SteamWorks development called "Beyond Porting: How Modern OpenGL Can Radically Reduce Driver Overhead", the graph is at the time-frame 31:55)

Also worth noting that this issue is magnified 10x in WebGL, since its implementation for changing states is quite fragile due to the environment it's exposed at.

Since FlxAnimate aims to support at least OpenGL 3.3 (released on March 10th, 2010), Render to a target is not something that I would really like to have in a general rendering basis since it can drastically reduce the amount of FlxAnimate instances per scene.

I can expose FlxAnimate to be wrapped in a MovieClip to easily replicate the flixel-animate behavior, which would also mean filters and the support of all the blend modes in internally in FlxAnimate, but for general rendering (let's say changing the alpha values without any kind of post-processing filters), I'm very hesitant to do so.

Not to mention that with an FBO, it would drastically lose the quality of the spritemap the second you scale the texture atlas, or the whole complex situation that Adobe describes in the "cacheAsBitmap" blog entry, referenced previously.

I suppose it would be easier to accomplish more advanced graphics stuff if Flixel used OpenGL directly instead of the Graphics API, which is something I've been interested in!

This would tackle on a very far future plan for FlxAnimate. Right now it'd be wise to implement features, begrudgingly speaking, to the HaxeFlixel/OpenFL/Lime architecture.

[ACrazyTown]

Thanks for the info! Really interesting stuff, will take a deeper look later. I did notice that the video is quite old, so I wonder if there are any improvements regarding this on modern hardware/drivers.

This would tackle on a very far future plan for FlxAnimate. Right now it'd be wise to implement features, begrudgingly speaking, to the HaxeFlixel/OpenFL/Lime architecture.

Just to be clear, I was referring to a Flixel renderer overhaul, rather than anything specific to FlxAnimate. That's something I've been personally looking into quite a bit, so hopefully there'll be some improvements in that department soon.