Cleaning up Wolf3D

I am starting this thread to document how to remove unnecessary code and free up more memory in Wolf3D. The intent is that I can make the game more efficient and make room for more things, like more than 64 walls, and maybe even be able to add alternate episodes. One of my ideas is to add the Spear of Destiny levels as a separate episode. I'm not sure exactly what is involved there, but I liked the Mac version's 3rd Encounter that used episode files to allow for more than one episode, and you could add more. Also, I think this could be beneficial since this alone could end up saving memory. I'm not sure how many things are currently loaded into memory that don't apply to the episode currently being played, and making it where only those things required for the current episode are loaded in, I think, would save memory as well. Please correct me if I'm mistaken here.

The majority of what I will be doing here is based on a list of things AyranWolf3D did some years back, so I will be getting his help in implementing these things. so, stay tuned cause we're in for a wild ride.

OK, so to begin this, I am going to go through AryanWolf3D's list from the top. To start things off I will ask the question, does the following mean this is what the game started with before making any of the mods you did?

Code:

//
// Initial build: 83 bytes near memory, 184 kb main memory
//

And to dig into coding, let's deal with the general changes:

Code:

///////////////////
//
// General changes:
//
///////////////////

Added a way to show the main memory before the preload: -32 near bytes
Wrapped #ifdef/#ifndef SPEAR directives around exculsive SoD code: 114 near bytes
Turned off Word Alignment: 436 near bytes
Turn off the Treat Enums as Ints option: 1434 near bytes

Total freed: 1984 bytes near memory

What exactly did you change, and where? This seems like a good amount of memory to get back. For the #ifdef/#ifndef directives concerning SoD, I see those everywhere in the code. You mean to say there are parts iD didn't do that with?

The last 2 is actually an option in borland compiler, open up your project file click options -> compiler -> Code generation and take out the "X" for both Word Alignment and Treat enums as Ints.

There's a file called version.h that has few lines yet they have a serious role in the code, if you open it you'll see that define SPEAR is commented out, this means that the compiler basically ignores everything that is located between an #ifdef SPEAR - #endif segment. For instance in wl_act2:

Code:

#ifndef SPEAR
   case bossobj:
      SD_PlaySound(MUTTISND);            // JAB
      break;
   case schabbobj:
      SD_PlaySound(MEINGOTTSND);
      break;
   case fakeobj:
      SD_PlaySound(HITLERHASND);
      break;
   case mechahitlerobj:
      SD_PlaySound(SCHEISTSND);
      break;
   case realhitlerobj:
      SD_PlaySound(EVASND);
      break;
   case giftobj:
      SD_PlaySound(DONNERSND);
      break;
   case gretelobj:
      SD_PlaySound(MEINSND);
      break;
   case fatobj:
      SD_PlaySound(ROSESND);
      break;
#else
   case spectreobj:
      SD_PlaySound(GHOSTFADESND);
      break;
   case angelobj:
      SD_PlaySound(ANGELDEATHSND);
      break;
   case transobj:
      SD_PlaySound(TRANSDEATHSND);
      break;
   case uberobj:
      SD_PlaySound(UBERDEATHSND);
      break;
   case willobj:
      SD_PlaySound(WILHELMDEATHSND);
      break;
   case deathobj:
      SD_PlaySound(KNIGHTDEATHSND);
      break;
#endif

In here the #ifndef means if SPEAR is not defined because it's commented out or something, compile these lines for the death sounds of Wolf3D bosses, but because there is an #else which means if SPEAR is actually defined, ignore everything before the #else and compile stuff after the #else, that's how you get the Spear of Destiny stuff, the code is filled with these ifdefs, they're all around and sometimes it can be a mess. It's like if you enable this you get this but if you disable it you'll get that instead. However there's many places in the code where the ifdef spear is missing like in WL_ACT1.

Code:

   case   bo_cross:
   case   bo_chalice:
   case   bo_bible:
   case   bo_crown:
   case   bo_fullheal:
      if (!loadedgame)
        gamestate.treasuretotal++;

   case   bo_firstaid:
   case   bo_key1:
   case   bo_key2:
   case   bo_key3:
   case   bo_key4:
   case   bo_clip:
   case   bo_25clip:
   case   bo_machinegun:
   case   bo_chaingun:
   case   bo_food:
   case   bo_alpo:
   case   bo_gibs:
   case   bo_spear:

