Duke4.net Forums: Shadow Warrior 1.0-1.2 EXEs Accurately Recreated, Source Code Re-released - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Shadow Warrior 1.0-1.2 EXEs Accurately Recreated, Source Code Re-released

User is offline   Hendricks266 

  • Sperge Overlord
  • 6,319

  #1

With access to SW materials from the 3D Realms archives and official blessing from Devolver, NY00123 has extended his gamesrc-ver-recreation project to cover Shadow Warrior (1997). In addition to accurately recreating 1.2 Registered, we can also recreate several versions and variations, including 1.0, 1.1, and 1.2 Shareware.

https://twitter.com/NY00123/status/1093204288560656390

NY00123 said:

Thanks to @devolverdigital, @3DRealms, @Hendricks266, TerminX (@voidpnt) and Ken Silverman, you can now download the following package consisting of Shadow Warrior sources matching versions 1.0-1.2, a few older Build engine sources, and other files:

https://ny.duke4.net/files/stuff/sw-src-and-build-addendum-20190129.7z

NY00123 said:

========================================================================
Shadow Warrior (1997) and bonus Build Engine Source Codes Release - 2019
========================================================================

LEGAL
-----

This archive covers differing source snapshots of Shadow Warrior (1997),
a few Build Engine sources, and other files.

The Build Engine sources are licensed under the terms
of the Build Source Code License. They can be found in BUILDLIC.TXT.

The Shadow Warrior (1997) code is licensed under the terms of the GNU GPL
(General Public License) version 2 or later. See GPL-2.0.TXT for the details.

In addition to the terms of the GNU GPL referenced above, you are granted
a linking exception, for the purpose of linking any of the aforementioned
Shadow Warrior (1997) sources with other code used in
the original EXEs from 1997. This also covers derivatives
of the same code, like modern ports of the Build Engine.

Be warned that in general, the terms of the GNU GPL do *NOT* apply to any
such additional code. The Build Engine is a good example of this.

In particular, commercial exploitation of the additional code
is *NOT* allowed unless specifically permitted.

Please do not contact us for help with using the source code. We cannot
assist with getting this running and there is no guarantee of any kind.
Use at your own risk.

Any following mention of "Shadow Warrior" or "SW" will refer to the 1997 game.

ACKNOWLEDGEMENTS
----------------

This release is dedicated to the memory of Terence Colligan. Further known as
Terry, he was the founder of Tenberry Software (previously Rational Systems).
A notable product of this company for the time was DOS/4G, a DOS extender
used for a myriad of 32-bit DOS programs, and games in particular.
These include games made with the Build engine,
Shadow Warrior being no exception.

Many thanks go to 3D Realms for digging up old materials found in this
archive, including the Shadow Warrior source codes, later to be sent to
Richard Gobeille and Evan Ramos, who further inspected such materials.

Additional thanks go to Evan for getting the ball rolling, Devolver Digital
for their permission to release the old Shadow Warrior materials, and
Ken Silverman for his consent to release the older Build Engine sources.

Further thanks go to Ken Silverman for open-sourcing the Build Engine on 2000,
and to anybody involved in open-sourcing Shadow Warrior on 2005.
This includes Frank Maddin (one of the original Shadow Warrior programmers)
for digging up the sources and assisting with their release, Jonathon Fowler
(responsible for the JonoF ports of Build, Duke3D and SW) using his experience
for technical assistance, Charlie Wiederhold for preparing the
sources for release and 3D Realms for paving the way.

Finally, thanks to all fans of 3D Realms, Devolver Digital,
General Arcade, Shadow Warrior and the Build engine!

Building any of the Shadow Warrior EXEs or the SW Build editor EXE
------------------------------------------------------------------

The Shadow Warrior sources found in this archive were prepared in
such a way that with the right tools, you can create EXEs functionally
equivalent to the ones released on 1997, up to the following differences:
- Adding MemCheck (MC) 3.5 library code in the linking stage.
- Binding the DOS/4GW Professional 1.97 extender.

The SW EXEs in question can be found under the "exes" subdirectory, all
being named SWNMC.EXE. The SWB.EXE files are the originals from 1997, while
the SW.EXE ones are essentially SWB.EXE with the DOS/4GW extender removed.

