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:05+00:00 2026-10-10T03:23:05+00:00 Michael Smith mikesmiffy128@gmail.com 2026-10-10T00:35:12+00:00 urn:sha1:e9828050c75ab06c87c2157cf9508c03827d80d6 The SHUNT craziness I was doing triggers a warning with more recent Clang versions. Simply move the size into the macro to avoid the tentative definition abuse, which is probably less confusing (when combined with the new macro name, ARRAY) and also shuts the compiler up. 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 2026-01-12T20:52:00+00:00 urn:sha1:b891ce7ef63c7a75c3f5fd108032aea552536369 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-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-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-15T20:42:55+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-15T20:33:33+00:00 urn:sha1:13ddf47d80893eb4d09ca31f5469b835f24170c7 2025-11-15T20:24:41+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-15T20:24:41+00:00 urn:sha1:c15101df02685a5d26f4b130f7b559eb7ed7f74f Pretty hacky for now, but not the worst thing in the world. Can always be tidied up later. 2025-10-11T02:13:18+00:00 Michael Smith mikesmiffy128@gmail.com 2025-10-11T02:09:35+00:00 urn:sha1:74f1309af5310fbfa346048f8ecfc7fe1e8a4571 The old GAMESPECIFIC mechanism had worked in practice but was technically a little bit incorrect, oops.