Background:
From the values of PWVel, I think it is
actually two global variables that have
been merged into one.
int PWVel[4][3] = {
{ 2048, 1024, 512 },
{ 2048, 1024, 512 },
{ 2048, 1024, 512 },
{ 8, 8, 8 }
};
I think it should be:
int PWVel[3][3] = {
{ 2048, 1024, 512 },
{ 2048, 1024, 512 },
{ 2048, 1024, 512 }
};
int AnimLenFromClass[3] = {
{ 8, 8, 8 }
};
Then, this code in PM_DoWalk would make more sense:
Before:
vel = 8;
if (currlevel != 0) {
vel = PWVel[3][plr[pnum]._pClass];
}
After:
AnimLen = 8;
if (currlevel != 0) {
AnimLen = AnimLenFromClass[plr[pnum]._pClass];
}
This is now as close as it gets without switching to enum types/parameters everywhere, so the compiler can optimize all accesses/checks accordingly. This is especially noticeable in the way the code for the switch is generated (line 775). In the original binary you can see it does weird stuff if c is not one of the classes' enum value (probably due to optimization since the switch should be exhaustive).
I've tried switching the type of c to _ui_classes, also removing the UI_NUM_CLASSES value to see if that'd be enough to let it generate the optimized code, but nope, seems like we need to change it all at once. Currently, _pClass is a char, but an enum value would fit there as well, size-wise (alignment).
That's also why I'm guessing there had to be another enum for player classes, without the UI_NUM_CLASSES value...
Finished refactoring spells.cpp, modifying other files only as needed.
Some functions are 99% binary exact now, like PlacePlayer, for example.
Added notes/TODOs for places with remaining discrepancies.
Anders Jenbo
Robin Eklind
galaxyhaxz
Andrew Dunstan
aperturesecurity
Dennis Duda
Dennis Duda
galaxyhaxz