#Gzdoom strife code

#Gzdoom strife code

A region of new code between m_misc.c and am_map.c which implements the hub savegame system, starting at 0001:0001B078 in the 1.2 binary.This code was folded into the end of p_user.c in Chocolate Strife, based on its close relationship to code in the preceding p_user.c module. A region of new code between p_user.c and r_bsp.c which implements the inventory system, starting at 0001:00030710 in the 1.2 binary.This module was reconstructed and named p_dialog.c in Chocolate Strife. A region of new code between p_telept.c and p_saveg.c which implements the dialog system, starting at 0001:0002D990 in the 1.2 binary.Major differences that can be inferred to have existed on a source code module level include the following: These qualities together make reversing of the code significantly simpler than it would be if the code were emitted by a modern optimizing compiler. Functions are preserved in the binary in mostly the same ordering as they occur in the Doom source code, excepting instances of inlining by the compiler, and functions which have been inlined are still retained in their original locations as well in all but a few cases.

The structure of the Strife source code can be directly ascertained from observation of the binaries, due in large part to Watcom's lack of function-level linking capability - the modules are preserved in the binary in the exact same ordering that has been observed in the makefiles for Heretic and Hexen, and there is a 100% overlap with modules in the Doom source code with exceptions that follow below. In 2022, a faithful restoration of the Strife source code was added to the gamesrc-ver-recreation project. In 2014, Stephen Kick of Night Dive Studios began an attempt to recover the source code from a backup of the Rogue Entertainment assets in concert with his release of Strife: Veteran Edition, but has so far been unsuccessful. The stated goal of the Chocolate Strife project from its onset was to create a replica of the original code which was as humanly close as possible to perfect, given the inherent limitations in reversing compiled code (symbol names, to a great extent, and all comments are unrecoverable regardless of techniques employed). Samuel Villarreal produced an early attempt at emulation of Strife in the form of SvStrife that did not involve direct reversing, and then later cooperated with James Haley (Quasar) on the Chocolate Strife project, which utilized cutting-edge reverse engineering tools to fully disassemble and decompile every line of code in the binary (including portions of libraries such as DMX where necessary). To date, separate reverse engineering projects have been undertaken by source port authors involved with the Vavoom and ZDoom ports. Multiple projects have been undertaken to reverse engineer the Strife executable, with goals varying widely in terms of fidelity and compatibility. With both the developer and publisher of the game fully divested and dissolved as companies, and no known copies of the source in the possession of those who worked on it personally, it must be assumed the code has been irrevocably lost.

Unfortunately when he arrived, he found that the old NeXT servers used for Strife's development had been sold off and no known backups of their contents were on site.Įarly attempts at contacting Peter Mack made by Samuel Villarreal (Kaiser) were successful, and Peter thought he might still have a copy of the code on some of his old disks, but he was never able to locate it. According to Monroe, Carmack agreed to the release and he proceeded to travel in person to Rogue's offices to see if he could obtain a copy of the code (at that time, James was already now working for Raven in Madison, Wisconsin).

James Monroe, by his own admission, contacted John Carmack shortly after Raven Software's release of the Heretic and Hexen source codes to see if following suit with Strife would be possible.

4.4 Resurrection of unused code from Doom.