DieHard Wolfers Forum Index DieHard Wolfers
A Wolfenstein 3d Fan Community


  Hosted by: MCS & Areyep.com - Designed by: BrotherTank

Original Yahoo Forum - Die Hard Archives

AReyeP HomepageAreyep Homepage DieHard Wolfenstein BunkerDieHard Wolfenstein Bunker Log inLog in RegisterRegister Banlist FAQFAQ Search ForumsSearch

  Username:    Password:      Remember me       

Restoration of other Wolf3d/Spear EXE versions
Page 1 of 2 Goto page 1, 2  Next
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page BottomView Next Topic
Post new topicReply to topic
Author Message
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 14 Jun 2018

Topics: 55
Posts: 2132
Location: Canada
blank.gif

PostPosted: Sat Apr 25, 2015 11:18 pm
   Subject: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Next PostGoto Bottom of Posts

A member of Wolf3d Haven forum, NY00123, managed to expand the source code to include almost every official version of Wolf3d and Spear (Registered and Shareware) which you can now compile for, exactly, byte-for-byte:

http://wolf3d.darkbb.com/t3302-wolf3d-sod-exe-versions-restoration

If you've ever wondered why something behaved differently in another official exe version, or all the changes in the exe between versions, or just wanted to compile an exe with all the behavior of a specific version (ie. Wolf3d Shareware v1.0) to play around with, it's now much easier, as all the changes are in readable C format and defines. I successfully built WL6APO12.PRJ (Apogee v1.1 Registered) exactly the same as original 98402 byte exe following the instructions, and can confirm that it works. Very Happy

Since my first few years of playing Wolf3d were with Apogee v1.1 Registered, I have a lot of fond memories with that version, and I've always dreamed of knowing what was inside that mysterious exe! The wolf3d.diff file gives a nice list of the code differences.

Some areas I found interesting in it so far:

1353 - v1.1 uses a different version of VBL_Wait. It doesn't give me the flickering gray screen bug, which plagued Spear and v1.4 in real DOS on most of my post-2000 laptops. I'm still getting 70fps in v1.1 so it doesn't seem to have any drawbacks here yet, unless you like the "fancy smoother fadeouts" in Spear/v1.4. Replacing the v1.1 version with the v1.4 one does bring back the problem! I'm pretty sure Operation: Bodycount uses the v1.4 version because it flickers too... now I'm curious to see which one Blake Stone and Corridor 7 use (or if they use something else entirely).

1668 - It's the "boss being able to open the door while BJ is doing his victory run/jump" in the Angry German Kid vs. Wolfenstein video (which seems to be an v1.0 exclusive feature, as I suspected), and explains (maybe) one reason why the author of the video switched to Mortal Kombat Wolf half way through (because it uses v1.0 Shareware as a base) to accomplish this trick. Mr Green

1710 - Lots of unneeded Spear data and code was compiled into Wolf v1.4, but not v1.1 (because v1.1 was released before Spear). Because of this, and because v1.1 didn't add the WOLFHACK files yet and it put the gamepal in a different segment, v1.1 starts you off with 2757 bytes free near memory (instead of the measly 83 in v1.4 which led to the existence of this thread).

2151 - In v1.4, there is the frozen bosses bug, which even affects many bosses in the original game because Hans is in E6L10 at three different places, Fatface and Giftmacher can be approached from different angles, and Fake Hitlers are encountered from all directions! This code shows how v1.1 avoided the problem, by using the same dir*2 code as the guards. The funny thing is, "dir" is never passed from ScanInfoPlane to SpawnBoss, so what number is dir in v1.1? In my tests with Hansel and Gretel, dir is 64 (possibly from *map?), and 64*2 is 128, which is not even a valid dirtype enum (0-8, nodir being 8...), yet somehow bosses react from all angles in v1.1 with "out of range" numbers. I'm not sure if they react better this way than with nodir, the same, or worse though. Surely, ID must have known that weren't passing a dir, and understood (and possibly controlled) what was going on internally to make it work, or it was just a fluke coincidence that it worked in v1.1? Laughing

2939 - This code explains why the "death spin" doesn't point to some enemies in v1.1 after they kill you (like dogs in T_Bite here), which is a bug I remember Tricob mentioning here. Since ob is never passed to TakeDamage in this code, when it calculates the ob->x and ob->y for who to point BJ towards, it won't even have the values for that enemy.

