I’m having some performance problems with scene transitions.
I have a few menu related scenes, all of which are created with the usual create() and init() combo.
Some of these scenes have become quite complex, and creating them causes some very noticable stuttering during transitions.
I have tried to solve this by using Singletons, and loading the instances of my scenes in a loading scene.
This does not quite work; opening the scene for the first time works fine, but when you return to that scene after that first time, the scene is unresponsive (e.g. animations are paused/stopped).
I am curious if any of you guys have solutions/experiences/ideas on the matter, because i am pretty sure i’m not the only on with this problem.
You can preload the assets for two consecutive scenes, so they are ready at transition time.
Another approach would be a streaming solution. The assets of the next scene are loaded async in the background. That way you are minimizing the loading times and the assets are ready when transitioning.
If you want fast transitioning, you have to keep your assets in memory. Don’t delete them or let them be auto-deleted by the engine. By doing that, loading time at the beginning of your game and resource consumption will increase.
I’m already doing this for sprites and animations, however for other nodes like labels it is a bit of a problem.
Would you suggest creating some sort of cache for labels (i’m using TTF for label generation) and/or drawnodes?
Yes. As you know the content of all your labels anyway, you don’t need to create them when needed. You can just create them beforehand.
Creation time of assets and labels(esp. when using TTF or even lacking an atlas for it) can take rather long and defer your transition(as it will create those items, when the scene is created). Offloading it into a cache, which is filled/created at the start of your game, will ensure that all the needed assets are handy when needed. No waste on creation time at scene creation.
Many games(especially AAA games) suffer from loading screens, when a new level or scene is created. That’s why they load in as many items at game start-up or use some sort of streaming mechanism for the needed assets for the next scene, while playing the actual scene. By using such mechanisms you can get rid of any loading screens between levels/scenes. In fact games on consoles allocate the total memory available for the game at start-up.
The disadvantage is, that you have to create them at game start-up and this calls for a longer loading screen at the beginning and therefore uses more memory.
override onEnter and add a loading screen and then override onEnterTransitionDidFinish and do ur initialization… this looks more promising for me… Thats how im using after so many trial and errors. Hope this makes sense.
I just finished implementing a basic cache for my labels and I can already notice a vast improvement in transition “smoothness”.
However, some labels render with artifacts now, to be continued…
(I have used this, but haven’t tested if it actually behaves as expected)
In theory for TTF labels you should be able to create and retain one label with all characters you’ll use in the game? This should help the engine not need to generate textures after this label is created. You’ll keep this label around retained for the duration of the game.
Edit: This was too simplistic. If you have many different font sizes or effects like shadows you may have to look at using BMFonts or can try scaling instead of changing fontSize? You may also find the other methods of just creating and retaining labels at game or level load is better.
If you mean bitmap font atlas BMFont, it is still nice to be able to generate these in-engine based on a config so I still think LabelTTF is important. Plus often atlas performance is unnecessary (menus, etc).
What should happen is that the API for bitmap fonts should be made identical to LabelTTF with the right configuration so that you can create atlases as part of the release optimization without having to change code for positioning, alignment, sizing, scaling, coloring, effects, etc. Shadows can be done using a 2nd atlas label, or shader. Or you can supply a shadow atlas. Same with other effects.
I don’t agree atlases need to be used everywhere, nor in many mobile games where often the only changing text is the digits 0-9. It’s an optimization, but also a hassle unless you know exactly what font style and size and effects you want at early design time.
Yes, I referred to the BMFont atlas, but why not use bitmap font generators like BMFont - AngelCode.com ?
If you want to really control your UI fidelity, LabelTTF will not be on par with label atlases, as I can exatly control the look and feel with the latter one.
We are not even using any labels, as we are exporting the assets with the text already on them. The only text we are using BMFonts is some multi-language informational text. You are very limited, when your art style of the font is depending on various other things like shadows, lighting, glows, effects and what not and still have the same art design as your game. So it’s better to let the designer use the fonts, apply the effects and export the assets for usage in the game.
Why not incorporate tools like the one in the link?
Isn’t all about shaders these days?
But yes, it would be nice to have the TTF stuff exchanged with BMFonts at release time.
It depends on your game. E.g., a RPG will use a lot of text and letters beyond the digits 0-9, which will change over time.
Of course an atlas is an optimization technique, and you don’t need them everywhere, but why waist performance, if there are simple techniques you can use?
Actual GPUs/APIs even come with features, which even make atlases a thing from the past. Things are always changing rapidly.
Isn’t the design the job of the designer and not the coder? He will take care of generating the atlases, once the design is finished and you are starting the implementation of the game after the design phase is finished anyway. So there is not really a need to use TTF besides testing some “design” with some prototype.
Argh, my re-post got lost I think. Third times a charm, right?
You are right. You should definitely atlas everything and you can even embed multiple BMFont files into your other sprite sheets. We use bmGlyph and have found it better than angelcode’s on Mac
We had some issues with BMFonts in certain node hierarchies we created with CocosBuilder. We also converted from BMFont to TTF, so it wasn’t because we didn’t want to generate the font atlases. I’ll leave it at that as it was probably just our specific case.
I do prefer to use hardware in place of images where possible, and particle effects over sprite animations, for example, and would rather not embed text inside image assets where possible. If your game calls for highly artistic or designed UI where text is used you may very well find that having the artist embed them into images is the best way to go, but I find asset management to be a larger portion of time spent than people give it credit, especially if you don’t setup a good workflow right away. I also find artists I’ve worked with tend to come from web design and sort of over-bloat texture usage since they’re not used to thinking that every pixel costs resources. I come from the a perspective where it’s usually 1-3 coders working with 2-5 artists.
Edit: I also think that having the ability to use TTF or system fonts for as long as you care to use them and bring in stylized BMFont at some point later with very few code changes and use a mapping from font config to BMFont file would be a nice feature to have internal to the engine. We use a wrapper as it is now to handle this so we may go back and put our BMfont back into the game(s) and see if everything is working fine now.
We have also not seen any problems with texture resource usage or performance in profiling related to our font/text/label choices when compared to everything else in our games.
In my game I don’t use labels too often, mainly in menus for titles etc.
Since all these labels have a different size in my game, I thought TTF was better for me.
Generating an entire atlas for just one label seems a bit overkill to me.