For the Build editor, the relevant EXE is BUILDNMC.EXE.
As in the case of SW, BUILDB.EXE is the original EXE from 1997,
while BUILD.EXE is simply BUILDB.EXE without the extender.

For the behaviors to be as close to the originals as possible, it is important
to use Watcom C32 10.6, and no other version. If you don't mind the
accuracy, you can still try to use a different version,
but this has *NOT* been tested.

The following build directories are recommended if you want to further
increase the accuracy of the recreation (mostly for debugging information):
- Shareware versions 1.0 and 1.1, as well as the registered and
parental locked releases (1.2): C:\DEV\SW.
- Version 1.2, shareware and UK releases: H:\DEV\SW.
- The Build editor (as originally distributed with the game): C:\JIM\SW\CODE.

Additionally, for SW 1.2, it's recommended that the copy of Watcom C32
in use is found exactly at C:\WATCOM. In particular, this includes
setting the INCLUDE environment variable's value to C:\WATCOM\H,
in an uppercase (well, UPPERCASE) form.

Side-note: For SW 1.0 and 1.1, the Watcom path is shown in the original SW.MAP
files in the lowercase form of c:\watcom (as a part of c:\watcom\lib386).

Steps for building any of the EXEs:
1. Make sure you have a compatible DOS environment with a ready installation
of Watcom C32. As stated above, version 10.6 is (highly) recommended.
2. Further ensure there's no existing directory named DEV in the same
location as this README.TXT file and the PREP.BAT file.
3. Run PREP.BAT and then select the SW EXE you want to make. If you want
to make the editor EXE, choose any of the SW 1.2 EXEs.
4. Wait for PREP.BAT's run to complete. You should end up with files ready for
building under DEV\SW. As stated above, you may wish to set the exact location
appropriately (e.g., to H:\DEV\SW for the UK version), but this is optional.
5. Change to this same directory. To make the SW EXE, run MAKESW.BAT.
6. If you have previously chosen to prepare the files for any EXE matching
version 1.2, you can further make the Build Editor EXE by running MAKEBLD.BAT.
7. Please be warned that you may wish to ensure the DEV\SW\OBJ directory does
*not* include any of the following files first: MDASTR.OBJ, COLORMAP.OBJ.
Otherwise, the layout of any involved EXE may change, at least if
you're trying to build the game and editor EXEs altogether.

Faithfully recreating any EXE, given access to additional files
---------------------------------------------------------------

Please note that any output EXE file might still differ from the original,
depending on the specific MemCheck and DOS/4GW Professional files in use.

You should first prepare a modification of the PREP.BAT file:
1. Comment out this command: "call tools\striphdr DEV\SW newstuff\HOOKS.C"
2. Uncomment the next line: "REM copy source\CODE\OBJ\HOOKS.OBJ DEV\SW\OBJ"
3. Make sure the original unmodified make files are copied. In particular,
replace newstuff\sws10\MAKEFILE with source\sws10\MAKEFILE,
newstuff\SWV11\MAKEFILE with source\SWV11\MAKEFILE and/or
newstuff\SWV12ADD\MAKEFILE with source\CODE\MAKEFILE,
depending on the SW EXEs you want to recreate. For the Build editor,
replace newstuff\SWV12ADD\makebld with source\CODE\makebld.

Afterwards, you may create a source tree with the modified PREP.BAT file
(under DEV\SW) as previously described. You should then follow these steps:

1. Optionally edit the make file to omit the dependencies
on MC35A3S.LIB and RXA3S.LIB.
2. Make sure the following files from MemCheck 3.5 are present
in the same source tree: MC35A3R.LIB, RXA3R.LIB. If you don't edit
the make file, you'll also have to add MC35A3S.LIB and RXA3S.LIB.
3. Build the EXE as previously described.
4. To bind the DOS/4GW Professional 1.97 stub, make sure the files 4GWPRO.EXE
and 4GWBIND.EXE are present in the same directory. Use them like this:
"4gwpro 4gwbind sw.exe swb.exe -v"

Bonus addendum - Making the ENGINE.OBJ file (SW 1.1 & 1.2)
----------------------------------------------------------

As stated above, a few older Build Engine sources were released. These
include an old CACHE1D.TXT file from 1995, as well as a "blddbg" subdir
that has the required source files for ENGINE.OBJ as originally used
for Shadow Warrior versions 1.1 and 1.2.

