I’ve been working feverishly on the Beta lately and have decided to take a step back and look and what’s been accomplished. While it’s hard to say, linearly, how far along things are – going through the code just doesn’t work that way – I can show a “map” of the code as seen so far.
For many of the files (21 of them) I know the actual name used, which I will provide. For other files, I don’t know the real name but do know about the functionality provided (to varying levels).
Numerical values shown are the first 3 numbers of the in-memory hex addresses – for example 0x16F4C7 “LoadCell()” would be shown as 16F. This is a high level map, so only file names are shown.
MAP:
Start Address | Code File or Description
————————————————————–
130 | main game loop (3D view) – file name unknown (yet)
132 | archive.c
134 | engsupp.c
13D | maploads.c
144 | career.c
147 | automap.c
155 | fs2df.c
15A | intro.c
15D | init.c
15D | text.c
166 | parse.c
16B | quests.c
16E | LoadCell and support – file name unknown (yet)
178 | char.c
18C | disk.c
192 | weapon.c
19B | loadsave.c
19C | support.c
1A0 | interface.c
1A5 | objlib.c
1A6 | maplogic.c
——————————–
Files names below this point are unknown but functionality is.
——————————–
1B0 | c-lib (malloc, free, fopen, fread, fclose, memset, rand,etc.)
1E0 | 3D rendering functionality
240 | mouse and font functionality
This includes sound support but I’ve re-written most of that already to support OpenAL.
I should also mention that most c-lib functions are not being written based off of the Daggerfall code – instead the modern equivalents are used (DOS based file system support, for example, isn’t very useful on Windows).
The major exception to this is rand() – since it must act exactly like vanilla Daggerfall, otherwise dungeon textures will be wrong. Yes, you read that right – here’s why:
{ 119, 120, 122, 123, 124 };
word textureTableCur[5]; //0x286186
void InitializeTextureTable()
{
int r0 = rand();
srand( curLocationRec->locationID>>16 );
byte r = randByte();
int r2 = _texRandTable[ r ];
memcpy(textureTableCur, textureTableSrc, 10);
for (int i=0; i<5; i++)
{
byte n = random_range(0, 4);
if ( n == 2 )
{
n += 2;
}
n += textureTableSrc[r2];
textureTableCur[i]= n;
}
srand(r0);
}
textureTableCur[] now contains texture file indices which are used to texture the various dungeon sections (modulo 5). As you can tell, if the random number generator is even slightly different, the dungeons will be textured completely differently. As it is, it works because the random number seed is based off the location ID – but note that the generator is re-seeded at the end so things like loot, random encounters, etc. are not affected by the locationID as well. 
