* wpgu: Initial implementation of PixelBender shader execution
The implementation is split across four crates:
* `ruffle_render` now holds the main PixelBender bytecode parsing
implementation (previously, this was in `ruffle_core`).
* `ruffle_core` holds some helper functions for converting between
AVM2 `Value`s and the PixelBender vector types.
* `naga-pixelbender` (newly created) constructs a Naga `Module`
from parsed PixelBender bytecode
* `ruffle_render_wgpu` sets up the render pipeline for the shader
constructed by `naga-pixelbender`, and actually executes the shader.
The Actionscript-side shader parameters are passed in through uniforms.
This allows us to cache the compiled `naga::Module` and associated
wgpu types inside `ShaderData`, when it's first created. Each invocation
of a `ShaderJob` only needs to create a bind group and render pass.
Limitations:
* Only a few of the PixelBender opcodes are implemented - however, this is
enough to get Stemlands cannon rotation working, as well as a cool
"donut" shader that I found and included as a test.
* PixelBender matrix types are not supported.
* Only BitmapData is supported as an input/output type - Flash Player
also supports using Vector and ByteArray
* ShaderJob execution is always synchronous.
* Adjust comments
* Address review comments
We create a separate child domain, which is accessible
from the Stage and the root movieclip.
This prevents ActionScript from loading classes into the
special playerglobals domain (Domain.parentDomain is modified
to return null instead of the playerglobals domain when applicable),
so the native method lookup logic will never run for user code.
We now support deleting named children, as well as attributes.
Additionally, I've fixed our handling of `XML.parent()` - we now
properly set the parent when a child is created, and clear the parent
when `delete` is used.
If a child named 'foo' is removed by the timeline (without
having been previous added/removed from the timeline by ActionScript),
then the 'foo' field in the parent will be set to null. This occurs
even if the 'foo' field in the parent is not currently set to
the child 'foo' (e.g. 'this.foo = someOtherObject' was executed by
ActionScript).
The Adobe Animate compiler rejects a subclass that contains
a non-private field with the same name as a field in an ancestor
class (e.g. 'pub var foo:String' in both the subclass and superclass).
Unfortunately, Flash Player accepts this code, and creates a distinct
field for each class (even though they have the same namespace and
name). I suspect that this is caused by the optimizer replacing the
field accesses with internal slot accesses.
I've added an ignored test demonstrating this behavior - getting Ruffle
to reproduce it will be tricky.
When we run a 'goto', a weird "nested frame" gets triggered.
Previously, we were only calling `construct_frame` on the target
MovieClip as part of this "nested frame". However, Flash Player
seems to treat this (in some ways) like a normal frame - *all*
objects on the Stage (and orphans) have `construct_frame` called.
In particular, `gotoAndStop`/`gotoAndPlay` is called during
an "enterFrame" event handler, then unrelated objects on the Stage
will have their children constructed during the execution of
`gotoAndStop`/`gotoAndPlay`. The same logic holds for frame scripts.
This fixes a bug in Steamlands, which relies on children on the main
timeline being constructed immediately following a call to `gotoAndStop`
on an orphan (originally triggered from an "enterFrame" handler).
QName can contain characters like '.' and '<' as part of the
package or class name (though this requires editing the SWF
or using a nonstandard compiler). This broke our attempt to parse
generic type paramters by looking for '.<'
Instead, our 'Vector' special casing now operates on the unparsed
'AVMString' name, instead of attempting to construct a 'QName'.
This means that we don't need to handle generic paramters at
all for obfuscated names (which will never start with '__AS3__'
or 'Vector.<')
This fixes a bug in Red Ball 4v3, which has an obfuscated class
'!D.<H'
If we have two PlaceObject tags in the same frame with the same depth,
only the first one actually places an object. The second one is ignored
(Flash Player logs a warning).
We now parse PixelBender bytecode, and populate the parameters
from the bytecode on `ShaderData`. This is enough to progress
Steamlands, which needs to access dynamically set properties
on `ShaderData`
Bytecode execution is not implemented yet.
When we create a DisplayObject from ActionScript, we should always
run `construct_frame` on it, regardless of what frame phase we
are currently in.
This fixes a regression in Fancy Pants World 4 Part 1, where entering
the first door produced an error.