Reconstructed BioMenace Source Code

[K1n9_Duk3]

Ladies and gentlemen, I proudly present:

Reconstructed BioMenace source code

The archive contains full source code for all known versions of BioMenace, from the BioHazard beta (July 1992) to the rather obscure Gold Medallion release. Compiling the source code and compressing the generated executables with the included copy of LZEXE creates 100% identical copies of the original executables.

Some of you might already know that I released a similar source code reconstruction for Keen 4-6 in 2021. This BioMenace source code predates my Keen 4-6 source code by a couple of years. In fact, my Keen 4-6 code was based on this BioMenace code.

Just a few weeks ago, I found the last remaining bits of true BioMenace-related code in my Keen 4-6 source code: The order of the tile info offsets in ID_ASM.EQU is ANIM, SPEED in that file. It should really have been SPEED, ANIM for Keen 4-6, and both the Keen Dreams and the Catacomb 3-D source code used the SPEED, ANIM order in their versions of ID_ASM.EQU. The ANIM and SPEED offsets are never actually used anywhere in the assembly code, so the wrong order doesn't have an effect on the compiled/assembled code. That explains why I missed it. There are also some disabled include directives for VERSION.H or VERSION.EQU in the AUDIOCK?.H and GFX?_CK?.* files, but there are no VERSION.H or VERSION.EQU files in my Keen 4-6 source. The "Return to the Shadowlands" source code was based on an early version of my reconstructed Keen 4-6 code and has some more BioMenace code in it, like the ClipPushSprite() function in CK_STATE.C or the enumeration used for the pushtofloor field of the statetype structure in CK_DEF.H.

When I heard about another BioMenace Episode 1 source reconstruction by lethal-guitar, based on my reconstructed Keen 4-6 code, I decided to revisit my own BioMenace code and prepare it for public release to save everybody the trouble of reconstructing the code for episodes 2 and 3.

It's kind of funny: The original BioMenace code was based on the original Keen Dreams and Keen 4-6 code. I reconstructed the BioMenace code based on the Keen Dreams and Catacomb 3-D (and Wolfenstein 3-D) sources. My Keen 4-6 code was based on my BioMenace code. And then lethal-guitar reconstructed the BioMenace source code based on my Keen 4-6 code. So, in a way, we've come full circle.

This reconstructed source code also comes with a couple of alternative source code files. These files make it easier to modify and expand the dialogue for the hostages, the bosses and the hint robots and/or add proper mid-level saving for the non-beta versions. The mid-level saving code is very similar (but not fully identical) to a patch that I created for the v1.1 freeware release of BioMenace back in August 2018, shortly after the BioHazard beta (which had a semi-working mid-level saving implementation) was released to the public.

Merry christmas everybody.

[szemi]

Merry Christmas to you, too.

Happy to use codes from the source in the future.

[NY00123]

And, here it is.

I initially approached K1n9_Duk3 with relation to the 15th anniversary release of my Keen 6 level pack, shortly known as AAMBA. I turned out to bring up lethal-guitar's Bio Menace reverse-engineering efforts. Afterwards, I became aware of K1n9_Duk3 actually starting with BM source reconstruction earlier and using the work as a base for keensource456 (from which lethal-guitar started later). That was also leading to K1n9_Duk3 working to get the earlier BM reverse-engineering efforts to the state offered here, with the ability to byte-by-byte recreate multiple EXEs matching ones built in the 1990s.

There's a lot that may be discovered; Also without the code, albeit it often makes it much easier. I'll bring just one example for now, as K1n9_Duk3 and/or others might refer to more of these.

Consider the hazard identified as the sparkbot in the reconstructed sources. It's the flying one that brings Snake Logan to death right on touch, and follows paths using the behaviors of a Goplat.

Now, while occurring just in BM3, you may also find sprites for it in BM1 and BM2/BH1. Additionally, there's a sprite info tile for usage from maps in BM1 and BM2/BH1, but it won't spawn anything. I actually recall taking advantage of the sprites for that one BM1 level pack of mine, as released in 2012. I'm quite sure I repurposed the Goplat behaviors as used for the helicopter.

