* Initial commit
* Update macros
* Add GPU Markers
* Fix builds without microprofile
* minor updates
* clang format
* Update profiler.cpp
* clang format
* Name Main Thread
* Update profiler_macros.h
* Fix end flip
* Update fiddle_context_gl.cpp
* clang format
* Update rive_build_config.lua
* Update rive_build_config.lua
* forked microprofile so I can use a tag
* Update render_context_d3d_impl.cpp
* clang
Co-authored-by: John White <aliasbinman@gmail.com>
* Add profiling macros and optick profiler
* Update premake5_optick.lua
* Added more profiling markers
* Remove microprofiler option for now as not implemented
* Added more markers ro rendering code
* Update Optick build premake only for windows builds
* More build file changes for optick with windows
* Change how optick is built on windows
* Update premake5_v2.lua
* Update build files to use with_optick option
* Added ScopeName macro to appease ASAN
* Push to rekick jobs
* Delete ProfilerMacros.h
* Create profiler_macros.h
* Update path_fiddle.cpp
* Update fiddle_context.hpp
* Update for rename of header
* More header changes
* Update fiddle_context.hpp
* Update profiler_macros.h
* Update for clang format
* Update fiddle_context.hpp
* Update profiler_macros.h
* Update profiler_macros.h
* Changed premake values on Chris' comments
* Removed multiple define fro RIVE_OPTICK and now in rive_build_config.lua
* Added Optick URL and Version to rive_build_config
Co-authored-by: John White <aliasbinman@gmail.com>
It looks like the premake5 "v5.0.0-beta3" tag isn't compatible with
Sequoia 15.4.1. Bump our tag to v5.0.0-beta7 and update the deprecated
features we had been using.
Also fix the script to rebuild if the premake5 binary doesn't exist.
Before it only checked if the parent "premake-core" directory existed,
so if a build had failed previously, build_rive.sh would fail forever
without ever attempting to build premake5 again.
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Co-authored-by: Jonathon Copeland <jcopela4@gmail.com>
Drafting as I'm still working on where to show the reports. You can run locally by doing:
```
cd pacakges/runtime/tests/unit_tests
./test.sh coverage
```
Diffs=
99cf88f77d Report runtime test coverage (#9114)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
This pull request adds support for both visionOS and tvOS to the Apple (colloquially referred to as iOS) runtime.
It should _not_ be a breaking change, since the only major API change is an internal one (see `RenderContext` below). I believe we should be able to make this a minor release. Developers who have subclassed `RiveView` or `RiveRendererView` should not see any changes, unless they were explicitly expecting this view to be `MTKView`, which is fully unavailable on visionOS (hence our recreation - see `RiveMTKView` below.
## Premake Scripts
The premake scripts were updated to add a few new variants for iOS:
- xros (visionOS devices; named after the internal sdk)
- xrsimulator (visionOS simulator; named after the internal sdk)
- appletvos (tvOS devices; named after the internal sdk)
- appletvsimulator (tvOS simulators; named after the internal sdk)
The majority of the work here is copy/pasting existing code, and just adding additional filters when these new options are used, primarily used to target the new SDKs / minimums for those SDKs.
## Shaders
Shaders are pre-compiled for visionOS and tvOS separately, and the correct shaders are then used later-on at compile time.
## Build scripts
Build scripts were updated to support building the new libraries, targeting the new devices, using the new options above. Additionally, they have to point to new output files.
The `build_framework` script has been updated to build the new libraries to add to the final output `xcframework`.
## Project
Example targets for both visionOS and tvOS, since these truly are the "native" apps, rather than just iPad-on-your-device. These use a new `streaming` riv by the creative team.
The tvOS example app adds additional support for remote control, since that behavior can be utilized in multiple ways during development; that is, we don't add any "default" behavior for remote controls. The visionOS app, on the other hand, works out-of-the-box with no additional changes.
## RenderContext
`RenderContext` is an internal type; it's forward-declared, so it's unusable outside of the scope of internal development. There have been some "breaking" changes here - the API has been updated to, instead of passing in `MTKView` around, using `id<RiveMetalDrawableView>`. This had to be changed, regardless, since visionOS does not have `MTKView`. The choice to use a protocol was because it forces a little more explicit initialization across platforms, rather than having a parent class that acts as an abstract class, but isn't abstract because it still needs some default values, but those values are different based on device and API availability, etc. We could've passed around `RiveMTKView` as the type, but with a protocol, there's a possibility of being able to use a type that isn't exactly a view, but might want to still act against the drawing process. Personal choice, really.
## RiveRendererView
`RiveRendererView` is now a subclass of `RiveMTKView`. `RiveMTKView`'s superclass depends on the device:
- On visionOS, this is a `UIView` with an underlying `CAMetalLayer`
- On all other platforms, `MTKView`
This new class conforms to `RiveMetalDrawableView`, which allows it to be passed to `RenderContext` types.
### RiveMTKView (visionOS)
`RiveMTKView` on visionOS is a subclass of `UIView` that is backed by a `CAMetalLayer`, providing the necessary properties of `RiveMetalDrawableView` (compile-time safety here, baby). This is quite a simple recreation of the default `MTKView`, since that type is not available on visionOS (thanks, Apple).
## Other things
Additional compile-time checks for platform OS have been added to make sure each new platform compiles with the correct APIs that can be shared, or otherwise newly implemented.
Diffs=
6f70a0e803 Add visionOS and tvOS support to Apple runtime (#8107)
Co-authored-by: David Skuza <david@rive.app>
This makes sure that the yoga includes are only included in internal headers.
Eventually we should move private headers to the "internal" folder, for now I'm just defining a helper header to include in internal only headers which will assert if it's incorrectly included by a runtime/higher level public implementation.
Diffs=
071b19ba62 don't expose yoga includes (#8526)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Co-authored-by: blakdragan7 <jcopela4@gmail.com>
Many changes to add in support for Unreal RHI
This is the first step. Afterwords we need more changes such as finalizing the for_unreal switch to premake.
Diffs=
1cc5f2b6f Prep for rhi (#8270)
Co-authored-by: Jonathon Copeland <jcopela4@gmail.com>
By including ```rive/text/font_hb.hpp``` in iOS you'll get access to ```HBFont::FromSystem``` along with the ```HBFont::Decode``` (which we've been using so far to generate Font objects to put into the fallback list).
You can get a UIFont with [this API](https://developer.apple.com/documentation/uikit/uifont/1619027-systemfontofsize?language=objc).
You should be able to cast that to a CTFontRef:
```
CTFontRef ctFont = (__bridge CTFontRef)uiFont;
auto fallbackFont = HBFont::FromSystem((void*)ctFont);
```
You can then use that in a fallback font procedure (like the example from the editor below) to load on demand/cache/provide from a list etc:
b5b930f88f/packages/rive_common/macos/rive_text/rive_text.cpp (L153-L175)
Diffs=
da1bb7745 Make an HBFont from a CTFontRef. (#7661)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Addresses the Unity issues raised by Adam here: https://2dimensions.slack.com/archives/CLLCU09T6/p1718727712078119
libjpeg has a flag `NEED_SHORT_EXTERNAL_NAMES`, which renames functions to shorter names, however, I didn't use this approach because its possible we could get naming collisions if someone brings another 3rd party lib which also has this flag enabled.
Diffs=
a4439ee42 Renames for Yoga and libjpeg (#7446)
Co-authored-by: Philip Chung <philterdesign@gmail.com>
Trying to disable some unused features that might be biting us..
Diffs=
0d03a416b Fix ios analyzer (#7198)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Thread here: https://2dimensions.slack.com/archives/CLLCU09T6/p1707353939433169
The executable will return a non zero code with an error printed on stderr if there's a problem. If the exit code is 0 (success) the output will be JSON like this:
```
{"channels":2,"duration":192.49632263183594,"format":"mp3","sampleRate":44100,"size":8095932}
```
or:
```
{"channels":2,"duration":3.9996354579925537,"format":"wav","sampleRate":96000,"size":2303834}
```
Sample invocation:
```
rive_audio_preview_generator -s ~/Desktop/games_original.wav -d ~/Desktop/games_preview.mp3
```
Diffs=
e145f9348 Add audio preview generator. (#6580)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
* Don't use an external premake extension for emscripten; just set up the environment ourselves to build with emscripten.
* Delete the spots that turned on the '-pthread' flag for emscripten.
* Get the WebGL and WebGPU builds compiling again and add a github workflow for them.
* Delete the bubbles example. It didn't compile on android or wasm and caused confusion. It's in the git history if we want it back.
Diffs=
ac0d97c12 Clean up emscripten build (#6531)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
