Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2025-04-06T15:41:13+00:00 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-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.