3088 - In v1.1, a 7-digit score will still show up on the status bar, but in v1.4 it won't, because of this added code.

4394 - Case 71 on E1L3 didn't bomb the game in a v1.1 exe (only v1.4) because it wasn't added yet.

4425 - Mutants set to Patrol in v1.1 just stand still. Maybe this is why Bill Kirby never bothered to add code for objects above 255 in early Mapedit versions.

4836 - Seems like they forgot to /70 ? Now I'm curious to see how high my total time can be in Shareware v1.0-1.1. Very Happy

4916 - Have you ever noticed, that the right edge on the PC13 screen in v1.1 is still red?

4973 - v1.0 uses actual TimeCount (70 per second) for par times, so using floats and dividing by 4200 wasn't needed. Interesting.

5491 - I didn't know that ratios after level 8 saved in any version of SOD (v1.0 or 1.4), but it looks like they do in SOD Activision v1.4.

6227 and 6312 and 6447 - In v1.1, you could actually "Save the Demo" by dying your last man, or hitting End Game or F7, then waiting for the demo to load, then pressing Esc and the "Save Game" option would still be available (you could also save your game as a dead BJ this way too). Together, these three lines of code seem to be what stop you from being able to pull this trick in v1.4.

7317 - This pwallstate=0 code made me realize something: the moving pushwall makes the wall free when you die in v1.4 seems to be fixed in v1.1, same with the moving pushwall keeps moving into the next level bug in v1.4. I tried removing this pwallstate line and it's still fixed in v1.1 though, so perhaps there is something else... somewhere... that makes this already reset correctly in v1.1, but not in v1.4.

7500 - It's the gliding guards bug from Spear and v1.4, already fixed in v1.1! Hahah, + 1 indeed. The first place I noticed this bug was in Spear actually, because I had v1.1 and Spear before I even knew about wolf v1.4. I'm guessing they switched to US_RndT() in v1.4 because they realized their v1.1 demos were not consistent in this area, and they forgot to add the +1 back in. One funny thing is that the demo for Spear Level 6 (at least in my versions), the "gliding guard" is completely obvious, there's no way you can miss it if you watch that demo! I don't think ID added the bug after they made the demos, because then the demos wouldn't sync correctly, so it seems that they must have noticed the problem, and just didn't know where to look to fix it when they introduced it into Spear and v1.4? What?

7703 - The enemy shows shooting frame when getting shot bug (pointed out by Architect) in v1.4 doesn't happen in v1.1, because it already used Adam's solution to the problem, interestingly. It looks like ID added the hitpoints&1 line forgetting they they already had the rotate 2 version. I think that's 8 bugs now I pointed out that were introduced in v1.4 and Spear that were not in v1.1! Laughing

7986 - Hurr hurr, this SPDPATROL*3 in v1.4 changes nothing. Must have been added as a test. Ok, I'll stop beating this dead horse (v1.4) now... Mr Green

I'm still playing around with it though. Lots of stuff to uncover. Feel free to post anything you found interesting as well.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sun Apr 26, 2015 8:58 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

In which version did they finally fix the "killed by dog" bug? In Version 1.1 and below, if BJ was killed by a dog, the game didn't know what actor sent the fatal blow to the player, so it usually turned to a wall or some place that showed no attacker. This bug is actually the easiest way to tell v1.1 from v1.2, since the sign-on screen in v1.2 is exactly the same as v1.1.

There's also a change in the "thrust" value of the player from v1.1 and v1.2. I never knew its actual speed, so I could never implement it into the Wolf4SDL code. But this is why the Wolfenstein 3-D Hint Manual says that v1.1 is the only version where you can make that record speed for the total time in Episode 1 (Was it 5:20?).
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 14 Jun 2018

Topics: 55
Posts: 2132
Location: Canada
blank.gif

PostPosted: Sun Apr 26, 2015 3:43 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
In which version did they finally fix the "killed by dog" bug?

It looks like the dog (and ghost) TakeDamage fix was only added in v1.4. But there's other easy ways to tell v1.1 from v1.2 too

Tricob wrote:
But this is why the Wolfenstein 3-D Hint Manual says that v1.1 is the only version where you can make that record speed for the total time in Episode 1 (Was it 5:20?).

Yes, it was 5:20. I did it on Bring Em On in 3:45 about 15 years ago though. The trick was to lure the guards to open the locked doors for you on Level 5, 6, and 7 (which is possible in all versions Very Happy ). I usually remove this "feature" for new levels / mods.

Here's how the ReadThis! describes his time in each version:

Version 1.0:
John Romero, Systems Engineer:
"I really need to work on my Total Time of 7:32 for Episode One. I was messing around too much in those rooms."

Version 1.1:
John Romero, Programming Director:
"There! Now those cheat programs won't work. By the way, Episode One--5:20!"

Version 1.4:
John Romero, Programming Director:
"I really need to work on my Total Time of 5:20 for Episode One. I was messing around too much in those rooms."

John did say in an email that someone beat his time even in 1992, which is probably why he changed his attitude from proud to negative in v1.4. Laughing My guess is that he was talking about using v1.1 instead of v1.0 in the Hint Manual, as the signon screen still says v1.1 on "v1.2" (so they appear the same), and the Wolf3d Hint Manuals were apparently never updated since v1.1.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sun Apr 26, 2015 7:42 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
My guess is that he was talking about using v1.1 instead of v1.0 in the Hint Manual, as the signon screen still says v1.1 on "v1.2" (so they appear the same), and the Wolf3d Hint Manuals were apparently never updated since v1.1.
That's a very interesting guess, and I have nothing to debunk it with. Smile At any rate, you'll find that the forward speed for BJ is much slower in v1.0 than it is in v1.4. Given those circumstances, I assumed that the forward speed was changed again in v1.2, although I've honestly had a lot of trouble telling the difference. So it's quite possible that I was wrong. Good call on that, Chris. Smile
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Sat May 23, 2015 12:18 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Hey there,

Thanks for your interest in this modified codebase!

As I already wrote in the Wolf3d Haven forum, I wasn't really doing Wolf3D modding, and I'm not as familiar with Wolf3D/SOD as many others are here. At least I was aware of a few points like the well-known 3-tiles pushwall movement bug (heh).
In particular, I'm not familiar with all of the differences written here, and it's interesting to see how do the various Wolf3D v1.4 and SOD releases have more bugs than certain Wolf3D releases, even though some of these may appear to come from actual fixes (e.g., not passing a direction argument to a spawn function).

I can add this, though. I think that originally the registered Wolf3D v1.1/1.2 project was called WL6APO11.PRJ. Eventually, though, I decided to rename it WL6APO12.PRJ, since it appears to be closer to WL1APO12 than WL1APO11 (which has probably been known for some time):
- First of all, as already known by some, WL6APO11 and WL6APO12 technically share the same EXE. Even the version number in the signon screen wasn't touched.
- WL1APO11 is earlier than WL6APO11.
- The only way in which WL1APO12 differs from WL6APO11/WL6APO12 (if I have a guess from the reconstructed code) is the definition of the macro UPLOAD.

It also makes it a bit easier to mark changes which are common to WL1APO12 and WL6APO11/WL6APO12, even though in practice I just manually used GAMEVER_RESTORATION_WL1_APO10 and GAMEVER_RESTORATION_WL1_APO11 for the earlier versions.

It may be a bit more confusing/difficult to identify code revisions by version numbers in other games, though. A good example is Keen 4-6, where I think the following versions were made available in the given order:
- Keen 4 Special Demo Version 1.0.
- Keen 6 v1.0.
- Keen 4 v1.0.
- Keen 6 Special Demo Version 1.0 (looks based on Keen 6 v1.0).
- Keen 4 v1.1.
- Keen 4 v1.2 and Keen 5 v1.0 (possibly built from the same revision of the codebase).
- Keen 6 Promotional Release Version 1.0: Has at least a couple of the changes between Keen 6 v1.0 and Keen 4 v1.2, but otherwise it's probably based on the Keen 6 demo (e.g., debug keys can be used immediately, and F10+P (PicturePause) also appears to behave the same as in Keen 6 v1.0 and the demo).
- Keen 4-6 v1.4, as prepared for Apogee (4+5) and FormGen (4+6, not sure about 5).
- Keen 6 v1.5 (Keen 6 v1.4 was a bit rushed, with a couple of changes related to the end-of-game not being sufficiently checked).
- Keen 4-5 v1.4, as prepared for GoodTimes Software (GT Interactive Software).

For the interested, some more (possibly guessed) details are available here: http://www.pckf.com/viewtopic.php?p=74306#74306
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat May 23, 2015 6:05 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

OT -

NY00123 wrote:
- Keen 6 Special Demo Version 1.0 (looks based on Keen 6 v1.0).
I've come across at least two different versions of the Keen 6 Demo ... assuming the "oldest" release isn't in a fact a corrupted copy.

