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 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-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-18T23:33:26+00:00 urn:sha1:f386f2a1fcae885967278710fe997c56e2183476 Saves multiple kilobytes, somehow. Unlikely to make much of a performance difference since it's mostly init/shutdown stuff. 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-03T15:09:42+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-03T15:09:42+00:00 urn:sha1:69f34b359c0ec0d4517050fe274883421c4c119b Since this codebase is already extremely nonportable, I've decided to relax the obsessive ifdef-else-error usage around all the extensions. From now on, if there's no alternative to using an extension, we can just use that extension. If it's possible to do something in a relatively portable way, we can still try to do that in order to make the code somewhat reusable, in contexts where that makes sense. I also decided to use langext.h for naked functions and tail calls. If that's used in another codebase build with a different compiler, those just won't work, but that's fine. The benefit is really just that there's less ceremony in places where those are used, because it's likely there'll be a few more such places in the future, and it gets annoying reading all the double-underscore stuff all over the place. I still kind of want to do something about all the _WIN32 ifdefs too, but I've realised that doing so will lead to almost nothing actually being built on Linux. Then again, none of it currently runs on Linux so I guess that's a moot point. Will worry about it later, anyway. 2025-08-03T14:29:48+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-03T14:29:48+00:00 urn:sha1:b11cf48853bc4eccde60bc82180025f0797fa823 Turns out, there's no need for the trailing underscores. Plus, glibc does some stupid stuff with __attribute__ for non-GCC compilers. Not that that matters here, but it seems like a good practice just to use the forms that never have such problems. And it's shorter too. 2025-08-03T14:16:08+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-03T14:16:08+00:00 urn:sha1:9853d19b4de3e66138da8b3e66ccdaea356ea35b 2025-06-21T13:50:00+00:00 Michael Smith mikesmiffy128@gmail.com 2025-06-21T13:46:10+00:00 urn:sha1:f38fc784ffab00c11b9818d18f55be34cc8aa130 This doesn't allow us to support OE in and of itself but is part of the groundwork necessary to do so in the future. 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-16T01:21:43+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-16T01:20:31+00:00 urn:sha1:27ce81043a31e61d9e2bea88e4ea883d8e4a4b39 Also pointed out by bill. D'oh, guess I'm fired.