I think I should premise this, with expressing that I think it is important that you develop your own style and approach to coding.
I offer you my thoughts, sometimes with a degree of persuasiveness, but I believe it’s important that you pick and choose and weigh up what is also going to work well for you, and what makes sense to you. So what I offer here now is merely something to consider, and is not intended as “the way you should be doing it”.
You’re right, that one approach is to use a loop to switch off all MovieClips before activating the new one. I don’t think that will incur much overhead, but for argument sake, let’s say that was a problem, and some more precise logic is needed.
(I’ve not tested the below code, I just wrote it in notepad, so treat it as something like psuedocode, expressing the idea)
public var currentMC:MovieClip;
public function goState(state:String):Void {
if (currentMC != null) {
currentMC.stop();
currentMC.visible = false;
Starling.current.juggler.remove(currentMC);
}
switch(state) {
case "walk":
currentMC = walkMC;
case "jump":
currentMC = jumpMC;
default:
currentMC = idleMC;
}
Starling.current.juggler.add(currentMC);
currentMC.visible = true;
currentMC.play();
}
The above method selectively works only with the active MovieClip (disabling it), then playing the MovieClip to be activated. It assumes you have a state mechanism of some sort set up so the correct movieClip plays at the appropriate time.
Ok, I had some success translating this using deepl.com. I suspect the font used on the forum doesn’t support the Chinese characters, so it’s not rendering here.
The settings you used in TexturePacker are important, as well as the target you’re using with OpenFL, and the platform / computer / device / browser you’re running it in. Knowing these things will hopefully provide some pointers for troubleshooting.
Vector text in OpenFL / Flash / AIR, is rasterised and displayed. So whilst the source is vector, it is ultimately displayed as raster.
With Starling, the text is essentially pre-rasterised which has significant performance benefits for text that is updated frequently.
I anticipate you have quite a number of options here, still. Understanding what you’re trying to do, like some visual mock-ups, might help us hone in on some of those. For example:
You can export size specific bitmap fonts, so you don’t need to scale them.
You can use distance field fonts, that scale better.
You can use OpenFL textfields (vector!), as this will display on top of Starling, just be aware of performance implications if you’re updating that text a lot.
I have had very positive communications with the TexturePacker team, and we currently have two likely outcomes:
They are entertaining the idea of officially adding pivot point support to the Sparrow / Starling exporter.
I have also produced a custom Sparrow / Starling exporter for TexturePacker that has pivot point support, but I still need to test and refine this more before sharing.
I would add as a caveat, as this would be for use with the latest version of TexturePacker, I’m leveraging the KTX format, not ATF, but I have that working in all my testing with new KTX code I’m working on. I’m still refining the code structure of that, to bring it inline with OpenFL paradigms and future-proofing considerations, before offering it as a pull request.
The main goal is “html5”, where text is placed in the container UI. “html5” adapts to the scaling of the screen container UI, and text inside the container will also be scaled
The text of ‘starling’ will be converted into a texture image, and scaling will cause blurring
In order to display the text clearly, I initially set the text size to 50 and then scaled it to 0.2, scale=0.2
I like to add strokes, which make the text look more beautiful, but sometimes I can also skip them. Adults don’t have to make a choice, I want everything
The picture above is the UI interface of a game I have played before
This type of UI interface is common in games
In the game, there is also an exquisite UI interface where the text is very clear and refined, even for small words
The text of “as3” and “openfl” seems to be vector graphics, and no matter how they are scaled, they are still very clear and exquisite. I don’t need to consider this issue, but now I am using “starling” and I am looking for a solution. Thank you
This option uses the OpenFL TextField within Starling, but added to the a special Starling.current.nativeOverlay Sprite, so it’s controlled from within the Starling context, but is rendered outside of it.
Be mindful, to achieve the stroke effect, I’ve layered two GlowFilters here. These are expensive performance wise.
var textField = new openfl.text.TextField();
var font = Assets.getFont("fonts/someFont.ttf");
textField.defaultTextFormat = new openfl.text.TextFormat(font.fontName, 100, 0xFF0000);
textField.autoSize = openfl.text.TextFieldAutoSize.LEFT;
textField.text = "This is VECTOR text!";
textField.filters = [
new openfl.filters.GlowFilter(
0x000000, // Outline color (black)
1.0, // Alpha
3, 3, // Blur X, Blur Y (pixels)
10, // Strength
false, // inner
false // knockout
),
new openfl.filters.GlowFilter(
0x000000, // Outline color (black)
1.0, // Alpha
3, 3, // Blur X, Blur Y (pixels)
10, // Strength
false, // inner
false // knockout
)
];
Starling.current.nativeOverlay.addChild(textField);
Make sure you change the font path ("fonts/someFont.ttf") to a legitimate font file. In the below screenshot, the OpenFL vector text is sitting on top of the Starling Stage3D backdrop.
Before now, I had never used this feature, so it was interesting to play with it. Feel free to adjust it as you see necessary, The code I’ve provided is an example or idea at most.
When using Starling, I approach text natively in Starling, as most of my projects are built for very specific hardware and resolutions. The dynamic scaling you’re wrestling with isn’t an issue in the context of my projects.
When I’ve built for HTML5, I have tended away from Starling, using OpenFL + SVG. But in those cases, I’m not developing games.
Yes, that will be a limitation. Stage3D will render to the bottom most layer, therefore causing OpenFL display objects to always appear on top of that.
The example you provided was small static white text that would not be covered at all. The Starling.current.nativeOverlay method may yet have use there.
I do agree with its shortcomings as far as tracking with characters in-game and such. I would not recommend that method for text that is updating frequently, such as character stats anyway.
Have you tried using distance field fonts? I’ve mentioned them a number of times.
