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-08T00:35:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-08T00:32:41+00:00 urn:sha1:6c8cd62277a9c81d1d24c146067c405ec90cbfb2 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. 2023-08-26T23:46:09+00:00 Michael Smith mikesmiffy128@gmail.com 2023-08-20T15:20:03+00:00 urn:sha1:a1998f2f7ce4153d670e2e5cb5018366517cc1ca Nothing really works yet, but at least test.h and fastspin are fixed and some of the issues with RTTI and libdl and stuff are maybe kind of sorted, subject to more testing later. The main issue now seems to be the cvar interface not quite lining up and crashing pretty much immediately. That'll probably take a lot more debugging to figure out, which likely still won't be a priority for quite a while. 2023-08-02T20:02:31+00:00 Michael Smith mikesmiffy128@gmail.com 2023-07-29T13:32:06+00:00 urn:sha1:9a0d8730fa977f666b5c12e4c5901e7d0391e245 A lot of this is random WIP from a while back, at least a month ago, and is being committed now to get it out of the way so that other patches can be brought in and integrated against it without causing headaches. Also rolled into this commit is a way to distinguish plugin_unload from exiting the game. This is required for another soon-to-be-integrated feature to avoid crashing on exit, and could in theory also be used to speed up unloading on exit in future. While we're at it, this also avoids the need to linearly scan through the plugin list to do the old branch unloading fix, because we can. Rough summary of the other smaller stuff I can remember doing: - Rework bitbuf a bit - Add some cryptographic nonsense in ac.c (not final at all) - Introduce the first couple of "chunklets" libraries as a sort-of subproject of this one - Tidy up random small bits and bobs - Add source for a small keypair generation tool - Rework democustom to be very marginally more useful 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