search

LiveSplit / livesplit-core

livesplit-core is a library that provides a lot of functionality for creating a speedrun timer.
https://livesplit.org/
Apache License 2.0
209 stars 57 forks source link

Support no_std use cases by using alloc #223

Closed CryZe closed 2 years ago

CryZe commented 5 years ago

We long term want to support compilation of livesplit-core with just core + alloc. You'd provide your own time source as some global handler but other than that everything should mostly just work as we already see with wasm32-unknown-unknown. However most crates that we depend on probably don't support this yet, so that's probably going to be a lot of Pull Requests.

Update

All the crates we need are sufficiently patched on forked branches. We just need to do a bunch of PRs now. Here's the super fancy results, with LiveSplit One being rendered within the world of Wind Waker:

https://twitter.com/CryZe107/status/1158444993549414401

Status

Basic Support

Required

Rendering

Software Rendering

CryZe commented 5 years ago

It seems that std::io is causing massive problems, where all our parsing, saving, serializing and co. is just not within the bounds of core and alloc. It easily could be as there barely is a reason you can't do IO without an operating system, but it's currently std only due to OS specific error codes. There is a fork called core-io, but that's going to be a ton of PRs. However there is the possibility of simply not doing any parsing, saving and serializing on no_std until then. Other problems include HashMap, Hotkeys, timing and paths, but all of these can easily be replaced (BTreeMap, mocked Hotkeys, timing handler, and a wrapper around String / &str).

Images are probably also going to be problematic, but other than for rendering, image shrinking and parsing, we don't actually need to interpret them.

hallcristobal commented 5 years ago

Speaking in terms of a no_std implementation, I see no real reason to have file IO directly. At most I could see implementing support for Parsing and Serializing but leave it to the developer implementing the no_std library to handle any IO needs. This would require a custom built BufReader, BufRead, Seek (possibly others) implementations which might be outside the scope of this crate though. Having livesplit-core omit this functionality until that can be safely, and correctly, implemented seems like a viable path to go down for now.

CryZe commented 5 years ago

Well yeah it wouldn't be File IO, it would just be the IO traits, such as Read, Write, Seek, BufRead that we can't use as they are in std only. And all our dependencies use them too, so that's a pain to fix in the ecosystem without no clear solution other than possibly using the fork, but that's super hacky too.

CryZe commented 4 years ago

All required crates are released now, so we can merge basic support in.

CryZe commented 3 years ago

So a ton changed in our renderer recently and we have fairly different dependencies now. rusttype is gone, lyon is gone and instead we have ttf-parser, tiny-skia and rustybuzz as dependencies now. ttf-parser is already no_std compatible, rustybuzz turned out to be trivial, so I just opened a PR. I'll have to look into tiny-skia as well, but I believe we can probably close this soon.

CryZe commented 2 years ago

This is blocked on proper optional feature propagation support in cargo, which is reasonably close to stabilizing.