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. 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-18T21:35:50+00:00 urn:sha1:7a07c08abe46f97f2412f06c77204e9015f97a47 Does away with the need to mark a region as executable on load. Also allows the self-modified stuff and hook trampolines to fit in the same page, so we take up ever-so-slightly less memory. Unfortunately I had issues getting the test binary to build correctly and eventually decided to give up as it wasn't testing much of value anyway. Also note that the build now allows for .c and .S files with the same basename, which required renaming the .o files, so you might want to clean out your .build/ directory before building this one. 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-04-16T20:31:20+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-16T19:58:38+00:00 urn:sha1:7dcdcd0f62c7c103148b17aed8376a457aad6d8a I had this hunch that Intel's strong memory model wouldn't actually require anything like this, and some cursory research suggests this is correct even across threads, or at least definitely within the same thread which is what we care about. I kind of don't know why FlushInstructionCache() even exists in that case. Maybe it's for other architectures or maybe it's just for the benefit of debuggers. Microsoft's documentation helpfully asserts that it is necessary to call it even though it isn't, and doesn't elaborate further. Of course. 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-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. 2024-08-23T19:37:37+00:00 Michael Smith mikesmiffy128@gmail.com 2024-08-03T22:40:31+00:00 urn:sha1:83da606072ce272eb053d4e1497d77e647cfecae My new programming style is branch hints. All non-confusing branches must be hinted when I can be bothered. It's faster, sometimes, maybe. Also, start trying to use more signed sizes in at least some of the places where it makes sense. Unsigned sizes are surprisingly error-prone! 2024-08-21T23:01:06+00:00 Michael Smith mikesmiffy128@gmail.com 2024-08-03T15:11:57+00:00 urn:sha1:44902cb49cd51e2bb2f1cef05cb3c0e799b83434 - As much as possible avoid dragging system headers into translation units. This should avoid namespace pollution and, hopefully, speed up builds a little bit. - Avoid leaning on the UCRT so much on Windows - prefer native win32 calls and native file handles except where doing so is inconvenient (in particular, for stat(), which we might try and replace later). - Also, switch from SystemFunction036 to ProcessPrng on Windows. This requires us to generate a stub for bcryptprimitives.dll because Microsoft haven't bothered to provide a link library, but the function is better-documented and seems to be a more direct under-the-hood call as well. Apparently it's what's used by the major web browsers these days, which seems like a good indication it's stable and trusted. - Lastly, remove a bunch of functions and macros and stuff that weren't actually being used. It seems good to try and keep the scope of OS-dependent stuff relatively contained and only add to it when actually required.