ruffle/tests/Cargo.toml

25 lines
721 B
TOML
Raw Normal View History

[package]
name = "tests"
version = "0.1.0"
authors = ["Aaron Hill <aa1ronham@gmail.com>"]
edition.workspace = true
[dependencies]
futures = "0.3.24"
ruffle_core = { path = "../core", features = ["deterministic", "timeline_debug", "avm_debug"] }
ruffle_render_wgpu = { path = "../render/wgpu", optional = true }
ruffle_input_format = { path = "input-format" }
image = "0.24.4"
avm2: Implement DisplayObject.transform and most of Transform 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)'
2022-06-19 20:37:31 +00:00
regex = "1.6.0"
2021-02-20 18:10:04 +00:00
[features]
# Enable running image comparison tests. This is off by default,
# since the images we compare against are generated on CI, and may
# not match your local machine's Vulkan version / image output.
imgtests = ["ruffle_render_wgpu"]
[dev-dependencies]
approx = "0.5.0"
pretty_assertions = "1.3.0"
env_logger = "0.9.1"