Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2026-02-16T19:11:24+00:00 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-02T13:43:19+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-02T13:43:19+00:00 urn:sha1:0d905d7998a031c2d7a1cdc5d0d1148b55b610a2 2025-05-11T13:41:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-05-11T13:41:13+00:00 urn:sha1:397a3fe8863e740456f1a61dda4d9d48b7456147 Sorry Hayden. My next project for SST is a testing system. Because I *royally* screwed up this release cycle. Anyway I just inlined that function because it was evidently a sufficient source of confusion that I managed to totally screw up basically every part of call boundary. Truly catastrophically bungled the thing. I must have been really tired... 2025-04-30T21:37:45+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-30T21:37:45+00:00 urn:sha1:45a21380fcc2c9a0b9035814ab0f8cc38165bb64 With apologies to Hayden, whose code was mostly fine until my quest to make it neater ended up bungling stuff. I wanted it reviewed and tested before pushing it anywhere public but people have limited free time - how dare they!!!! - and at some point I kind of impatiently just sent it because I had a pile of unrelated changes I didn't want to untangle. I didn't really know how to reproduce the bad performance myself to test the fix here properly, so I was kind of unfairly relying on him to do it, even though he'd already tested his own code and made sure it worked *before* I decided to break it. My bad. Don't worry though, I was never actually going actually release SST in such a broken state. I mean, I have released it in worse states before, but I wasn't gonna do it on this occasion. :^) Now this is definitely done correctly, I think, and I've done yet another pass over the comments, I'm pretty confident that 0.9 is around the corner. Just a few more commits of entirely non-user facing stuff to get out of the way first... 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-16T01:13:01+00:00 urn:sha1:4fddfa831d2a33ab3eee7ceb5f181c82d5aa78d2 This both simplifies and complicates things, but probably hopefully maybe simplifies things overall. Certainly in cases like the L4D1 demo thing where there's 3 inline hooks at once, it seems simpler to be able to batch the fallible stuff to avoid rollbacks. In cases where you only need one hook, it's a bit more verbose, but what can you do. Thanks bill for discussing this with me pretty exhaustively and giving a lot of good input. I think both of us still kind of hate it actually. 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-06T19:59:36+00:00 Hayden K imaciidz@gmail.com 2025-02-07T19:22:37+00:00 urn:sha1:dc540372be9da686a3087843ae4ae5f038a3a9a0 Turns out the cvar we use to detect 2147 was actually added in 2125. Since renaming it doesn't currently break anything (and 2125 was a fairly notable code shuffling update, given it was the first update with a native Linux build of the game), it makes most sense to just do this.