The rationate for preferring Name over Str is that Str
suggest a string for printing and Name a file name,
also based on the following associated PSX debug info:
char *FileName;
unsigned char mAnimName;
ItemDropNames correspond to the base file name (e.g. foo) of
diabdat.mpq/items/foo.cel
Infer name of spOptionsMenu from PSX debug data:
struct OMENUITEM MemcardLoadOptionsMenu[4]
struct OMENUITEM MemcardSaveOptionsMenu[4]
Use "sp" prefix for spOptionsMenu to conform with assert
information.
Rationale described in sanctuary/notes@3cd6417cdfafba340145939c2054ec614e1bd33e
as included below:
Infer the name of NetMsgStr and NetMsgHotKey from the
PSX debug names of:
char *PanBtnHotKey[8];
unsigned long PanBtnStr[8];
Note, the previous use of spsz hungarian notation has been removed
since searching for "spsz" gave no results in the merged output of
PSX debug info: https://github.com/diasurgical/scalpel/tree/master/psx/_dump_/_dump_merge_c_
Rationale described in sanctuary/notes@cb8812d1a605b363a90707a375ed4de999b13665
as included below:
Note, the BarColor and BarPos globals don't have
PSX debug info. However, the progress bar is
referred to as "barfoo" in other parts of the
PSX debug info, e.g.
// register: 21
register unsigned char barr;
// register: 16
register unsigned char barg;
Thus, we apply a similar naming convention for BarColor
and BarPos, using CamelCase as is conventional for global
variables in Diablo 1.
Rationale described in sanctuary/notes@541e63f85a442cbb2293734c24c5868ccceec800
as included below:
Note, the ChrBtnsRect global doesn't have PSX debug info.
However, the functionality correspond to that of InvRect
of inv.h. Moreover, the we may infer the name from the
function CheckChrBtns, and simply combine the two names.
Rationale described in a479cc56b8
as included below:
Note, neither rand_increment nor rand_multiplier are
present in the PSX debug info. To keep the names for
these variables consistent with the naming convention
used for sglGameSeed, SeedCount, SetRndSeed and
GetRndSeed (which are part of the PSX debug info), we
rename them to RndInc and RndMult, respectively.
Rationale described in f609ea371d:
as included below:
Note, the PSX sym file does not seem to include the
original name for monster_action_sounds. However, it
does include the names for very similar global
variables used for players rather than monsters, so
from these we may infer a similar name for
monster_action_sounds.
In particular, ArmourChar, WepChar and CharChar are
used for player graphics. So, following the same naming
convention we arrive at MonstSndChar.
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];
}
Also simplify if conditions to make
use of boolean values.
(If the cleanup4 PR ends up increasing
inserts/deletions, then this commit is
probably at fault.)
galaxyhaxz
Anders Jenbo
Robin Eklind
Alex Yatskov
Alex Yatskov
Alex Sweet
Martin Hauke
Pyr0Byt3
Sergey Semushin
Joan Karadimov