[Hendricks266]

[ All text taken from RELEASE.TXT and https://www.facebook...076257905961485 ]

25 years ago today, Snake Logan was unleashed on the world!

Snake is the star of Bio Menace, which celebrates its 25th birthday today! The game was originally released on Aug 3, 1993! Bio Menace was the creation of Jim Norwood, who also went on to be one of the co-creators of the original version of Shadow Warrior!

Bio Menace was released at the hight of our time in the 90's putting out side scrollers. We had a few published at this time (the original Duke Nukem, Commander Keen), so this was a popular game. It was later released as freeware on Dec 23, 2005, so it has been free to play for some time now.

Before the game was released, when it was in development we referred to it as "Bio Hazard". Given the nature of the plot line and the things you ran into, that fit the theme well. However, before the game came out, we changed it to "Bio Menace". When we asked Jim Norwood about that, he had this to say..

"That happened because it turned out that there was some rock band named BioHazard who already held the copyright to that name. I'm not sure why we couldn't still use the name anyway since my use was for a video game versus a music brand. You'd have to ask Scott and George about the why's on that one."

-----

JIM LOOKS BACK

We asked Jim this week to send us some thoughts looking back on Bio Menace now that it has reached it's silver anniversary.

Bio Menace was really the first game that I ever designed, did all the level design, art, and code for as my first full on game project. And if that wasn't enough, it had to be a Trilogy! That was quite a project for a lone dude that was completely new to the gaming industry, but, it got done eventually and we shipped that full Trilogy in the end.

Bobby Prince did the music and I used Id's Keen Dreams engine to back the 2D game. Having the Keen Dreams engine is the only thing that made doing this game alone possible.

As John Carmack used to quote, 'There really is no such thing as a trivial game.' So true! Every game that is worth anything is going to take significant effort to finish and bring to market. However, I had some of the most fun working on this title that I've ever had working on any game since. Working nowadays in the AAA industry, I'm no longer the 'driving force' behind new IP's and as a Senior Engineer, I am a significant contributor to really large titles, but I'm really more now a piece of machinery in the giant teams required to ship such ambitious projects. That's just how this industry has evolved and I'm ok with that. But that doesn't stop me from looking back fondly on the glory days when I lone guy could make a great selling 2D platformer by himself. In some ways, those days have come back with mobile games, and then grew again to where even top tier mobile games are still going to require a competent team to create anything great.

I did manage to do another game called Tekken Bowling for iOS while I was at Namco where I was the sole programmer for the entire project, and I worked with only one designer and two artists on it. That was the closest I've come to making a game alone since the Bio Menace days.

--- Jim

----

ANGRY COSMO?

One the Bio Menace game characters looks like he could be Cosmo, only his slightly more angrier brother. Jim seemed confused by the question when we asked him about this, as this exchange shows:

Joe Siegler: Angry Cosmo - is that what that really was?

Jim Norwood: I actually cannot remember the Angry Cosmo except vaguely? Was it cool? LOL!

JS: Here you go. Angry Cosmo... (with a picture sent to Jim)

JN: Haha nice. Ok, but that was one of the main creatures throughout the game. I thought you meant I had added actual Cosmo as an Easter egg.

JS: No no - most folks who played the game thought it was supposed to be Cosmo - just his angrier brother or something. Seriously - even *I* thought that back before the game came out.

JN: Well, you are right. It sure as heck looks like Cosmo!

JS: The main difference is Cosmo has those spots on him, and the suckers. But visually your character is like an Angry Cosmo.

One of the more fun things that was in this game was something called "The Apogee Room". Was a very hidden section in one of the maps where Jim Norwood, Scott Miller, & George Broussard were visualized, along with a few computers and a ton of Apogee visual gags - mostly from Commander Keen & Duke Nukem. Here's what Jim had to say about this.. "That was all me. I loved the Easter Eggs in Commander Keen at the time and I wanted to put something similar in Bio Menace - hence the Apogee Room. "

-----

BONUS FUN!

It's always fun looking back on games like this, but today, we're going a bit beyond than what we usually do for these anniversary stories. We've dug into the archives and found a working copy (well, after some massaging) of one of the game's betas that we are releasing for free today!

The game was actually still called "Bio Hazard" at this point, and was dated July 15, 1992.

We've also thrown in a PDF the "Secret Moves" paper that we used to send out with Bio Menace orders placed with us.

Big thanks to Jim Norwood for allowing this to be released, and for Evan Ramos for whipping it into shape. There were some fiddly tech issues with this release that he goes into in greater detail in the release.txt file in the game directory about what fixes had to be made to the beta for release. Make sure and read it for additional info, as some of it is quite interesting.

You can download the zip file here:
https://legacy.3drealms.com/menace/bh_071592.zip
(Mirror) https://dukeworld.duke4.net/2001-current/apogee%20freeware/bh_071592.zip

Some other Bio Menace related links for you to check out:

1) Our original Bio Menace webpage here: http://legacy.3drealms.com/menace
2) Youtube Video showing you the Apogee Room:

3) Frenkel's Bio Menace Maps: http://legacy.3dreal...maps/index.html
4) Apogee Legacy Interview with Jim Norwood: http://legacy.3dreal...jim_norwoo.html
5) 3D Realms' Bio Menace Trailer:


Thanks for checking this all out, and thanks for playing our games these last 25-30 years or so!

Joe Siegler
Apogee Software / 3D Realms
Aug 3, 2018

https://www.facebook.com/official3dr/
https://twitter.com/3drealms
https://boards.3drealms.com

==============================================================================

TECHNICAL STUFF FOR THIS BETA RELEASE:

There are several interesting things to note in this prototype. First and foremost, it can be seen that the final game's Episode 2 was originally slotted to be Episode 1. The final boss of the episode is a floating head of Dr. Mangle (whose art can still be found in the final game's data) rather than The Enforcer, though their behavior is functionally similar, if not identical. The in-level save feature inherited as part of the Keen Galaxy engine is still active in this build, before being disabled for technical reasons in the final game. Some of the item sprites differ in this beta. I'm sure there are more curiosities waiting to be discovered and documented.

Unfortunately, some of the files that make up the game's graphics banks were found to have experienced some kind of data corruption. The data was collected into a zip file that passed all checksum tests, meaning whatever happened took place before archival. My collaborator NY00123 stepped up and repaired the damage by inspecting it with various tools, including one of his own design, and cross-referencing with the final BM2 where necessary.

In testing, NY discovered a crash that manifests at two points in the episode, and we agreed that he would make a one-byte edit to fix the problem, improving Quality of Life for players. As copy protection, the executable performs a date check that aims to make the beta expire after a certain time. Bypassing this would require changing the system clock or intercepting the call with a TSR, but since we already modified the exe, he simply disabled the check with another one-byte change. Additionally, the executable requires a password to be entered on the command line, so we inspected the exe to find it and have provided it for you as part of PLAY.BAT. (If you wish to compare our modified exe with the original, you will need to use UNLZEXE to unpack both files.)

Unmodified versions of all edited files, as well as the original internal beta tester documentation text files, are available in the folder named "ORIGINAL". Below you can find a detailed technical description of modifications made, written by NY00123.

-Evan Ramos / Hendricks266

==============================================================================

BHAZARD1.EXE, EGAGRAPH.BH1 and EGAHEAD.BH1 were modified. Details are given below. This text file, PLAY.BAT, and SecretMoves.pdf were not originally present.

Original timestamps (local timezone information is unavailable):

ABOUT.BH1    1992-03-22 16:40:04
AUDIOHED.BH1 1992-06-10 12:44:24
AUDIOT.BH1   1992-06-10 12:44:22
BHAZARD1.EXE 1992-07-15 22:36:40 *
CONTEXT.BH1  1992-03-15 16:24:26
CONTRART.BH1 1992-03-22 18:26:14
DEMO0.BH1    1992-07-14 03:07:12
EGADICT.BH1  1992-07-13 19:03:44
EGAGRAPH.BH1 1992-07-13 19:03:44 *
EGAHEAD.BH1  1992-07-13 19:03:44 *
ENDART.BH1   1992-07-12 19:12:16
GAMEMAPS.BH1 1992-06-17 17:17:48
GAMETEXT.BH1 1992-03-15 16:24:26
GFXINFOE.BH1 1992-07-13 19:03:46
HELPART.BH1  1992-03-22 18:07:42
MAPHEAD.BH1  1992-07-12 19:23:50
MAPTEMP.BH1  1992-07-12 19:23:46
MAPTHEAD.BH1 1992-07-12 19:23:44
MUSEINFO.BH1 1992-06-10 12:44:22
ORDERART.BH1 1992-03-23 02:09:16
README2.TXT  1992-07-15 17:06:40 *
README.TXT   1992-06-29 20:58:54 *
STORYART.BH1 1992-03-22 18:07:42
STORY.BH1    1992-03-22 16:40:04
TEDINFO.BH1  1992-07-12 19:23:48
TEDINFOE.BH1 1992-03-15 16:24:26

* The unmodified original copies can be found under "ORIGINAL".

BHAZARD1.EXE had the following edits applied, changing exactly two bytes of code (in the LZEXE-unpacked EXE):
- The beta expiration date check (which is somewhat buggy) is skipped.
- With the original EXE, if you try to read the color sequence in "Ant Caves" (level 3) or activate the easter egg in "Specimens Labs" (level 10), the game will abort from a call to the StartMusic function with (virtual) level number 20 (21st level). Based on the note from README2.TXT saying that the amount of playable levels was reduced by 6, this was fixed so StartMusic is called with the value of 14, leading to playback of "Resting" (as in the final game).

The original EGA data is partially corrupted, so EGAGRAPH.BH1 and EGAHEAD.BH1 had to be recreated. ModId was used for exporting and importing graphics.
- The presence of two complete 16x16 tiles in the initially exported data gave the hint that 7725 bytes shall be removed from some offset in EGAGRAPH.BH1 (done at offset 0x16308). This assisted with getting virtually all tiles, which were the same as in Bio Menace ep. 2 for most. A small amount of missing or partially corrupted tiles were simply copied from BM2.
- An internal tool was written for displaying the sprites, including the separate EGA planes. At some point, it could let one "move" the EGA planes around and export them as separate BMP files. Eventually, most sprites were actually copied from BM2 as-is. It's only most of the player sprites and other few sprites which needed more edits.
- After modifying the tool for usage with masked 8x8 tiles, it was found out that they were exactly the same as in BM2. As for unmasked 8x8 tiles, it was separately found out that such tiles were only added between BH1 and BM2, not removed or replaced.
- A portion of the "This is -NOT- Shareware" picture had to be recreated. The rest of the unmasked pictures remained intact, while the only masked picture (used in the menu) was copied from BM2.

-NY00123

[Poorchop]

Good read and excellent news. It's amazing to see some fresh content after 25 years. This game was big for me when it was released and I've continued to play it from time to time over the years. It's nice to see Jim's input on it after all this time. Definitely my favorite Apogee game - can't wait to give the beta a spin.

[K1n9_Duk3]

 Hendricks266, on 03 August 2018 - 01:03 PM, said:

You can download the zip file here: http://legacy.3dreal...r_beta_0892.zip

That links to the Major Stryker beta. Use this instead: http://legacy.3dreal...e/bh_071592.zip

[Sanek]

Great read! Never liked Bio Menace, which is a lesser side-scroller from Apogee, but this "Secret Room" is really something! The stuff you'll see on the shelves is literally the ripped off enemies from Duke1 and Commander Keen! Don't recognise the bombs and candies, though.