In the older version, if you go into the Bean-With-Bacon Megarocket, go into the hidden area completely off-screen (Don't fall down), Save your game, and then load it again, your man will become visible in an area with distorted blocks (These "distorted blocks" represent areas of the map that aren't supposed to appear on-screen). When your man falls down to the next part of the map, the game crashes with some weird sort of error that makes sense only to the programmer of the game. The error doesn't tell you to call Apogee or Id or anything - It just shows the error after reverting to text mode, drops you to the DOS prompt, and that's it.

I've only come across that version in a Shareware disk magazine ... so far.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 14 Jun 2018

Topics: 55
Posts: 2132
Location: Canada
blank.gif

PostPosted: Sat May 23, 2015 9:30 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Welcome aboard NY00123! Here's a few fixed/raised limit exes for Apogee v1.1/1.2 Registered I compiled using your source.

Tricob wrote:
In the older version, if you go into the Bean-With-Bacon Megarocket, go into the hidden area completely off-screen (Don't fall down), Save your game, and then load it again, your man will become visible in an area with distorted blocks (These "distorted blocks" represent areas of the map that aren't supposed to appear on-screen).

I remember this version too. The first level I noticed this savegame trick in was Second Dome of Darkness, which got me curious to try it in other levels, and think that's how I found the Bean-with-Bacon one too. Very Happy The first version I played was actually CGA only (4 colors) at a friend's house then I ended up buying Keen 6 box which came with a cool poster as well.

That reminds me. I remember having a version of Keen 3 where you could type F11 (or was it F12?) in any level and it would "generate" a new random level, which was usually funny garble but sometimes you could navigate through it. I still have it on a bright yellow 3.5" floppy disk. I just found a video of it, but the video doesn't explore the potential of the feature too much.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat May 23, 2015 6:34 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

OT -

Chris wrote:
That reminds me. I remember having a version of Keen 3 where you could type F11 (or was it F12?) in any level and it would "generate" a new random level, which was usually funny garble but sometimes you could navigate through it. I still have it on a bright yellow 3.5" floppy disk. I just found a video of it, but the video doesn't explore the potential of the feature too much.
The newest version is v1.31, if I have the version number right.

The oldest version reportedly reset the system clock to 12:00 Midnight every time the game started up. What? This bug is fixed in all the newer versions. The oldest version I've ran is v1.11, assuming I have the version number right. It was on an old Shareware disk that I may or may not still have. But I'm sure some Keen fansite out there is going to carry the older versions ... just not necessarily Keen 3. Smile
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Tue May 26, 2015 11:38 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

POST EDIT (May 27): Sorry for the confusion, looks like the Keen 6 Promotional Release does show corrupted graphics if the saved game glitch is taken advantage of.

Hey there,

Good to see someone's looking at the recreated Wolf3D sources again!

At least some Keen versions are listed in the KeenWiki. Example for Keen 1 (including the late November Beta partially restored from a Gamer's Edge game sample disk): http://www.shikadi.net/keenwiki/Keen_1_Versions

It is true there are two versions of the Keen 6 demo. These have been listed by me as the "Special Demo Version" and the "Promotional Release Version". The latter version was distributed by Precision Software Applications, although chances are if you ordered the whole thing from them then you'd just get the retail FormGen product.

I've quickly checked versions 1.0 and 1.4 of Keen 6, as well as the Promotional Release, and I game hasn't crashed for me while checking the BWB game saving glitch. After falling down I can simply let Keen go to the left so the viewport is eventually centered as it should be. Maybe it's just a matter of luck, if not the opposite (e.g., partially corrupted data).

That Keen 3 "random level" bug is probably the broken screenshot functionality (can be activated using the F8 key) removed in v1.3 of Keen 1 and described here: http://www.shikadi.net/keenwiki/Keen_1_Bugs#F8_Crash

I was aware of the availability of the CGA versions; Initially just Keen 4, though, and this is still what I think is the most familiar to me when it comes to CGA, although Keen Dreams has possibly taken over as well during the last year. And yes, there is also a CGA version of Keen Dreams (apparently there were even three, but only one was known to be available to me and others, before the campaign of May 2014 to acquire the Keen Dreams (publishing) rights, which is a topic on its own).

It's interesting to see that an original version of a Keen game could actually reset the system clock. I knew the original releases of Crystal Saves and Secret Agent could rewind the system clock by 100 years in Windows XP (assuming just NTVDM is used), leading to updating the games in 2005, 14 years after the original releases! Original post: http://legacy.3drealms.com/news/2005/10/updates_for_some_older_titles.html

While the differences between the CGA and EGA releases of Keen Dreams may appear very small and truly insignificant (e.g., VW_FadeIn and VW_FadeOut being no-ops), things are a bit different in Keen 4-6. There's no scrolling animation for the status screen, and rather than the Star Wars scrolling text sequence appearing on some background with some music playing, you just get the background with the additional of credits in the CGA versions. (On a side-note, the scrolling text is apparently powered by self-generated rendering code similar to what's used in Catacomb 3-D, just for rows instead of columns).


