- C17 fmax
- Rust f64::max
- LLVM llvm.maxnum
- ARM FMAXNM (either mode)
use std::{ | |
marker::PhantomData, | |
mem, | |
ops::{Deref, DerefMut}, | |
ptr::{self, NonNull}, | |
}; | |
use bytemuck::{AnyBitPattern, Zeroable}; | |
mod utils; |
My solution to this whole issue with Twitch's Community System would be to introduce a Tag based system instead. This is backwards compatible with the Community System. The idea would be that your stream has additional tags that specify additional information that can be searched for. So if you stream a Wind Waker 100% speedrun, you'd have these tags:
nintendo
, zelda
, wind waker
, gamecube
, japanese
, speedrun
, 100%
Now, it is obviously annoying to choose these tags, but the Game selection automatically implicitly selects the tags for this game for you, so for Wind Waker that would be:
nintendo
, zelda
, wind waker
, gamecube
Works pretty well, but not having a lock file and accidentally relying on packages that are in the node_modules folder, but are not present in the package.json, causes some occasional breakages here and there.
Does what it's supposed to do. I can't think of any issues with it.
Fits the state model of livesplit-core really nicely and is a really good fit for LiveSplit One for that reason. The performance isn't all too great though. But that's really only a problem due to the 30 FPS refresh rate. For any normal web page React should be just fine.
The backend has its own coordinate space that ranges from 0 to 1 across both dimensions. (0, 0) is the top left corner of the rendered layout and (1, 1) is the bottom right corner. Since the coordinate space forms a square, the aspect ratio of the layout is not respected.
^ ╔═══════════════════════════════════════════════════════════════════════════════════════════════╗ | |
| ║ ^ ^ ║ | |
| ║ | min(0.1 * H, 0.35) | 0.1 ║ | |
| ║ v v ║ | |
| ║ ╔════════════════╗ ^ ^ ╔═════════════════════════════╗ ^ ║ | |
| ║ ║ ║ | | ║ ║ | ║ | |
| ║ ║ ║ | | ║ ║ | Ascent ║ | |
| ║ 0.35 ║ ║ | | ║ ║ | ║ | |
H | ║ <----> ║ IMAGE ║ | dynamic |
Language | Compiler | Setup / Limitations | Standard Library |
---|---|---|---|
TypeScript | duktape | Needs Web IDE Setup | Everything but OS operations |
JavaScript | duktape | Needs Web IDE Setup | Everything but OS operations |
Rust | Rust | wasm32-unknown-unknown or -wasi target | Everything works with -wasi target |
AssemblyScript | AssemblyScript | No builtin UTF-8 support | Has optional WASI library for OS operations |
Go | tinygo | Needs some flags, annotations and wasm-snip of at least io_get_stdout. | Everything but OS operations |
Python | RustPython | Needs Web IDE Setup and is slow |
We can't use std's Instant as it's insufficiently specified. It neither guarantees "real time" nor does it guarantee measuring "uptime" (the time the OS has been awake rather than suspended), meaning that you can't actually rely on it in practice. In livesplit-core we definitely want real time rather than uptime. Various operating systems are problematic: