world's fastest dota 2 and deadlock (the game) replay parser. more then two times faster than comically fast.
haste attempts to squeeze maximum single-core performance from the cpu, which enables efficient utilization of all cores for parsing multiple replays simultaneously.
haste does not want to be very user-friendly, it provides you with a relatively low-level access to correct usable data. it up to you how you structure your programs. you may choose to build your own nice api layer. anything is possible, theoretically even something as silly (i love silly) as ecs is doable (think of bevy game engine).
Warning
there are many unsafe
s in the codebase, some are rational and explained,
some need to be let go; public api isn't great and can be considered very
unstable (e.g. it is not final and parts of it may change dramatically).
notable examples to check out for detailed usage:
- deadlock-position demonstrates how to work with entities and how to get player (or any other entity, if desired) positions in deadlock (the game);
- deadlock-gametime also demonstrates how to work with entities and how to compute game time (not a very straightforward thing to do, thanks valve).
- dota2-allchat shows how to work with packet messages.
to run these examples navigate to haste directory and run
$ cargo run --example <example-name> -- <path-to-dem-file>
to use haste in your project, you'll need either:
protoc
(protocol buffer compiler) in your$PATH
, or$PROTOC
environment variable needs point to it- or
cmake
(if you don't haveprotoc
, it will be compiled for you) andprotobuf-src
feature flag enabled
haste is not published to crates.io (yet?). you can add it
to your Cargo.toml
as a git
dependency,
[dependencies]
haste = { git = "https://github.com/blukai/haste.git" }
haste's entity representatin is not debugger / print friendly, you would want to use haste-inspector (replay dev tools) to explore all the entities that are present in replays.
broadcast
: enables http broadcasts.deadlock
: enables deadlock protos and some utilities.dota2
: enabled dota2 protos and some utilities.protobuf-src
: enables protobuf_src crate which buildsprotoc
.
TODO: benchmarks and comparisons with other projects such as clarity and manta.
to tease a bit.. as of 25-09-2024 in standard release build with no extra optimizations nor non-stadard memory allocators:
- 31 minutes deadlock match can be parsed in ~660 ms with ~17.5 mb peak memory consumtion;
- 38 minutes dota 2 captains mode match - in ~650 ms with ~18 mb peak memory consumtion.
run time is an average from 10 runs with no warmups. peak memory consumtion is
time
's maximum resident set size
stat.
why create another replay parser? to prove myself that i'm right (long story; the proof was found quicly, but then i fell down the rabbit hole of further performance optimizations).
valve's official repos and wiki provide quite a handful of useful information, but special credits go to invokr who worked on dotabuff/manta and to spheenik the creator of skadistats/clarity (i have not personally interacted with either of them).
other notable resources:
- ButterflyStats/butterfly
- ValveSoftware/csgo-demoinfo
- ValveSoftware/source-sdk-2013
- SwagSoftware/Kisak-Strike
- markus-wa/demoinfocs-golang (some info about how pointer serializer fields work)
- demofile-net (tv broadcasts)
and some more can probably be found across comments in the codebase.