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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 30 Oct 2017

Topics: 55
Posts: 2115
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: 18:56 ago.

Topics: 160
Posts: 7991
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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 18:56 ago.

Topics: 160
Posts: 7991
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: 30 Oct 2017

Topics: 55
Posts: 2115
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: 10 Oct 2017

Topics: 91
Posts: 464

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: 30 Oct 2017

Topics: 55
Posts: 2115
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: 10 Oct 2017

Topics: 91
Posts: 464

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: 30 Oct 2017

Topics: 55
Posts: 2115
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: 10 Oct 2017

Topics: 91
Posts: 464

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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 30 Oct 2017

Topics: 55
Posts: 2115
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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 18:56 ago.

Topics: 160
Posts: 7991
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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 18:56 ago.

Topics: 160
Posts: 7991
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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 18:56 ago.

Topics: 160
Posts: 7991
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
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

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: 18:56 ago.

Topics: 160
Posts: 7991
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 Next 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
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

blank.gif

PostPosted: Sun May 07, 2017 10: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

OK, I want to correct a few mistakes of mine. Afterwards, I'll ask about the new macros used in the sources recreation repository.

1. First, about Blake Stone: Aliens of Gold, I mistakenly mentioned in DHW and RGB that demo no. 3 is the first to be played in version 3.00. In fact, this is the case only in the registered version. The LastDemo variable is still initialized to 3 in shareware v3.0, but the actual demo number is calculated mod 3.
2. Secondly, about the projects SODFG14A.PRJ and SODFG14B.PRJ, I mistakenly hinted that there are differences between term, in the orders objects get linked. This is incorrect. In fact, these two projects are almost identical (and hence are both similar to SODFG10.PRJ, ignoring Borland C++ version originally used). Basically, the only real difference (other than SIGNON.OBJ) is that Source Debugging is toggled "On" in SODFG14A.PRJ and "Off" in SODFG14B.PRJ.

Now, I'm wondering if my choice of new macros (like GAMEVER_WOLFREV) is not favored by some of you? Maybe there's a better approach?

I'll say that I still want these points to apply:
- Macros shouldn't be as long as they used to be (or else the compiler may trim some of them).
- There should be one EXEDEF macro per EXE, mentioned *only* in VERSION.H and VERSION.EQU. I basically think it's (somewhat) better in terms of maintenance. It's also a good way to clarify that shareware v1.1 isn't of the the same revision as registered v1.1.

The thing is, maybe I should've used names like "GAMEVER_WOLF3D_PREREG" for shareware versions 1.0 and 1.1. But then, GAMEVER_WOLFREV can be used to (roughly) describe a range of code revisions, and not necessarily specific game versions.

There's also the special case of GAMEVER_WOLFREV being compared to 19921007L in ID_PM.C. (Yeah, I could use 19921008L, but I tried to be consistent, so I always used "<=" in comparisions, rather than ">"; Admittedly a bit of an imperfect situation.)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 30 Oct 2017

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

PostPosted: Thu May 25, 2017 6:22 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

Thanks NY00123. I noticed Shareware v1.0 doesn't have most code for the Nocturnal Missions, so I used that difference as a base to add a WL3 fork into my patched Apogee v1.2 today. The updated zip can be found here or here (diff KEEP_WOLFWL6).

I might clean out SOD demo next, as wl_act2 kept all enemies/bosses. Looking forward to your Japanese addition as well. Very Happy
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

blank.gif

PostPosted: Tue Jun 06, 2017 2:25 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

Think it's time for another update. Let's begin with a few initial notes:

- It turned out the Blake Stone codebase had a silly typo specific to AOG. In the AOG versions of the enemy_t enum, en_goldmorphshot was mistakenly defined instead of en_arc_barrier. It was also used instead of en_arc_barrier in AOG-specific code pieces, but luckily it didn't occur that much.
Interestingly, the EXEs *still* built as expected! Thanks to Aryan_Wolf3D for reporting this.

- Following some feedback, I've changed some stuff with the Wolfenstein 3D game versions *yet again*. Basically, instead of comparing GAMEVER_WOLFREV to mere numbers, helper macros are used, prefixed with GV_WR (e.g., GV_WR_WL1AP10). Note that there's still an exception to this rule in ID_PM.C (with the AJR bug-fix).
Sorry if this has caused more mess for anybody, but hopefully it won't happen that much start.

Now, hopefully these updates will be more interesting:

- I suppose at least a few users have wondered about this, especially after an earlier reference of mine in DHW. Thanks to some assistance, you can now recreate the DOS EXE from the Wolfenstein 3D 6-episodes Japanese version!
As expected, there wasn't really much code to add, since it's already found under the "JAPAN" ifdefs. I did use that old recreated FOREIGN\JAPAN\GFXV_WJ6.H file I previously referred to.
It was almost there, *really*. Only the value of CONTROLS_LUMP_END had to be corrected, heh. Other than these points, and the different sign-on screen, WJ6IM14.PRJ is essentially the same as WL4GT14A.PRJ, just with JAPAN defined instead of GOODTIMES.

- Next, there's basically a bonus. Usually, I wouldn't cover such game's versions, since they're generally not intended for public usage. However, the following version of Wolfenstein 3D apparently started to get widely accessible even in 1992, and may even be considered another "semi legitimate" shareware release (although I won't link to it here).
That's right, I'm talking about recreating the EXE from that Wolfenstein 3D March 1992 alpha/beta build! Recreated code is now available from my repository. One surprise to mention is the various occasions in which S3DNA and the alpha are grouped together (under #if conditions). There are also a few cases in which S3DNA and v1.0 (and possibly also the alpha) are grouped, but I don't recall that many of these. Also, there's a somewhat(?) interesting name for the contents of some unused variable in WL_TEXT.C (present in the alpha only); Leaving it for you too locate this name, heh.
In addition, there's this empty stub, which I originally added to ID_VH.C under the name of VW_NullStub, while recreating v1.0. Turns out, it was (almost surely) named VW_SetDefaultColors. Reason is that it is called from MM_ShowMemory in Catacomb 3-D, and the code is almost the same in that Wolf3D March 92 build. Furthermore, except for VW_SetDefaultColors, this implementation of MM_ShowMemory is also present in Keen Dreams, albeit access to it from KD_MAIN.C was originally disabled in the sources (using FRILLS). There are also other cases in which some alpha code is similar to Keen Dreams and/or Catacomb 3-D code piece.

- Finally, I've added a new "HOWTO.md" file, partially describing some points about the process of recreating EXEs built with Borland C++ 2.0/3.0/3.1.

LATE POST EDIT (June 7 2017): Looks like I've forgotten to mention one more thing. Did you know that I originally started this codebase as a git repository hosted by GitHub? Well, this is what happened, basically hosting the Catacomb Abyss sources, modified to recreate CATABYSS.EXE from shareware version 1.13 (QA [0]). Just a week later, though, I moved to a Mercurial repository hosted by BitBucket, and added a few Wolf3D and SOD versions (Wolf3D shareware v1.4, SOD demo v1.0 and the Activision versions).
I did get rid of the original git repository as originally hosted on GitHub. Luckily, though, I've still had a local copy of this repository. It is now up on BitBucket in the following link (note it's still a git repository, *not* a Mercurial one): https://bitbucket.org/NY00123/game-srccode-ver-recreation-git-legacy/


Last edited by NY00123 on Wed Jun 07, 2017 9:05 am; edited 4 times in total
Aryan_Wolf3D
I am Death Incarnate
I am Death Incarnate


Joined: 21 Jul 2011
Last Visit: 16 Nov 2017

Topics: 6
Posts: 171

blank.gif

PostPosted: Tue Jun 06, 2017 2:31 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 for the update, NY00123! It'll be really interesting to see just what is contained in the alpha EXE! Laughing

_________________
"Way too many #ifdefs in the code!" - John Carmack
NY00123
Can I Play Daddy
Can I Play Daddy


Joined: 20 May 2015
Last Visit: 25 Jun 2017

Topics: 1
Posts: 26

blank.gif

PostPosted: Tue Jun 06, 2017 2:55 pm
   Subject: Re: Restoration of other Wolf3d/Spear EXE versions
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

Chris wrote:
Thanks NY00123. I noticed Shareware v1.0 doesn't have most code for the Nocturnal Missions, so I used that difference as a base to add a WL3 fork into my patched Apogee v1.2 today. The updated zip can be found here or here (diff KEEP_WOLFWL6).

I might clean out SOD demo next, as wl_act2 kept all enemies/bosses. Looking forward to your Japanese addition as well. Very Happy


It is great to see how you (and others) are messing with these different code revisions! Hope you have fun checking out the Japanese addition, although I think the alpha has much more to show.

Aryan_Wolf3D wrote:
Thanks for the update, NY00123! It'll be really interesting to see just what is contained in the alpha EXE! Laughing


Great! Hope you'll find the time to look into the alpha (if not already done).
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 6401 Tue Feb 08, 2005 5:44 am
Guest View latest post
No new posts [Help] Setting RocketLauncher: Explosive Range...?
Author: KyleRTCW
17 4223 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 104 Sun Jul 06, 2003 1:25 pm
Guest View latest post
No new posts [Info] Alarm Sounding in game?? WSJ...??
Author: Guest
7 308 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