The mouse picking behavior in AVM2 interacts in complicated
ways with `mouseEnabled` and `mouseChildren.` It's sufficiently
different from AVM1 that I decided to split the logic into separate
`mouse_pick_avm1` and `mouse_pick_avm2` methods.
The `mouseChildren` property is now fully implemented.
Additionally, the `click_block` tests now work correctly
under Ruffle.
Combined with the orphan-movie PR, this is enough to make
SteamBirds fully playable (though performance greatly degrades
over a course of a level).
When removing a clip, first check if it has an unload event listener somewhere
it's hierarchy.
If it does, enqueue the removal to happen on the next frame, by moving it to a negative depth.
In future versions of `gc-arena`, the `Debug` impl. of `Gc`
and `GcCell` will print the pointed-to value, which will cause
derived `Debug` impls. to enter an infinite recursion.
As such, this manually implements `Debug` on types wrapping a
`Gc/GcCell` to maintain the current behavior.
This also centralizes all the code we added in the prior commit into `on_construction_complete`, which should be called whenever an AVM2 object finishes construction.
D.O.s removed by the timeline may only be removed from the depth list
(if they were manipulated by AS3 scripts), but their unload method
would still be called, which is wrong.
And make it generic, as a first step towards making it a general-purpose
data structure for the whole codebase. Some potential replacements are:
* `BoundingBox` in `render/src/bounding_box.rs`.
* `BoxBounds` in `core/src/html/dimensions.rs`.
* Parameters to a bunch of `BitmapData` methods in
`core/src/bitmap/bitmap_data.rs`.
Change `set_matrix` and `set_color_transform` to accept owned structs,
instead of references. This allows callers that already have an owned
struct to pass it directly, thus saving an unnecessary borrow + clone.
This also aligns with other methods, such as `set_sound_transform`,
which currently accepts an owned struct.
It was only used to make structs `#[derive(gc_arena::Collect)]`, and
generally it doesn't make much sense that `render` needs to be GC-aware.
So instead annotate `render` fields in `core` with `#[collect(require_static)]`.
This PR implements the `Loader.load` method, as well as
the associated `LoaderInfo` properties and events.
We can now load in an external AVM2 SWf: it will be added
as a child of `Loader` object, and will render properly
to the screen.
Limitations:
* The only supported `URLRequest` property is `url`
* `LoaderContext` is not supported at all - we always use the default
behavior
* Only `Loader.load` is implemented - we do not yet support unloading.
* We fire a plain 'Event' for the 'progress' event, instead of using
the (not yet implemented) 'ProgressEvent' class
The main changes in this PR are:
* The AVM2 `Loader` class now has an associated display object,
`LoaderDisplay`. This is basically a stub, and just renders
its single child (if it exists).
* `LoaderStream::Stage` is renamed to `LoaderStream::NotYetLoaded`.
This is used for both the `Stage` and an 'uninitialized'
`Loader.contentLoaderInfo`. In both cases, certain properties throw
errors, while others return actual values.
* The rust `Loader` manager now handles both AVM1 and AVM2 movie loads.
Each render backend keeps track of a stack of BlenModes,
which are pushed and popped by 'core' as we render objects
in the displaay tree. For now, I've just implemented BlendMode.ADD,
which maps directly onto blend mode supported by each backend.
All other blend modes (besides 'NORMAL') will produce a warning
when we try to render using them. This may produce a very large amount
of log output, but it's simpler than emitting each warning only once,
and will help to point developers in the right direction when they
get otherwise inexplicable rendering issues (due to a blend mode
not being implemented).
The wgpu implementation is by far the most complicated, as we need
to construct a `RenderPipeline` for each possible
`(BlendMode, MaskState)`. I haven't been able to find any documentation
about the maximum supported number of (simultaneous) WebGPU render
pipelines - if this becomes an issue, we may need to register them
on-demand when a particular blend mode is requested.
This PR implements the 'DisplayObject.transform' getters/setters,
and most of the getters/setters in the `Transform` class
From testing in FP, it appears that each call to the
'DisplayObject.transform' property produces a new
'Transform' instance, which is permanently tied to the
owner 'DisplayObject'. All of the getters/setters in
`Transform` operate directly on owner `DisplayObject`.
However, note that the `Matrix` and `ColorTransform`
valuse *produced* the getter are plain ActionScript objects,
and have no further tie to the `DisplayObject`.
Using the `DisplayObject.transform` setter results in
values being *copied* from the input `Transform` object.
The input object retains its original owner `DisplayObject`.
Not implemented:
* Transform.concatenatedColorTransform
* Transform.pixelBounds
When a DisplayObject is not a descendant of the stage,
the `concatenatedMatrix` property produces a bizarre matrix:
a scale matrix that the depends on the global state quality.
Any DisplayObject that *is* a descendant of the stage has
a `concatenatedMatrix` that does not depend on the stage quality.
I'm not sure why the behavior occurs - for now, I just manually
mimic the values prdduced by FP. However, these values may indicate
that we need to do some internal scaling based on stage quality values,
and then 'undo' this in certain circumstances when constructing
an ActionScript matrix.
Unfortunately, some of the computed 'concatenatedMatrix' values
are off by f32::EPSILON. This is likely due to us storing some
internal values in pixels rather than twips (the rounding introduced
by round-trip twips conversions could cause this slight difference0.
For now, I've opted to mark these tests as 'approximate'.
To support this, I've extended our test framework to support providing
a regex that matches floating-point values in the output. This allows
us to print out 'Matrix.toString()' and still perform approximate
comparisons between strings of the format
'(a=0, b=0, c=0, d=0, tx=0, ty=0)'
Previously, we would create a fresh `LoaderInfo` object each
time the `loaderInfo` property was accessed. However, users can
add event handlers to a `LoaderInfo`, so we need to create and
store exactly one `LoaderInfo` object per movie (and stage).
To verify that we're correctly handling the storage of `LoaderInfo`,
I've implemented firing the "init" event. This required a new
`on_frame_exit` hook, so that we can properly fire the "init"
event after the "exitFrame" for the initial frame but before
the "enterFrame" of the next frame.
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.
Nathan Adams