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. 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-27T21:52:10+00:00 Michael Smith mikesmiffy128@gmail.com 2025-06-21T14:13:42+00:00 urn:sha1:a9f44f3a6cccdf147376f8bf010a85b334ed4c72 The code I'm about to commit appears to generate a call to this. Funny we never needed it until now... 2025-05-04T23:26:34+00:00 Michael Smith mikesmiffy128@gmail.com 2025-05-04T23:26:34+00:00 urn:sha1:618a1d60ddc98bf41b7a3e8216746d1eff827110 I think memcpy might have been returning the wrong thing before, actually, but I guess it didn't matter in practice. Who the hell uses the return value from memcpy? 2024-02-26T02:24:30+00:00 Michael Smith mikesmiffy128@gmail.com 2024-02-25T18:54:45+00:00 urn:sha1:579ec0dced9a72c331591a479705a459cf715b64 2023-08-26T23:46:09+00:00 Michael Smith mikesmiffy128@gmail.com 2023-08-26T23:02:23+00:00 urn:sha1:6e9bbe397c4846f440e57163e56694f95f5d9128 This will save users having to install the VS runtime in order to load the plugin. Turns out there was very little to implement to make this work. Turning off stack probing might cause spooky outcomes further down the line but we'll burn that bridge when we get there.