[K1n9_Duk3]

Bombs and candy in the Apogee room are from Keen Dreams, I think.

[gemeaux333]

A remake in project ?

[CryptKiller]

Great news! BioMenace is one of my favs from Apogee catalogue.

The beta has a weird bug where starting from the second level, you have 0 hit points, so everything kills you immediately. Also, there's no menu music, so the in-game music plays at the menu screen, and the demo on highscore table shows the score box. And it may be my memory playing tricks, but the "outer woods" level theme sounds slower than in the final release, it seems there's more of a pause between bell tolls...

[K1n9_Duk3]

The beta uses the same method for activating the debug keys as the freeware release.

Once the debug keys are active, you will start every new level with 8 hit points and won't be killed by the first thing that hits you.

[NY00123]

A little bit late reply, but here it goes: It's finally out in the public!

To anybody a little bit stuck or confused, use the "Backspace" key to
toggle on/off the scorebox from the game, and Alt+Up to throw grenades
(assuming you didn't mess with the keyboard settings). Also,
check out the ORIGINAL/README2.TXT file for more
caveats and other notes.

I intend to write/show a bit more on the technical side of
things (including the originally corrupted EGAGRAPH data),
but it's probably better to do so in a separate post.
The RELEASE.TXT file shall still have something
for you to read, though.


==================


Let me say the following:



I must emphasize that this couldn't be done just by myself.

Thanks to Jim Norwood, 3D Realms and Hendricks for getting the ball rolling!


Wait, a longer credits list? I'm sure that I'll miss *someone* around here.
This is why I shouldn't do this...

I apologize in advance. Anybody who deserves the credits, no matter
if listed here or (APOLOGIES!) not - here, I'm sending them to you!


...You *still* want a list? Oh well, since you've asked for it:

- First of all, thanks to Jim Norwood and 3D Realms for the game itself!
Let's add Robert Prince for the game's sound track, of course!

- id Software, for the codebase that powers Keen 4-6, later
licensed to Jim Norwood for the making of Bio Menace.

- John Carmack, John Romero, Jason Blochowiak, Adrian Carmack, Tom Hall
and Mark Rein for their involvements with id Software during the development
of Keen 4-6, along with Robert Prince for the sound track.

- Jim Norwood and 3D Realms, for giving the green light for the release of
this prototype, along with Hendricks for his involvement with me and others.

- Frederik Schreiber, Joe Siegler and TerminX for their parts in this release.

- Yatta for the creation of Duke4.net, and Geoff Sims for founding
the message board that eventually became the PCKF.

- Special thanks to Lunick, Roobar, MYHOUSE.MAP and Malvineous
for their feedbacks on the prototype.

Finally, thanks to the Duke4.net and PCKF communities for all of these years!

[K1n9_Duk3]

This might come a bit too late, but in addition to thanking everyone involved with the beta release, I wanted to give special thanks to the person who decided to include the MUSEINFO.BH1 file (and all the other unused files) in the beta release.

This is the first time ever that I've seen a MUSEINFO file. As the name suggests, this file would have been used by MUSE, the tool that was used to create and edit the sound files (AUDIO/AUDIOT files). The game does not need this file at all, which is why I've never seen one before. The reason why I think this is important is that this file contains the actual names that were assigned to each sound effect during development.

Knowing what some of the sounds were named allows me to make very educated guesses on what the enemies in the game are called.

• The small snakes are called "Cobra" ("Snake" is the player character).
  
• The green thing that walks on the ceiling and looks like a Garg, only at the size of a Yorp (both are enemies from Keen 1) is actually called "Gorp".
  
• One creature is probably called "Chomp", but I am not 100% sure about that. I think it's the green worm thing that the player can transform into. At least that's the only part that plays the "CHOMPWALK" sound (when jumping).

Aside from the MUSEINFO file, there are a few other files that are not required for the game to be playable. These are GFXINFOE.BH1, TEDINFO.BH1 and TEDINFOE.BH1, which were used by TED, the map editor for these games. TEDINFO.BH1 also has the name "CHOMP" in it, right after "BHAZARD1", so it's safe to assume that this was used as the hidden command switch that was required to play an earlier version of the beta (the released beta requires the "slammer" switch, as seen in the PLAY.BAT file). If you compare the executable of the beta to that of the final release, you'll see that the final version has the text "sewerman" where the "slammer" text used to be in the beta. The final release does not use that text at all, Jim Norwood probably just didn't remove the text when he removed the code that used it.

All these "passwords" seem to be the name of one of the creatures in the game. "Sewerman" is obviously the tall green monster that is first seen in Episode 1 Level 5: "Sewers" in the final release. I'm not sure who "Slammer" is, so feel free to share your theories.

Edit: fixed typo.

[NY00123]

 K1n9_Duk3, on 05 August 2018 - 01:12 PM, said:

This might come a bit too late, but in addition to thanking everyone involved with the beta release, I wanted to give special thanks to the person who decided to include the MUSEINFO.BH1 file (and all the other unused files) in the beta release.

Wow, what a great find! Can't believe I've missed this! (Then again, maybe it makes sense.)

It's incredible you've discovered creatures' names by checking these files. This is something I knew to be mostly unknown long ago, and I've recently wondered about this again, so it's really great to finally learn about even just a few of them!





On another note, I think it's a good chance to finally reveal how I, at least partially, took care of corrupted graphics (emphasis on sprites).
I basically wrote an internal tool for assisting me with the sprites, and later forked it to cover other kinds of chunks, although not all of them.

Source code: https://gitlab.com/N...-chunk-shifters
Video with demonstration:

[Hendricks266]

Among the 3DR archives, I see a MUSEINFO in a Blake Stone beta. That game has its 25th later this year.

[K1n9_Duk3]

If you're curious what Food and Potions are for:

Spoiler

You gain 1 unit of health for every 10 food units you collect. This gives you up to 8 hit points, regardless of the selected difficulty. Some food items give you 2 units of food instead of just 1.

Collecting 25 small potions basically gives you an invincibility potion. Collecting the 25th potion is what makes you invincible and sets the potion count back to 0.

@Hendricks266: That's an interesting teaser. But we already have the full source code for Blake Stone, so we know the names of most sounds from the .H files in the source code. MUSE used the names found in the MUSEINFO file to generate these header files.

[NY00123]

ok, a few more technical tidbits: Already noticed that this beta (mostly) supports savestates as in Keen 4-6, unlike the later Bio Menace releases, in which you need to start a level from scratch?

Interestingly, I'm having a *guess* for the cause, and it was actually discovered while messing with the codebase of a whole different game!

Well, OK, it still shares enough code with Bio Menace and others. I'm talking about Softdisk's Catacomb Armageddon title! This is a part of the Catacomb Adventure Series, a follow-up to Catacomb 3-D.


TL;DR description:


The saved games in question include pointers to structs of type "statetype".
- In games like Keen Dreams, Keen 4-6 and the Bio Hazard prototype, these are 16-bit near pointers.
- However, in games like Bio Menace and Catacomb Armageddon, these are 32-bit far pointers.

The exact saved value of a given 16-bit near pointer depends just on the EXE's layout. As long as the same EXE is used, it's reliable.
Unfortunately this does not apply to the 32-bit far pointers, which probably explains why there were issues with game saving during the development of Bio Hazard/Menace. In Catacomb Armageddon/Apocalypse, you can still save and load as usual, but this can be unreliable.


Longer description:


I'll first remind that we're talking about 16-bit real mode DOS apps. The latter means that it's somewhat tricky to access more than 64KiB of memory. This is where memory segmentation has its role. Basically, a memory location can be referenced by a seg:off (segment:offset) pair, where seg and off are 16-bit values.



Now, various early id games use a struct of type "statetype" to describe a current state of an in-game object (like an enemy, or the player itself). Various such states reside in each game's EXE file, and can be referenced by pointers.

Originally, all states were a part of a segment known as the "data segment", also known as "near memory". It can't have more than 64KiB of memory, and a single 16-bit near pointer (the offset part of seg:off) is sufficient to describe a state in such a case.

This is the case in Keen Dreams and Keen 4-6, Catacomb 3-D and Catacomb Abyss, Wolfenstein 3D and Blake Stone, and also the Bio Hazard prototype.

However, for Bio Menace, as well as Catacomb Armageddon and Catacomb Apocalypse, the developers were *apparently* forced to take advantage of more memory. Thus, the states aren't constrained to a single 64KiB segment anymore. This means, though, that such a state's location has to be referenced by a 32-bit far pointer, with a full seg:off address.



Let's show this in the code. Here's the way it's defined in the Catacomb 3-D sources (shall be similar in Wolfenstein 3D and Blake Stone, and somewhat also in Keen Dreams): https://github.com/C...4/C3_DEF.H#L150

Compare to Catacomb Armageddon (and also Catacomb Apocalypse): https://github.com/C...ddb2/DEF.H#L259



Let's finish with the impact of this on saved games. Basically, amongst other data, the current objects' states are written to the saved game file using such pointers. Question is, if these values are reliable. Will they be *exactly the same* after loading the saved game from file?

For 16-bit near pointers, the answer is "yes", as long as the *exact* same EXE is used. Even when you re-build an EXE from source code, any minor difference can break compatibility with saved games. Otherwise, though, this is a non-issue.

This cannot be said about 32-bit far pointers, though. The segment part of the pointer greatly depends on where's a (somewhat modified) copy of the EXE's code loaded into memory. Thus, chances are they'll break as you're moving between computers. Even on the same installation, though, there's no guarantee.



In fact, here's how you can reproduce totally unexpected behaviors on your own, in Catacomb Armageddon v1.02 (and similarly Catacomb Apocalypse v1.01):

- Do *NOT* try this on real hardware unless you agree to take the risk!!!
- Load DOSBox, mount the directory in which a working copy of Catacomb Armageddon v1.02 resides, and change to it.
- Start the game by entering "CATARM". Go through the dialogs until you find yourself in the beginning of a play-through.
- Press on F3 to save a game. Enter a name of your choice and then save the game.
- To quit, press on "Esc", followed by 'Q'.
- Start the game again, but rather by entering "LOADFIX CATARM". Press on F4 to load the saved game.
- Make sure you enter the saved game's name correctly.
- At this point, ANYTHING CAN HAPPEN. You might get a weird error message, like "ScaleShape: NULL compshape ptr!64 kb freed."; You might also get a totally unpredictable play-through; Oh yeah, DOSBox may crash, too. Again, ANYTHING CAN HAPPEN.

[K1n9_Duk3]

You get +1 because you explained the Catacomb Armageddon thing.

But you're wrong about this causing the issues in Bio Hazard. Bio Hazard (a.k.a. the beta) still uses 16-bit near pointers for the state pointers in the objtype structure. Only the final Bio Menace releases use 32-bit far pointers.

You can verify this by looking at the SnakeThrow function (seg008:0443 in beta, seg008:04D0 in BM1 v1.1 freeware) or any other function that changes the state of an object.

[NY00123]

 K1n9_Duk3, on 07 August 2018 - 12:44 PM, said:

You get +1 because you explained the Catacomb Armageddon thing.

While many will say that "rep. points are to be ignored", thanks for the one, I guess! Heh.

Quote

But you're wrong about this causing the issues in Bio Hazard. Bio Hazard (a.k.a. the beta) still uses 16-bit near pointers for the state pointers in the objtype structure. Only the final Bio Menace releases use 32-bit far pointers.

Can you show me where have I implied this? Quite sure I've written it's still the usual 16-bit near pointers for the prototype.

Maybe you've referred to this brief text of mine by chance?

 NY00123, on 07 August 2018 - 10:32 AM, said:

Unfortunately this does not apply to the 32-bit far pointers, which probably explains why there were issues with game saving during the development of Bio Hazard/Menace

The only reason I've written "Bio Hazard/Menace" this way, is that I'm not sure how was the game originally titled when the change to the pointer size occurred.

[K1n9_Duk3]

Sorry. I guess I didn't read your post carefully enough, which lead me to believe your post was about the fact that loading a game in the beta seems to cause the game to crash or lock up when you are loading it directly from the menu without starting a game first. Now I realize that you actually just gave one possible reason why the mid-level saves were removed in the final version, instead of explaining why the load feature is (partially) broken in the beta.

[NY00123]

Side-note: If I don't see more diffs between BH and BM being mentioned here or in the PCKF, then I might add at least some of them on my own later
(I suppose the TCRF is a better place for this, though.)

Let's add the following. As stated by me in RELEASE.TXT, ModId was used for importing and exporting graphics. In addition, a really simple modification of a part of ModId's code, BMP256 (which in turn is a modification of BMP16 from (L)ModKeen), was used for the EGA chunk shifters. In a retrospect, maybe BMP16 was sufficient, but this is the situation.

ModId was created after a few instances of forking. Here's a rough summary (LModKeen II also integrated Fin2Bmp):

ModLatch -> ModKeen -> LModKeen (I && II) -> ModId

Some credits collected from the KeenWiki page about ModKeen, as well as a few other sources:

Andrew Durdin - Wrote ModLatch, later morphing into ModKeen. Also coded Fin2Bmp, used for Keen 1-3 finale/preview screen editing, eventually getting merged into LModKeen II.
Anders Gavare and Daniel Olson - Their assistance for the work on ModKeen.
David Gow - Addition of Keen Dreams support.
z-1 - Win32 port.
Shadow Master - LModKeen, a Linux fork of ModKeen.
Malvineous - Script and mini-program converting lowercase filenames to uppercase, used by one of the (L)ModKeen devs. (Addendum: Let's also mention his vast experience with handling different DOS games' file formats!)
Szevvy - Information about Bio Menace data files.
Levellass - The addition of Shadow Knights and Dangerous Dave 2 support.
lemm - Forked LModKeen into ModId, in order to support arbitrarily formatted xGAGRAPH files for arbitrary games and mods (the original intention being usage with source mods).
furan - His contributions to ModId.

It's also a good chance to mention Levellord, Levellass and lemm, as well as KeenRush, Andy Durdin and David Gow, for their EXE patching skills and related!

[K1n9_Duk3]

I compared the levels from the beta to the ones in the final episode 2 and found surprisingly few differences in the layout of the levels. After all, Jim Norwood kept working on the game for over a year after this beta...

The gameplay mechanics are what changed the most. The level layout itself stayed mostly the same. These are some of the differences I noticed:

• There is only one type of grenade (green). No landmines at all.
  
• There's only one type of ammo. No plasma bolts or super bullets.
  
• There are no first aid kits, only food items
  
• There are no instant invincibility potions, only the small potions
  
• There are no gems to collect for an extra life in the beta
  
• There are no checkpoints in the beta (probably because it still had mid-level saves)
  
• The are no warp gems (and no secret levels) in the beta

Layout changes in the levels:

• Level 1 of the beta has the crashed plane at the beginning (along with 3 green grenades). The final release still has the graphics of the crashed plane in it, but it doesn't appear in any level.
  
• Level 3 (Ant Caves) cannot be finished without entering the correct color code. If you enter the wrong code, the trap kills you. And because you can't respawn after the trap kills you, the alternate exit doesn't (need to) exist.
  
• The starting area of level 4 (Ant Town) is slightly different (there's no warp gem to collect in the beta)
  
• Level 8 (Electronics Lab) has a slightly different layout because the beta uses the same type of force field to morph the player into the green worm and back, while the final game has one force field to change you into a worm and a different type to change you back to a human.
  
• Level 10 (Specimens Lab) has only one door in the secret Apogee room, while the final version has three doors. Also, the area with the special key was moved a little, which only affects how far the camera can scroll up & down in that area.

Enemy placement hasn't changed much (it did change in at least one level, but I don't remember where exactly). Items were exchanged for the final release, but they are usually placed in the same area of the level.

• Small potions were mostly replaced by gems.
  
• Groups of food items worth 10 food were replaced by first aid kits.
  
• Goodies behind locked doors might also have changed. This is hard to tell without actually playing the games (I was merely using my level viewer for most of my "research").

While playing the beta on easy difficulty, I noticed that the ammo pickups didn't give me any ammo. It works fine on normal difficulty, though. Probably another one of the many bugs in this beta.

[Fantinaikos]

That unstoppable thing of Lingyan203 has made a gameplay (not full).


This beta may be open the road for some serious Bio Menace modding? (source code allowing)

[K1n9_Duk3]

 Fantinaikos, on 16 August 2018 - 08:20 AM, said:

This beta may be open the road for some serious Bio Menace modding? (source code allowing)

I'm not sure what you mean. As far as I know no source code was ever released for Bio Menace (final or beta).

Most of the graphics in the beta are the same as in the final release (in part because some of the corrupted graphics had to be imported from the final relase to make the beta playable), so I don't see how that would lead to more mods for Bio Menace. And most of the "unique" features that the demo has code-wise (food & potion meters, carrying ammo and grenades over from the previous level) could be added to any other release if you know enough about assembly/machine code and patching.

[NY00123]

 K1n9_Duk3, on 16 August 2018 - 02:51 PM, said:

 Fantinaikos, on 16 August 2018 - 08:20 AM, said:

This beta may be open the road for some serious Bio Menace modding? (source code allowing)

I'm not sure what you mean. As far as I know no source code was ever released for Bio Menace (final or beta).

Quote

most of the "unique" features that the demo has code-wise (food & potion meters, carrying ammo and grenades over from the previous level) could be added to any other release if you know enough about assembly/machine code and patching.

That's true, Bio Menace was never open-sourced in any form. The closest I can think of which was properly open sourced, was a combination of about half of the Catacomb 3-D sources (more precisely the "ID Engine" components) with Keen Dreams' game code. (There's also enough RE'd Keen 4-6 code.)

Even then, it should be feasible to import certain features of BH1 into BM2 with patching. Game saving might be quite non-trivial, though. Maybe it's doable by taking care of the saved 32-bit far pointers, while taking advantage of unused space for additional code.

Quote

Most of the graphics in the beta are the same as in the final release (in part because some of the corrupted graphics had to be imported from the final relase to make the beta playable)

Yeah, it's true that most of the graphics are the same. As for importing them from the final release, interestingly, I have evidence that most of the graphics in the corrupted files remained the same, including the sprites (almost all player sprites are an example of an exception). In fact, with one of the aforementioned EGAGRAPH chunk shifters (the one for sprites), it's possible to recognize the sprites in the corrupted data, and see that most of them are more-or-less the same. I shall upload to the same git repository (on GitLab) a sprite shifter input txt file letting you view them.

[K1n9_Duk3]

 NY00123, on 17 August 2018 - 06:02 AM, said:

Game saving might be quite non-trivial, though. Maybe it's doable by taking care of the saved 32-bit far pointers, while taking advantage of unused space for additional code.

Adding game saving to the final releases is most definitely doable. But it requires a lot of work to get right, because you would need to save/restore more variables than just gamestate, map planes and objects. For example, the variable that stores the current state of the colored switches is not saved in the beta. So if you save and load after using the first switch, you might not be able to complete the sequence anymore.

What's interesting to me is that, unlike the beta, the final release shows the Apogee logo as an in-game demo at startup. That means the program has already been in a level when you get to the main menu and loading a game can't cause the crash/freeze that occurs in the beta.

Fixing the far pointers only requires you to subtract a known segment value (like any data or code segment) from the segment part of the far pointer before writing it to the file. And when the pointer is loaded from a file, you simply add the "same" segment (which might actually have a different value depending on how much free memory you had when the program was started) to the segment part of the far pointer and you're done. Of course this doesn't work for all far pointers, but it does work for the state pointers in Bio Menace.

[K1n9_Duk3]

To prove that what I said above is true, I decided to write some patch scripts that allow you to save and restore the game at any point in the level (for the 1.1 freeware release of Bio Menace). While I was testing the patches, I also decided to investigate what causes the freezes when loading a game in the Bio Hazard prototype/beta.

As it turns out, the crash/freeze has abolutely nothing to do with the data that's being loaded and saved. Actually, the root cause of this issue is still present in the final release - and it might have been part of the reason why the game was discontinued and eventually released as freeware.

Quote

2) Of all the games we've ever released, this one has had the most problems
working in some situations. Even back when MS-DOS was the #1 operating
system on the PC, it had problems, it required odd uses of config.sys
variables, and now in the era of Windows XP, it's somewhat more
problematic. If you can't get it running, you're not alone. It is most
definitely being released "as is".