Last edited by NY00123 on Wed May 27, 2015 12:39 pm; edited 1 time in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Tue May 26, 2015 3:42 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

OT -

NY00123 wrote:
I've quickly checked versions 1.0 and 1.4 of Keen 6, as well as the Promotional Release, and I game hasn't crashed for me while checking the BWB game saving glitch. After falling down I can simply let Keen go to the left so the viewport is eventually centered as it should be. Maybe it's just a matter of luck, if not the opposite (e.g., partially corrupted data).
The BWB stage in the full version is different from the one in the demo. I suspect the map was corrected in the commercial version before release, but the bug stayed in the first demo version. I can picture myself making the same mistake. Smile
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Wed May 27, 2015 12:44 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
The BWB stage in the full version is different from the one in the demo. I suspect the map was corrected in the commercial version before release, but the bug stayed in the first demo version. I can picture myself making the same mistake. Smile


Looks like I actually missed this. Indeed, you see random pixels instead of the gray colored blocks with the label... "BLOCK". This appears to the demo and promotional release altogether. Haven't observed a crash, though. Another difference (which I've known about earlier) is the lack of the Bobba. My old guess for a reason is the fact that the Bobba does not make an appearance in any of the retail Keen 6 maps that are also present in the demos, except for the BWB. There's also the possibility that someone thought it could scare potential customers. Based on certain modifications dates, the original demo appears to be a little bit newer than Keen 6 v1.0, although it doesn't have to be any definite proof of anything.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Thu May 28, 2015 3:30 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

The BWB differences were quick for me to spot. I exploit a little "unfair advantage" in the BWB portion of Keen 4 and 6: If you enter the BWB stage, fire one shot, exit, and then re-enter the stage, it'll give you an extra gun, thus allowing you to start Level One with more shotgun charges than you normally would.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Sat Jun 27, 2015 5:39 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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).
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Jun 27, 2015 5:45 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Interesting stuff, NY00123. I'd say that info definitely warrants a bump. Thumbs Up
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Sat Jul 11, 2015 12:06 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

LATE EDIT (MAY 7 2017): Corrected a minor typo regarding the first demo played in AOG shareware v3.0.

Tricob wrote:
Interesting stuff, NY00123. I'd say that info definitely warrants a bump. Thumbs Up


Chris wrote:
Here's a few fixed/raised limit exes for Apogee v1.1/1.2 Registered I compiled using your source.


Thanks for the support again! Regarding the alternative exes, Chris, it looks like this RAR file is actually a ZIP? It can be extracted otherwise, though. In addition, I can't see exact source code modifications. Do you mind posting these (generating .diff files showing just the differences is probably better than uploading the whole source trees)? While the Wolfenstein 3D sources are basically dual-licensed under GPL and some custom license, so this may be unnecessary legal-wise, it is still nice to have the chance to see the exact code changes (although they seem to be really small and a few).

Some of you may wonder about differences between the AOG versions currently recreated, and similarly the PS versions. As expected, I'm ignoring what's trivial (meaning the definition of the __VERSION__ macro, plus original compilation time and date).

There are only two code changes between versions 1.00 and 1.01 of Planet Strike, which can be found by looking for mentions of the macro GAMEVER_RESTORATION_ANY_LATE:
- In version 1.00, any of the shift keys can be used to double movement speed while using the mouse. The keyboard's key configured for running is totally ignored here. In version 1.01, any keyboard/mouse/joystick button defined for running can be used to do the same, in *addition* to the shift keys.
- No mouse button can be configured for running in v1.00. This was changed for v1.01.

Regarding AOG v2.1 and v3.0, the two changes above apply between these, too, but there are a few more changes in the code. You can find these by looking for mentions of GAMEVER_RESTORATION_BS1_300, GAMEVER_RESTORATION_BS6_300 and GAMEVER_RESTORATION_AOG_300:
- The amount of demos was reduced by one in-between versions 2.1 and 3.0.
- DemoLoop begins with demo no. 3 in registered v3.0, and with demo no. 0 otherwise. (Technically, LastDemo is also initialized to 3 in shareware v3.0, but the demo number is taken mod 3.)
- A different TERM_BACK_COLOR value is used in the menus as of v3.0.
- Planet Strike promotion pictures were added to v3.0.
- The registration phone number shown in the default high scores table was edited for v3.0.


Last edited by NY00123 on Sun May 07, 2017 9:43 am; edited 2 times in total
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Fri Aug 28, 2015 6:48 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 14 Jun 2018

Topics: 55
Posts: 2132
Location: Canada
blank.gif

PostPosted: Sat Aug 29, 2015 11:36 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Neat. Lots of interesting surprises to find (searching _N3D_) in your w3d_plus.diff. Always wished I could add midi music when modding wolf3d in the 90s as I had so many fun midi tracks, for instance. S3DNA itself never kept my interest for very long, but the coder(s) do seem like they made some impressive and well executed changes. Cool that your experiences are with IDA, the first disassembler I ever tried (that worked) with Wolf3d and Blake was IDA37fw. I did manage to compile byte-for-byte EXEs with your BS6_210, BS6_300, VSI_10*, and N3DWIS10 (minus the debug info) as advertised, and did figure out the VSI changes from your defs before they were explained. It's great that you're doing this, and unraveling the mysteries inside all these EXEs. Smile
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Tue Sep 01, 2015 1:34 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
Neat. Lots of interesting surprises to find (searching _N3D_) in your w3d_plus.diff.


Hopefully it's again interesting to see these for the first time! Truly, it's mainly been a part of trying to recreate the EXE (or at least the actual EXE image) for me as the time has passed for me.

Quote:
Cool that your experiences are with IDA, the first disassembler I ever tried (that worked) with Wolf3d and Blake was IDA37fw.


Good for you with taking similar looks at the raw code like this!

Quote:
I did manage to compile byte-for-byte EXEs with your BS6_210, BS6_300, VSI_10*, and N3DWIS10 (minus the debug info) as advertised, and did figure out the VSI changes from your defs before they were explained. It's great that you're doing this, and unraveling the mysteries inside all these EXEs. Smile


Thanks again for checking this out. One thing I haven't written a list of all differences between Aliens of Gold and Planet Strike. I think the current list of changes as found in the above repository may be misleading, though. As previously said, I think that PS was created as a separate branch of the AOG codebase before AOG v2.1 was released, and there's the example of CA_LoadAllSounds again.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Tue Sep 22, 2015 2:40 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.


Last edited by NY00123 on Wed Sep 23, 2015 12:40 am; edited 1 time in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Tue Sep 22, 2015 4:44 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I know that the SDL code plays back the music of Wolf3D and its sound effects at a different tempo than the DOS version (The SDL port plays its back slightly slower, IIRC). It's possible that a similar occurrence can happen with the Noah port if it uses the same timing routines for sound playback.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Wed Sep 23, 2015 12:41 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I've just added a subdirectory within the w3d_plus codebase, with the MIDI tempo patch and its description that I've posted, as well as an EXE built from the sources after applying the patch. The same forum post of mine has been edited to include a link to this subdirectory.

Tricob wrote:
I know that the SDL code plays back the music of Wolf3D and its sound effects at a different tempo than the DOS version (The SDL port plays its back slightly slower, IIRC). It's possible that a similar occurrence can happen with the Noah port if it uses the same timing routines for sound playback.


I've just checked the sound outputs of Wolfenstein 3D in DOS and ECWolf, and compared. While ECWolf's output is maybe not exactly the same, the tempo is really close to what you get in DOSBox (at least for the few tracks I checked). While ECWolf is used for the new official Super 3-D Noah's Ark port, and originally started using Wolf4SDL as a base, I have no idea how much does it differ from Wolf4SDL in terms of sound and music playback, especially when it comes to the new MIDI track support (or alternatively the SC-55 tracks recorded by MusicallyInspired and used in the official port).

Also, comparing the tempos of the S3DNA tracks, usually they play a bit slower in the DOS version, but the following tracks seem to play at least slightly faster (using the names from the JukeBox): Feed-time Shuffle, Song 6, Song 9, The Happy Song.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 14 Jun 2018