bo_spear and bo_25clip are SoD exclusive pickups but because there is no ifdef to separate Spear bonuses from Wolf3D and they still appear in Wolf3D in a way and they're eating up some memory for no reason. In wl_def they're also not separated in the stat_t typedef enum, just like the enemies below a bit.

You probably want to change your WL_DEF to look like this:

Code:

typedef enum {
   dressing,
   block,
   bo_gibs,
   bo_alpo,
   bo_firstaid,
   bo_key1,
   bo_key2,
   bo_key3,
   bo_key4,
   bo_cross,
   bo_chalice,
   bo_bible,
   bo_crown,
   bo_clip,
   bo_clip2,
   bo_machinegun,
   bo_chaingun,
   bo_food,
#ifdef SPEAR
   bo_25clip,
   bo_spear,
#endif
   bo_fullheal
} stat_t;

Code:

#ifndef SPEAR
   #define NUMENEMIES      16
#else
   #define NUMENEMIES      11
#endif
typedef enum {
   en_guard,
   en_dog,
   en_ss,
   en_mutant,
   en_officer,
#ifndef SPEAR
   en_boss,
   en_schabbs,
   en_fake,
   en_hitler,
   en_gift,
   en_gretel,
   en_fat,
   en_blinky,
   en_clyde,
   en_pinky,
   en_inky,
#else
   en_spectre,
   en_angel,
   en_trans,
   en_uber,
   en_will,
   en_death
#endif
} enemy_t;

These changes aren't enough tho and there's alot more place where this needs to be done as well, I just showed you an example of how to separate Spear and Wolf3D stuff from each other.

Yes, that's the memory of a completely virgin wolf3d.exe (at least for 1.4; older versions have significantly more bytes free.)

I don't really want to go all over the code saying what changed and where, because there's way too much, but as a general tip for #ifdef/#ifndef, wrap them around the declared constants and variables first (most of them are in WL_DEF.H) and try to compile. When the compiler finds those things in the code, it will report an error and where it occurred. Use that to find where you should exclude those bits of code.

Turning off Word Alignment will stop it from adding padding bytes to structs, which can get quite expensive. It will theoretically make the program slower, but it won't make any real difference (unless you ran it on a veeery slow machine maybe.)

Turning off Treat Enums as Ints will make variables/structure members with a typedef enum datatype 1 byte in size instead of 2. A better option in my opinion is to instead remove all the stupid typedef enums (because they are a terrible and useless feature of C) and just give them 8 bit datatypes (usually "byte" or "char".)

The main memory thing isn't that useful for now, because for the most part it will stay the same after startup. The "before preload" thing is because when you start a level, all available main memory is used to cache in as many of the VSWAP's graphical assets as possible to avoid having to cache them in during gameplay, which could cause short but severe framerate drops.

Finally, I'd recommend checking out this thread on DHWs: http://dhw.wolfenstein3d.com/viewtopic.php?t=2798

Many of the posts there were included in my list. But don't just follow them without studying what it does, or you could break something. In the case of completely unused variables, you can just follow the list.

Another thing you can try is go here and search for KEEP_UNUSED

https://chokfiles.webs.com/diff.txt

It should show 92 entries with things that are not used in the code so far
Thanks to Aryan, Ripper, and a few others for helping me find many of them!
If you find some more or I missed any I'd love to know so I can update it even more.

You guys forgot to include WL_MENU.C and .H! What a shame!

@Princess Peach That was very useful indeed, glad you've kept it. 

Thank you for sending the diffs Maggie! Much appreciated! lol

So, what do the lines like this mean:

@@ -63,9 +63,11 @@

I'm aware of what #ifdef anf #ifndef directives do. My question was are there places where these directives should be but aren't? Wolf3DGuy did answer that in one specific instance. Finding them all will require me to know exactly what doesn't belong in Wolf3D that does belong in Spear, so be prepared for questions. Like this one. I don't recall where I read it, but somewhere in the source I think I saw it say that bo_gibs is Spear, not Wolf3D. I'll have to look again to be sure, but is it true or do I have it misremembered?

