| commit | 1e4015f41a46a73048faf3d8891f434e9c706590 | [log] [tgz] |
|---|---|---|
| author | JoshJRive <hello@rive.app> | Thu Sep 04 17:16:54 2025 +0000 |
| committer | JoshJRive <hello@rive.app> | Thu Sep 04 17:16:54 2025 +0000 |
| tree | 42f971df2cc94d5271697cb2bb3fa136846de3f0 | |
| parent | e049c47e1b3ac4af0a09570d75e17dcdcb707a9e [diff] |
fix(ios): Don't call abort when the unexpected happens. (#10472) 1adc508ecd * removed aborts and properly handle the error case instead. Don't use printf because nslog allows for proper output to log files in ios * more converts to nslog * made checks more specific * Wiring up multiple synthesized failure types * Wiring through the new synthesized failure modes to D3D11, 12, and GL * Move the Metal ubershaderLoad failure synthesis to a better spot * clang format * Missed wrapping a variable in #ifdef WITH_RIVE_TOOLS * Correction: missed *multiple* #ifdef WITH_RIVE_TOOLSes * Still more * Testing to see if the D3D12/GL errors are related to the ubershaderLoad synthesis or not * Removing additional pieces of the testing to see what's causing the issues * It's important to write your preprocessor directives correctly 🙃 * Trying to figure out what the fence value is that is coming out wrong on the D3D12 tests and why GL is failing * trying something dumb to see if this re-breaks the oneplus7 * Split the render test up into three tests to see if it is any better on the oneplus7 * Trying to see where the d3d12 device is getting removed (and why), and also what happens if I run 2 of the same synth test on oneplus7 * Sorry everyone it's effectively printf debugging time 🫤 * Changed the CreateEvent call to see if that works for D3D12 and also more printing for GL * More * Okay testing some other dumb stuff - this might resolve oneplus 7, still no idea on D3D12 yet * Testing an alternate fix for the oneplus7 issue plus a different initial frame value for the copy fence * Adding a comment before push * Clean up the testing code (the D3D and oneplus7 issues are fixed but now there's a GL issue on windows. sigh. * clang format again I'm good at this lol * Okay I think this will fix the windows GLFW issue at the cost of it might break all the android tests or something (but I hope not!) * Now debugging why glfw window creation is failing for windows unit tests * Okay this should "fix" the GL issues on github by just not creating a GL window if GL is not supported. * Some minor cleanup * Clarifying a comment, mostly to get the tests to re-kick Co-authored-by: Jonathon Copeland <jcopela4@gmail.com> Co-authored-by: Josh Jersild <joshua@rive.app>
Rive C++ is a runtime library for Rive, a real-time interactive design and animation tool.
The C++ runtime for Rive provides these runtime features:
We use premake5. The Rive dev team primarily works on MacOS. There is some work done by the community to also support Windows and Linux. PRs welcomed for specific platforms you wish to support! We encourage you to use premake as it's highly extensible and configurable for a variety of platforms.
In the rive-cpp directory, run build.sh to debug build and build.sh release for a release build.
If you've put the premake5 executable in the rive-cpp/build folder, you can run it with PATH=.:$PATH ./build.sh
Rive makes use of clang vector builtins, which are, as of 2022, still a work in progress. Please use clang and ensure you have the latest version.
Uses the Catch2 testing framework.
cd tests/unit_tests ./test.sh
In the tests/unit_tests directory, run test.sh to compile and execute the tests.
(if you've installed premake5 in rive-runtime/build, you can run it with PATH=../../build:$PATH ./test.sh)
The tests live in rive/test. To add new tests, create a new xxx_test.cpp file here. The test harness will automatically pick up the new file.
There's a VSCode command provided to run tests from the Tasks: Run Task command palette.
rive-cpp uses clang-format, you can install it with brew on MacOS: brew install clang-format.
Note that if you‘re on MacOS you’ll want to install valgrind, which is somewhat complicated these days. This is the easiest solution (please PR a better one when it becomes available).
brew tap LouisBrunner/valgrind brew install --HEAD LouisBrunner/valgrind/valgrind
You can now run the all the tests through valgrind by running test.sh memory.
If you want to examine the generated assembly code per cpp file, install Disassembly Explorer in VSCode.
A disassemble task is provided to compile and preview the generated assembly. You can reach it via the Tasks: Run Task command palette or you can bind it to a shortcut by editing your VSCode keybindings.json:
[
{
"key": "cmd+d",
"command": "workbench.action.tasks.runTask",
"args": "disassemble"
}
]