The main issue I noticed when playing Bio Menace on actual hardware is that the game tends to crash with an "out of memory" error on some levels. The debug keys in the freeware release allowed me to track this down to the game "leaking" memory when changing the music. You can see this for yourself by using the debug cheats. Start a new game from the main menu and once in the game, enable the debug keys. Now use M+F10 to see the memory usage and remember the "free with purge" value. Hit escape to go back to the menu, then return to the game and check the memory usage again. You'll see that the amount of free memory has decreased. This problem only gets worse in the later levels, where you have bosses, hostages and/or invincibility potions, all of which change the music when defeated or picked up. And if you open up the main menu (to save the game) and/or the help menu, you lose even more memory.

The only thing that temporarily fixes the memory leak is the fact that the CA_SetAllPurge function is called when the game loads a level. The function basically tells the memory manager that it's okay to remove all graphics, sounds and music from memory to make room for new things. And this is what causes the freezes in the beta. The memory manager reassigns the buffers that were previously used to store graphics and the font for the menu get re-assigned and are now used for the level data. And because the menu was designed to re-draw itself after loading a saved game and before exiting the menu, the menu code trying to access the data that is no longer in memory is what causes the freeze. In the final release, the game does not need to load the level while loading a saved game, so no memory blocks are re-assigned while still in the menu. The level is actually loaded after exiting from the menu.