Also, will it have an impact on the game to re-order the list the way you did in your example above? If I should keep the same order, then there will be two #ifdef SPEAR/#endif's in that list. OK, I think I might have looked at your lists incorrectly the first time. It now seems as though they are two different code segments and I got confused by the similarity of item names.

bo_gibs is in both games.

Those numbers are probably related to line numbers, but all you need to worry about is the module name and what is being changed (just search for that code segment.)

Fridays and Saturdays are my days for getting videos uploaded to my YouTube channel. These videos are not Wolf3D related (well, not always anyway), so I won't go into detail about them here. While uploading them, I play Wolf3D. I am doing a playthrough I like to call "the god mode games", because I play every level in god mode just for the heck of it. I was just now playing through E1L4 when the game crashed. The error is:

Code:

SP_PlayDigitized: bad sound number

This is the first time I have ever gotten this error. I was picking up treasures in that big secret room accessed through the room with all of the dogs.

Edit: I replayed the level, since I am saving at each level I start, and played it again, and continued through the rest of Episode 1 without the error recurring. I'm guessing it was just a fluke and somehow a memory address got trashed.

I haven't really tried to change anything yet, but I was looking at the files that were in the downloads that I got from STEAM and GOG, and I noticed that the file size of the exe is 107K. I looked at the copy I have currently (after adding in the overhead map and making the noclipping cheat available again) and the file size is 482K. That's over 4 times the size of the unmodified 1.4 version! I can't believe that the few changes I made produced over 4 times the size of the unmodified app! I didn't make that many changes! What is going on here? Is the exe not compressed or something?

Yes they used LZexe to compress the exe file. You can also use it as well, but note whenever you make changes and recompile the code you'll have to compress the new exe as well.

OK. That makes sense. I found and downloaded the lzexe program (both the 91 and 91e versions) and also found and downloaded the unlzexe program (16 bit and 32/64 bit versions). Not sure I'll ever need the unlzexe program, but figured I should have the de-compressor as well as the compressor.

OK, 107k again. That's more like it! LOL

OK, the fix for pushwalls isn't exactly a fix. It mostly is, but I have found one circumstance where it creates a new bug. Episode 3, Level 6, As follows:

From the front (after pushing it):


From the back (after pushing it):


From the overhead map (after pushing it):


I used noclipping to get past it when it didn't open all the way. Funny thing is, the sound was still the same as for opening the entire 2 tiles. and it still counted towards the pwall count at the end of the level. I am going to see if it does the same thing again by repaying the level.

Edit: OK, it wasn't what I thought. Apparently, if there are any enemies standing behind the wall it won't open. In the replay, it was giving the sound of a pushwall being pushed when it's against another wall. I used the overhead map and saw there were two enemies in the spaces where the wall had to move, and the game was refusing to move the wall. My guess is that in the first one, there was an officer in the second tile, but not in the tile immediately behind the pushwall, so it was able to move one tile before it had to stop.

Would that still be considered a bug? I did find a solution, though. If you go to the area you started in, where the officers are behind the columns, and fire a couple of shots, the ones blocking the pushwall will leave and you will be able to open it fully.

Is there a known fix for this bug?

E4L10 secret room view from the east side:


Same room from the west side:


I've also noticed many times that when you are fighting the officers, many of them are invisible until you turn to the left or the right. I find myself firing at invisible enemies for most of the time spent fighting them.

