This might be a useful topic to review, as it explores this limitation, and your options:
Not uncommon, but always for a reason. You’d need to provide more details and context (a separate topic perhaps) if you’re seeking troubleshooting assistance.
No, at least not when working with bitmap fonts in Starling. These are highly GPU optimised in Starling. The bitmap font can (optionally) be integrated into an ATF texture atlas and decoded directly in the GPU in a highly performant way.
Starling has underpinned my work for years across dozens of commercial projects in the experiential marketing industry. This was more so the case when working with the AIR SDK, as Starling had a clear advantage over native in terms of performance.
With OpenFL however, the performance difference isn’t so pronounced (to OpenFL’s credit), but Starling does still offer another way of doing things that’s nicely tuned for making games and such, as well as many useful features.
I still use it for new projects (including currently), as well as standalone OpenFL, as the need arises.
You mean total size, or per spritesheet? It depends on your targets and how you manage runtime assets. I’d suggest staying at or below 4096x4096 per spritesheet if it’s all the same anyway, to ensure compatibility. As for total assets, it depends what you plan to have pre-loaded in the GPU at any given time and just being mindful of not rendering it unplayable on your target audiences hardware because of excessive memory consumption.
I see you’ve already got character spritesheets so it seems you’re already familiar with character animation. Perhaps you’ll need to be a bit more specific about the sort of character animation you mean @785597448 