To make sure the created file is sufficiently close to the original
(and even has the exact same file size):
- Use Watcom C32 10.6, and no other version. It should be installed
to c:\watcom. In particular, the INCLUDE environment variable should
be set to c:\watcom\h. Be warned that unlike the case of the SW 1.2
game code, here, "c:\watcom\h" should be fully lowercase
(which is actually matching SW 1.1's SW.MAP).
- Ensure the ENGINE.OBJ sources are ready under the "D:" path.

Use this command to create ENGINE.OBJ: wcc386 engine /4r /s /or

If done correctly, the output file will be the same as the original,
up to differences related to the timestamps of the source files.

Description of the contents of this archive
-------------------------------------------

For a little background, there were originally a few directories found in
3D Realms' archives, with their contents later being split across differing
directories for this release. In particular, there was this directory
named "CODE" that had not just a Shadow Warrior source snapshot,
but also additional files required for making the EXEs.
It also turned out to have a backup of a few older Build engine sources.

If you want to have a really short summary, then basically, source\sws10
has the code for SW 1.0, source\SWV11 covers 1.1, and for 1.2 you need
to combine source\REGCODE with the correct files from source\SWV12ADD.

It is possible that this package will be updated in the future,
provided that more work is done on additional contents.

A summary of the included contents is following.

README.TXT: This file.

FILESLST.TXT: A list of old files with their original line counts
(for textual files), sizes and timestamps, before modifications
were applied (like the addition of GNU GPL headers).

PREP.BAT: A helper Batch file that can be used for preparing a source code
tree, eventually letting you make a working EXE with Watcom C.

tools: Helper batch files and an extra tool, each of these
being copied/used by PREP.BAT.

build\CODE: This includes a few Build Engine source materials.
BUILD.TXT and BUILD2.TXT are earlier revisions of the documents
released by Ken to the public on 2000. CACHE1D.TXT is an old
renamed version of CACHE1D.C from 1995. The blddbg subdir
includes the code for ENGINE.OBJ as originally used
in versions 1.1 and 1.2 of Shadow Warrior.

F_OBJS: The contents of a miscellaneous OBJS.ZIP file which was found. Out of
these files, ENGINE.OBJ was used for version 1.0 of Shadow Warrior.

newstuff: Some new or recreated files. For one, this includes OBJ files made
out of proprietary code, for which the sources are not included. As stated
above, the terms of the GNU GPL do *NOT* apply to this code. These files
are provided for the purpose of recreating SW EXEs as close to the
originals as possible.
There are also MAKEFILEs edited from the originals, found under the "source"
subdirs of sws10, SWV11, CODE and REGCODE, in order to remove the dependencies
on MC. As a bonus, static symbols are now added to the linker's output MAP
files. Another file added is HOOKS.C, recreated from HOOKS.OBJ as used in
SW 1.0-1.2. Reason is that the original HOOKS.OBJ file depends on the
MC library. In particular, it is guessed that the same HOOKS.OBJ file
was built using headers from SWC0507B, including GAME.H, which had
DEBUG defined to 1 (and thus, leading to a dependency on MC).

exes: A collection consisting of the original SW and Build editor EXEs,
in binded and unbinded forms. The latter lack the binded DOS/4GW extender.
There are also alternative unbinded EXEs excluding the MC
libraries' code that you may use for comparisons.

source: Differing snapshots of the Shadow Warrior sources.

source\sws10: Version 1.0.

source\SWV11: Version 1.1.

source\REGCODE: A revision earlier than 1.2 by not more than a few
days. This revision is the closest to version 1.2 out of what was found.

source\SWV12ADD: A list of changes on top of REGCODE intended for the
recreation of the code in 1.2. While some of these come from the GPLed
release of 2005, other missing code pieces had to be re-filled in GAME.C.

source\SWV12ADD\ALT: Alternative files for the registered and parental
locked versions. Compared to the shareware and UK versions, the differences
are a bit silly: A few global variables were shuffled around in order
to recreate the original EXEs' layouts. There are good chances
this wasn't the way the EXEs were originally created; Maybe
about 1-3 header files were modified instead.

source\SWC0507: A source snapshot added for the simple reason
we also have SWC0507B covered...

source\SWC0507B: A source snapshot that is assumed to be the one used
for building HOOKS.OBJ as present in SW 1.0-1.2.

source\SWC0511: A source snapshot originally used while trying
to recreate the EXE from version 1.0, in conjunction with sws10.
It isn't in use by PREP.BAT, but it's provided for reference.

source\SWC0519: A source snapshot similarly used while attempting
to recreate SWV11's EXE. It's also not in use by PREP.BAT.

source\CODE: A snapshot of contents from the "CODE" dir,
covering not just a Shadow Warrior source snapshot
(earlier than REGCODE by about 3 days), but also
additional files used for building all EXEs.

extras: Unused files from the above-mentioned source code subdirs
(like SWV11), as well as additional files not in direct use by PREP.BAT.

-Yoav N.

24

User is offline   NY00123 

  • 160

#2

Hope you'll have some fun (at the least!) with this release :)

Now, as some of you might know, I started this aforementioned code repository that I shamelessly titled "gamesrc-ver-recreation" back on 2014. For the ones not familiar with it, you can check out the following thread's first post: https://forums.duke4...-exes-versions/

This repository was inspired by multiple original versions of Softdisk's Keen Dreams title getting open-sourced on 2014, as well as related interests (e.g., the Chocolate Doom port).

Still, I don't think I believed that gamesrc-ver-recreation could literally pave the way for another similar release, i.e., Shadow Warrior (1997). Let's not forget the Build engine, too.


I'm probably bad with the credits as usual...anybody not mentioned here who deserves some credit (even if really tiny), please consider yourself credited as if you were listed!

Yeah, I know this probably won't work, but it's good to try...

Either way, I'll first quote from the README (80 columns constraint covered):

Quote

Many thanks go to 3D Realms for digging up old materials found in this
archive, including the Shadow Warrior source codes, later to be sent to
Richard Gobeille and Evan Ramos, who further inspected such materials.

Additional thanks go to Evan for getting the ball rolling, Devolver Digital
for their permission to release the old Shadow Warrior materials, and
Ken Silverman for his consent to release the older Build Engine sources.

Further thanks go to Ken Silverman for open-sourcing the Build Engine on 2000,
and to anybody involved in open-sourcing Shadow Warrior on 2005.
This includes Frank Maddin (one of the original Shadow Warrior programmers)
for digging up the sources and assisting with their release, Jonathon Fowler
(responsible for the JonoF ports of Build, Duke3D and SW) using his experience
for technical assistance, Charlie Wiederhold for preparing the
sources for release and 3D Realms for paving the way.

Finally, thanks to all fans of 3D Realms, Devolver Digital,
General Arcade, Shadow Warrior and the Build engine!


Special thanks go to: Nigel Lowrie, Gennadii Potapov, Frederik Schreiber, Joe Siegler, Samuel Schultz, Barry Duncan, Jarmo Kylmäaho, Leo Pellegrini, Max Ylitalo, Robert Rafii, Geoff Sims, Braden Obrzut, David Gow, Levellass, lemm, Adam Nielsen and Nuke.YKT.

Finally, thanks to the Duke4.net, PCKF and VOGONS communities, as well as any other related retro-gaming community!


This post has been edited by NY00123: 06 February 2019 - 11:34 AM

18

User is offline   Jimmy 100MPH 

  • Trooper
  • 4,328

#3

Posted Image

Coke costs a lot of money you know. - oasiz
0

User is offline   leilei 

  • 526

#4

                    strcpy(&botbuff[0][0],"Human's suck!  Bots kick ass!");
                    qcnt=1;
                    break;
                    case 2:
                    strcpy(&botbuff[0][0],"Drink it down dork!");

Nice, the bots are in there!

Posted Image
1

User is offline   Ninety-Six 

  • 146

#5

Not to downplay this as I'm sure it's a big deal, I just don't quite understand it so I am a bit confused. So from the standpoint of someone who doesn't grasp everything, what does this all mean? I thought the source code was already released?
2

User is online   Jblade 

  • 1,761

#6

View PostNinety-Six, on 06 February 2019 - 09:49 PM, said:

Not to downplay this as I'm sure it's a big deal, I just don't quite understand it so I am a bit confused. So from the standpoint of someone who doesn't grasp everything, what does this all mean? I thought the source code was already released?

IIRC the source that was released was an older version that didn't even have MP working, this is a more recent version.
0

User is offline   Ninety-Six 

  • 146

#7

View PostJblade, on 06 February 2019 - 09:56 PM, said:

IIRC the source that was released was an older version that didn't even have MP working, this is a more recent version.

That would certainly explain it.

This post has been edited by Ninety-Six: 06 February 2019 - 10:19 PM

0

User is offline   NY00123 

  • 160

#8

Going to mention the following for the record:
- This release was made public on February 6 2019, at least in all Eastern/Central/Western European and North/Central/South American time-zones that I'm aware of.
- The reason it says "20190129" in the archive name, is that this is the day when README.TXT was updated for the last time and the released 7Z file was actually created.
- Since I was asked about this (outside of these forums), the reason that I went for a 7Z file, rather than uploading the sources to a website like GitHub, Bitbucket or GitLab, is that it preserves timestamps. Admittedly, though, FILESLST.TXT should already cover the more important timestamps (at least before changes applied by me to most files).

Of course, I knew there was something I kinda forgot to say previously. As we can't edit posts after some limited time:

To continue from that post, again, I didn't think that gamesrc-ver-recreation could indirectly lead to anything like this release. It was really Hendricks who pushed me to do this, and as previously said, others had their roles as well.

I think this is actually a kind of a victory. If not for me, then for Devolver Digital, for anybody else who had a part in this release, and of course, for all of you.

Did I already say or hint that I had problems with the "credits" part? Whatever I previously said still applies...

In addition to the aforementioned SW (1997) developer Frank Maddin, thanks should be sent to Jim Norwood, not just for being directly involved in the development of this game like Frank, but also for previously granting his consent related to some earlier work I did with regards to Bio Menace (that's for another topic, and it was already posted, either way).

Additional special thanks are sent to: Alex Dawson, Ben Moir, Corentin Dallay, Fox, Green, 75, Jonathan Strander, Jordon Moss, Alon Amir, Replica, Turrican, Jaks, Juras, Skydro, Sjoerd van den Berg, Peter Veenstra, Ulf Wohlers, Tommy Frössman, Dean Beeler, Sebastian Strohhäcker, Ralf Grillenberger, P4R4D0X and VileRancour.

View Postleilei, on 06 February 2019 - 09:43 PM, said:

Nice, the bots are in there!


Indeed, SW 1.1 still has partially functional code (and possibly also 1.0). I'm quite sure it can even be toggled on with bits of hex editing, but now we have the exact sources, don't we? ;)

Here's a patch that I've applied on top of SW 1.1's GAME.C as released yesterday (note that the diff does not show carriage-returns; The attached 7Z file includes the correct diff):

diff -ur sw-src-and-build-addendum-20190129/source/SWV11/GAME.C sw-src-and-build-addendum-20190129-test/source/SWV11/GAME.C
--- sw-src-and-build-addendum-20190129/source/SWV11/GAME.C	2019-01-28 22:32:26.055704100 +0200
+++ sw-src-and-build-addendum-20190129-test/source/SWV11/GAME.C	2019-02-07 21:31:03.456137800 +0200
@@ -3369,7 +3369,7 @@
                 }
             }
         else
