livesplit-core is a library that provides a lot of functionality for creating a

Clone the repository and build the library with the following command:

livesplit-core

livesplit-core is a library that provides a lot of functionality for creating a speedrun timer. It can be used directly from Rust. Additional bindings are available for the following programming languages:

  • C
  • C++
  • C#
  • Java with Java Native Access or Java Native Interface
  • Kotlin with Java Native Interface
  • Swift
  • Ruby
  • Python
  • JavaScript + TypeScript for Node.js and WebAssembly

The documentation is available here:

  • Rust Documentation
  • TypeScript Documentation

Build Instructions

You can install Rust with the installer available on rustup.rs. Clone the repository and build the library with the following command:

The library will then be available as a shared and static library in the target folder.

If you want to build the bindings for the library too, you need to go into the capi/bind_gen folder and run the following command:

The bindings will then be available in capi/bindings.

Download

Builds for a lot of common platforms are available in the Releases.

License

Licensed under either of

  • Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT) at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.

Issues

Collection of the latest Issues

Hurricane996

Hurricane996

0

In certain contexts, when implementing a timer using this lib, the implementor will want to provide the user with a way to press a key which will then be set as a hotkey. However, if the implementor is using an input system which doesn't map surjectively (ie if two keypresses are the same according to the implementor's input system, they are the same according to livesplit-hotkey) to livesplit (eg winit/glutin), this becomes impossible to actually do without registering and then deregistering a hook for every single hotkey.

My proposal to fix this is to add a register_global_hook function that will call a callback whenever livesplit-hotkey recieves any keypress and provide that callback with the key that was pressed.

ShalokShalom

ShalokShalom

0

Is there a list of all the known implementations?

So, to find alternatives like Livesplit One and similar.

I am on Linux and trying to find a solution.

BRQuad

BRQuad

3

How you use livesplit-core with JNI on Linux ?

File system : /lib/livesplitcore/livesplitcore.so Java file : System.loadLibrary("livesplitcore") (static) in LiveSplitCoreNative.java IntelliJ : livesplitcore library in /lib/livesplitcore + livesplitcore library dependancy in the project module Java option : -Djava.library.path=/lib/livesplitcore

And finally i have an error : UnsatisfiedLinkError: no livesplitcore in java.library.path

I have used the livesplit-core-v0.12.0-x86_64-linux-android.tar.gz file. Does the .h and .cpp files are necessary ? And have the same name ?

DarkRTA

DarkRTA

enhancement
0

This is something we currently support on LiveSplit One Web by letting the browser handle it, but is something we completely lack in the native renderer.

CryZe

CryZe

enhancement
0

Currently we don't do any font fallback at all, which means that languages outside the latin range and emojis are not really supported with the default path based text engine at the moment. I have started working on a prototype, but it's not ready yet.

CryZe

CryZe

enhancement
4