Change NUMVISABLE (yes, that's how they spelled it) to something higher than 50. It'll cost 6 bytes for every increment, so don't raise it too much.

@AryanWolf3D wrote:Change NUMVISABLE (yes, that's how they spelled it) to something higher than 50. It'll cost 6 bytes for every increment, so don't raise it too much.

LOL I can believe they spelt it that way. I've known many programmers that are great at coding but lousy as spelling. According to the map editors, E4L10 has 75 Officers in Death mode. So, I will see what happens when I change NUMVISABLE. 75 is 25 more than the default 50, so 25 x 6 = 300 extra bytes if I go for all 25. I will try going for 60 first and see what happens.

@AryanWolf3D wrote:“We didn’t have spell checkers in our editors back then, and I always had poor spelling. The word "collumn" appears in the source code dozens of times. After I released the source code, one of the emails that stands out in memory read: It’s "COLUMN", you dumb FUCK! John Carmack - Programmer”

Now that is quite the quote. LOL

Anyway, the source code I have seems to be devoid of the word NUMVISABLE. I use TextPad as my primary editor, and it gives me the ability to create what it calls workspace files. I can group related files together and only have to open the workspace file to have them all load into TextPad, and they don't all have to be in the same folder. So, I created 3 different workspace files because there are so many files in the source to Wolf3D. One is all the .h files, one all the .c files and the third all the .asm files. An all document search in all three workspaces results in NUMVISABLE not found in any of the documents.

Please tell me where to find it.

Sorry, I meant to say MAXVISABLE. It's in WL_DRAW.C just above the DrawScaleds function.

@AryanWolf3D wrote:Sorry, I meant to say MAXVISABLE. It's in WL_DRAW.C just above the DrawScaleds function.

I found it, and changed all 4 occurrences to MAXVISIBLE. I tried 60, and it still had many invisible, so I tried 75 to see what would happen. The game runs fine, but there are still invisible officers, and when I have defeated them all it still shows only ammo clips when looking from the west end of the room. Maybe it's not that big of a deal if it only happens on this level, but if it happens on any others it may be a problem.

I think I may have figured out why changing MAXVISABLE didn't work. It turns out that MAXVISABLE is the maximum number of items that can be displayed at once, including static objects and animated objects. So, I have to include all of the ammo clips in the count as well. I'm going to try this and see what happens.

Edit: There are 27 ammo clips in that room, so I made the count 99 to see what it would do. It's alot better, but because 99 is < 75+27 there were still some invisibles. I also got to thinking, what if the number has to include the ammo clips dropped by the Officers? It took me a little while, but spending one round and picking up an ammo clip that wasn't visible before tells me that I have to make it 75 for the officers, 75 for the clips they drop and 27 for the clips already in the room. That's a total of 177. The game hasn't had any problems so far, so I will see what happens, but is there a way I can tell how much memory I am using? I have no clue and it's like flying in the dark without instruments.

That's 762 bytes. Not that big of a deal if you've freed up plenty of space. To find how much memory you have left, open up the Wolf3D.map file in the output folder, scroll to the end of the file, where you'll see something like this:

Code:

3A39:EFAD       _bufferwidth

The 2nd hexadecimal number is the amount of space in the data segment that the program is using. To find out how much space you have left, subtract this number from 0xF000 (which will be 0x53 or 83 bytes left in a vanilla Wolf3D.exe.)

Interesting development. The game still plays, and you can see all of the officers now, but when they have you surrounded at the west end of the room, firing towards the east slows the game down very much. If you turn to the right, the game speeds back up to normal. This continues until nearly all of the officers are dead. I'm guessing that's why they made the visible object limit so low. It prevents the game from slowing down when you have that many enemies all in one room.

@AryanWolf3D wrote:That's 762 bytes. Not that big of a deal if you've freed up plenty of space. To find how much memory you have left, open up the Wolf3D.map file in the output folder, scroll to the end of the file, where you'll see something like this:

Code:

3A39:EFAD       _bufferwidth

The 2nd hexadecimal number is the amount of space in the data segment that the program is using. To find out how much space you have left, subtract this number from 0xF000 (which will be 0x53 or 83 bytes left in a vanilla Wolf3D.exe.)

Code:

 39EB:EE57      _bufferwidth

Subtracting that from F000 leaves me 1A9 (425) bytes free. I guess I'm good for now, and that's with MAXVISABLE set to 177.

Yeah, sprites are a lot slower to draw than walls, because when you stack up enough of them, the amount of overdraw can start dropping the FPS rapidly. And besides that, the more objects there are, the more work DrawScaleds has to do (even determining whether an object is visible or not will slow it down when you have too much to do.)

That is totally reasonable. It makes sense to reduce the workload for drawing sprites when it may overwhelm the drawing function. I'm thinking I will set NUMVISABLE back to 50. I'll just have to be ready for invisible enemies here and there. LOL