-        #ifndef SW_SHAREWARE
+//        #ifndef SW_SHAREWARE
 		if (memcmp(argv[cnt], "-bots", 5) == 0)
             {
             if (strlen(argv[cnt]) > 5)
@@ -3381,7 +3381,7 @@
                 }
             }
         else
-        #endif
+//        #endif
 		if (memcmp(argv[cnt], "-coop", 5) == 0)
             {
             if (strlen(argv[cnt]) > 5)


I've attached a 7Z file with an EXE compatible with shareware v1.1's data that I've built with this (and an SW.MAP generated by the linker as a bonus).

Some notes (including caveats):
- Don't use DOSBox 0.74 or 0.74-2, the game will probably crash (as is the case with vanilla versions 1.0 and 1.1). Use a more recent SVN build instead.
- To anybody actually checking this, you'll probably realize why the bot code didn't survive into v1.2.
- The generated EXE requires DOS4GW.EXE or a compatible loader.
- Run as follows: "SW -level1 -monst -bots4"

Attached File(s)




This post has been edited by Lunick: 15 February 2019 - 12:21 AM

6

User is offline   NY00123 

  • 160

#9

I've uploaded the archive's contents to GitLab, including a copy of the original 7Z file itself (remove "tags" from the URL in order to browse the code in the...browser): https://gitlab.com/N...d-addendum/tags

Additionally, since I'm well-aware of "tl;dr", see the preceding post's very end for (quite incomplete) bot AI support in a modified SW 1.1.
1

User is offline   Master O 

  • 82

#10

View PostHendricks266, on 06 February 2019 - 10:37 AM, said:

With access to SW materials from the 3D Realms archives and official blessing from Devolver, NY00123 has extended his gamesrc-ver-recreation project to cover Shadow Warrior (1997). In addition to accurately recreating 1.2 Registered, we can also recreate several versions and variations, including 1.0, 1.1, and 1.2 Shareware...


Out of curiosity, how will this affect Shadow Warrior's eventual support within EDuke32?
0

User is offline   malvado 

  • 9

#11

Does this mean somebody can make a good source port to replace SW Redux? That thing runs awful for me and the mouse doesn't feel good at all. Thing has gross variable input lag and generally has a jittery feel, not fun.
2

User is offline   Jimmy 100MPH 

  • Trooper
  • 4,328

#12

This could mean more accurate to the original exe ports, but the problems with JonofSW, SWP, Redux extend far beyond original source code.

Coke costs a lot of money you know. - oasiz
0

User is offline   DustFalcon85 

  • 513

#13

View PostNY00123, on 06 February 2019 - 10:57 AM, said:

Special thanks go to: Nigel Lowrie, Gennadii Potapov, Frederik Schreiber, Joe Siegler, Samuel Schultz, Barry Duncan, Jarmo Kylmäaho, Leo Pellegrini, Max Ylitalo, Robert Rafii, Geoff Sims, Braden Obrzut, David Gow, Levellass, lemm, Adam Nielsen and Nuke.YKT.

Finally, thanks to the Duke4.net, PCKF and VOGONS communities, as well as any other related retro-gaming community!


And a no thanks and a big "Screw You" goes to...
Spoiler

-2

User is offline   Ninety-Six 

  • 146

#14

View PostJimmy 100MPH, on 09 February 2019 - 08:02 AM, said:

This could mean more accurate to the original exe ports, but the problems with JonofSW, SWP, Redux extend far beyond original source code.

Where do they extend to?
0

User is offline   MrFlibble 

  • 646

#15

On a somewhat related note, any chance that the code for LameDuke could be reconstructed in the same way?
0

User is offline   K1n9_Duk3 

  • 170

#16

View PostMrFlibble, on 09 February 2019 - 10:25 AM, said:

On a somewhat related note, any chance that the code for LameDuke could be reconstructed in the same way?

It wouldn't be impossible, the main issue is probably in getting permission and the old source backups from Gearbox. Or you could just reverse-engineer the whole thing, similar to what people did with Blood and Redneck Rampage, although they didn't recreate the full DOS version as far as I know.

Hail to the K1n9, baby!
0

User is offline   TerminX 

  • el fundador
  • 5,532

  #17

View PostK1n9_Duk3, on 09 February 2019 - 10:36 AM, said:

as far as I know.


EDuke32wikisvn buildsbugs
Join us in #eduke32 on irc.freenode.net!
2

User is online   Mark 

  • Honored Donor
  • 2,822

#18

.

Attached File(s)

  • Attached File  tenor.gif (277.96K)
    Number of downloads: 17

0

User is offline   leilei 

  • 526

#19

View PostK1n9_Duk3, on 09 February 2019 - 10:36 AM, said:

Or you could just reverse-engineer the whole thing,

There's also the problem with recreating the old pre-May95 Build without much source. One feature it had (instead of slopes) is some height bump voxel floor/ceil thing that was unstable (which I don't think Duke used in 94 but it was certainly possible)

