Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2026-10-10T14:33:00+00:00 2026-10-10T14:33:00+00:00 Michael Smith mikesmiffy128@gmail.com 2026-10-10T02:57:56+00:00 urn:sha1:5f0bf6dbf6291fbbbcf6db00eccde479f99a5608 2026-04-04T00:37:54+00:00 Michael Smith mikesmiffy128@gmail.com 2026-04-03T20:45:17+00:00 urn:sha1:2ee93c3f46f8e948d2331eab46c95322a88874ee Put all the cvars together contiguously; then we don't need to generate lots of individual calls to extfree() and can instead simply iterate a fixed-sized array. 2026-04-04T00:37:54+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-30T20:29:48+00:00 urn:sha1:0fdf9b3ed716a8baf048e7e302c4d9e727999df2 This isn't really making a difference right now but maybe it will in future builds with different section padding or LTO optimiser interactions or whatever. 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-12-02T19:31:29+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-02T19:31:29+00:00 urn:sha1:0faebcb90a042c292a8cc562352303a53e8323e0 2025-12-01T21:37:31+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-01T21:37:31+00:00 urn:sha1:99f7bb3d39043f74d03b29dc7d6a3f08570c544c 2025-11-28T22:30:55+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-28T22:28:17+00:00 urn:sha1:3e057a6365ba6793531ba2930aa53453ee3f0d8e Kind of unpleasant and probably something to revisit at some point to see if there's a more straightforward approach we can come up with. 2025-11-25T20:00:33+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-25T20:00:33+00:00 urn:sha1:8bed97cda76655c49fb80b604203ec572b2bf59e