Git Product home page Git Product logo

asr's Introduction

LiveSplit asr

Helper crate to write auto splitters for LiveSplit One's auto splitting runtime.

API Documentation

There are two ways of defining an auto splitter.

Defining an update function

You can define an update function that will be called every frame. This is the simplest way to define an auto splitter. The function must have the following signature:

#[no_mangle]
pub extern "C" fn update() {}

The advantage of this approach is that you have full control over what happens on every tick of the runtime. However, it's much harder to keep state around as you need to store all state in global variables as you need to return out of the function on every tick.

Example

#[no_mangle]
pub extern "C" fn update() {
    if let Some(process) = Process::attach("explorer.exe") {
        asr::print_message("Hello World!");
        if let Ok(address) = process.get_module_address("explorer.exe") {
            if let Ok(value) = process.read::<u32>(address) {
                if value > 0 {
                    asr::timer::start();
                }
            }
        }
    }
}

Defining an asynchronous main function

You can use the async_main macro to define an asynchronous main function.

Similar to using an update function, it is important to constantly yield back to the runtime to communicate that the auto splitter is still alive. All asynchronous code that you await automatically yields back to the runtime. However, if you want to write synchronous code, such as the main loop handling of a process on every tick, you can use the next_tick function to yield back to the runtime and continue on the next tick.

The main low level abstraction is the retry function, which wraps any code that you want to retry until it succeeds, yielding back to the runtime between each try.

So if you wanted to attach to a Process you could for example write:

let process = retry(|| Process::attach("MyGame.exe")).await;

This will try to attach to the process every tick until it succeeds. This specific example is exactly how the Process::wait_attach method is implemented. So if you wanted to attach to any of multiple processes, you could for example write:

let process = retry(|| {
   ["a.exe", "b.exe"].into_iter().find_map(Process::attach)
}).await;

Example

Here is a full example of how an auto splitter could look like using the async_main macro:

Usage on stable Rust:

async_main!(stable);

Usage on nightly Rust:

#![feature(type_alias_impl_trait, const_async_blocks)]

async_main!(nightly);

The asynchronous main function itself:

async fn main() {
    // TODO: Set up some general state and settings.
    loop {
        let process = Process::wait_attach("explorer.exe").await;
        process.until_closes(async {
            // TODO: Load some initial information from the process.
            loop {
                // TODO: Do something on every tick.
               next_tick().await;
            }
        }).await;
    }
}

License

Licensed under either of

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.

asr's People

Contributors

alexknauth avatar cryze avatar jujstme avatar partymanx avatar sphinxc0re avatar squareman avatar wooferzfg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

asr's Issues

Disambiguating Multiple Processes With Same Name

I'm currently writing an autosplitter for Tony Hawk's Pro Skater 1+2, a game which has an annoying issue: it has a UE4 bootstrap process and actual game process, both with the same name (thps12.exe).

I know that the bootstrap process is much smaller than the game itself and would like the ability to either get a vec of all processes with a certain name to check the module sizes myself, or have a way to select the correct process (maybe Process::attach() could even just attach to the largest process?).

As it stands, the autosplitter has to be started before the game, otherwise it will only ever see/attach to the bootstrap process.

Incorrect memory readings on SEGA Genesis emulator

This issue specifically affects emulators using a byte-swapped memory layout.

For historical reasons, most of the current emulators for the SEGA Genesis swap odd and even bytes in the emulated memory, effectively swapping an internal big endian memory layout to a little endian one. The crate currently deals with this with an internal enum that reports whether the emulator is using an original, big endian, or a byte swapped layout.

This allows for easily reading single u8 and u16 values from memory, as well as [u16; N] arrays, but breaks completely when dealing with [u8; N] due to the fact no additional abstraction is performed other than checking the original memory address to start reading from.

The solution, which I plan on implementing eventually, is to swap odd and even bytes from the [u8; N] array after reading it and before returning it to the calling function. This would require a bit of unsafe but would be safely wrapped inside the read() function anyway.

Speed up signature scanning

We currently use a highly efficient algorithm to match a signature against a specific position. The problem is however that making this fast isn't really helping all too much because the chance that the signature is not matching is very high, so no matter what you do, it'll be rejected very quickly anyway. So while a correct match is checked really quickly, that doesn't speed up all the cases where it doesn't match. Instead you really want to check many addresses in parallel at the same time. The standard approach is to splat a single byte into a SIMD vector and match 16 bytes (or whatever your SIMD vector width is) at the same time. The problem is of course that we don't just care about a single byte, but the whole signature. So you use this to quickly find good candidates to do the full signature match against. This is also exactly how Rust's hash map is that fast. In order to reduce false positives there's the idea to splat two separate bytes from the signatures into two simd vectors at the same time and only consider candidates where both bytes match. If the two bytes are also well chosen (you probably don't want 0x00 or 0xFF), then you should be able to very quickly skip through the memory. This algorithm is documented here: http://0x80.pl/articles/simd-strfind.html#algorithm

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.