This allows us to remove the conditionals on implementations of `from_path` that need to call this function, as the function is now always guaranteed to be there, even if it's just a no-op/`Err` generator.
During the small period of time when a player is created but has no root movie, a temporary empty movie is installed with an assumed stage size and framerate of 550x400@12fps. This is Flash default for new projects, so it seemed appropriate. User ActionScript cannot see these values, and I'm not even sure JavaScript can, either.
Calling loadMovieNum with a variable parameter compiles into a
GetURL2 call with a `_level` window target parameter. Previously
this triggered Ruffle to try to navigate to the SWF. Now it
properly loads the SWF inside the current movie.
Holding a `Ref` on a garbage-collected object inherently extends any borrow locks on that object. Since ABC files are references already, taking a `Ref` to them only helps to skip the refcount update. This is less useful than expected: in most situations, using `abc_ref` causes double-borrow panics. The few methods that can use it are going to be fragile in the face of future refactors, so I'm nipping the problem in the bud now.
For good measure, most of the other methods in `value` for retrieving pool primitives now also use `TranslationUnit` instead of `AbcFile`. This is the result of a handful of cascading changes throughout the project, and itself caused a few more.
Interface methods are specifically not allowed to be called: as a result, they don't get a method body. Existing code assumed a 1:1 relationship between methods and bodies, which causes spurious errors.
This is inspired by Dinnerbone's similar PR on the AVM1 side, where the Action half of that VM's `Executable` was reduced from 128 bytes to 16 by shoving it in a `Gc`. This won't be as dramatic but should still save some memory.
In fact, it should save a *lot* of memory in bytecode execution, where thanks to the previous commit's rebase, we now need to clone the current method once *for each instruction executed*. That is terrible, but should stop now.
This also results in a far reduced role for `ReturnValue`, since I also took the liberty of removing most of it's use. Furthermore, I also made it apply equally to native and AVM2 code, which ensures all native implementations of methods don't double-borrow.
In AVM1, `ReturnValue` was actually removed entirely, because it's not needed. I attempted to do the same, but the fact that we're currently embedding `ScriptObjectData` in native objects means that we need it for virtual properties. Otherwise, virtual property implementations will see locked objects, which is bad.
While some code that references pool multinames has zero as a valid index, we cannot validate exactly what the zero index is for a given index. Hence, callers instantiating multinames must check for zero and substitute the correct zero-value interpretation for their given type. If zero is an invalid value, it should ideally throw a different error than what's provided here.
This commit breaks the build: we still need to tell `Avm2` how to turn ABC traits into our own internal `Trait<'gc>`, `Class<'gc>`, and `Method<'gc>` types. We also need something to track which traits have already been instantiated, because `callstatic` would otherwise reinstantiate the trait in a different scope. (In fact, I think it *does* do exactly that right now...)
The intention is to completely replace all usage of `Avm2XYZEntry` with `Class`, `Trait`, and `Method`. This will allow runtime-provided global class traits to coexist with those provided by user code.
Inspired by Dinnerbone's PR doing the exact same thing to AVM1.
On AVM2 we have a bit of a subtle issue: the base implementation of `set_property_local` and `init_property_local` *must* return `ReturnValue`s to avoid double-borrows. Each implementation of `TObject` must resolve them before returning.
This function has vague documentation about enabling locale-specific formatting in subclasses. As far as I can tell, none of the objects I implemented so far do anything different than `toString`, so I just have it use the same `TObject` property I set up for `toString`.
This was originally something *way* more evil: mixed inheritance between ES3 and ES4 classes. It didn't pan out due to fundamental limitations of the two object models. How the hell did Brendan Eich/Adobe/TC-39 expect ES4 classes to be adopted in already-existing codebases?!
We still reuse the `FunctionObject` machinery internally. If necessary, we may want to split this into a separate `ClassObject` if some internal `TObject` method needs replacing for classes.
In practice not many movies will care about this, because the `AS3` namespace is open by default. You could opt-out of that, and I suppose that was there for using existing ES3 code in AS3 projects. ES4 would have had a similar ES4 namespace, which "JavaScript 2.0" code would need to opt into. Of course, ES4/JS2 never happened, so we just have this weird historical quirk here.
The reason for this is that, in AVM2, `toString` and `valueOf` are not defined on the classes or prototypes of `Function` or `Class`. Instead, they use the `Object.prototype` versions of those functions. Ergo, string and primitive coercion are inherent object methods (the ones that get `[[DoubleSquareBrackets]]` in the ECMA standards). In Ruffle, our equivalent to `[[DoubleSquareBrackets]]` methods are methods on the `TObject` trait, so we're adding them there.
This mechanism will make implementing boxed value types (ala AVM1's `BoxedObject`) easier, too.
We also add some reasonable defaults for `ScriptObject` and `FunctionObject` which will appear on objects, functions, and classes.
Private names now return `false`, and we run any names through trait lookups. This also means any namespace resolution can fail now, in case we need to throw a `VerifyError`.
I have... significant reservations with the way object enumeration happens in AVM2. For comparison, AVM1 enumeration works like this: You enumerate the entire object at once, producing a list of property names, which are then pushed onto the stack after a sentinel value. This is a properly abstract way to handle property enumeration.
In AVM2, they completely replaced this with index-based enumeration. What this means is that you hand the object an index and it gives you back a name or value. There's also an instruction that will give you the next index in the object.
The only advantage I can think of is that it results in less stack manipulation if you want to bail out of iteration early. You just jump out of your loop and kill the registers you don't care about. The disadvantage is that it locks the object representation down pretty hard. They also screwed up the definition of `hasnext`, and thus the VM is stuck enumerating properties from 1. This is because `hasnext` and `hasnext2` increment the index value before checking the object. Code generated by Animate 2020 (which I suspect to be the final version of that software that generates AVM2 code) initializes the index at hero, and then does `hasnext2`, hence we have to start from one.
I actually cheated a little and added a separate `Vec` for storing enumerant names. I strongly suspect that Adobe's implementation has objects be inherently slot-oriented, and named properties are just hashmap lookups to slots. This would allow enumerating the slots to get names out of the object.
Our already odd `super` handling throws up another subtlety regarding bound recievers. Since we have to construct an instance of a parent class in order to get traits on it, we also have to make sure that we initialize traits with the correct reciever. I'll demonstrate here:
```let mut base = base_proto.construct(avm, context, &[])?;
let name = base.resolve_multiname(&multiname).unwrap();
let value = base.get_property(object, &name, avm, context)?.resolve(avm, context)?```
In this case, if `name` is the name of a method, getter, or setter trait, then `get_property` will instantiate that trait on `base` but bound to `reciever`. This is correct behavior for this case, but more generally, trait instantiation is permenant and therefore there's potential for confusing shenanigans if you `get_property` with the wrong reciever.
To be very clear, `reciever` should *always* be the same object that is getting `get_property` et. all called on it. In the event that you need to instantiate traits with a different `reciever`, you should construct a one-off object and retrieve prototypes from that.
Previously, we were treating ES4 classes like syntactic sugar over a prototype chain (like ES6 classes); e.g. each declared trait was set in the given prototype and then property look-ups happened as normal.
This already caused problems with virtual properties, which could be partially-defined in subclasses and required careful checks to make sure we stopped checking the prototype chain on the *correct* half of the property.
However, this is a hint of a larger problem, which is that ES4 classes don't actually define anything on the prototype chain. Instead, the instance itself constructs class properties and methods on itself. This allows things like methods automatically binding `this`, which isn't included in this commit but will be implemented really soon.
The prototype chain still exists even on pure ES4 classes, due to the need for backwards compatibility with ES3 code. Object, for example, still defines it's methods as prototype methods and thus there needs to be a prototype chain to reach them. I actually could have gotten away with using the prototype chain if AS3 *hadn't* retained this "legacy" detail of ES3 allowing this class/prototype distinction to leak out into upcoming tests.
We still actually use the prototype chain for one other thing: trait resolution. When we look for a trait to install onto an object, we pull traits from the prototype chain using a special set of `TObject` methods. This happens in opposite order from normal prototype lookups so that subclassing and verification can proceed correctly.
`super` somehow became even harder to implement: we now actually construct the parent class so we can get traits from it, which is going to complicate method binding as mentioned above.
This tests:
* Getter invocation
* Setter invocation
* Properties with one or the other, but not both
* Inheritance
* Superproperty getters and setters
* Getters with inherited setter
* Setters with inherited getter
The previous system for handling setters would execute the setter and then return a value to indicate whether or not the caller needed to resolve a stack frame. However, no caller of `Property.set` actually did this. Ergo, errors in setters and getters would not resolve up the stack at the correct time.
This problem also exists in AVM1 but is far less noticable as AVM1 only has two very uncommon runtime errors and very few movies use `throw`.
Normally, `set_property` only affects the object it was called on, which makes sense: otherwise, we couldn't override values that originate from a class prototype without accidentally monkey-patching the prototype. However, virtual setters only exist in prototypes and need to be accessible from child objects.
The solution to this is to have a specific method to check if a virtual setter exists. Virtual setters are then resolved through the prototype chain. If no virtual setter exists, then the reciever object is handed the value.
Note that we always use the `reciever` object rather than `self` so that `setsuper` can work correctly. In `setsuper`, we resolve the base class, and then set properties on it with the actual object in question as it's reciever. If a virtual setter is called, it will get the actual object it should be manipulating; and otherwise, prototypes will not be modified or consulted.
This required the reintroduction of dedicated reciever parameters to `Object.get_property_local` and `Object.set_property`, which I had removed from the AVM1 code I copied it from. It turns out being able to change the reciever was actually necessary in order to make super set/get work.
The previous system primarily relied on `Executable` to automatically start and continue a super chain. This works, but only for class hierarchies without *override gaps* - methods that override another method not defined by the direct superclass of the method. In that case, the override method would be called twice as the `base_class` was moved up one prototype at a time, which is wrong.
The new system relies on the call site to accurately report the prototype from which the current method was retrieved from. Super calls then start the resolution process *from the superclass of this prototype*, to ensure that the already-called method is skipped.
It should be noted that the proper `base_class` for things like `callmethod`, `callstatic`, `call`, `get`/`set` methods, and other call opcodes that don't use property look-up are best-effort guesses that may need to be amended later with better tests.
To facilitate `base_proto` resolution, a new `Object` method has been added. It's similar to `get_property`, but instead returns the closest prototype that can resolve the given `QName`, rather than the actual property's `ReturnValue`. Call operations use this to resolve the `base_proto`, and then resolve the method being called in `base_proto`. The existing `exec_super` method was removed and a `base_proto` method added to `exec` and `call`.
This works primarily by retaining the current superclass prototype in the activation object and then using it to retrieve the super method.
For constructors, we implement the `constructor` property, which is probably not the correct way to do this.
This currently treats `coerce_a` as a no-op. Strictly speaking, this is for type verification purposes, but we currently don't type-verify ABC code. Ergo, this requires no VM support at this time.
Also, implement a method table that method traits can optionally add themselves to.
Also also, add the ability to invoke a method without a `this` object. This required a non-trivial refactoring of the activation machinery, and changes to the signature of `NativeFunction`, and all native AVM2 functions.
In the future, the `unwrap_stack_frame` mechanism should be expanded upon to allow running exception handlers and recovering from a Rust error - but not today.
Notably, this also removes `new_closure_scope` as it is not needed. AVM1 does not capture `with` scopes in closures, but AVM2 (as well as modern ECMAScript) does.
We already have a menagerie of `install_*` functions for adding static properties to a an object; and we don't have to support any kind of asinine nonsense liks `ASSetPropFlags` here. Ergo, we don't need this.
In AVM1, these are necessary because `ActionGetVariable` et. all directly interface with the scope chain. In AVM2, you `findpropstrict` up the scope chain, which gives you a normal object that you can interact with as you like. Ergo, the scope chain doesn't need set/get property methods.
All constant pools in an ABC file are actually numbered starting from one; there's an implicit 0 entry not stored in the file that the runtime is expected to retrieve when pulling constants from the pool.
The AVM2/ABC spec only mentions this in passing.
This allows the AVM to declare classes, which necessitated some refactoring to avoid double-borrows or having to do something "magic" that would dodge virtual properties.
I'm writing all this code assuming that classes and traits are syntactic sugar around ES3-style prototype chains on function objects. Hence, `FunctionObject` is still our workhorse object type for implementing typing.
If a text field with a variable binding is placed on the stage,
usually the variable is initialized with the initial text. However,
if the text field is empty, the variable remains undefined.
Fixes#777.
Don't override set_matrix and set_x for TextFields, and leave the
bounds intact.
TODO: There are still some wrapping issues in the tests, but
this allows the simple case of single-line texts to render
correctly.
Add `EditText::variable` as well as `TextField.variable` property.
This commit only adds the getter/setter and does not yet add the
binding functionality.
DefineLocal will call a virtual setter if the property already exists
on the local object, including the local object's prototype chain.
DefineLocal2 will also not overwrite a property if it already exists
on the local object, including the local object's prototype chain.
This was originally intended to correctly position text within the border, but it appears borders are weird and this doesn't jive with what unbordered text does.
On the desktop player, shared objects will now be flushed on quit.
Attempting to retrieve an existing shared object will now return a
reference to the existing one.
During the raising process, we maintain a list of pointers to the lowest-most `textformat`, `p`, `font`, `a`, `b`, `i`, and `u` in the document that we are appending to. When we get a new one of any of those elements, we clear the rest off the stack. This forces us to add HTML in the same order Flash does.
LIs are not yet supported because they require us to process text line-by-line which doesn't mesh with this model.
There's also a test but the XML DOM generates HTML strings with the wrong attribute order, so the test fails spuriously.
This necessitated a change to edittext_bullet, which turns out is accidentally an entity test, too. It now no longer uses entities so that it won't spuriously fail due to an entity related problem.
Bullets are implemented by rendering U+2022 as if it were normal text, but always placed 18px from the left of the line. This appears to be sort of what Flash does.
This also replaces the `edittext_html_defaults` test with a more robust test that checks the default format and global format of SWF-based, text, and HTML test vectors.
It *does*, however, respect `<sbr>` (which does the exact same thing), as well as `\n` (which makes absolutely no sense in HTML, normally that would get stripped out).
This implementation has a few bugs which appear to have something to do with alignment. It's not only justify, but justify is the only test that's flagged as failing.
If you look at the margins test, you'll see what I mean: right-aligned and justified text doesn't quite make it to the right edge of the box even though it should. I'm not sure why.
This also restricts text rounding further: `measure` now only rounds when wrapping text, since Flash Player appears to account for fractional pixels in all other cases.
There are several problems, first off:
1. I'm not entirely sure what I'm supposed to be changing on the text field when someone writes `html`.
2. We're using the XML parser for HTML (both `htmlText` and SWF tag parsing) which causes problems. Notably, `<br>` issues an AVM1 error (!!!) because the XML parser doesn't like unclosed tags.
3. Reading `htmlText` should not return the same HTML tree (at least, not until we implement stylesheets). It should instead regenerate an HTML tree from text spans.
This test is currently inaccurate by up to 5 pixels, this is due to some behavior with really, really wide tabstops and word breaks that I don't entirely get yet.
This was verified by visual comparison with Flash Player; lines of text appear to be shifted by half-pixels, while the script output is always still rounded down.
This is an approximate text with a 1-pixel tolerance because our height is currently off by one and I cannot explain why. Previous attempts to fix the bug have resulted in cascading errors that resulted in off-by-one errors in the opposite direction. This is still better than nothing and I need to check other tests in.
Flash has a weird bug where it will NOT trim trailing spaces off of the metrics reported to users if the text is left-aligned. We replicate this here so that tests pass.
The `Default` bounds are NOT safe to union against if they were uninitialized. Doing so will force any resulting layout box to enclose `(0,0)`, which can throw off certain layout calculations. Instead, we use `None` to signal an uninitialized box.
`EditText` supports two different forms of leading:
1. Font-provided leading, specified relative to the EM square and scaled with font size
2. User-specificed leading, specified in pixels
Notably, the former appears to apply to the first line in the text and pushes it down. This showed up in the `edittext_font_size` test, and according to that test result the leading is rounded *up* to the nearest pixel, plus one.
That last bit seems possibly wrong and is subject to further change, but it matches the tests at multiple scales.
Certain text routines calculate text on the pixel grid, despite the fact that Flash ordinarily works in twips. There is probably a reason for this - my guess is to keep text wrapping stable across multiple pixel densities (e.g. low-res screens plus high-res print).
I don't know why, but this is necessary for the "NEW STUFF" box on homestarrunner.com's toons menu to position correctly. SOMEWHERE, we are performing some kind of operation that adjusts one of the two, but not the other, and I can't find out what.
This fixes spaces at the start of text spans not being rendered, but also breaks center-align.
I also broke the font tests, so I had to rewrite them, which makes me question their value.
Right margins: Simple enough, we just need to subtract the right margin from the bounds when we calculate our alignment adjustment.
Trailing spaces: This is very tricky as we effectively have to remeasure the last box in the line when fixing it up. This also means LayoutContext has to hold the text itself so we can remeasure again...
Lines wider than bounds: If word wrap is disabled it is possible for a line to exceed the bounds of the box. In this case it will be left-aligned. Effectively, the align adjustment is clamped to positive values and we do that here too.
This doesn't work right yet because the resulting width doesn't apply correctly to the field. This is because `EditText`'s `_width` and `_height` change it's intrinsic bounds rather than it's X and Y scale (like it would with a button or a movie clip).
These tests depend on the particulars of our default device font, Noto Sans. If this test proves to be fragile we may need to create a testing font with a locked width and kerning table...
This prevents a bounds-check panic when we inevitably try to slice an array like `[300..2]` or something like that.
We also skip rendering the space that we're turning into a newline to avoid it popping up on the next line by accident.
`max_length` isn't a geometrical width, despite the fact that the type system didn't prevent me from making erroneous conversions. It's actually just a text length limit, which we won't be dealing with for some time.
When first instantiated, we use the static bounds; however, further relayouts grab `local_bounds` and calculate a width from that. `EditText` works almost identically to any other display object, with the exception that device fonts do not render if the transform is not an axis-aligned bounding box (and it doesn't respect scale). We don't have to worry about that for now.
This is surprisingly difficult because of how Flash handles these properties: they are cached at the start of a new line (explicit or flown) and then used for all spans that intersect with that line. Ergo, `LayoutContext` needs to keep track of all the boxes we generate within the line and the span that ultimately is going to provide margins for it.
And yet, at the same time, we also have to precalculate the effects of these margins when flowing text so that we know how much space we have to play with. This needs to be calculated the same at the start of the line as it is at the end. This is why `LayoutContext` is a separate type: it handles all the state tracking and crap that has to be done when splitting text into spans, paragraphs, and lines all at the same time.
Fortunately, this design will make it easier to implement other features like text alignment where we couldn't even begin to calculate everything in one pass.
This involves a new struct called a `FontDescriptor` which is generated whenever a font is registered and used to index the font in the library. When a font is requested, it goes through the descriptor system to get found.
"Mixing" is defined as `Option.or`ing all the properties in the new text format with the old one. Not specifying a text format in the new default will result in the field retaining it's old properties.
This yields nodes as `Step`s. This allows keeping track of the structure of the tree as you walk through descendents, as each element will be yielded twice: both as a `Step::In` *and* as a `Step::Out`. Non-element nodes will be yielded once as a `Step::Around`.
I'm adding `walk` iteration specifically to avoid having to write certain methods recursively. Existing recursive callers of `children` should probably be updated to `walk` the tree and maintain a separate `Vec` stack.
This also necessitated the addition of code to:
* Ensure span breaks exist at both sides of the text boundary, without creating degenerate (length-0) spans
* Consolidate spans with matching text formats
* Shorten or lengthen the total list of text spans to match the backing string
* Ensure at least one text span exists at all times
This still has some minor to-dos: for example, it relies on the default `TextSpan` formatting, which probably should be replaced with actually accepting or storing a default format to be used when constructing new text spans.
Despite having HTML and CSS rendering capabilities, the Flash text field actually does not use HTML as it's internal representation. Instead, the text-span format implied by `getTextFormat` and `setTextFormat` is used to drive layout. You can see this by watching what happens to `htmlText`, *especially* when you add and remove stylesheets.
The `LayoutBox` machinery will be adapted to consume text spans in a future commit. This would make the entire rendering pipeline: HTML/CSS -> Text Spans -> Layout Boxes -> Render commands.
This makes the implementation of rectangle union (`Add`/`AddAssign`) far easier as we just compute the min and max of the offset and extent coordinates. It also makes the conversion into and from `swf::Rectangle` easier as it's now effectively a generic version of that datatype.
On the other hand, `width`, `height`, and `size` now have to be calculated, and require `T` to be self-`Sub`. I'm not sure if this is that much of a problem or not.
We're reusing the XML machinery to handle HTML - this is probably not 100% correct, but writing a new HTML parser to cover just `EditText` will be rather complicated.
If a class is registered to a clip that is placed on the timeline
during a goto, that constructor should run after the frame is
completely constructed. In order to tell whether to run the
constructor immediately, add a parameter to `post_instantiation`
to indicate if the clip is instantiated from the AVM or via a
standard timeline seek.
There was a one-frame-off flicker when a button changed states.
Now children will tick a frame so that they are properly created
immediately when the parent button changes state.
Previously a MovieClip's clip action would have a set of events
that would trigger it. Now we flatten these out into a single
event per action, because this is by far the common case. If an
action does happen to have >1 event, it will be duplicated for each.
Don't call `render` from `Player::tick`; instead, require the
frontends to explicitly call `render` when they wish to redraw.
The frontend can query `Player::needs_render` to see if the stage
is dirty and needs a redraw. Update desktop and web to use this
new method.
This fits better with the newer winit event loop model, which
requires explicitly calling `request_redraw`, and should avoid
spurious renders.
A previous version of this PR (whose history has been scrubbed, but go check 918d88abe68b7467a4194738b95e5bf3e9b5bb72 if you're curious) implemented a new `TObject` property which basically every line of code that dealt with object construction had to populate. It was terrible.
This is accomplished via two new `TObject` methods: `has_own_virtual` and `call_setter`. If an object does not contain it's own version of a property, it will first crawl the prototype chain to see if there is an overwritable virtual. If so, it will invoke that prototype's setter.
A bit of borrow finangling was required to do this; `super` now no longer caches it's proto and constr values and instead dynamically constructs them. This also means it can't be downcasted to `Executable` anymore.
With this commit, virtual setters and super-setters now work correctly.
A base prototype is only applicable in cases where a method is being called as a property on an object. Bare function calls, `apply`/`call` calls, and so on do not generate a base prototype.
We also add a convenience method, `call_method`, to all objects. This method automatically calculates the correct base prototype for a method call on an object, which is the only operation that should generate base prototypes.
Revert to the old action queue method of popping off actions in a
loop, as new actions can be queued while iterating. Store proto
changes in a separate queue to maintain the high priority behavior.
Changes to the action queue caused actions queued during other
actions to run too late. These regressions weren't caught by the
tests because many of the goto tests ran for more frames than was
necessary, allowing the late actions to still run.
Change `ActionGetTime` (`getTimer`) to use a new backend method.
This allows it to return updated times if it is called multiple
times in a single frame. This fixes hangs caused by games that use
busy-loop "frame limiter" code.
`PropertyMap` wraps over `IndexMap` to handle object properties in
AVM1. All insert/remove/get methods require and `swf_version`
parameter, and the `PropertyMap` will take care of handling case
senstivity and maintaing iteration order based on the SWF version.
First implementation of Button object. Hook up to the button
display object and run onRelease etc. methods as appropriate.
Pull out common display object methods into globals::display_object.
This conversion allows negative octal values, but not negative
hex values, and ignores only leading ASCII whitespace. A test
for this behavior is included.
Specifically fall back to the device font when the UseOutlines
flag is not set in DefineEditText (SWF19 p.172). Fixes#451.
Note that since we only use a single font for "device" rendering,
this may sometimes be a different font than is specified in the
Flash IDE.
It doesn't feel like Flash without having the hand cursor display
when hovering over buttons. First pass at implementing this;
core communicates which mouse cursor to use via
`InputBackend::set_mouse_cursor`.
TODO: Hand cursor only displayed for Button display objects
currently. Movie clips should also display this when they are in
"button mode" (when a button mouse event is set on them in AVM1,
or `buttonMode` property in AVM2).
This is just testing that it exists and returns the same values as
getBounds for shapes without strokes.
TODO: When it is properly implemented for strokes, add stroked
shapes to testing.
Implements MovieClip.getBounds, and also reorganized the
DisplayObject AABB methods:
* `self_bounds` calculates the inherent untransfomed bounds of
the object without children. All `DisplayObject`s must implement
this method. For example, `Bitmap` returns the size of bitmap.
Composite objects like `MovieClip` return a null AABB because they
are made up of only children.
* `bounds` calculates the untransformed bounds including children.
* `local_bounds` calculates the bounds relative to the object's
parent.
* `world_bounds` calculates the bounds in global stage space.
* `bounds_with_transform` calculates a tight AABB for the object
with a given transform, and is used to implement the above.
Try to keep style more consistent by using functions for all MC
methods. Previous was a mix of closures and functions (we're still
a little bad with this elsewhere)
This is caused by the fact that `avm.root_object` references the *current* stack frame, not the one we are about to introduce. Ergo, we need to pull the base clip of the *new* stack frame and find it's root.
This particular behavior only crops up in situations where there can be multiple root objects, at least until we implement `_lockroot`.
`_root` is calculated dynamically based on the clip the currently executing function was called in.
Other things that used `context.root` have been changed to either update all layers or just update layer 0, which is the former `context.root`.
Interestingly enough, very little actually has to be done inside the async process for XML. The async process basically just fetches data and fires an event handler when it's done. Everything else is handled via a system builtin, `XML.onData`.
This implementation just returns the size of the current loaded movie. The test is also deliberately written to be loose on timings so that it likely won't see a partially loaded movie. (I don't want it to be a test of load events, so I just wait a few frames, rather than the correct way of waiting for `onLoadComplete`.)
Until we support streaming file loads, we can't faithfully support these properties. Still, it's better to have them, just in case.
This is technically better, but it may make more sense to trigger `ClipEvent::Load` at the start of the next frame instead. Furthermore, I don't know if other forms of load events should trigger on the next frame (or end of the current one) like this.
Loads in Flash Player, like all web technologies, are asynchronous tasks of some kind (probably a separate thread). They appear to operate on some kind of a delay. If I `trace` each frame out, like in the previous version of `mcl_loadclip`, you get a series of events that look like this:
1. Parent frame 1
2. Parent frame 2
3. Event: onLoadStart
4. Event: onLoadProgress
5. Event: onLoadComplete
6. Parent frame 3
7. Event: onLoadInit
If I run that version of the test on Ruffle, everything happens after frame 1. This is an artifact of how we're testing asynchronous behavior in Ruffle. In order to guarantee test determinism, we have a dummy implementation of `fetch` that does a blocking load, and we poll all futures every frame of execution. This means that there is a very specific order of execution with these tests, which is good for testing, but probably isn't 100% accurate.
Flash Player appears to delay all loads by at least one frame, even loads that are coming from disk which should load immediately. I don't know if this is intentional or not, so I don't want to implement a load delay just for the sake of making tests pass. Ergo, I'm loosening the tests to just test the ability to load and unload movies, and fire events from a loader.
Specifically:
1. `mcl_loadclip` no longer traces out frames of the parent timeline
2. `unloadmovie` et. all use a target movie that doesn't fail the test until 10 frames have passed.
If someone can find a movie network that breaks with fast loading, then I'll consider implementing explicit frame delays for async tasks. Otherwise, this is how we're testing this.
This also adjusts `MovieClip.unloadMovie` to do just that, instead of removing the clip from the display list. We also have to unload clips when loading new movies into them, since `unloadMovie` desugars to loading `""` as the URL.
Interestingly, this constitutes an implementation of `AsBroadcaster`. It appears Macromedia decided to implement event handling on `MovieClipLoader` in a very similar fashion to `AsBroadcaster`, down to invoking `broadcastMessage` and searching a `_listeners` property for listeners.
*De*implement the free function versions of the above, as well as their `Num` variants, since they don't actually exist as callables. Instead, the ActionScript compiler treats them as preprocessor functions that represent various forms of `ActionGetURL`/`ActionGetURL2`.
This function is part of `Avm1`, rather than a hypothetical `LayerManager`, because we're going to need to eventually construct layers differently for AVM2.
This has some subtle problems: we cannot hold references to garbage-collected data in Futures, so we have to arrange for the AVM itself to forcibly root them for us. Then we get them back when our async code is ready to do something to the AVM.
This allows the formation of `'static` futures that can still interact with a player. Async code will need to upgrade the weak reference in order to be able to interact with the player.
Due to some strangeness with the way Rust implemented unsafe-to-move behavior, boxed futures are implicitly `Unpin`. Which is useless to us.
The reason for this is a little counter-intuitive. Actually, the fact that Rust supports memory pinning at all is a little odd, because the core language explicitly requires all types be movable. To get around this, Pin requires that all !Unpin types be *born pinned*. This is because you can't re-pin an already unpinned value in memory.
Anyway, this necessitates this silly API change.
When `_parent` is preloaded in a `DefineFunction2` action,
we previously resolve it on the scope chain. This could cause
double borrow panics as the parent object could already be
borrowed, and also this matches the behavior of the official Flash
player.
Addresses #398.
This is the smallest positive number, not the most negative value.
This is actually the smallest positive subnormal f64, which Rust
does not provide a constant for. This is ~5e-324.
Match Flash's more closely when converting number to string:
* NAN -> NaN
* inf -> Infinity
* -inf -> -Infinity
* Use exponential notation for very large/very small
This is a little bit of a cheat by using Rust's number-to-string
formatting for exponentials, and shoving a sign in front of the
exponent.
Setting a property such as _x to undefined or null should have no
effect. This was working for v7+ SWFs because it would coerce to
NaN and we toss out NaNs. But on v6 and below, these coerce to 0
and would end up setting the property to 0.
Explicitly check for undefined/null and bail out. Fixes#380.
Also adjust the _visible setter, since this actually coerces to a
number (because of its legacy from SWFv4). For example,
_visible = "" should have no effect.
If a property is not set on the object passed to Color.setTransform,
then that channel is left unmodified. This fixes invisible objects
in some games (fixes#369, addresses #380).
Also improve handling of wrapping/invalid values to better match the
behavior in the Flash Player (some work pending on #193).
When a movie clip or button is used as a mask, the masking will be
disabled if that object has no children; the maskee will be
completely visible. An empty movie clip inside an empty movie clip
successfully masks.
An EditText can also not be used as a masker (although it can be
wrapped inside a movie clip, and then the text successfully masks).
Add a `TDisplayObject::allow_mask` trait method that will
return whether the object can be used as a mask.
This fixes characters not being visible in Dad 'n' Me.
If you goto past the final loaded frame of a timeline, for example,
with gotoAndStop(9999), this seeks to the final frame on the
timeline, but it doesn't run the actions on this frame.
MovieClip::goto_frame now will not run the final frame actions if
the target frame was not reached.
Use the same code path for the global GotoFrame2 action and
MovieClip.gotoAndX, which properly handles out-of-range and invalid
values like NaN.
Fixes Disorderly hanging on game start
(https://www.newgrounds.com/portal/view/121896)