Add FlxGraphic.dump

[ACrazyTown]

Adds the feature described in #3034. I think it might also be possible to add undumping, but I'd have to play around and confirm.

One concern I have is about the naming, imo I feel as if dump isn't very descriptive and there's also deprecated canBeDumped and undump() fields that aren't related to this.

Also, the original issue mentions:

Depending on the type of graphic I think this should probably even be the default in many cases, requiring the graphic to be explicitly "undumped" to be drawn on.

Maybe there could be a compile flag (FLX_GRAPHIC_DEFAULT_DUMP?) or a variable that decides whether the graphics should be automatically dumped

[Geokureli]

If you're not already aware, the previous dump/undump fields were just removed in flixel 6.0.0, here: #3059

I still don't fully understand the implications of graphic dumping, but the idea was to remove the previous fields that did nothing, and then add them back with actual functionality later on, so people know to remove them from their project to avoid unintended behavior (not that anyone should have been using them)

So this is gonna be a post-6.0.0 feature, but pointing it at release6 is the right move

[ACrazyTown]

If you're not already aware, the previous dump/undump fields were just removed in flixel 6.0.0, here: #3059

I was waiting for that to get merged to avoid any potential conflicts

I still don't fully understand the implications of graphic dumping, but the idea was to remove the previous fields that did nothing, and then add them back with actual functionality later on, so people know to remove them from their project to avoid unintended behavior (not that anyone should have been using them)

In short, OpenFL BitmapDatas hold references to both an image buffer in RAM and a texture on the GPU. When rendering, the texture is used. When drawing on the bitmap or modifying its pixels, the image buffer is used and the rendering texture is updated. If you don't need to modify the pixels (most cases) you can get rid of the image buffer from RAM and just keep the GPU texture. Since decompressed images in RAM can be quite large in size (especially if dealing with bigger spritesheets, like FNF does), this lets us free a lot of memory and the only drawback is losing the ability to modify the bitmap's pixels.

I think a lot of fuss could be avoided simply by using names other than dump() and undump()

[Geokureli]

this all makes sense to me, thanks for the info

[ACrazyTown]

Was this meant to be closed?

[Geokureli]

This was closed automatically when I merged and deleted the release 6 branch. I didn't know that would happen, try pointing it at dev

[ACrazyTown]

FYI #2909 and #2891 were also closed for the same reason it seems. I'll try to fix the messed up commits