As for BM3, while the sparkbot appears in stock maps, you may rather find that BM2/BH1's caterpillar head sprite info tile is used for spawning it. That is not a coincidence, as BM3's sparkbot was indeed implemented as a modified caterpillar! You may even use the second caterpillar sprite info tile (used for one of the caterpillar's body parts in BM2/BH1), spawning a sparkbot that might not animate, yet is still functional.

My guess is that the sparkbot as a concept was thought about back in the times of the July 1992 prototype or earlier, but the implementation (as a modified caterpillar) had eventually arrived only later in development, for BM3.

[dark]

Very cool stuff! I love this forum! Thank you K1n9_Duk3 for this and all of your other incredible contributions to understanding and modding classic shareware games!

[dark]

Does Biomenace have the same XMS code issue that Keen 4 has, where the game does not utilize all available XMS?

This may sound like an academic question since there are not many Biomenace mods to justify needing more memory, but I actually have a peculiar use case.

-On my 386 retro computer I have a Gravis Ultrasound sound card that requires a TSR to be loaded into memory in order to provide emulated OPL/adlib sound. I have had the game automatically dump me to the dos prompt before due to lack of memory to run certain levels while this TSR is in memory (this is the only TSR in memory)
-I have used memory managers to increase the available EMS to try and get over this slight problem... however, for some reason, Biomenace and Major Stryker seem to freeze after playing for a very short while when I use my memory manager (QEMM) for EMS (I don't know why), so this has not been a suitable work around
-Therefore, I wonder if I can use the config.sys boot option discussed in this thread https://pckf.com/viewtopic.php?t=6409 to get the game to recognize and use increased XMS and see if that helps akin to how it does with Keen 4.

[Frenkel]

Awesome.

Have you tried compiling this or the Keen 4 source code in a different compiler than one from Borland?

For size checks at compile-time, I like to do

Code: Select all

typedef char assertUint16Size[sizeof(Uint16) == 2 ? 1 : -1];

This works in gcc-ia16 and Watcom.

[lethal_guitar]

When I heard about another BioMenace Episode 1 source reconstruction by lethal-guitar, based on my reconstructed Keen 4-6 code, I decided to revisit my own BioMenace code and prepare it for public release to save everybody the trouble of reconstructing the code for episodes 2 and 3.

Thanks for releasing this! I was maybe about a third or half-way into episode 2 when NY00123 got in touch with me and told me about your upcoming release.

Does Biomenace have the same XMS code issue that Keen 4 has, where the game does not utilize all available XMS?

I would assume so - from a comparison of ID_MM.C between BioMenace and Keen 4/5/6, the files seem practically identical (I normalized the formatting using clang-format and then did a diff). But I haven't looked too deeply nor tested anything so it's possible that there are some subtle differences.

[K1n9_Duk3]

Does Biomenace have the same XMS code issue that Keen 4 has, where the game does not utilize all available XMS?

The memory manager code in BioMenace is completely identical to the code in Keen 4-6 (v1.4), so booting with DOS=HIGH,NOUMB might be necessary to make enough memory available for the game. But BioMenace has some memory leaking problems that Keen 4-6 don't have, which means it requires a lot more memory than the Keen games. I suspect that the memory problems were the main reason why the game was discontinued and eventually released as freeware. I wrote about it in the MEMORY.TXT file that is included in the source release.

In your case, you might want to try booting with DOS=HIGH,NOUMB and loading your TSR into conventional memory instead of loading it into high memory. This way, the TSR only takes away whatever memory it needs instead of making all your UMB memory unavailable to the game. Let's say you have 75k of UMB memory and your TSR requires 27k. Letting DOS use the UMBs and loading the TSR into high memory means you free up 27k of conventional memory. That's great for all the games that rely entirely on conventional memory, like Duke Nukem 1 and 2, but not for BioMenace and Keen 4-6. Because those games could make use of the entire 75k of UMB memory, you would be wasting 48k of memory.

If you want to know how much memory you are wasting on your system, just type MEM at the DOS prompt and check how much high memory is still free. That is how much memory you could make available for Keen 4-6 (mods) and BioMenace by loading stuff into conventional memory instead of loading it into high memory.

The alternative would be to add my UMB allocation code from FITF into the memory manager code for BioMenace and compile new executables. This additional code would be able to allocate the 48k that are left unused after loading the TSR into high memory in the example above.

(I used the term "high memory" here because the commands for loading things into upper memory are called LOADHIGH and DEVICEHIGH in DOS. The terminology can be a bit confusing.)

As for the freezes you experienced... I'm not sure what's going on there. I know for a fact that Major Stryker doesn't use EMS or XMS memory at all. The freezes in that game could be related to the Sound Blaster code. I think an incorrect IRQ or DMA setting could lead to a freeze. But BioMenace doesn't use Sound Blaster effects, so I don't see how the freezes could have a common cause. Maybe your OPL-emulating TSR is the problem, but this is just a wild guess. I have never used QEMM or a Gravis Ultrasound, so I am perhaps not the right person to help you debug these problems.

Awesome.

Have you tried compiling this or the Keen 4 source code in a different compiler than one from Borland?

For size checks at compile-time, I like to do

Code: Select all

typedef char assertUint16Size[sizeof(Uint16) == 2 ? 1 : -1];

This works in gcc-ia16 and Watcom.

No, I have never tried to use anything other than Borland's compilers for these, and it shows. NY00123 told me that my size checks wouldn't work in other compilers, and I verified that such checks don't work in my old copies of Open Watcom 1.8 and Visual Studio 2008. That's why I added (optional) run-time checks in CHECKS.C for the BioMenace code.

In my defense, the Keen Dreams source code also has a sizeof() check inside a preprocessor #if condition in CA_CacheMap() in ID_CA.C. I must have copied that idea and added an #error directive for my checks to produce a more helpful error message.

Your suggestion is an interesting approach, thank you very much for sharing that idea! The compiler errors won't be quite as helpful in this case, but at least it works a true compile-time check. I have adapted your suggestion a little bit and turned it into a macro to make it more obvious what the code is for and to allow me to re-use it more easily:

Code: Select all

#define VERIFY_SIZE(type, size) typedef char type##SizeTest[sizeof(type) == (size)? 1 : -1];

VERIFY_SIZE(Uint16, 2)
VERIFY_SIZE(Sint32, 4)

The token pasting via ## should be supported by modern C compilers. I have verified that this macro works in Open Watcom 1.8 and Visual Studio 2008. (It also works in Turbo C 1.0 from 1987, but that compiler also supports sizeof() expressions and type casts inside preprocessor #if conditions, which the other non-Borland compilers don't support, so its token pasting abilities don't necessarily mean it was part of the C standard back then.)

[dark]

But BioMenace has some memory leaking problems that Keen 4-6 don't have, which means it requires a lot more memory than the Keen games.

I was wondering about this, as when the game has dumped me to dos before for lack of memory, it was not immediately upon loading a level, it tended to be mid-level, when I'd assume everything necessary for the stage is already loaded into memory (although I just read memory.txt, and that gave some examples of when additional memory might be needed mid level, such as accessing help menus or music change when rescuing hostage).

When I played through Biomenace recently, I did it on a Windows 98 Pentium machine in a windows dos shell. I never had a memory related crash when running the game this way. I see the game was discontinued around 2000, that would be around the time of things like Windows ME and its much reduced dos compatibility.

I have a custom boot setting on my 386 just for Keen mods, with dos=high,noumb, plus some memory manager stuff for EMS, and no TSRs (i can load the Gravis TSR from the prompt after these settings run). I'll be experimenting with Biomenace on this setting to see how it goes with the TSR, my guess is that it will work OK

[Williamblaze]

But BioMenace has some memory leaking problems that Keen 4-6 don't have, which means it requires a lot more memory than the Keen games.

I was wondering about this, as when the game has dumped me to dos before for lack of memory, it was not immediately upon loading a level, it tended to be mid-level, when I'd assume everything necessary for the stage is already loaded into memory (although I just read memory.txt, and that gave some examples of when additional memory might be needed mid level, such as accessing help menus or music change when rescuing hostage).

When I played through Biomenace recently, I did it on a Windows 98 Pentium machine in a windows dos shell. I never had a memory related crash when running the game this way. I see the game was discontinued around 2000, that would be around the time of things like Windows ME and its much reduced dos compatibility.

I have a custom boot setting on my 386 just for Keen mods, with dos=high,noumb, plus some memory manager stuff for EMS, and no TSRs (i can load the Gravis TSR from the prompt after these settings run). I'll be experimenting with Biomenace on this setting to see how it goes with the TSR, my guess is that it will work OK

I think we’re having the exact same problems. I’m trying to run a Bio menace mod on my Pentium running W98 (actually switched it over to 95 on my IDE drive) and having a few limitations on later levels.

The original games run just fine for me memory wise. It’s this mod I’m having issues with. Did you ever get your memory issues solved?

[dark]

I would recommend following the suggestions in this thread for freeing up memory. Works well with keen mods and a Biomenace mod ought to be similar.

viewtopic.php?t=6409

[Nisaba]

The archive contains full source code for all known versions of BioMenace [...]

I may be a bit late to the party, but I still want to pay my respects to you and everybody involved. This is truly a great contribution to better understand classic shareware games and to get a glimpse behind the scenes. I'm (once again) impressed by the work you've done / sweat and time you've spent to reconstruct the BioMenace source code! That is very inspiring. Top notch!

I would very much like to store the content outside of the forum as well to keep it for the long term. If you provide me with a suitable blurb, I will gladly take care of filling the server and editing the wiki entry. I think this could be an appropriate place:
https://moddingwiki.shikadi.net/wiki/Bio_Menace

[K1n9_Duk3]

I’m trying to run a Bio menace mod on my Pentium running W98 (actually switched it over to 95 on my IDE drive) and having a few limitations on later levels.

The original games run just fine for me memory wise. It’s this mod I’m having issues with. Did you ever get your memory issues solved?

Try creating a fully patched executable with my patching utility. That will save about 22k.