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-10T03:23:43+00:00 2026-10-10T03:23:43+00:00 Michael Smith mikesmiffy128@gmail.com 2026-10-10T02:21:36+00:00 urn:sha1:518b46400f45a525681cc9325c45e3a6a934f4c3 This will need to be accompanied by the publication of my toolchains repo at some point which has scripts to set up fixed versions of MSVC and LLVM, with way less space wasted than the official distributions thereof. Also that'll become necessary for a period of time until I figure out why LLVM 22 and 23 are unable to link SST now; we are stuck on 20 for the foreseeable future which makes having a self-contained thing quite helpful. This change also includes a couple of other build script improvements too, most notably debug builds without having to edit the damn script every time. 2026-10-10T03:23:05+00:00 Michael Smith mikesmiffy128@gmail.com 2026-04-04T00:34:31+00:00 urn:sha1:c219ee378c374ceaf576ac477ccbe34a73e65d94 To be enhanced and extended later! 2026-04-04T00:37:54+00:00 Michael Smith mikesmiffy128@gmail.com 2026-01-13T19:30:47+00:00 urn:sha1:2344c8df392d4d8489c5bbee60a6894f908561e5 There was never really much point in this, and it probably slowed things down a little bit, though not a lot. 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-13T18:26:51+00:00 urn:sha1:40f9d989df2c1ff2f567656ccbdbfc0d97e34a77 This lexer is being written as a chunklet, not quite quite complete yet as it lacks some functionality to make it generally useful for things, but good enough for the gluegen use case now. So it's in the repo now and we can go ahead and use it for this instead of having this hacked-to-pieces third party thing that's nowhere near as efficient. In the future the goal is to have a decently usable library for any sort of C metaprogramming needs, not just within this project. This design does the data-oriented thing of storing as little about each token as possible (just 5 bytes), and re-lexing specific pieces only when necessary. In some cases, full validation of correct syntax is only possible through this secondary step. Since the use case is metaprogramming and code-generation rather than the reimplementation of Clang, this slight sloppiness in validation doesn't seem too bad. It's been a while since I did a proper performance measurement of this code but in some crude tests I did in the past the primary tokenisation step was running at well over 500MB/s, which is fast enough for me. It's possible that this version is a tiny bit slower due to the added complexity of making UCNs work. UCNs, incidentally, are one of the dumbest features of C by far. However, unlike trigraphs - which this lexer does not handle - UCNs are still in the language, so it's kind of sort of necessary to support them. It's probably still possible to come up with a faster design with some SIMD trickery, but the main loop is currently branchless and the lookup tables are too big for the SIMD lookup things, so that seems kind of hard. A separate SIMD path for whitespace or comment runs seems dubious as it would introduce branch mispredictions everywhere. I also made previous attempts to unroll the main loop and every attempt just made it slower, so I guess code size is a significant factor. Optimising the secondary tokenisation of identifiers (and later numerals and string/character literals once those are handled) is still on the cards, but since that happens less often, I don't know how much difference it'll make. At any rate, in a multithreaded context this thing would already come pretty close to SSD speeds, if open-read-close syscall overhead doesn't get in the way first. I imagine it's fast enough for anyone who hasn't *already* written something faster. 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-08-03T14:16:08+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-03T14:16:08+00:00 urn:sha1:9853d19b4de3e66138da8b3e66ccdaea356ea35b 2025-06-27T21:58:54+00:00 Willian Henrique wsimanbrazil@yahoo.com.br 2025-06-20T00:28:10+00:00 urn:sha1:35a3e0871c5a98110847765f10a3c2c604323ee6 This is a stopgap solution approved by the Portal moderators until we have a better way to handle timing and verifying closing/restarting the game mid-run. Essentially, the agreed-upon short-term solution is to somewhat emulate restarting the game by simply turning off the glitch and sending the player back to the main menu. Committer's note: this wasn't added to the Linux compile script since it doesn't work and I honestly just couldn't be bothered adding in the usual ifdef-errors. And in fact I'm starting to wonder if we should just be leaving out features that don't work on Linux to avoid all the ifdefs, but that can happen later because the main goal of committing this is to get a release out, so I don't want to faff about with that right now.