Topics: 55
Posts: 2132
Location: Canada
blank.gif

PostPosted: Wed Sep 23, 2015 12:40 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
I know that the SDL code plays back the music of Wolf3D and its sound effects at a different tempo than the DOS version (The SDL port plays its back slightly slower, IIRC). It's possible that a similar occurrence can happen with the Noah port if it uses the same timing routines for sound playback.

I remember Ripper found out the sounds in Wolf3d were actually played at 7042Hz even though WolfSnd and Floedit claimed it was 6896Hz, and IMFTools made IMFs play a bit slower than IMFCreator did, and the songs from BioMenace played faster when used in Wolf3d (700Hz vs. 560Hz), and Commander Keen music didn't even work at all in Wolf3d because it was Huffmanized.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Sat Sep 26, 2015 12:09 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
I remember Ripper found out the sounds in Wolf3d were actually played at 7042Hz even though WolfSnd and Floedit claimed it was 6896Hz, and IMFTools made IMFs play a bit slower than IMFCreator did, and the songs from BioMenace played faster when used in Wolf3d (700Hz vs. 560Hz), and Commander Keen music didn't even work at all in Wolf3d because it was Huffmanized.


This is an interesting find, given that, at least since one specific day, I've remembered the sample rate to be somewhere below 7000Hz! I agree that it can be a bit tricky to figure out the exact rate, which is probably the explanation.

Comparing to the other games as also mentioned by you, it's again known that a lot of things, file formats being a relatively small bit of them, were re-used in multiple early games developed by id Software, including Keen Dreams and Wolfenstein 3D (and more). I'll tell what I think that I know, at least, about the audio files as used from Keen Dreams and up to Wolfenstein 3-D (inclusive):

- In Keen Dreams and almost all releases of Keen 4-6, as well as the 3D Catacomb games' versions I'm aware of, the AUDIOT data is Huffman-compressed, and the EXE has embedded AUDIODCT and AUDIOHHD chunks. The OPL rate is 560Hz. ID_SD.C from the Catacomb 3-D sources should show why.
- In the early Special Demo Version of Keen 4, as well as the versions Bio Menace I'm aware of, the AUDIOT data is not compressed and there's an external AUDIOHED file. The OPL rate should still be 560Hz. In the case of the Keen 4 demo, there's a chance there's a little bit of difference in some header structure, but I'm not sure.
- All releases for DOS of Wolfenstein 3D, Spear of Destiny, the two Blake Stone games and Super 3-D Noah's Ark, that I'm aware of, again use non-compressed AUDIOT data with an external AUDIOHED file. The OPL rate (as far as I know) is 700Hz in all of these. While the digitized sound sample rate may be 7042Hz in most of these games, it was changed to about 11111Hz for Super 3-D Noah's Ark. Further note that the DOS release of Super 3-D Noah's Ark that I've gotten includes an unused AUDIODCT.N3D file.

As possibly also mentioned before, for some unknown reason, as evidenced by looking at ID_CA.C from the Keen Dreams/Catacomb 3-D/Wolfenstein 3D sources, either the AUDIOT data is LZHUF-compressed and the EXE has embedded AUDIOHHD and AUDIODCT chunks, or the data is not compressed and there's an external AUDIOHED file.

There are also some other titles, including ones published by Apogee Software Ltd., which use the IMF format. The OPL rate appears to be 700Hz for Major Stryker and Wolf3D-derived games, and 560Hz for the rest, with the exception of Duke Nukem II using the rate of 280Hz.

There are chances I'm wrong at some point, though.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Sep 26, 2015 6:33 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Part of the tricky thing is that - with IMF playback - the playback slows down as more layers of sounds are playing back at the same time. This wouldn't be so hard to duplicate if it wasn't for one thing - the IMFs have been tweaked so that the tempo won't change all that much when the layers drop off several at a time (E1L1 of Wolf3d, for instance). There are still several times where the IMF files aren't tweaked, and you see that change in tempo decrease as the song goes on, and then the tempo jumps a bit when it repeats itself (Level 1 of SOD, for example).

