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-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. 2025-04-07T20:31:32+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-07T20:31:32+00:00 urn:sha1:58b495650f7613cdebfe78fff9de2b99556f1998 They're legally unnecessary as far as I know, and kind of annoying to maintain on a long-term basis. This was done with the consent of all 3 other contributors, in case anyone was wondering. 2025-04-06T15:41:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-10T02:37:19+00:00 urn:sha1:244fea664121acf12871ab5858a5fe95a2606b52 Also switch to somewhat proper C23 flags while we're at it. This is a huge change. It took me forever, in between being really busy. Sorry about that. But the good news is I'm now free to start integrating the various patches that have accumulated since last release. Well, at least in between still being really busy. Gotta manage expectations. The main benefit of introducing GAMESPECIFIC() is that features that don't apply to a particular game no longer show up *at all*, and less time is wasted on init. It also enables a cool optimisation wherein unnecessary REQUIRE_GAMEDATA() checks can elided at compile time whenever the gamedata is known up-front to always exist in supported games. The DEF_FEAT_CVAR macro family meanwhile makes it easier to manage the lifecycle of cvars/ccmds, with less manual registering, unhiding and such. Originally I was going to try and just hack these features into the existing codegen abomination, but it just got too terrible. This rewrite should make it easier to continue tweaking codegen behaviour in future. It also has slightly better error messages. 2024-08-21T23:01:06+00:00 Michael Smith mikesmiffy128@gmail.com 2024-08-03T15:11:57+00:00 urn:sha1:44902cb49cd51e2bb2f1cef05cb3c0e799b83434 - As much as possible avoid dragging system headers into translation units. This should avoid namespace pollution and, hopefully, speed up builds a little bit. - Avoid leaning on the UCRT so much on Windows - prefer native win32 calls and native file handles except where doing so is inconvenient (in particular, for stat(), which we might try and replace later). - Also, switch from SystemFunction036 to ProcessPrng on Windows. This requires us to generate a stub for bcryptprimitives.dll because Microsoft haven't bothered to provide a link library, but the function is better-documented and seems to be a more direct under-the-hood call as well. Apparently it's what's used by the major web browsers these days, which seems like a good indication it's stable and trusted. - Lastly, remove a bunch of functions and macros and stuff that weren't actually being used. It seems good to try and keep the scope of OS-dependent stuff relatively contained and only add to it when actually required. 2022-09-13T21:50:30+00:00 Michael Smith mikesmiffy128@gmail.com 2022-09-13T20:46:21+00:00 urn:sha1:792463cb133f65645feb48743bbc03ef8eb96bdd Another big one. Here's a list of things: - Since the upcoming C23 standardises typeof(), use it as an extension for the time being in order to allow passing arbitrary types as macro/codegen parameters. It wouldn't have been a big leap to do this even without standardisation since it's apparently an easy extension to implement - and also, to be honest, this project is essentially glued to Clang anyway so who cares. - Likewise, bool, true and false are becoming pre-defined, so pre-pre-define them now in order to get the benefit of not having to remember one header everywhere. - Really ungodly/amazing vcall macro stuff now allows us to call C++ virtual functions like regular C functions. It's pretty cool! - Events can now take arbitrary parameters and come in two types: regular events and predicates. All this makes the base code even uglier but makes the feature implementation nicer. In other words, it places more of the cognitive burden on myself and less on other people who might want to contribute. This is a good tradeoff, because I'm a genius. 2022-08-10T21:40:52+00:00 Michael Smith mikesmiffy128@gmail.com 2022-07-31T15:02:10+00:00 urn:sha1:5e921bf59373d79d27c322ff86e8b5a37b151e45 2022-07-23T22:47:26+00:00 Michael Smith mikesmiffy128@gmail.com 2022-07-23T22:47:26+00:00 urn:sha1:c8d7588251fd4fe63ac6afe2a90ca7066c786609 2022-05-03T15:55:46+00:00 Michael Smith mikesmiffy128@gmail.com 2022-05-03T03:20:27+00:00 urn:sha1:6d0db0d5bee0201b732149616a691827367cfb35 This was a lot more code than expected, but it might be finally close to time to release the next beta... We'll see if any more rabbit holes present themselves to jump into, though. 2022-04-24T02:43:26+00:00 Michael Smith mikesmiffy128@gmail.com 2022-04-24T02:27:35+00:00 urn:sha1:7b12eb811ff62d9d14ccb7c152a9821796efe9a5 hook_inline() uses the new x86_len() function to get instruction lengths instead of doing full-blown disassembly, which should be a tiny bit quicker, and also removes the next for about 90KiB of lookup tables and such in the final binary. The code-digging logic in demorecord is also rewritten to be opcode-based rather than mnenmonic based. In general, going forward the plan is to always rely on opcodes and thus avoid a bunch of disassembly work every plugin load. udis86 is still in the tree for now to provide dbg_asmdump(), but it's only compiled into debug builds and left out of releases completely. As such, the whole BSD licence statement is also gone from the distribution LICENCE files. There's now also a dbg_toghidra() which spits out a rebased address to look stuff up for proper reverse engineering, which might be more useful than dbg_asmdump() anyway. If nobody ends up using the latter ever again, udis86 could get chucked completely. We'll see. Also shoehorned into this commit are a couple more forgotten copyright year bumps and some general minor cleanup here and there, because I couldn't be bothered wading through all the diff hunks. Oh, and makebindist.bat now makes an effort to make the zip file timestamps predictable/reproducible. That should be a different commit for sure, but oh well too bad. 2022-03-20T20:09:53+00:00 Michael Smith mikesmiffy128@gmail.com 2022-03-20T20:05:42+00:00 urn:sha1:c0d4714cb304394f19cac5b71d704aa6b2c27dd5 This allows stuff to be registered conditionally. Unfortunately cmeta is now truly the worst thing of all time, but cleaning it up isn't a huge priority. On the plus side, codegen actually got simpler.