| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason the DLL got a tiny little bit bigger again but that's
fine. This will make orig_ calls more efficient in the inline case, and
also make it harder to screw up and hook the wrong thing by mistake.
Self-explanatory-ish, apart from the fact it's a fairly large API change
of course. And it relies on some more bonkers assembler directive
hackery.
But it works!
The only complaint one might have is that the featsetup functions no
longer take an explicit string which occasionally yields slightly less
perfect error messages, but I've decided this isn't really a problem and
makes the API nicer to use. It's a tradeoff, innit.
|
| |
|
|
| |
Quick unused header cleanup pass while we're at it.
|
| |
|
|
|
| |
The old GAMESPECIFIC mechanism had worked in practice but was
technically a little bit incorrect, oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this codebase is already extremely nonportable, I've decided to
relax the obsessive ifdef-else-error usage around all the extensions.
From now on, if there's no alternative to using an extension, we can
just use that extension. If it's possible to do something in a
relatively portable way, we can still try to do that in order to make
the code somewhat reusable, in contexts where that makes sense.
I also decided to use langext.h for naked functions and tail calls. If
that's used in another codebase build with a different compiler, those
just won't work, but that's fine. The benefit is really just that
there's less ceremony in places where those are used, because it's
likely there'll be a few more such places in the future, and it gets
annoying reading all the double-underscore stuff all over the place.
I still kind of want to do something about all the _WIN32 ifdefs too,
but I've realised that doing so will lead to almost nothing actually
being built on Linux. Then again, none of it currently runs on Linux so
I guess that's a moot point. Will worry about it later, anyway.
|
| |
|
|
|
|
|
| |
Turns out, there's no need for the trailing underscores. Plus, glibc
does some stupid stuff with __attribute__ for non-GCC compilers. Not
that that matters here, but it seems like a good practice just to use
the forms that never have such problems. And it's shorter too.
|
| | |
|
| | |
|
| |
|
|
|
| |
Every. Single. Time. And having screwed up the zip dates was just a
bonus I suppose.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Doesn't matter how many history rewrites I do before pushing my local
branch, there will always be something I still got wrong.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
Michael Smith
Hayden K