The only reason why loading the game in the beta works when you have started a game (or have watched a demo) is that the memory manager seems to re-assign the buffers that were used for the old level and the sprites in that level before it re-assigns the buffers that the menu uses. While this seems to bypass the error under most circumstances, there is still a nonzero chance that things could go wrong.

In conclusion, had Jim Norwood changed his code to free the old music buffer(s) every time a new song was played, he would not have been forced to use the CA_SetAllPurge function when loading a level. And we might have gotten a Bio Menace release that included mid-level saves and would not run out of memory all the time (or at least less frequently). But in that case, we probably wouldn't have gotten the freeware release.

PS: If anyone wants to have a version with mid-level saves (and without memory leaks), let me know.

[NY00123]

OK, I've just added a few sprite offsets files to my repository (https://gitlab.com/N...1bda0b337d/misc).

To summarize:

- After renaming egagraph_sprite_shifter_offsets_MOD.txt -> egagraph_sprite_shifter_offsets.txt, you can view the partially corrupted sprites with the sprite shifter, using the *original* corrupted graphics' files. This refers to the EGADICT.BH1, ORIGINAL\EGAGRAPH.BH1 and ORIGINAL\EGAHEAD.BH1 files from Jul 13 1992.

- egagraph_sprite_shifter_offsets_ORIG.txt is actually the file on which the above is based. You'll have to remove 7725 bytes from offset 0x16308 of the corrupted EGAGRAPH.BH1 file. Why was this modified file originally used with the sprite shifter? Because this way, you could use it with the unmodified EGADICT.BH1 and EGAHEAD.BH1 files (from 1992) in order to partially recognize graphics in-game, and similarly export these graphics with ModId.

 K1n9_Duk3, on 23 August 2018 - 01:54 PM, said:

