Wolf3d Haven Forum

Please log in or register. Smile
Wolf3d Haven Forum

A friendly Wolfenstein 3D community, about Wolfenstein 3D, the game that gave birth to first person shooters...


    Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Share

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Sat Apr 18, 2015 8:31 am

    UPDATE (Dec 25th 2015): This is a generic notice stating that this post does not have to be edited after any update to the repository or this topic; And so, possibly mentioning in this post for the last time, the update for today is the addition of versions 1.0 and 2.0 (1 and 6 episodes releases) of Blake Stone: Aliens of Gold.

    UPDATE (August 28th 2015): The "wolf3d" subdirectory has been renamed "w3d_plus", now that the same codebase can be used to recreate (ignoring debugging information differences) the EXE for the DOS port of Super 3-D Noah's Ark, v1.0. The same applies to the .diff file. Other than this edit, I haven't touched the original post.

    UPDATE (June 27th 2015): Blake Stone EXEs can be recreated as well now, with another post added to here on this topic. To summarize, versions 2.1 and 3.0 of Blake Stone: Aliens of Gold, Shareware and Registered, as well as versions 1.00 and 1.01 of Planet Strike, can be rebuilt using Borland C++ 3.1 and LZEXE 0.91. The rest of this post is untouched.

    Hey there, I think it's a good time to link to the following repository (you may be interested in the "wolf3d" subdirectory): https://bitbucket.org/NY00123/gamesrc-ver-recreation/

    The topic's description should briefly tell what is this, so it may be good to tell how did I get to all of that.

    Back in September of 2014, following a campaign to acquire the rights to publish the "lost" episode of Commander Keen known as "Keen Dreams", original sources for this episode were made available. These include sources not just for one, but apparently all versions of Keen Dreams originally made in the 90s for DOS, with the possible exception of 1.93 (which isn't that different from 1.92 anyway and could also be reconstructed).

    It looked to me like the sources were in a relatively good state, and that the released forms were not greatly different from the originals. It's also stated that Borland C++ 2.0 was originally used to build the EXEs, and it also looks clear that a lot of the EXEs were originally packed using LZEXE 0.91.

    Therefore, I decided to have a little attempt, using Borland C++ 2.0 and LZEXE 0.91 to build and pack version 1.13 (Shareware release). Turns out, I got the exact same EXE as created in 1992, byte-by-byte. I also got such results with at least a few other versions.

    This looks like the main motivation behind starting the "gamesrc-ver-recreation" repository above (although originally under a different location). I think that initially, I wanted to try and recreate the Catacomb Abyss v1.13 EXE. Eventually, this followed with the Catacomb 3-D v1.0 EXE and the Catacomb Abyss v1.24 EXE. To compare, the Catacombs sources as released on June of 2014 can be used to build the Catacomb 3-D v1.22 EXE, as well as an EXE *very* close to Catacomb Abyss v1.24. However, for some reason, in order to get exactly the original v1.24 EXE, STARTTILE8 has to be edited in GFXE_ABS.EQU, but not in GFXE_ABS.H (there's some function in ID_VW_AE.ASM which shouldn't be called but is compiled into the EXE, for which this has an effect). The exact same edit is also required for recreation of the v1.13 EXE.

    Eventually, I decided to fiddle with the Wolf3D/SOD sources for similar purposes, gradually adding projects for recreation of certain EXEs over time. With a few exceptions, the right tools can now be used to build original EXEs from the sources above, byte-by-byte. The EXEs I refer to are these:
    - Wolfenstein 3D Shareware v1.0+1.1+1.2+1.4, Apogee releases (with cheats).
    - Wolfenstein 3D Registered v1.1+1.2+1.4, Apogee releases (with cheats).
    - Wolfenstein 3D Registered v1.4, early GT Interactive release.
    - Wolfenstein 3D Registered v1.4, ID Software release (same EXE as in the early
    GT Interactive release, except for a different logo in the signon screen).
    - Wolfenstein 3D Registered v1.4, late GT Interactive release
    (no three-letter code is shown after completing an episode).
    - Wolfenstein 3D Registered v1.4, Activision release.
    - Spear of Destiny demo v1.0, FormGen release.
    - Spear of Destiny v1.0+1.4, FormGen releases (copy protected).
    - Spear of Destiny v1.4, Activision release (no copy protection).

    It should be noted that the original SOD v1.0 EXE, as well as the originally released Activision EXEs (as currently available from Steam), appear to be a bit different. The former has the "LZ91" string from its first 32 bytes replaced with NUL bytes, while the latter two have "shifted" LZEXE signatures. In addition, the very beginning of the SOD v1.0 EXE has a couple of bytes differing from what you may currently get from the sources, implying an increased so-called "BSS section". The STRIPBSS tool included in the same repository wasn't made with this in mind, and I'm not sure about this. However, apparently it was very common to use modified EXEs in which the copy protection is skipped or removed, and this may further add some confusion.

    There are also a few EXEs which are *not* reproduced by any project above, and there are great chances they won't be (but at least we have all of the above!):
    - A release of SOD v1.4 made for FormGen, mistakenly labelled as v1.0 in the signon screen. (If it's just the v1.4 FormGen EXE, but with another signon screen, then it should be relatively easy to recreate it now.)
    - Any translated release.

    Unfortunately, there aren't exactly tools I'm aware of that can automatically compare two EXEs from different revisions of very similar source codes, given the EXEs and one source code revision as an input. Hence, the differences had to be manually located. There are still enough ways to ease the work, though. Obviously disassemblers can be used so we don't have to look just at machine code. Furthermore, Borland C++'s linker can generate a MAP file that shows the locations of most functions and variables in the EXE (as segment:offset pairs).

    It's not just a matter of modifying the C/H/ASM/EQU files themselves, though. Project settings (like optimizations) had to be guessed for at least 2-3 projects, the ordering of a few source files to had to change in certain projects, there are files that should be removed from some projects (possibly most), and the GAMEPAL data has to be linked in different ways for different projects (either into its own segment, or as a part of the data segment).

    Finally, these are still not exactly the original revisions of the sources, since we don't have access to them. However, what can be done now, is telling differences between versions as expressed in the compiled EXE files (e.g., the differences in secret elevator handling between Shareware versions 1.1 and 1.2, although these were basically known for a while).


    Last edited by NY00123 on Fri Dec 25, 2015 10:14 am; edited 3 times in total

    stathmk
    Hardcore Wolfer
    Hardcore Wolfer

    Male
    Number of posts : 1403
    Age : 36
    Location : Indiana, United States
    Job : fast food worker & wolfensteingoodies.com webmaster
    Hobbie : old games & young dames
    Registration date : 2008-04-08

    I've gotten your message.

    Post by stathmk on Thu Apr 30, 2015 7:37 pm

    I've gotten your message. Just email me at stathmk (at) yahoo (dot) com because my Wolf3D Haven inbox is almost 100% full. In the message tell me what username you want to use for Diehard Wolfers and what email address you will be using. This is so that I can have Tricob or somebody whitelist it.

    I've heard that it's areyep.com (RIP) because the South African webmaster is a family member or relative to a band member of Areyep (RIP). It's been so many years that I don't remember exactly where I've heard of this.

    Webmaster Brian of wolfenstein3d.co.uk has Parkinson's and doesn't type much anymore. We wish him the best. Do a search for Ersatz Wolf3d Dome News in the Diehard Wolfers Forum to find Andy's post of mods. For no apparent reason, Andy stopped posting in February. I hope that he's doing well. So until Tristan becomes the webmaster of wolfenstein3d.co.uk, then email your finished mods to me. I need to post them on wolfensteingoodies.com. Hopefully I'll post 2 every Sunday. I have a backlog of files.

    On May 5, Wolfenstein: The Old Blood will be for sale. I understand that it's a prequel to Wolfenstein: The New Order and takes place in the parallel universe timeline where it's 1946 and the Nazis still haven't lost. While in reality, Hitler killed himself on April 30, 1945. So maybe it's a parallel universe where the war continues on anyways after Hitler's death?

    I need to comment another day about Wolf3D/SOD Exe versions restoration.

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Fri May 01, 2015 1:08 am

    Heh, thanks for your reply. I shall do as you've suggested. As you've probably guessed or seen I'm not really that familiar with the differing Wolf3D-related communities/websites, at least not as much as others.

    I've heard, though, that basically the admin of DHW (if not someone else) seemed to lose the interest and/or move on to other things, which should be a natural progress that tends to occur to a lot of individuals. I know it's kind of similar with pckf.com and keenmodding.org; I think that these days, while you may be able to create an account over any of these Keen-related forums, you need to wait for a moderator who's also able to activate new accounts, and I'm not sure how active are they these days (but at least one of them seems to be reading posts). The original admin of the sites, who also, naturally, seemed to move on, still took care to let the forums be up in a few occurrences they stopped working, though. (As a side note, my PM inbox at pckf.com is also quite full nowadays. Just a side-note, though.)

    I also did heard the story about Brian Lowe. I guess one thing I can say for now is to hope for better.

    Also, if this is what you mean, I'm afraid I don't really have any Wolf3D mod of mine to submit. The closest to that which I worked on is weirdly the "versions restoration" stuff.

    Finally, it's interesting to see Tricob mentioned given that a related topic has already been started on DHW, in which he's replied: http://diehardwolfers.areyep.com/viewtopic.php?t=7098

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Sat Jun 27, 2015 5:40 am

    Bump.

    There is another update to the repository that at least some of you may be interested in. But first, while working on it, I think that I finally figured out how to strip the BSS segment (a bunch of zeros) from the end of an EXE file right from Borland C++, without using the STRIPBSS tool that you may find in the repository itself. Turns out you should open the Debugger settings window from Options -> Debugger, and then select "On" for "Source Debugging". I looked for a way to strip the BSS segment before and somehow didn't think to try here...

    Note that I haven't yet changed the relevant Wolf3D projects to take this into effect. But there's the other update that I've briefly referred to. I've just added a new "bstone" directory today, with the restoration of some Blake Stone versions. This also includes Aliens of Gold. The exact versions that can be rebuilt are these:
    - Blake Stone: Aliens of Gold v2.1+3.0, Shareware and Registered releases.
    - Blake Stone: Planet Strike v1.00+1.01.

    Like the way I grabbed and modified GFXV_APO.H from Wolf4SDL by Moritz "Ripper" Kroll, for the restoration of Wolfenstein 3D Apogee EXEs, I used GFXV_BS1.H definitions from the bstone port by Boris Bendovsky. I also "borrowed" a few song definitions in the very beginning from the same port. Regarding AOG restoration in general, most of the source code recreation was done using earlier research work by Braden Obrzut.

    Not remembering a lot from the two Blake Stone games, I thought that I may encounter quite large differences and a lot of code pieces removed. Turns out this wasn't really the case. 3D_MAIN.C has a couple of AOG-specific functions related to player alignment, and the AOG implementations of ShowOverhead and InputFloor have great differences from the PS implementations, but a lot is really the same. There are also a few commented out AOG-specific code pieces in the released Planet Strike sources, like Vital sprite definitions. Interestingly, there are at least a few occasion in which AOG-specific line codes apparently has different indentation (when compared to similar codebases). Furthermore, this is probably known, but it looks like the vital was "transformed" into the rotating cube during the development of Planet Strike.

    As expected, though, I think that Planet Strike was started as a separate branch even before Aliens of Gold v2.1 was released. As a hint of that, the implementation of CA_LoadAllSounds in Planet Strike is the same as in the Catacomb 3-D sources, while there are minor edits in Aliens of Gold (at least in versions 2.1 and 3.0).

    Guest
    Guest

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by Guest on Wed Jul 08, 2015 8:31 am

    .


    Last edited by    on Tue Aug 04, 2015 7:08 pm; edited 1 time in total

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Wed Jul 08, 2015 9:03 am

    Hey there, thanks for your interest in the restoration of the few games' versions!

    Have you taken a look at Aliens of Gold v1.0? The shareware version can be found here and the registered version can be bought on ebay for $11.50. I think we will find the differences interesting (like how they managed to go from 591K to 540K). To tie your two posts together: It looks like all versions of Aliens of Gold and Planet Strike use Wolfenstein v1.2 as a base, not v1.4. I first noticed this when I changed the Screen Size and it still said "Computing" instead of "Thinking". Smile

    I haven't looked at any version of Blake Stone other than the ones you may recreate now.
    It's good to see you finding a reference Wolfenstein 3D version. One thing I'm still a bit confused about is the implementation of VL_WaitVBL. You can see that for the restoration of the versions, I modified VL_WaitVBL as found in ID_VL_A.ASM to be the same as the WaitVBL function from WAITVBL.ASM. However:
    - There are commented out reference to WaitVBL in ID_VL.C. All other mentions refer to VL_WaitVBL or VW_WaitVBL.
    - Except for this, and ignoring the different compilation time and date (originally embedded into the EXEs using the __TIME__ and __DATE__ macros), the sources as released by Apogee Software, LLC were used as-is to recreate the Planet Strik v1.01 EXE. Furthermore, just about a couple of edits were required in order to recreate the Planet Strike v1.00 EXE (look for mentions of GAMEVER_RESTORATION_ANY_LATE in the current revision of the recreated codebase).
    Hence, it isn't clear if the implementation of VL_WaitVBL in ID_VL_A.ASM was actually edited at any point. Maybe some symbol/object-code shuffling was done, but these are really just guesses.

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Fri Aug 28, 2015 6:50 am

    POST EDIT: Just made a minor correction spotted by Blzut3 (had a misleading mention of SNES texture/sprite size, which may really apply to the Jaguar and Mac versions of Wolf3D).

    All right, I think it's time for another update:

    - To begin with, please note that the "wolf3d" directory has been renamed "w3d_plus", for a reason that should be quite obvious very soon. Similarly, the wolf3d.diff file has been replaced with w3d_plus.diff.
    - For each project you previously had to use STRIPBSS, there's no need to anymore. While working on Blake Stone, a way to strip the BSS section right from Borland C++ was found: Disabling the addition of debugging information to the EXE.
    - As in the Blake Stone tree, PREP.BAT can now be used for making a clean up, before a project is built in w3d_plus.
    - The most significant update, though, is the recreation of code for the DOS port of Super 3-D Noah's Ark, a title which many may consider a Wolfenstein 3D mod with changes.

    Now, there's enough to tell about Super 3-D Noah's Ark (i.e., S3DNA) which differs from previous restoration efforts. I should begin with a little introduction, being that S3DNA was originally released as a SNES title, using the SNES port of Wolfenstein 3D as a base. The latter port, known to belong to the so-called Mac Family of Wolf3D ports, has some clear differences from the original DOS title. These include variable-length episodes, enemies appearing to face the player for all time, two additional weapons (flamethrower and rocket launcher) and generally a different storyline and somewhat different maps. The SNES version also had some censoring.

    As said before, S3DNA was started as a SNES game based on the port above. The original DOS codebase was then used as a base for a DOS version of S3DNA. It is more similar to the SNES version than the DOS and SNES versions of Wolf3D are, though. For instance, the two versions of S3DNA let you use an auto-map, and there's an arsenal of up to 6 feeders (weapons), including hand feeding. The most technically significant addition to the DOS version, though, may be MIDI music playback (still via an AdLib or Sound Blaster), using what appears to be the MIDI data from the SNES version.

    Now, according to Braden Obrzut (aka Blzut3), developer of the ECWolf port of Wolfenstein 3D, which is also used as a base for a new commercial port of S3DNA, unfortunately the original source code for S3DNA is assumed to be lost. However, I figured out that S3DNA isn't that different from Wolf3D in many ways. In fact, it feels much more like Wolf3D than the Blake Stone games may be. For instance, it's now clear to me that each animal in S3DNA is basically just one of the Wolf3D enemies with a few changes. There are still some modifications, the largest possibly being the MIDI code, but otherwise it's more-or-less the same. And so, the recreation of the EXE has started.

    It may be a good chance to tell that a disassembler known as IDA Pro has been in use (there are a few versions which can be used for free for non-commercial purposes). While it does not translate the code in the EXE back to readable C code, it can still be useful for many purposes, like an initial automatic analyzing of the code, locating functions, variables, string literals and more.

    One thing it can't seem to do (at least the version in use), though, is reading debugging information appended to the original S3DNA EXE. I've decided that I initially skip this and make sure the actual code and data match with the original, which is most of the work (and further the practically interesting part) anyway, and also what I've been familiar with. Some earlier research work done by Blzut3 has also been very useful.

    Let's take one step back. Debugging information? That's right, not only the original S3DNA EXE is not an EXE packed with anything like LZEXE, it still has intact debugging symbols. This includes names of functions, almost all variables and even some enum definitions (probably as long as there's a variable of the given enum's type mentioned somewhere). As said above, though, I've initially skipped these. Only towards the end, having a little problem in the compiled MissileTryMove function, I've decided to start the Turbo Debugger and inspect the function. Turns out, while the original sources may be lost, the EXE still has line numbers information. Surprisingly enough, splitting an "if" expression with an "&&" operator into 2 lines has solved the issue, and I've finally gotten the exact same EXE image as the original (ignoring the debugging stuff).

    Afterwards, I've figured out that Turbo Dump can be used in order to dump the debugging information in a somewhat more readable way. The -v argument may be used control the way the output appears to be. With the help of this, and by comparing the output of the original EXE with a recreated one's output, I've assigned names used in the original codebase to all functions and almost all of the variables, as well as some enum values (in case of differences in the TDUMP outputs). There are very few (local) variable names which may be missing, but it isn't a great deal.

    There are still a few differences in the Turbo Dump outputs, mainly with some type symbols. Missing function prototypes may be one cause, while there can be more. However, given that the actual EXE image has been successfully recreated, and original symbol names are now in use where found, I think this can be sufficient for now.

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Wed Sep 23, 2015 12:46 am

    ok, this is more like a minor side note, but did anybody notice that some of the Noah tunes play in the DOS version with different tempos, compared to other versions (including the ECWolf-based re-release)?

    Code:
    diff -r 789c61553acd w3d_plus/ID_SD.C
    --- a/w3d_plus/ID_SD.C Fri Aug 28 16:36:20 2015 +0300
    +++ b/w3d_plus/ID_SD.C Wed Sep 23 00:40:22 2015 +0300
    @@ -2126,9 +2126,9 @@
    {
    case 0x51:
    length = MIDI_VarLength();
    - tempo = ((long)(*midiData)<<16) + (long)((*(midiData+1))<<8) + (*(midiData+2));
    + tempo = ((long)(*midiData)<<16) + ((long)(*(midiData+1))<<8) + (*(midiData+2));
    midiTimeScale = (double)tempo/2.74176e5;
    - midiTimeScale *= 1.1;
    + //midiTimeScale *= 1.1;
    midiData += length;
    break;
    case 0x2F:

    A directory with the same patch, an EXE built after applying the patch and the following description may currently be found in the w3d_plus/MISC subdirectory of the same repository: https://bitbucket.org/NY00123/gamesrc-ver-recreation/src/a57d87f5102aa9f378fefdbdf55d6160c37e9277/w3d_plus/MISC/?at=default

    What I think that happened is this: Originally, the cast to long for the middle byte was done in the wrong place, leading to an integer overflow in case *(midiData+1), an unsigned 8-bit byte, had the value of 128 or greater. While (*midiData+1) may internally be casted to int, a 16-bit signed integer in this case, for the shift by 8 bits to the left, this isn't sufficient for the later cast to long, since a sign extension is done here.

    Example: if (*midiData+1) is, in binary, the value of 11000100b, then after shifting we get the 16-bit value of 1100010000000000b. By casting from a 16-bit SIGNED int to a 32-bit signed long int (i.e. doing a signed extension to 32-bit), we get the bit pattern of 11111111111111111100010000000000b. This is not the expected result, though, as it should've really been just 0000000000000000100010000000000b stored in a long int.

    The multiplication of midiTimeScale by 1.1 is probably an attempt to get the correct tempo, at least for certain musical tracks, as the actual cause of the bug was apparently not found back in the 90s.

    Obviously this isn't exactly in the goal of recreating original EXEs' behaviors, including all quirks, but it may still be a bit relevant since this is a minor modification of the recreated S3DNA sources.

    NY00123
    Freshmen
    Freshmen

    Number of posts : 10
    Age : 28
    Registration date : 2015-04-14

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by NY00123 on Fri Dec 25, 2015 10:11 am

    Hi again,

    I think Dec 25 may be a good time for an update!

    This time, it's about Blake Stone: Aliens of Gold again. With the possibility of a few really minor differences, you can now recreate the EXEs from the 1 and 6 episodes releases, versions 1.0 and 2.0.

    To begin with, it's probably not a surprise that version 2.1 has very few differences from 2.0 in terms of code. The chunks definitions as given in GFXV_BS1.H are exactly the same for these. If I haven't missed anything, I think these are all of the differences in the code:
    - The addition of destPath/tempPath handling.
    - The new GS_TAB_ROTATED_MAP flag (you can decide if Tab shows a rotated map in-game, or Shift+Tab).
    - The "flags" field of the gametype struct was changed from an unsigned to a long. By the way, this field's type is still unsigned in Planet Strike.
    - Misc. changes in GetNewActor and PlayLoop (3D_PLAY.C).

    Now, it's version 1.0 where things changed more significantly. I don't see myself bothering to list all of the differences, but I'll give a few examples, one of them possibly being the most significant. Let's begin with simple cases:
    - Some ID_SD.C code was moved to JM_FREE.C, before being relocated back to ID_SD.C for v2.0. I really have no explanation for this.
    - A few bits of ID_SD.C are closer to code from the Wolfenstein 3D sources in v1.0. This also applies to at least 3D_DRAW.C function (ScalePost).
    - If you check out ID_PM.C from the released Wolfenstein 3D sources, or JM_FREE.C from the Planet Strike sources as originally released, you should find two mentions of the comment "AJR: bugfix 10/8/92" in PML_StartupXMS. While recreating different version of Wolfenstein 3D, I found out this was fixed before making any release of Wolfenstein 3D or Spear of Destiny with version number 1.4. Looks like this was similarly applied in-between versions 1.0 and 2.0 of Blake Stone: Aliens of Gold.

    One known difference between versions 1.0 and 2.0, is that 2.0 requires less memory (required amount changed from 605k to 580k and then to 540k): http://litude.webege.com/apogee/version/blake.html#Version_2.0

    It probably sounds a bit too silly to think that modifying the value of MIN_MEM_NEEDED is all that was needed: https://bitbucket.org/NY00123/gamesrc-ver-recreation/src/b899fb1e19a7bedc7bd037c8d18d7d724fd5e438/bstone/3D_DEF.H?at=default&fileviewer=file-view-default#3D_DEF.H-63

    In this case, I think that 3D_SCALE.C may have the answer. Between versions 1.0 and 2.0, 3D_SCALE.C was mostly rewritten (possibly along with some related code pieces). In fact, for the recreation of v1.0, I simply copy-and-pasted WL_SCALE.C from the Wolfenstein 3D sources and modified it as required.

    It should be known that version 1.0 missed some features, like the way lighting is done in later version. This is also a good explanation for differences in performance: v1.0 may feel much smoother than v2.0 and later on a given machine, unless you disable the lighting. That may be one reason for the changes to 3D_SCALE.C; I don't know.

    But there's also the following point. Anybody sufficiently familiar with the Wolfenstein 3D codebase, or at least WL_SCALE.C, should be familiar with the function BuildCompScale, which is responsible for generating scaling code in runtime. It's called as a part of a chain of function calls NewViewSize -> SetViewSize -> SetupScaling -> BuildCompScale on certain occasions, like changing the view size during gameplay. BuildCompScale is used in Wolfenstein 3D and AOG v1.0, but is not used in later releases of Blake Stone games. I can't say I get all the details, but it clearly feels like a rewrite to me.

    To the few who may wonder: According to http://litude.webege.com/apogee/version/blake.html, versions 1.0 and 2.0 were also released as 3-episodes forms. In the case of Wolfenstein 3D, the 6-episodes EXEs were known to be shared. For each original 3-episodes build of Blake Stone: Aliens of Gold, I *guess* that MAPTEMP_CHECKSUM is all that's different from the value for the corresponding 6-episodes build. I can't say this for sure at the moment, though.

    One final note: By looking at GAMEVER.H (or even just the raw EXEs, at least after unpacking), you can find out the 1-episode v1.0 EXE was built one month before the corresponding 6-episodes EXE. As expected, there are a few changes in the code between these versions (currently you may find these by looking for mentions of GAMEVER_RESTORATION_BS1_100), but these are really just a few.

    Sponsored content

    Re: Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

    Post by Sponsored content Today at 12:19 pm


      Current date/time is Thu Dec 08, 2016 12:19 pm