As for the MUS/Midi playback, I think it's a similar matter, but without IMF tweaking to complicate things. I suspect the sound chips use some sort of "buffer" to play back several "instruments" at one time, and whenever the buffer is full, it plays back what it can, plays whatever is left over, and then proceeds with the next set of notes in the file. And the fuller the buffer is, the slower the tempo becomes. Of course, the question is - how many notes does the buffer hold at one time, and how much exactly is the tempo slowed down when the buffer is exceeded? Lastly, does the playback slow down to different speeds on different DOS-based soundcards? That's a lot of questions I don't have the answers to. It's primarily my own fault; there's a lot of beefs I have with PCs in general, and it goes back to the 80286 days. I have particular expectations for what a computer should be able to do from its very first year on the market, and the PC fell short on that in several areas.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Fri Dec 25, 2015 10:15 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Dec 25, 2015 7:02 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Re: Blake Stone. Versions above 1.0 have some sort of update so that 80286 processors can't run the game. Once the game level starts or you get to an animated part of the Read This! section, the program just hangs. Not sure whether this was done in v3.0 or before.
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Fri Dec 25, 2015 11:54 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
Re: Blake Stone. Versions above 1.0 have some sort of update so that 80286 processors can't run the game. Once the game level starts or you get to an animated part of the Read This! section, the program just hangs. Not sure whether this was done in v3.0 or before.


MARKHACK.ASM and SCALE.ASM were both added in between versions 1.0 and 2.0 (the code is not present in the v1.0 EXEs). Accesses to 32-bit registers (like eax) can be found, which may explain the situation above.

MARKHARK.ASM's DrawPost and DrawLSPost can be called from 3D_DRAW.C:ScalePost in v2.0+, not the 1.0 (or Wolf3D) revision. Similarly, it's only in 3D_SCALE.C from v2.0+ where any SCALE.ASM function may be called.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Dec 26, 2015 6:08 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

When is MARKHACK used in the Read This! pages, then?
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 14 Mar 2018

Topics: 2
Posts: 29

blank.gif

PostPosted: Sat Dec 26, 2015 8:49 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
When is MARKHACK used in the Read This! pages, then?


On preparation of any of the "Read This!" sections (also including intro and briefing sections), 3D_MENU.C:HelpPresenter is called, which eventually leads to a call to JM_TP.C:TP_Presenter.

Inside JM_TP.C:TP_Presenter, as long as the flags variable has the fl_presenting bit set, TP_HandleCodes or TP_WrapText is called in a loop. I believe that most of the time is spent in TP_HandleCodes.

Within TP_HandleCodes, TP_DrawShape may be called: Either directly, or via TP_AnimatePage. For shapes of type pis_scaled, TP_DrawShape calls 3D_SCALE.C:MegaSimpleScaleShape with a shape height of 64. If done as expected, then eventually ScaleMaskedPost (in AOG) or ScaleMaskedLSPost (in PS) is called. The former may call R_DrawColumn, which the latter can call R_DrawSLSColumn or R_DrawLSColumn. These are three SCALE.ASM functions with accesses to 32-bit registers.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 0:10 ago.

Topics: 163
Posts: 8146
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Dec 26, 2015 12:53 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

I'm going to make an educated guess here. The "attack info" routine in the game and the animation in the "Read This!" code - does this share any of the same code? I think that would make a lot of sense. Smile
Display posts from previous:   
Post new topicReply to topic Time synchronized with the forum server time
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page TopView Next Topic
Page 1 of 2 Goto page 1, 2  Next
Jump to:  

Related topics
 Topics   Replies   Views   Last Post 
No new posts [Info] Breakable or Exploding Objects (colums or barrels)
Author: wolf3dbreaker
37 7682 Tue Feb 08, 2005 5:44 am
Guest View latest post
No new posts [Help] Setting RocketLauncher: Explosive Range...?
Author: KyleRTCW
17 5010 Thu Jun 03, 2004 3:21 am
Codetech84 View latest post
No new posts [Info] Tricks - Dogs that shoot - Modifying Behaviour
Author: Guest
19 288 Sat Mar 20, 2004 7:31 am
Dugtrio17 View latest post
No new posts [Info] Assigning Static Objects problem.
Author: Guest
1 104 Sun Jul 06, 2003 1:25 pm
Guest View latest post
No new posts [Info] Alarm Sounding in game?? WSJ...??
Author: Guest
7 309 Tue Jun 17, 2003 10:04 pm
Reivax44 View latest post
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
   You cannot delete your posts in this forum
You cannot vote in polls in this forum


Copyright ©2003-2008 DieHard Wolfers
A Modified subBunker Theme by BrotherTank
Powered by phpBB © 2001, 2005 phpBB Group