To prove that what I said above is true, I decided to write some patch scripts that allow you to save and restore the game at any point in the level (for the 1.1 freeware release of Bio Menace). While I was testing the patches, I also decided to investigate what causes the freezes when loading a game in the Bio Hazard prototype/beta.

Wow, it is great to see that you got these up! Are these intended to be used with BMxPATCH.EXE? Also, this is probably quite obvious, but I suppose the 32-bit far pointers are still written as-is, the same way it's done in Catacomb Armageddon?

Quote

As it turns out, the crash/freeze has abolutely nothing to do with the data that's being loaded and saved. Actually, the root cause of this issue is still present in the final release - and it might have been part of the reason why the game was discontinued and eventually released as freeware.

This is interesting. I already saw you writing about the music-related memory leaks in that other PCKF thread on Bio Menace (https://pckf.com/vie...?p=87624#p87624). I also recall having a few problems with these beforehand; It's possible I can see the reason now.

Thus, a call to CA_SetAllPurge was added as a workaround, only that it can lead to a hang if no game was started. And this might be a reason for the removal of mid-level saved game loading (and hence, the move to checkpoints), you're saying.

Question is, why weren't the memory leaks an issue in Keen 4-6, then. Maybe because no music is played in the menu? (A track is played in Keen 5's "Help" section, though.)