Posted Image
0

User is offline   Hendricks266 

  • Sperge Overlord
  • 6,319

  #20

View Postleilei, on 09 February 2019 - 06:00 PM, said:

One feature it had (instead of slopes) is some height bump voxel floor/ceil thing that was unstable (which I don't think Duke used in 94 but it was certainly possible)

We have full engine source from May 95, including the groudraw feature you refer to.
3

User is offline   NY00123 

  • 160

#21

So there are a few tidbits that I haven't seen anybody commenting about. Guess that I'll add my words on it :)

- Anybody spotted this PREP.BAT script from the released archive? It's referencing tools\STRIPHDR.EXE (and also a few other batch files in "tools" that in turn call STRIPHDR.EXE).

STRIPHDR is used in order to make some kind of "pre-processing" to .C files (say from the SW 1.1 sources as found under source\SWV11), before storing these in DEV\SW, rather than merely copying them to there.

- What is exactly done to these .C files? Well, STRIPHDR describes itself as a "Code header stripper", which "Strips headers from C/C++ sources" under certain conditions.

That's right, it is used to strip the headers that reference the GNU General Public License.

But why? Shouldn't they be there, for very obvious reasons?

- Well, the practical reason for stripping the headers is that you can find mentions of __LINE__ in the SW code. That's right, exact line numbers are used in a few places, theoretically impacting the behaviors of the game. Or do they?