It seems like on most platforms our hotkeys currently repeat when you keep the key pressed.

  • Windows (There's no way to differentiate, we probably have to track the pressed, released status ourselves)
  • Linux (Easy to deal with on evdev)
  • macOS (The event has a EventField::KeyboardEventAutorepeat field that we need to take into account)
  • Web (The event has a repeat field that we need to take into account)
CryZe

CryZe

enhancement
0

KeyCode is based on a Keyboard layout independent web specification. This is great as this means the hotkeys will always refer to a very specific key on the Keyboard no matter the operating system or currently active layout. However when visualizing these in some user interface, the user would prefer to see the key as it is on their keyboard.

I have a WIP implementation for all the platforms, but there are some issues:

  • For Linux we need an open X11 connection.
  • In the web the API is actually async, and I don't want to expose it that way in Rust.

I initially started implementing this as a free method on KeyCode but it will likely for the reasons above need to be a method on Hook / HotkeySystem. The reason for this is that for the web we need a point where we start up the Promise that loads the layout map, such that later when we call the resolve method, the result would be available (hopefully, if not we'll just use the fallback implementation, but it resolves basically immediately on the next tick). The Hook / HotkeySystem constructor is the ideal point in time for this. Also since we need an open X11 connection on Linux, we can just reuse the one we already use for the hotkey handling. Thus implementing this as a method seems to work reasonably well on all platforms.

  • Windows
  • macOS
  • Linux
  • Web
CryZe

CryZe

enhancement
0

In #449 we accidentally merged too early. The component settings were in an inconsistent order. We can write a test per component that just iterates through all the settings and sets them with the value they already have. That way we have a basic "smoke test" that ensures that at least a basic interaction like that works across the board. That would've caught this.

CryZe

CryZe

enhancement
2

As it turns out, creating brushes is actually quite expensive with a lot of rendering backends. So we definitely want to only create them once and then just attach them to the individual entities.

verstatx

verstatx

support
1

While porting the Risk of Rain 2 auto splitter I noticed that, for modules with multiple entries in the maps file, the offset for pointer paths was off.

Given the following /proc/pid/maps file:

using push_pointer_path("AkSoundEngine.dll", ...) sets the pointer path offset to the second entry (0x1215e000 - 0x227000) rather than the expected 0x11f30000. Is this behavior intended?

Juesto

Juesto

enhancement
1

Original LiveSplit has a hidden function where you can close splits and as long you don't change the layout you would be able to perform stopwatch functionality without making use of the splits system. Thought perhaps this could make a return in a more reliable and accessible manner, for those who wish to speedrun without worrying about splits.

CryZe

CryZe

enhancement
1

This should mostly just be a stroke rendering in our renderer and some CSS in the web version. Fairly trivial to support.

CryZe

CryZe

enhancement
0

livesplit-core has accumulated a bunch of features that you can turn on / off by now. How they interact and what they do is not super obvious, so we should probably add a section to both the README and the Rust documentation that explains it.

CryZe

CryZe

enhancement
0

Rust 1.48 just came out with a proper built-in way to mention types in documentation that you can click on and get linked to that specific type. Before you needed to write the relative URL of the type which was both cumbersome and based on an implementation detail, so we just never linked to any types. Here's the blog post:

Rust 1.48

DarkRTA

DarkRTA

needs further discussion
0

Something I've had on my mind for a while now is the possibility of specifying a comparison or maybe even a goal time for the PB chance component to get the chance of beating a time that isn't just your PB.

I have no idea how this will work so i'm just putting this out there for discussion.

CryZe

CryZe

suitable for contributions
1

In cross they removed OpenSSL from all the docker containers as they didn't want to keep maintaining OpenSSL anymore. So this broke our tests on mips and powerpc, as these are the platforms where we use OpenSSL. For now I've deactivated the tests, but we likely want to either switch those to rustls (which doesn't support those platforms yet, but might in the future). Alternatively we could maintain our own containers, but that's probably overkill. The likeliest short term solution should be to adjust our CI script to run the tests on those platforms again, but instead of using --all-features it compiles all features except networking for them.

wooferzfg

wooferzfg

enhancement
2

Similar to overriding the timing method, we should show a dropdown that includes the names of all the available comparisons.

We should also decide how to handle the case where a comparison override doesn't match a comparison that's available in the current run. In the original LS, we handled this by disabling the comparison override in this case. However, we still showed the comparison override in the dropdown so that the user wouldn't accidentally disable it in the settings just by visiting the settings.

CryZe

CryZe

enhancement
3

We are currently not caching anything. Doing so should significantly improve the builds on CI. However I'm not sure if the huge amount of data and jobs we are producing is going to cause any problems, so we'll have to just try it and see.

Versions

Find the latest versions by id

v0.12.0 - Nov 14, 2021

What's Changed

  • Runs now support custom variables that are key value pairs that either the user can specify in the run editor or are provided by a script like an auto splitter. #201
  • There is now an option in the run editor to generate a comparison based on a user specified goal time. This uses the same algorithm as the Balanced PB comparison but with the time specified instead of the personal best. #209
  • Images internally are now stored as is without being reencoded as Base64 which was done before in order to make it easier for the web LiveSplit One to display them. #227
  • The Splits.io API is now available under the optional networking feature. #236
  • All key value based components share the same component state type now. #257
  • The crate now properly supports wasm-bindgen and WASI. #263
  • There is now a dedicated component for displaying the comparison's segment time. #264
  • Compiling the crate without std is now supported. Most features are not supported at this time though. #270
  • Splitterino splits can now be parsed. #276
  • The Timer component can now show a segment timer instead. #288
  • Gamepads are now supported on the web. #310
  • The underlying "skill curve" that the Balanced PB samples is now exposed in the API. #330
  • The layout states can now be updated, which means almost all of the allocations can be reused from the previous frame. This is a lot faster. #334
  • In order to calculate a layout state, the timer now provides a snapshot mechanism that ensures that the layout state gets calculated at a fixed point in time. #339
  • Text shaping is now done via rustybuzz which is a port of harfbuzz. #378
  • Custom fonts are now supported. #385
  • The renderer is not based on meshes anymore that are suitable for rendering with a 3D graphics API. Instead the renderer is now based on paths, which are suitable for rendering with a 2D graphics API such as Direct2D, Skia, HTML Canvas, and many more. The software renderer is now based on tiny-skia which is so fast that it actually outperforms any other rendering and is the recommended way to render. #408
  • Remove support for parsing worstrun splits. worstrun doesn't support splits anymore, so livesplit-core doesn't need to keep its parsing support. #411
  • Remove support for parsing Llanfair 2 splits. Llanfair 2 was never publicly available and is now deleted entirely. #420
  • Hotkeys are now supported on macOS. #422
  • The renderer is now based on two layers. A bottom layer that rarely needs to be rerendered and the top layer that needs to be rerendered on every frame. Additionally the renderer is now a scene manager which manages a scene that an actual rendering backend can then render out. #430
  • The hotkeys are now based on the UI Events KeyboardEvent code Values web standard. #440
  • Timing is now based on CLOCK_BOOTTIME on Linux and CLOCK_MONOTONIC on macOS and iOS. This ensures that all platforms keep tracking time while the operating system is in a suspended state. #445
  • Segment time columns are now formatted as segment times. #448
  • Hotkeys can now be resolved to the US keyboard layout. #452
  • They hotkeys are now based on keydown instead of keypress in the web. keydown handles all keys whereas keypress only handles visual keys and is also deprecated. #455
  • Hotkeys can now be resolved to the user's keyboard layout on both Windows and macOS. #459 and #460
  • The time crate is now used instead of chrono for keeping track of time. #462
  • The scene manager now caches a lot more information. This improves the performance a lot as it does not need to reshape the text on every frame anymore, which is a very expensive operation. #466 and #467
  • The hotkeys on Linux are now based on evdev, which means Wayland is now supported. Additionally the hotkeys are not consuming the key press anymore. #474
  • When holding down a key, the hotkey doesn't repeat anymore on Linux, macOS and WebAssembly. The problem still occurs on Windows at this time. #475 and #476

New Contributors

Full Changelog: https://github.com/LiveSplit/livesplit-core/compare/v0.11.0...v0.12.0

v0.11.0 - May 14, 2019

What's Changed

  • If the crate is compiled with the image-shrinking feature, which is activated by default, all images such as game and segment icons that are too large are automatically being shrunk to reduce the file size of splits files. #145
  • Flitter splits can now be parsed. #105
  • The splits component now has support for custom columns. #149
  • A generic renderer suitable for targeting various graphics frameworks has been implemented. It is available via the rendering feature. #163
  • A software renderer using the generic renderer has been implemented as well. While certainly slower than the GPU based rendering, it offers portable rendering of the layouts without a need for a GPU. It is mostly suitable for screenshots. It is available via the software-rendering feature. #163
  • The Layout files of the original LiveSplit can now be imported. #103
  • Horizontal layouts are now supported in livesplit-core. #180
  • Hotkeys can now be edited. #152

Full Changelog: https://github.com/LiveSplit/livesplit-core/compare/v0.10.0...v0.11.0

v0.10.0 - Sep 22, 2018

v0.9.0 - Jan 22, 2018

v0.8.1 - Sep 28, 2017

v0.8.0 - Sep 26, 2017

v0.7.0 - Aug 15, 2017

v0.6.0 - Jun 11, 2017

v0.5.1 - May 27, 2017

v0.5.0 - May 25, 2017

v0.4.1 - May 09, 2017

v0.4.0 - May 08, 2017

v0.3.0 - Apr 24, 2017

v0.2.0 - Apr 03, 2017

v0.1.4 - Apr 02, 2017

v0.1.3 - Mar 26, 2017

v0.1.2 - Mar 23, 2017

v0.1.1 - Mar 23, 2017

v0.1.0 - Mar 23, 2017

Information - Updated Jun 18, 2022

Stars: 163
Forks: 33
Issues: 62

Rust library for Self Organising Maps (SOM)

Add rusticsom as a dependency in Cargo

Rust library for Self Organising Maps (SOM)

Rust library for parsing configuration files

The 'option' can be any string with no whitespace

Rust library for parsing configuration files

Rust library for the Pimoroni Four Letter pHAT

This library aims to port ht16k33 (or rather a fork, as of right now) so credit goes to ht16k33-diet

Rust library for the Pimoroni Four Letter pHAT

Rust library for emulating 32-bit RISC-V

This library can execute instructions against any memory and register file that implements

Rust library for emulating 32-bit RISC-V

Rust library for connecting to the IPFS HTTP API using Hyper/Actix

You can use actix-web as a backend instead of hyper

Rust library for connecting to the IPFS HTTP API using Hyper/Actix

Rust library to manipulate file system access control lists (ACL) on macOS, Linux, and FreeBSD

This module provides two high level functions, getfacl and setfacl

Rust library to manipulate file system access control lists (ACL) on macOS, Linux, and FreeBSD

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

This is the place to translate Having a documentation in your native language is essential if you don't speak English, and still enjoyable even if...

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

Rust library for using Infrared hardware decoders (For example a Vishay TSOP* decoder),

enabling remote control support for embedded project

Rust library for using Infrared hardware decoders (For example a Vishay TSOP* decoder),

Rust library for interaction with the OriginTrail Decentralized Knowledge Graph

open up an issue on this repository and let us know

Rust library for interaction with the OriginTrail Decentralized Knowledge Graph

Rust library for parsing COLLADA files

Notice: This library is built around files exported from Blender 2

Rust library for parsing COLLADA files

Rust library for low-level abstraction of MIPS32 processors

This project is licensed under the terms of the MIT license

Rust library for low-level abstraction of MIPS32 processors
Facebook Instagram Twitter GitHub Dribbble
Privacy