Quote

PS: If anyone wants to have a version with mid-level saves (and without memory leaks), let me know.

It probably won't hurt to upload a .PAT file's contents to somewhere, if you have the place for it, heh.

[K1n9_Duk3]

 NY00123, on 23 August 2018 - 02:40 PM, said:

Wow, it is great to see that you got these up! Are these intended to be used with BMxPATCH.EXE? Also, this is probably quite obvious, but I suppose the 32-bit far pointers are still written as-is, the same way it's done in Catacomb Armageddon?

Yes, I used BMxPATCH.EXE. The 32-bit far pointers are saved using the method I described earlier (subtracting & adding another segment from/to the segment part of the pointer). I tested this method in some other code and it worked perfectly fine, as in I could load the same file in DOSBox (with and without loadfix) as well as on actual hardware.

 NY00123, on 23 August 2018 - 02:40 PM, said:

Question is, why weren't the memory leaks an issue in Keen 4-6, then. Maybe because no music is played in the menu? (A track is played in Keen 5's "Help" section, though.)

Unlike Bio Menace, Keen 4-6 (as well as Catacomb 3-D) have a StopMusic function that stops the music and makes all music memory purgable. The function is also present in Bio Menace, but it's actually just an empty stub.

Here's my patch script for episode 1. I'll have to post the scripts for BM2 and BM3 later, since they're still missing the fix for the memory issues.
[attachment=13316:bm1_sav.txt]

By the way, I'm not happy with the 20+ kilobytes of memory that BMxPATCH uses. That makes it pretty much impossible to use the patches on actual hardware, due to the insane memory requirements of some of the later levels in BM1 and BM3. Is there a way to let BMxPATCH generate a fully patched standalone EXE?

Edit: By the way, is it possible that the 7725 bytes you removed from the EGAGRAPH.BH1 file were introduced when the game merged EGA1.BH1 and EGA2.BH1 into EGAGRAPH.BH1?

[NY00123]

Hey, I've briefly tried your patch now. Very great work, it really seems to do its job!

Interestingly, it even loads the original states of help messages to display; That is, it remembers, for each specific help message, if it was internally set as "shown". This also has an impact in case you later wish to start a new game, which is expected.

As for the color codes and more, I suppose this can be taken care of, if the relevant global variables are found, by modifying the gaming saving/loading routines (quite sure something similar is done for separate global variables in the Keens, or at least Keen 5). Maybe the help messages code pieces can be replaced.

Also, on the following comment from your patch:

- respawn coordinates are not saved, so Snake will respawn at the level
entrance when he dies after loading the game

I know this probably shouldn't be done, but I've briefly thought (as an evil joke) that maybe you can remove the checkpoints, and revert to Keen/BH's behaviors of a full level reload, ahaha.

Quote

Unlike Bio Menace, Keen 4-6 (as well as Catacomb 3-D) have a StopMusic function that stops the music and makes all music memory purgable. The function is also present in Bio Menace, but it's actually just an empty stub.

Hmm, it's possible it became an empty stub since it was mistakenly assumed to become redundant, with music playing for all time.
Not surprisingly, this is also the case in the BH prototype (the function preceding StartMusic is an empty stub).

Quote

By the way, I'm not happy with the 20+ kilobytes of memory that BMxPATCH uses. That makes it pretty much impossible to use the patches on actual hardware, due to the insane memory requirements of some of the later levels in BM1 and BM3. Is there a way to let BMxPATCH generate a fully patched standalone EXE?

Yeah, I think this is a concern I already heard or thought about beforehand; Especially since a few later (unofficial) revisions of BMxPATCH may actually be a bit larger in size.

I don't think BMxPATCH can do what you're asking for, at least not directly. "%dump exeimage.img" can be used to dump an image of the EXE, with all preceding patches applied; However, this also has all segment pointers corrected, based on the EXE's relocation table.

