I don’t recall ever saying HTML5 was not fully supported. If I did, it was likely within a specific context, like my personal preference for using vector graphics (SVGs) with OpenFL when targeting HTML5, as opposed to Starling’s use of bitmaps for reasons of scaling across devices.
. Bink joshtynjala
.
Thank you very much. It depends on what “Bink” means, or it may be a translation difference It’s great that ‘html5’ fully supports it
.
Ah, I think I know what you’re referring to now @785597448. It just clicked: specifically, with respect to spacing in HTML5 targets.
To clarify @785597448, the lack of support for letter spacing wasn’t an OpenFL limitation, it was the web API limitation. Support for letter spacing was only added to the web API this year, and OpenFL’s development branch (9.6.0) has been updated to include that support.
In that context, I understand why you thought I’d said HTML5 wasn’t fully supported yet, in a manner of speaking, I had. But that’d be a very general way of putting it, and perhaps a bit confusing
I understand working across translations is difficult @785597448. I’ve faced similar issues discussing technical ideas with German folk (I don’t speak German!).
Sometimes I have, but only really if there’s a specific reason, like a new feature I’m needing, or testing, or building.
If there’s no specific reason to use the git version, I’d suggest using the latest release.
I would consider the git version pre-release in terms of stability. That is, it may have bugs as a result of being a work in progress, but @joshtynjala, @Dimensionscape and @singmajesty would be in a far better position than I to comment on the stability you might expect as they are the ones shaping and managing those commits with their much appreciated efforts.
The example I provided in the past, is how I’ve typically used it, but that’s based on my needs (simple full-screen toggle, with the option to maintain aspect or stretch to fit):
.
After reading your code,
What you added is’ ResizeEvent. RESIZE ‘,
And what I added was’ Event. RESIZE ',
All of them are window change events, should the effect be the same?
.
private function stageResized(e:ResizeEvent):Void {
shapeScaler.width = e.width;
shapeScaler.height = e.height;
// choose the larger scale property and match the other to it;
(shapeScaler.scaleX < shapeScaler.scaleY) ? shapeScaler.scaleY = shapeScaler.scaleX : shapeScaler.scaleX = shapeScaler.scaleY;
// choose the smaller scale property and match the other to it;
(shapeScaler.scaleX > shapeScaler.scaleY) ? shapeScaler.scaleY = shapeScaler.scaleX : shapeScaler.scaleX = shapeScaler.scaleY;
// Auto-fit any resolution maintaining aspect.
Starling.current.viewPort = new Rectangle((e.width - shapeScaler.width) / 2, (e.height - shapeScaler.height) / 2, shapeScaler.width,
shapeScaler.height);
// Auto-fit any resolution with stretch.
// Starling.current.viewPort = new Rectangle(0, 0, e.width, e.height);
trace('Stage resized to:', e.width, e.height, ' and viewPort resized to', shapeScaler.width, shapeScaler.height);
}
Strictly speaking though, the Stage class dispatches the event type ResizeEvent:
/** Dispatched when the Flash container is resized. */
@:meta(Event(name="resize", type="starling.events.ResizeEvent"))
* <p>When the Flash player is resized, the stage dispatches a <code>ResizeEvent</code>. The
* event contains properties containing the updated width and height of the Flash player.</p>
*
* @see starling.events.KeyboardEvent
* @see starling.events.ResizeEvent
Using Event.RESIZE instead may mean you can’t retrieve the event.width and event.height data from it, as these are defined in ResizeEvent and not Event.
e.width and e.height there is the updated size of the application window, not the Starling view port. The Starling view port is the Starling.current.viewPort, which in my example, is adjusted to respond to the updated size of the application window.