I knew it wasn't much of the case in SW 1.2. They seem to be used just for debugging, in functions like _PlayerSound (via the PlayerSound macro) and _ErrMsg, and even then, only in cases of fatal errors leading to abnormal exits.

- But what about SW 1.0 and 1.1? They have the RANDOM_DEBUG macro defined to 1 in GAME.H. A few more lines reveal the following:

#define RANDOM_DEBUG 1 // Set this to 1 for network testing.
#if RANDOM_DEBUG
int RandomRange(int, char*, unsigned);
int krand(char*, unsigned);
#define RANDOM_P2(pwr_of_2) (MOD_P2(krand(__FILE__,__LINE__),(pwr_of_2)))
#define RANDOM_RANGE(range) (RandomRange(range,__FILE__,__LINE__))
#define RANDOM() (krand(__FILE__,__LINE__))
#else
int RandomRange(int);
int krand(void);
#define RANDOM_P2(pwr_of_2) (MOD_P2(krand(),(pwr_of_2)))
#define RANDOM_RANGE(range) (RandomRange(range))
#define RANDOM() (krand())
#endif


Uh oh. Does this mean that random number generation depends on precise line numbers? In particular, is the addition of the GNU GPL headers impacting the ability to reproduce original demos? Note also the "network testing" comment, which might be a good hint.

