| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With apologies to Hayden, whose code was mostly fine until my quest to
make it neater ended up bungling stuff. I wanted it reviewed and tested
before pushing it anywhere public but people have limited free time -
how dare they!!!! - and at some point I kind of impatiently just sent
it because I had a pile of unrelated changes I didn't want to untangle.
I didn't really know how to reproduce the bad performance myself to test
the fix here properly, so I was kind of unfairly relying on him to do
it, even though he'd already tested his own code and made sure it worked
*before* I decided to break it.
My bad.
Don't worry though, I was never actually going actually release SST in
such a broken state. I mean, I have released it in worse states before,
but I wasn't gonna do it on this occasion. :^)
Now this is definitely done correctly, I think, and I've done yet
another pass over the comments, I'm pretty confident that 0.9 is around
the corner. Just a few more commits of entirely non-user facing stuff to
get out of the way first...
|
|
|
|
|
|
|
|
|
|
|
|
| |
This probably should have been the design from the start.
It's still possible to use void pointers, and this is done in a couple
of places for simplicity, but wherever possible, we have actual structs
for things now.
Additionally, in places where vtables are fiddled with, e.g. vtable
hooks, we have actual struct definitions with vtable pointers so there's
need for pointer-casting horror.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This both simplifies and complicates things, but probably hopefully
maybe simplifies things overall. Certainly in cases like the L4D1 demo
thing where there's 3 inline hooks at once, it seems simpler to be able
to batch the fallible stuff to avoid rollbacks. In cases where you only
need one hook, it's a bit more verbose, but what can you do.
Thanks bill for discussing this with me pretty exhaustively and giving a
lot of good input.
I think both of us still kind of hate it actually.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Turns out the cvar we use to detect 2147 was actually added in 2125.
Since renaming it doesn't currently break anything (and 2125 was a
fairly notable code shuffling update, given it was the first update with
a native Linux build of the game), it makes most sense to just do this.
|
|
This should greatly improve the experience of running newest/TLS as well
as custom campaigns.
The bugginess in question is quite a lot to explain so there's some
rather substantial exposition via code comments. The actual fixes are
comparatively simple, although still a little subtle to get exactly
right and took a few iterations to nail down the edge cases.
Thanks to bill for helping me with the RE & assistance on writing the
hooks/code and so on. I tracked down a lot of this myself, but the end
result wouldn't have been possible without his help.
Committers' note: I ended up wrangling this change a fair bit, as I am
apparently just always wont to do, and also fixed a bug in the process,
hence adding my copyright notice as well. Nonetheless, big thanks to
aciidz (and bill) for doing the bulk of the *actual* hard work of
figuring out how to do any of this! The actual code changes I made to
the original submitted patch were relatively minor; a lot of my effort
honestly went into attempting to shorten the massive wall of comment
text. At the end of the day, there's still a really long comment, but
it's just a lot to explain really so it is what it is. I hope it's at
least somewhat understandable to a reader, anyway.
|