I think it's possible to modify CKPatch to more-or-less get rid of itself, by behaving somewhat like that internal UNLZEXE stub; That is, load the EXE to memory, patch it, move remaining used CKPatch code past the EXE, push the EXE back, remove more unused CKPatch code (and possibly do other clean-ups) and then finally jump to the EXE's starting point.

Ignoring other technical hurdles with the above, though, there's also this one specific issue. CKPatch has a alternative int 0x21 handler for file redirection, in REDIR.ASM:Int21Handler. This can be used for changing certain filenames, e.g., "%gamemaps custmaps.ck4" for Keen 4. I'm not entirely sure why was this added instead of merely patching the file names. Maybe since this makes it possible to use longer file names?

Either way, this is a piece of code that will probably have to remain in memory, at least for compatibility with existing patches (and only if actually used).

Quote

Edit: By the way, is it possible that the 7725 bytes you removed from the EGAGRAPH.BH1 file were introduced when the game merged EGA1.BH1 and EGA2.BH1 into EGAGRAPH.BH1?

This is actually a good question. Afraid this isn't related, though. For any comparison in mind, I took _1galaxy.zip and then unpacked the files with K4E1-ASP.EXE and K4E2-ASP.EXE. These included a 400000-bytes long EGA1.CK4 and a 120581-bytes long EGA2.CK4, respectively.

As previously stated, most graphics can be recognized, even if there are corruptions. While I mentioned the sprites beforehand, the situation is even better with the 16x16 tiles, for instance. Only a few of the unmasked 16x16 tiles have corruptions, and it's otherwise clear they're all the same as in BM2. As for the masked tiles, some of the very last tiles (the ground/trees/ship in the very beginning of BH1/BM2) are missing, since they're technically out of the bounds of EGAGRAPH.BH1. However, according to EGAHEAD.BH1, the same tiles are marked as "empty" (i.e., no tile data) as in BM2, and again I'm almost sure there was no change to the graphics.

[K1n9_Duk3]

 NY00123, on 23 August 2018 - 11:31 PM, said:

Hey, I've briefly tried your patch now. Very great work, it really seems to do its job!

Interestingly, it even loads the original states of help messages to display; That is, it remembers, for each specific help message, if it was internally set as "shown". This also has an impact in case you later wish to start a new game, which is expected.

As for the color codes and more, I suppose this can be taken care of, if the relevant global variables are found, by modifying the gaming saving/loading routines (quite sure something similar is done for separate global variables in the Keens, or at least Keen 5). Maybe the help messages code pieces can be replaced.

Thanks for the kind words.

The variables that indicate which help messages have already been displayed are part of the gamestate struct, so they are saved automatically along with the score and everything else. The same applies to the Keen 5 as well, I guess. The other variables that would probably need to be saved are scattered all across the data segment and I'm not sure if there are enough unused bytes left in my patch that would allow me to add code to read and write them as well. And the variable that stores the state of the colored switches is actually reset to 0 at the beginning of the GameLoop function, so it would be reset even if it was loaded from the saved game. I can't just remove that command, because that would mean the variable wouldn't be reset when entering a new level.

I'm not quite happy with the fact the patch makes the old saved games unusable. I might add some code to make the saved games compatible. By the way, any games saved with the patch applied will still work in the original (unpatched) version of the game.

 NY00123, on 23 August 2018 - 11:31 PM, said:

Also, on the following comment from your patch:

- respawn coordinates are not saved, so Snake will respawn at the level
entrance when he dies after loading the game

I know this probably shouldn't be done, but I've briefly thought (as an evil joke) that maybe you can remove the checkpoints, and revert to Keen/BH's behaviors of a full level reload, ahaha.

That would be easy. And it reminds me of something else I wanted to mention. As you might remember, E2L4 (Ant Town) starts with a series of falling blocks that you need to jump on in order to progress. If you die, you respawn at the beginning, but none the blocks respawn, making the level unwinnable. As it turns out, the final release still has code in it that will cause the game to reload the entire level if you die but haven't reached a checkpoint yet. With this system, E2L4 wouldn't become unwinnable (at least not right at the beginning). But the code that spawns the player object marks the starting location as a checkpoint, so the code that reloads the level will never be executed.

This (marking the starting location as a checkpoint) looks a lot like a last minute change in an attempt to make the game less difficult. And nobody noticed that it broke E2L4, a level that was basically finished over a year before the game was released.

[Frenkel]

Is the in store demo mode also in this beta?

 K1n9_Duk3, on 11 August 2018 - 02:16 PM, said:

While playing the beta on easy difficulty, I noticed that the ammo pickups didn't give me any ammo. It works fine on normal difficulty, though. Probably another one of the many bugs in this beta.

I noticed that too, but at the later levels it somehow worked sometimes.

[K1n9_Duk3]

 Frenkel, on 28 August 2018 - 11:57 AM, said:

Is the in store demo mode also in this beta?

The code that would limit you to this special mode is already/still there (I was told by levellass that this code was most likely inherited from Keen 4-6, where this mode can be activated via the -DEMO parameter). But Bio Menace (beta and final) doesn't recognize the -DEMO parameter. There is no code that would set the variable to 1, same as in the final releases of Bio Menace.

The only time I got any amoo from a pickup was when I started a new game and picked up a clip without firing a single shot before picking it up. The thing is that the game will only give you ammo when your current ammo count is <= 0. But on easy dificulty, the game always gives you 3 shots if you have no ammo when you start firing, which means you can't use any of the clips you pick up. This was changed in the final release so that you load one of the clips when your ammo count is <= 1, which also explains why you never get to shoot a plasma bolt when you only have 1 shot left.

By the way, I ended up writing my own tool to apply CKPATCH-style patch scripts to 16-bit MS-DOS executables. This actually helped me a lot while I was finishing up my patch scripts for Bio Menace.