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 2 of 2 Goto page Previous  1, 2
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
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

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

Tricob wrote:
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


Can you elaborate a bit on what you're referring to? If you want to refer to any actual code, it's probably better to link to the relevant location(s) in the recreated codebase from my repository.

After going a bit through the code, I have a feeling that you're referring to info area drawing routines.

There's the GS_ATTACK_INFOAREA bit of gamestate.flags. If this bit is set while the player is attacked by something (in 3D_AGENT.C:TakeDamage), then (under certain conditions) DISPLAY_TIMED_MSG, or more precisely 3D_AGENT.C:DisplayInfoMsg, is called. This may update gamestate.msg to contain some message. It looks like the actual on-screen update begins via UpdateStatusBar -> UpdateInfoArea. Here, AnimatePage -> DrawShape may be called, presumably for drawing the attacker.

DrawShape may also be called like this: UpdateInfoArea -> DrawInfoArea -> HandleControlCodes -> DrawShape. Indeed, HandleControlCodes appears to use some JM_TP definitions (and also DrawInfoArea, at the least). Furthermore, for shapes of type pis_scaled, DrawShape calls MegaSimpleScaleShape, as done in JM_TP.C:TP_DrawShape.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 24 Apr 2017

Topics: 53
Posts: 2064
Location: Canada
blank.gif

PostPosted: Sun Dec 27, 2015 2:04 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

Very nice NY00123. Now the Blake Restoration feels complete! Very Happy

