The fix in #5218 wasn't sufficient; 30-bit arithmetic should be used
along all the way when calculating an effective sound transform.
For example, a sound transform composited by volumes `-0x80000000` and
`25` should end up as effectively 0, whereas previously it would have
been calculated as `-0x80000000 * 25 / 100 = -0x20000000`, which is a
30-bit integer that hasn't been truncated.
Fixes#5655.
This also necessitated removing the `impl_display_object` family of macros, as you cannot name a field of a field in a macro expression. I tried. So instead I've reverted to standard default method inheritance, in the same way we did with AVM2 objects.
`handle_clip_event` is now a default trait method that calls three methods in order:
* `filter_clip_event`, to determine which events that either this object or it's children may handle
* `propagate_to_children`, to check if any children of this object want to handle an event. (This also includes AVM2 button states, which are not technically "children" in the usual sense...)
* `event_dispatch`, which does the actual "object reacts to an event" bit if no child handles the object.
These roughly correspond to phases of existing event-handling objects pre-`InteractiveObject`.
* Rename movie_clip::ClipAction to movie_clip::ClipEventHandler.
* Store the swf::ClipEventFlag event flags that trigger the event
directly in the event handler. Previously we split up any event
that had multiple event flags into separate events. Now these
can be kept as a single event.
* Remove `MovieClip::has_button_event`, and instead store the
union of all event flags in `MovieClip::clip_event_flags`. This
will be useful for other cases in the future.
A `PlaceObjectAction::Replace` signals that a shape should
be swapped with a different shape. Previously we instantiated a
completely new `Graphic`, but this is incorrect; instead the
underlying shape handle should be swapped out, but the outer object
remains. This is visible in AVM2 where you can access `Shape` as
a normal display object.
Matrices in an SWF file store their scale/skew components in
in 16.16 format (fbits).
Split `ruffle_core::Matrix` and `swf::Matrix`. `swf::Matrix` now
stores its data as `Fixed16` instead of immediately converting to
`f32`.
Move `MovieClip::is_swf` flag to `DisplayObject::is_root`, and use
this flag to handle the behavior of `DisplayObject.root` crawling
upwards until it hits a top-most loaded SWF/Bitmap.
Simplify `root` and `stage` so that they don't have to consider
buttons. Instead, do some trickery to ensure the button's states
see the proper values of `parent`, `root`, and `stage` during
construction.
`parent` is now a bare accessor, `avm1_parent` returns what AVM1 thinks the parent should be, and `avm2_parent` returns what AVM2 thinks the parent should be.
Use the proper types for ColorTransform:
* Fixed8 (8.8) format for multiplicative component
* i16 format for additive component
This matches the behavior of Flash (for example, alpha only changes
in units of 1/256).
If a child clip is named `_level0`, accessing `_level0` should
return the level and not the child clip.
Move `DisplayObject::get_level_by_path` to `StageObject`, and
change it to return an `Option<Value>`, and return
`Some(Value::Undefined)` if the path is a valid level path but
the level is not occupied. This causes get/set of `_levelN` to
be swallowed, even if the level isn't populated.
This appears to only be in use for AVM2. Objects placed on a given frame are constructed before anything else happens with it's parent - even it's constructor being called. This involves splitting AVM2 up into a bunch of steps that really don't make sense for AVM1 content. Hence, `construct_frame` is a no-op for AVM1 and pre-running the first frame when instantiated is AVM1 exclusive now.
Since 19034b7, clip event scripts are returned as slices from the
SWF. This caused a panic when a movie was loaded into a clip,
because the loaded clip's `movie` would be used as the source for
clip events. However, clip events are placed by the parent's
PlaceObject tags, so the movie in this case should be the parent's
movie.
Fixes#2870.
The purpose of this refactor is twofold:
1. Ensure `TDisplayObjectContainer` holds all the container methods we need
2. Ensure that future adjustments to trait methods automatically apply to the display object's own use of the container, in case we want to do things in those methods that can't be done in a borrowed container
There are two places where we cannot use the new trait methods:
1. `Button.set_state` as it holds a borrow at the point we want to clear the container
2. `MovieClipData.goto_remove_object`, since it's a method on the data and thus cannot access trait methods
This particular commit generates a lot of noise as several `DisplayObject` methods were incorrectly marked as non-mutating.
`ChildContainer` is responsible for maintaining child lists for all display objects that can hold children. Currently, this is just `Button` and `MovieClip` since those are the only objects in AVM1 that can have children, but this will be extended to other objects in future commits.
The number of lists managed has also increased from two to three. The execution list is unchanged save for it's migration into the `ChildContainer` struct. The render list has been split in two to support AS3. Specifically, the render list is now a `Vec`. Render children are still rendered in order but they are now referenced by AS3 `id`s rather than depths. The old `BTreeMap` that served as a render list is now the depth list and serves to maintain compatibility with SWF tags and AVM1 code that refers to things on the timeline by depth.
Moulins