Well, I've actually started to prepare videos of original SW 1.1 demo playbacks showcasing the differences. As it turns out, I haven't spotted any.

- Inspecting the random number generation routines reveals that, again, __FILE__ and __LINE__ are merely used for debugging. Going over the implementations of RandomRange from AI.C (https://gitlab.com/N...GCODE/AI.C#L145), as well as krand and krand2 from GAME.C (https://gitlab.com/N...ODE/GAME.C#L341), we can see why:

1. krand2, which is defined only if RANDOM_DEBUG is nonzero, differs from the non-RANDOM_DEBUG implementation of krand just by the lack of incrementing krandcount. But krandcount is never even used outside krand. Additionally, the RANDOM_DEBUG implementation of krand differs from krand2 just by the addition of conditionally writing debugging information. One of these conditions is the presence of the "-randprint" command-line argument.

2. The two implementations of RandomRange in AI.C differ by similar optional debugging information, as well as the usage of krand2 in the RANDOM_DEBUG version and the RANDOM macro in the other. But we can see that for non-RANDOM_DEBUG builds, RANDOM() is simply defined to (krand()) in GAME.H, and we've already established that it's equivalent to krand2.

3. It should now be clear that, except for any added debug output, the RANDOM_DEBUG macro makes no practical differences when it comes to the definitions in GAME.H, and also in AI.C and GAME.C.

4. As a side-note, in version 1.2 (and similarly the CODE+REGCODE revisions), these RandomRange implementations were more-or-less copied from AI.C into GAME.C, while the AI.C implementations were left behind. I don't think that this otherwise has any impact. You can see in a few SW*.MAP files (under "exes") that there are warnings like this: "Warning(1027): file .\obj\ai.obj(C:\DEV\SW\ai.c): redefinition of RandomRange_ ignored"

- Bonus point: Wait, haven't I mentioned krand? Isn't this a Build engine function? It doesn't belong to the SW game code, does it?

Well, it's basically *overriding* the engine implementation; That's the simple explanation. You can see a warning like the following one in the linker-generated SW*.MAP files: "Warning(1027): file .\obj\engine.obj(D:\engine.c): redefinition of krand_ ignored"
4

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Maiden! ;) © 2018 Voidpoint, LLC

Enter your sign in name and password


Sign in options