The new/old scalers and 286-compatible stuff sounds interesting. I never really liked the "lighting" and other additions in v2.0+, so being able to compile the original 1.0 version (then seeing if there's any changes worth salvaging from later versions) is a definite plus. I had a chance to compile shareware exes for v1.0, v2.0, and v3.0 with your source and did some experimenting.

edit: In the spirit of restoration, here's some tunes from Blake Stone v0.63b to jam to (JAM! lol): http://youtu.be/gjat5cLnlhI


Last edited by Chris on Wed Jun 22, 2016 7:27 am; edited 22 times in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sun Dec 27, 2015 3: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

NY00123 wrote:
Tricob wrote:
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


Can you elaborate a bit on what you're referring to?
Certainly. When you're successfully hit by something, the code says what (or who) attacked you. But - that's not all. The code draws an animated version of that enemy on the statusbar. This is the animation routine I'm talking about. Smile
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Mon Dec 28, 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

Thanks again for all of the responses!

Chris wrote:
Very nice NY00123. Now the Blake Restoration feels complete! Very Happy

The new/old scalers and 286-compatible stuff sounds interesting. I never really liked the "lighting" and other additions in v2.0+, so being able to compile the original 1.0 version (then seeing if there's any changes worth salvaging from later versions) is a definite plus. I had a chance to compile shareware exes for v1.0, v2.0, and v3.0 with your source and did some experimenting.


Great to see you experimenting again! It also looks like you surely have preference for older versions of games at times (although it should be obvious you aren't alone).

Regarding the "lighting" and possibly also other additions, can't you simply toggle these off in v2.0 and later? If not from the menus, then some in-game shortcut keys may do the job.

Tricob wrote:
NY00123 wrote:
Can you elaborate a bit on what you're referring to?
Certainly. When you're successfully hit by something, the code says what (or who) attacked you. But - that's not all. The code draws an animated version of that enemy on the statusbar. This is the animation routine I'm talking about. Smile


Thanks for the explanation! I think that my preceding post should cover this, then.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Mon Dec 28, 2015 1:38 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:
I never really liked the "lighting" and other additions in v2.0+, so being able to compile the original 1.0 version (then seeing if there's any changes worth salvaging from later versions) is a definite plus.
I believe that the lighting and other features can be disabled in the menus. The problem is that the Floor and Ceiling keys are hard-coded to be used in the game, and you can't remap them. Not a huge problem if you use Ctrl and Alt instead of the letter keys, but otherwise ...
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 24 Apr 2017

Topics: 53
Posts: 2064
Location: Canada
blank.gif

PostPosted: Wed Jun 22, 2016 7:25 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

NY00123 wrote:
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)?

I started working on the WL6MAX12.EXE some more this week: http://chokfiles.webs.com/diff.txt (yes the "rar" is actually a zip)
Matthew
DieHard SS
DieHard SS


Joined: 02 Jul 2007
Last Visit: 06 Mar 2017

Topics: 90
Posts: 456

usa.gif

PostPosted: Mon Aug 01, 2016 1:42 pm
   Subject: 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:
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


There is a bug in v1.1 where sometimes when a boss is alerted, the game will crash with the error "Walk: bad dir".

This often happens in Temporary Insanity. Here is a quote from "hints.txt":

Quote:
PROBLEM: The game dies with the error "Walk: bad dir"

SOLUTION: This annoying problem occurs apparently at random when a huge
guard sees you. For some reason, when they are next to something solid,
especially walls, they often try to walk into it and this results. I
could stop this problem by moving every huge guard so it is surrounded
by empty space, but in some cases this is impossible while still
maintaining the level the same as before. Save your game before
triggering one and hope it will decide to walk in the right direction,
which it usually does. This problem most often occurs when you try to
rush past one very quickly from a strange angle instead of waiting a
moment or two.


I've known about this bug for 15 years, but didn't know why it occurs until now. I suspected it had something to do with the fact that unlike in later versions of Wolf3D, bosses can see the player in any direction.

If you want to see it, one place where it occurs is the corridor where the gold key is on E1L6 of Temporary Insanity. If you try to run through the second side door on the right and grab the key without blocking the Hans Grosses, it will happen.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 24 Apr 2017

Topics: 53
Posts: 2064
Location: Canada
blank.gif

PostPosted: Thu Aug 18, 2016 8: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

Thanks Matthew. I had a recollection of Bosses beside walls and the "Walk: Bad dir" thing happening too, and thanks to your Temporary Insanity E1L6 scenario (which does happen pretty much every time), it was easy to test and see that it does indeed happen because of that out-of-range dir. I tried MCS's frozen bosses nodir suggestion to see if it caused the same problems, and it didn't, so I guess his nodir truly is better than "the v1.1 way" if you want to use all-seeing Bosses in tight areas - haha.

If you ever want a patched v1.1 exe, your post inspired me to update the WL6APO12.EXE branch in that rar/zip above today. The apo one should perform all the tricks the same in Temporary Insanity as Apogee v1.1, as the memory locations in the MAP file are still in the same place. I converted 8 of the fixes from the MAX one into APO one this way so far, might try a few more later.
Matthew
DieHard SS
DieHard SS


Joined: 02 Jul 2007
Last Visit: 06 Mar 2017

Topics: 90
Posts: 456

usa.gif

PostPosted: Fri Aug 19, 2016 3:06 pm
   Subject: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Is there anywhere I can get the MAP files for Wolf3D v1.1 and Wolf3D v1.4GT?

I would love to be able to calculate the map codes for tricks directly.

Since map codes and near pointers are both 16-bit integers, this should allow any bytes in near memory to be incremented or decremented with the "areaconnect" array.

One time many years ago, with one "areaconnect" trick that, in Wolf3D v1.4GT, had a wall code as the higher-order number, I calculated an alternate combination that used map code 0 instead, so both sides of the door could be empty space. The lower-order number that was necessary was huge, but it worked. MapEdit wouldn't let me place it; I saved the map to a file and placed it with a program I had written. (I also could have used a hex editor.)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 24 Apr 2017

Topics: 53
Posts: 2064
Location: Canada
blank.gif

PostPosted: Sun Aug 21, 2016 3:12 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 like the way you think Matthew. Here's the WL6 ones (will try doing WL1 and SOD in a bit):
http://chokfiles.webs.com/MAP/WL6APO12.MAP.txt
http://chokfiles.webs.com/MAP/WL6APO14.MAP.txt
http://chokfiles.webs.com/MAP/WL6GT114.MAP.txt
http://chokfiles.webs.com/MAP/WL6ID14.MAP.txt
http://chokfiles.webs.com/MAP/WL6GT214.MAP.txt
http://chokfiles.webs.com/MAP/WL6ACT14.MAP.txt


To find out if your GT is version1 or 2, try comparing your file sizes here. WL6APO12 is Apogee v1.1 (v1.1/v1.2 use the same exe).

Think I got the Temporary Insanity science mostly figured out...
In Apogee v1.1 wl6, areaconnect[0][0] seems equivalent to near 0x9EC0 below 0, ie.

*** (0x40) 0,64 noclip (E2L9) = -107, -43 / 149, 213

areaconnect[-107][-43] = 0x9EC0 - 107*37 - 43 = 0x8F1E = DigiMap+155
areaconnect[-43][-107] = 0x9EC0 - 107 - 43*37 = 0x981E = noclip
areabyplayer[149] = 0x45CE + 149*2 = 0x46F8 = vertwall[46]
areabyplayer[213] = 0x45CE + 213*2 = 0x4778 = horizwall[46]

So reversed, can also use...
areaconnect[4][-46] = 0x9EC0 + 4 - 46*37 = 0x981E = noclip (111,61)
areaconnect[6][-46] = 0x9EC0 + 6 - 46*37 = 0x9820 = godmode (113,61)
areabyplayer[210] = horizwall[43] (White Brick w/map, light side)

*** (0x69) 0,105 Temporarily lose your gun (E3L9) = -107,-2 / 149, 254

areaconnect[-107][-2] = 0x9EC0 - 107*37 - 2 = 0x8F47 = Keyboard+4
areaconnect[-2][-107] = 0x9EC0 - 107 - 2*37 = 0x9E0B = spotvis+1511
areabyplayer[149] = 0x45CE + 149*2 = 0x46F8 = vertwall[46]
areabyplayer[254] = 0x45CE + 254*2 = 0x47CA = update+34

***
More (E2L4/L8, E3L1/L10):
(0xA0) 0,160 = -107, 53 Control
(0xD6) 0,214 = -107, 107 Alt
(0xD7) 0,215 = -107, 108 Space Bar
(0xF6) 0,246 = -107, 139 Up Arrow
(0xFB) 0,251 = -107, 144 Right Arrow
Randoms:
(0x6D) 0,109 = -107, 2 pacman entrance (E2L9)
(0x73) 0,115 = -107, 7 entrance before noclip room (E2L9)
(0x90) 144,144 = 37, 37 near: pwallstate (E3L8)
(0x93) 106,147 = 0, 40 near: doorposition[2], far: spotvis (E3L4)

I got "pushwall stuck in savegames fix" (BUGFIX_09) into the wl6apo12.exe now. This was the most complex to pull off so far. Laughing
Matthew
DieHard SS
DieHard SS


Joined: 02 Jul 2007
Last Visit: 06 Mar 2017

Topics: 90
Posts: 456

usa.gif

PostPosted: Sat Oct 22, 2016 8:04 pm
   Subject: 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:
Think I got the Temporary Insanity science mostly figured out...
In Apogee v1.1 wl6, areaconnect[0][0] seems equivalent to near 0x9EC0 below 0, ie.

*** (0x40) 0,64 noclip (E2L9) = -107, -43 / 149, 213

areaconnect[-107][-43] = 0x9EC0 - 107*37 - 43 = 0x8F1E = DigiMap+155
areaconnect[-43][-107] = 0x9EC0 - 107 - 43*37 = 0x981E = noclip
areabyplayer[149] = 0x45CE + 149*2 = 0x46F8 = vertwall[46]
areabyplayer[213] = 0x45CE + 213*2 = 0x4778 = horizwall[46]

So reversed, can also use...
areaconnect[4][-46] = 0x9EC0 + 4 - 46*37 = 0x981E = noclip (111,61)
areaconnect[6][-46] = 0x9EC0 + 6 - 46*37 = 0x9820 = godmode (113,61)
areabyplayer[210] = horizwall[43] (White Brick w/map, light side)

*** (0x69) 0,105 Temporarily lose your gun (E3L9) = -107,-2 / 149, 254

areaconnect[-107][-2] = 0x9EC0 - 107*37 - 2 = 0x8F47 = Keyboard+4
areaconnect[-2][-107] = 0x9EC0 - 107 - 2*37 = 0x9E0B = spotvis+1511
areabyplayer[149] = 0x45CE + 149*2 = 0x46F8 = vertwall[46]
areabyplayer[254] = 0x45CE + 254*2 = 0x47CA = update+34

***
More (E2L4/L8, E3L1/L10):
(0xA0) 0,160 = -107, 53 Control
(0xD6) 0,214 = -107, 107 Alt
(0xD7) 0,215 = -107, 108 Space Bar
(0xF6) 0,246 = -107, 139 Up Arrow
(0xFB) 0,251 = -107, 144 Right Arrow
Randoms:
(0x6D) 0,109 = -107, 2 pacman entrance (E2L9)
(0x73) 0,115 = -107, 7 entrance before noclip room (E2L9)
(0x90) 144,144 = 37, 37 near: pwallstate (E3L8)
(0x93) 106,147 = 0, 40 near: doorposition[2], far: spotvis (E3L4)


Thank you so much for this. I tried to figure out how exactly the Temporary Insanity tricks worked, but wasn't able to. I had forgotten that "areaconnect" is a far pointer; I wasn't sure exactly how those values made it point to "near" memory.

What does (0, 115) do? That is the locked door leading to the door that triggers "no clipping" on E2L9. I haven't noticed that do anything.

With (106, 147), didn't you mean (107, 147)? The former combination is not used on E3L4, and would make the door "invisible", because 106 is the "deaf guard" floor code. The latter combination is used with the door leading to the gray brick area on E3L4. What does it do? I just tried it, and didn't notice it doing anything.

With 144, it is not the "areaconnect" combination that triggers "pwallstate"; it is "areabyplayer". Note that it is not triggered by the door opening or closing, or by the door itself, only by any door opening or closing while the player is standing on that map code.

With E3 L9 of Temporary Insanity, most of the map uses out-of-range map and object codes, which results in the map being shrouded from view when viewed in MapEdit, and it has the appearance of a skull (it appears white in MapEdit, because MapEdit displays "unknown" map and object codes as white). At one point (tilex = 32, tiley = 3), there is a tile with map code 144. It is even next to a door, with a pushwall on the opposite side. It appears that Nat forgot what that code does. Smile

With the trick I was talking about in my previous post, it was the "move uncontrollably" trick that is used in Temporary Insanity, but in version 1.4GT of Wolf3D. When I originally did searching for tricks in Wolf3D back in 2000 and 2001, after many months, I was able to find a range of map code combinations that would cause those effects in v1.4GT.

The way I found it was, I first noticed that with the combination that is used to trigger "no clipping" on Temporary Insanity E3 L10, in v1.4GT, although it doesn't trigger "no clipping", it causes the player's weapon to switch to the chaingun. I then tried other nearby map codes, hoping to find ones that would do the other things, but only found one that would cause the player's weapon to switch to the machine gun (I used this on E1L4 of The Thirteenth Floor), and another one that would cause the game to crash with the error message "Demo buffer overflowed!". I eventually figured out, by looking at the source code, that it was the combination of map codes on both sides of the door, not just one of the codes, that determines what it does. I eventually figured out that it is possible to calculate alternate map code combinations that do the same thing, if you figure out which map code is the lower-order number and which is the higher-order number. I soon found a combination that would do the "weapon switching to knife" trick that is used in Temporary Insanity E3 L9, and eventually found combinations for all the other tricks except the "no clipping" trick, which I used in The Devil's Attack.

Yes, I was able to figure that all out when I was only 13 or 14 years old. Smile

The combinations I found required that a wall be adjacent to one of the sides of the door. Many years later (I think maybe in 2007 or 2008; I'm not sure), I found that I was able to use a combination where both codes were empty space, if I used a program that allowed me to place such a large number (MapEdit didn't). I explained that in my previous post.

To this day, I have never found a combination that triggers "no clipping" in v1.4GT, or any version other than v1.1. Is there a way to calculate a combination that does it in v1.4GT, from the "wolf3d.map" data?
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Sun Apr 09, 2017 1:28 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

Hey there,

While I don't have a lot of new actual contents to report about, there's still what to write.

1. To begin with, anybody who's been messing with the modified Wolf3D codebase from my repository should probably read this point. Not long ago, I've found out that Borland C++ effectively truncates too long identifiers behind-the-scenes. There's an "Identifier Length" option which tells the max. identifier length, and has to fall in the range 1-32 (at least under Borland C++ 3.0).

So it's been a good chance for me to not just shorten identifier names, but also do some other changes. A significant one is the usage of a new GAMEVER_WOLFREV macro for covering different ranges of Wolf3D codebase revisions.

Also, the project file names have been renamed. In particular, note these renames: WL1APO12.PRJ -> WL1AP11.PRJ, SODFOR14.PRJ -> SODFG14B.PRJ. There is indeed a new "SODFG14A.PRJ" project, see below.

Finally, VERSION.H and VERSION.EQU now internally used "EXEDEF" macros that match the corresponding project files. These macros are *never* directly used in any other source file (on purpose). GAMEVER_WOLFREV should be used for this, combined with macros like UPLOAD and GOODTIMES, as well as the new GAMEVER_NOAH3D macro.

2. I've added a project file for another EXE, named SODFG14A.PRJ. This is the "v1.4" release mistakenly labelled as "V1.0" in-game, which was apparently released on 1992-11-12, according to Litude. To compare, SODFG14B.PRJ (previously named SODFOR14.PRJ) is assumed to be released on 1993-01-12.

In terms of actual code found in the C and ASM sources, SODFG14A.PRJ and SODFG14B.PRJ are exactly the same. Furthermore, both EXEs were originally built using Borland C++ 3.1. However, in other ways, SODFG10.PRJ is more similar to SODFG14A.PRJ. This includes differences like the order in which objects get linked, as well as the "V1.0" sign-on screen. In fact, ignoring my addition of the "EXEDEF" macros, the exact same project file can theoretically be used for SODFG10 and SODFG14A altogether, with a bit different VERSION.H/EQU definitions.

3. For some weird unknown reason, the instructions for building SODFG10.EXE (previously SODFOR10.EXE) have changed a bit. After building the EXE, you now have to remove WL_PLAY.OBJ, re-open the project with Borland C++ 3.0 and then again press on F9 to build the removed code. Only then, LZEXE91 may be used. I really don't know why this is the case, especially since it's not required in an earlier revision of the codebase (I've verified this). It might be related to source file(s) layouts and/or the way a table of definitions internally used by the compiler is structured.

4. I've also updated the notes regarding the compression of the Activision EXEs. To summarize, you can use LZEXE 0.91e, rather than 0.91, to faithfully recreate the EXEs from 1998. These two versions of LZEXE seem to differ, a little bit, by the contents of the decompressor stub as embedded in the packed EXEs (0.91e appears to add a "push ax" and a later "pop ax", if there's no other change). Since UNLZEXE8 checks the first 232 bytes of the decompressor stub, this should explain why it fails to unpack any of the Activision EXEs, while UNLZEXE7 can do so. Of course, if any of you attempts to hide that "LZ91" string (found in the first 32 bytes of the EXE), then UNLZEXE7 will fail, too.

I'll also add a few bonus points here:

5. So now, I don't exactly have the means to build this as-is, but let's continue anyway. The file http://www.freewebs.com/choksta/wolflist.txt lists a "WOLF3D_J.EXE" executable, which comes from a Japanese localization of the game made for DOS/V (not to be confused with the PC-98 port i.e., WOLF98.EXE). It is reportedly 254046 bytes long. Well, it turns out, that when you modify WL6GT14A so the JAPAN macro is defined instead of GOODTIMES, Borland C++ 3.1 outputs an EXE with the exact same size. Again, though, I cannot confirm it's the exact same EXE. In fact, I'm quite sure it isn't, given the presence of the (wrong) GT sign-on screen, heh.

6. One may be wondering if WOLF3D.EXE, as originally bundled on 1995 along with the Wolfenstein 3D sources, can be re-created? In fact, maybe it can simply be built from the sources as released back then? Well, it turns out the answer is "yes", under a few conditions. First, you should use Borland C++ 3.0. Secondly, make sure all files have their original modification dates, not older than 1995. Otherwise, expect to get a few minor differences between the 1995 EXE build and your build.

Can the same be done from my repository? Well, if we ignore differences in debugging symbols, then again the answer is "yes". Basically, you should begin from (a copy of) WL6AC14.PRJ, then replace the Activision SIGNON.OBJ with the GT one, select "On" for "Source Debugging" in Borland C++ 3.0 (under Debugger Options) and finally make sure that GAMEVER_WOLFREV is the same as for WL6GT14B. You may wish to modify the output directory to something other than OBJ\WL6AC14, and possibly also update the Include and Library directories (so files from BC30 are used instead of BC31). Watch out, though, in case you also want to replace the GAMEVER_EXEDEF_WL6AC14 macro. Reason is, not only you should edit it under "Compiler -> Code Generation", but it also has to be manually changed for a few ASM sources (under params passed to the assembler).


Last edited by NY00123 on Mon Apr 17, 2017 8:43 am; edited 1 time in total
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 24 Apr 2017

Topics: 53
Posts: 2064
Location: Canada
blank.gif

PostPosted: Wed Apr 12, 2017 8: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

Thanks NY00123. I would think that it would make more sense to use a define like:

::: CODE :::
#if (GAMEVER_WOLFREV <= WOLF_SHARE10)

Rather than:

::: CODE :::
#if (GAMEVER_WOLFREV <= 19920505L)

So you don't have to change every occurrence if you find that a date is wrong, or am I missing something? Laughing

I am sure someone still has the Japanese exe to make sure about #5. Maybe try PMing Brothertank, Adam Biser, Ripper...

edit: Tricob posted it's signon screen in here, so a byte-for-byte recreation could be more possible (theoretically) Very Happy
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Thu Apr 13, 2017 2:48 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:
Thanks NY00123. I would think that it would make more sense to use a define like:

::: CODE :::
#if (GAMEVER_WOLFREV <= WOLF_SHARE10)

Rather than:

::: CODE :::
#if (GAMEVER_WOLFREV <= 19920505L)

So you don't have to change every occurrence if you find that a date is wrong, or am I missing something? Laughing


Using definitions for the revision numbers themselves is indeed a possibility. However, I think that I still prefer to refrain from using the version number, especially when there may be a bit of ambiguity or some other confusion.
For Wolfenstein 3D, there are the earlier shareware v1.1 and the later registered v1.1/1.2 and shareware v1.2 revisions.
For Blake Stone, across all versions currently recreated, I think this is less of an issue, although the 1-episode v1.0 code is somewhat earlier than 6-episodes v1.0 (based on evidences from code changes).

What's true, though, is that a single revision number like GAMEVER_WOLFREV is not necessarily sufficient. For one, you can see the definitions I've chosen for S3DNA.
For another example, which is related to Blake Stone, I think that Planet Strike started off a branch of a revision of Aliens of Gold close to v2.0 (possibly in-between versions 2.0 and 2.1). So it might make sense to use more than one revision number, e.g., BSTONEREV and FIREREV, or AOGREV and FIREREV.

Quote:
I am sure someone still has the Japanese exe to make sure about #5. Maybe try PMing Brothertank, Adam Biser, Ripper...

edit: Tricob posted it's signon screen in here, so a byte-for-byte recreation could be more possible (theoretically) Very Happy


Heh, it is great to see that Imagineer logo, even if this is supposedly a recreated/converted signon screen.
One missing source file is GFXV_WJ6.H. A recreated one was originally uploaded to http://www.canadianphilatelics.com/choksta/GFXV_WJ6.H (and linked from http://forums.3drealms.com/vb/showthread.php?t=22050), but unfortunately it looks like the link is dead. Luckily, though, I downloaded it beforehand, and this is how I could even build an EXE with the "JAPAN" macro defined (albeit it isn't the original EXE from 1994). Here is a copy of the recreated header: https://pastebin.com/pKPMFrF8

I currently suspect that, while there are references to Spanish localization in the code, there was no Spanish-localized release of the original DOS game. On the other hand, there was clearly a (dunno if even more obscure) Taiwanese localization, according to Romero:
- http://forums.3drealms.com/vb/showpost.php?p=399646&postcount=5 (a later post says Traditional Chinese was used for the menus, and chances are it was also used for HelpScreens as in the Japanese version)
- Sorry, 2 years late for getting this product (and it didn't cost a little anyway), but in case there are still doubts: https://twitter.com/romero/status/605250862991024129
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Thu Apr 13, 2017 3:21 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

In case people posting here have missed it, the v1.2 release of Shareware Wolf3D still has "v1.1" on the sign-on screen. Although there was more than one change in this version, the easiest way to identify the v1.2 release is by letting a dog kill you. V1.2 will identify the dog as the attacker ... while v1.1 can not.
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Fri Apr 14, 2017 12:07 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:
In case people posting here have missed it, the v1.2 release of Shareware Wolf3D still has "v1.1" on the sign-on screen. Although there was more than one change in this version, the easiest way to identify the v1.2 release is by letting a dog kill you. V1.2 will identify the dog as the attacker ... while v1.1 can not.


The point about the sign-on screen is true, but wasn't the dog-related bug fixed only after v1.2? I can still reproduce it in shareware v1.2.

I've found in my modified codebase two ways to tell shareware v1.1 apart from shareware v1.2 or registered v1.1/1.2 (independently of actual game data in use):
- Shareware v1.1 still has the Tab+N (no clipping) functionality.
- If stereo PCM is enabled, then the GUTENTAGSND sound (Hans Grosse' introduction) is played back with stereo panning in shareware v1.1, and without it in the later versions.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Apr 14, 2017 8:20 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

NY00123 wrote:
The point about the sign-on screen is true, but wasn't the dog-related bug fixed only after v1.2? I can still reproduce it in shareware v1.2.
I've only found one copy of Shareware v1.2, and it had the dog problem fixed. Speed issues with the fading still exist in every version before v1.4, though ... at least those that I've seen.

Edit: I believe there was a change in the compression scheme some place in the v1.2 update. You might check the GAMEMAPS files to confirm or disprove this.
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Sat Apr 15, 2017 9:24 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:
I've only found one copy of Shareware v1.2, and it had the dog problem fixed. Speed issues with the fading still exist in every version before v1.4, though ... at least those that I've seen.


I've rechecked this, and I still get the dog problem. I've gotten the copy of v1.2 from here: https://www.classicdosgames.com/game/Wolfenstein_3D.html

If your data is indeed different, mind comparing your EXE to the EXEs of a few other releases (mainly shareware versions 1.2 and 1.4)?

Quote:
Edit: I believe there was a change in the compression scheme some place in the v1.2 update. You might check the GAMEMAPS files to confirm or disprove this.


I think it's a change that occurred in-between shareware versions 1.0 and 1.1. In v1.0, the maps are uncompressed and stored in MAPTEMP.WL1. In v1.1 and later, the maps are Carmack-compressed and stored in GAMEMAPS.WL1. The CARMACIZED macro can be used to control this feature.

In fact, there are good chances that originally, CARMACIZED didn't exist. Why? Well, for reference, let's compare the versions of ID_CA.C:CAL_SetupMapFile from the released Catacomb 3-D and Wolfenstein 3D sources:
https://github.com/FlatRockSoft/Catacomb3D/blob/master/ID_CA.C#L934
https://github.com/id-Software/wolf3d/blob/master/WOLFSRC/ID_CA.C#L973

Basically, originally, there was a single MAPHEADERLINKED macro that enabled not one, but *two* features:
1. Linking the map header file into the EXE, the same way GAMEPAL.OBJ and SIGNON.ORJ are commonly linked into WOLF3D.EXE. Note that for Catacomb 3-D, the corresponding object file is C3DMHEAD.OBJ, and it has the internal file name of MTEMP.TMP. Based on some info., I conclude it was generated using TED5 (during the maps "carmackization" process).
2. Carmack-compression for maps.

There are good chances the same applied while making Wolf3D v1.0. Eventually, a separate CARMACIZED macro was introduced for feature no #2.

Side-note: CARMACIZED is *undefined* in all versions of Blake Stone that I restored, while it's still defined for Super 3-D Noah's Ark.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Apr 15, 2017 11:22 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 v1.2 I found was from the Wolf3D Dome.

::: CODE :::
http://www.wolfenstein3d.co.uk/adds_VWX.htm#wolfshar
http://www.brlowe.co.uk/wolf12.zip
NY00123
Registered User
Registered User


Joined: 20 May 2015
Last Visit: 17 Apr 2017

Topics: None
Posts: 21

blank.gif

PostPosted: Sat Apr 15, 2017 11:46 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:
The v1.2 I found was from the Wolf3D Dome.

::: CODE :::
http://www.wolfenstein3d.co.uk/adds_VWX.htm#wolfshar
http://www.brlowe.co.uk/wolf12.zip


I've checked the data, and this is the exact version found at RGB.

Just to verify we're talking about the same bug with the dog: I start a game in E1F1 under "I am Death incarnate!" difficulty. I then approach the first dog that can be seen (in the east). After letting it kill B.J., the viewpoint changes to some "random" location towards the south-east. I say "random" like this since, in fact, this location appears to be deterministic, but it's still not exactly the dog's.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 3:40 ago.

Topics: 156
Posts: 7805
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Apr 15, 2017 11:57 am
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

You're right; I've tried the version I posted a link for, and I get the same exact thing. What's going on is that the code is rotating towards the last shot that was fired at you (unless no shot was ever fired, in which it's rotated to "NULL"). The code doesn't care whether the shot fired is from a guard that's now dead. 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 2 of 2 Goto page Previous  1, 2
Jump to:  

Related topics
 Topics   Replies   Views   Last Post 
No new posts [Info] Breakable or Exploding Objects (colums or barrels)
Author: wolf3dbreaker
37 5352 Tue Feb 08, 2005 5:44 am
Guest View latest post
No new posts [Help] Setting RocketLauncher: Explosive Range...?
Author: KyleRTCW
17 3597 Thu Jun 03, 2004 3:21 am
Codetech84 View latest post
No new posts [Info] Tricks - Dogs that shoot - Modifying Behaviour
Author: Guest
19 284 Sat Mar 20, 2004 7:31 am
Dugtrio17 View latest post
No new posts [Info] Assigning Static Objects problem.
Author: Guest
1 103 Sun Jul 06, 2003 1:25 pm
Guest View latest post
No new posts [Info] Alarm Sounding in game?? WSJ...??
Author: Guest
7 306 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