Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2026-04-04T00:37:54+00:00 2026-04-04T00:37:54+00:00 Michael Smith mikesmiffy128@gmail.com 2026-04-03T20:48:15+00:00 urn:sha1:3ddb31ea086155c551507357b77d83d5b57935c6 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-27T03:05:05+00:00 urn:sha1:8d4b47298b6c9eeb9a3f79a5b80d894f80ed4a45 Now everything is either explicitly a rep thing, or explicitly some other small run of reasonably efficient instructions. No library calls or function call overhead of any kind. Code size remains nice and small. Ban a few other bad libc functions while we're at it. More can be added later if we decide that's a useful idea. This will require some discipline and workarounds to cope with Clang's tendency to shove mem* calls in places you don't want them even when you tell it not to. Well, c'est la vie. I'm a little nervous that the __builtin_memmove() usage in shuntvars() could still one day emit actual library calls. It appears we're not importing memmove() from anywhere at the moment, though. So I guess it's good enough for now. Also I had to get rid of alloca() in con_.c but that was kind of bad anyway, so that's fine. 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-26T23:12:11+00:00 urn:sha1:af370088fc178996a46ee508aaa1a2c46318bbf2 For some reason the DLL got a tiny little bit bigger again but that's fine. This will make orig_ calls more efficient in the inline case, and also make it harder to screw up and hook the wrong thing by mistake. Self-explanatory-ish, apart from the fact it's a fairly large API change of course. And it relies on some more bonkers assembler directive hackery. But it works! The only complaint one might have is that the featsetup functions no longer take an explicit string which occasionally yields slightly less perfect error messages, but I've decided this isn't really a problem and makes the API nicer to use. It's a tradeoff, innit. 2025-11-24T03:23:22+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-24T03:19:49+00:00 urn:sha1:508878ff0a9e4cd8528727c41819bc2d70b33dd0 Quick unused header cleanup pass while we're at it. 2025-08-02T19:43:12+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-02T15:15:15+00:00 urn:sha1:3cce0e5621dc118b32c4143b42ced51c5328f7c7 This is a step towards making command hooks work in OE, once OE is supported. Not the most ideal or efficient thing in the world, but it works okay until we come up with something better, I suppose. Not a fan of the argv copying but avoiding that would make the API a lot less ergonomic. Not the easiest problem to solve, really... 2025-06-21T13:50:00+00:00 Michael Smith mikesmiffy128@gmail.com 2025-06-17T19:18:48+00:00 urn:sha1:ac7e7d0f21978afc70fe3ef76db69d575742b974 This improves the ergonomics of a few different things, and sets us up somewhat for the fact OE had a different interface for commands too (it was v1 only and had a separate API call for getting the args). 2025-04-17T19:02:18+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-17T00:39:10+00:00 urn:sha1:8a669bc96ffdb9d0f6f54e464da11e3375c80a55 This probably should have been the design from the start. It's still possible to use void pointers, and this is done in a couple of places for simplicity, but wherever possible, we have actual structs for things now. Additionally, in places where vtables are fiddled with, e.g. vtable hooks, we have actual struct definitions with vtable pointers so there's need for pointer-casting horror. 2025-04-16T20:31:20+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-16T20:28:45+00:00 urn:sha1:0b40d4d9ea1cbfbb92795e0d6f26cf108f2dec5f These gamedata entries are always available, but there's no reason not to check for them in case that changes in future. As-is now, the checks will be trivial for the compiler to optimise out. 2025-04-07T20:31:32+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-07T20:31:32+00:00 urn:sha1:58b495650f7613cdebfe78fff9de2b99556f1998 They're legally unnecessary as far as I know, and kind of annoying to maintain on a long-term basis. This was done with the consent of all 3 other contributors, in case anyone was wondering. 2025-04-06T15:41:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-10T20:37:28+00:00 urn:sha1:daa55cade14146f04814cf8a7ad2028becf4db66 In the future we can also consider moving to {} instead of {0} for initialisers, but my old Clang (16) doesn't support this, so it might be wise to wait longer on that one so people don't need too bleeding-edge of a compiler just to build this thing.