SWFLite using texture atlas

I use openfl process command to generate swflite assets and it works well.
But I have a situation when my SWF file contains lots of small pngs, and process command exports them all separatly, that causes slow load on html target.

So is there way to generate this assets to one texture atlas?

The SWFLiteExporter in OpenFL is open-source and written in Haxe, you’re welcome to look at a possible solution for packing into texture atlases automatically :slight_smile:

At the moment, currently you would want to/need to do this yourself at runtime, or use the export to generate an atlas yourself, manually, before runtime.

However, you could try creating a large BitmapData, then going to each frame, and using bitmapData.draw to layer them into the same large BitmapData, then replacing the clip with a custom one that will use Tilemap instead?

EDIT: Could you try and edit this line:

…and see if a higher value helps your load times?

Thanks for advice!
Looks like setting up requestLimit to 20 decrease loading time

I set it to 17 in the development builds (based on some things I read online), and we’ll make it official. Thank you for testing :slight_smile:

you’re welcome to look at a possible solution for packing into texture atlases automatically

The way I’ve done is pack everything into a single file, download and decompress it to populare a cache, and then, in the AssetLibrary, if any of the files that are loaded (loadImage, loadAudioBuffer, …) are in the cache, it invokes loadFromBytes() on it. This hits the server much less, but of course it still has to load things locally, with base64 data. Though, extending it to put all images into a single file would certainly be possible (cache contains image, x, y - loadImage simply copies it out from there).

I realize there’s already support for loading PAKs, but at the moment that AssetLibrary doesn’t extend to MovieClips, which I need.

The question is how interested people would be in that kind of code to start with. I’ve done two PRs so far, none of them were added (one rejected with “I would do it differently” and one with no reply so far). Which is a bit weird, because openfl is very hacky (lots of TODOs).

Right now I have all my code in a local branch, that I merge with upstream every once in a while. I don’t mind improving openfl with it, but atm it feels contributions are difficult to get in.

If you’d like to make contributions, joining the OpenFL Discord (https://discord.gg/tDgq8EE) is a great place where we can discuss the changes, and consider different approaches. I really appreciate your help and patience.

OpenFL has some features that are less complete than we’d want. Sometimes this really just boils down to how many developers are touching a feature. For example, I love the SWF asset support, but most developers coming from a Starling background (for example) already dropping SWF support and don’t see the point. (I think it’s great!)

PAK + SWF might be the logical step, but also happy to discuss the asset library architecture in general, perhaps there should be a better way to chain multiple steps (such as SWF + asset packing)