El código fuente de Strife, los archivos legibles por humanos a partir de los cuales se podría producir el ejecutable de Strife, a diferencia del código de la mayoría de los otros juegos comerciales del motor de Doom, nunca se ha publicado. Según James Monroe, programador principal del juego en Rogue Entertainment, y su colega Peter Mack, esto se debe a que se han perdido todas las copias conocidas del código.
Intento de liberación[]
James Monroe, según admitió él mismo, se puso en contacto con John Carmack poco después del lanzamiento por parte de Raven Software de los códigos fuente de Heretic y Hexen para ver si sería posible seguir el ejemplo con Strife. Según Monroe, Carmack aceptó la liberación y procedió a viajar en persona a las oficinas de Rogue para ver si podía obtener una copia del código (en ese momento, James ya estaba trabajando para Raven en Madison, Wisconsin). Desafortunadamente, cuando llegó, descubrió que los antiguos servidores NeXT utilizados para el desarrollo de Strife se habían vendido y no se conocían copias de seguridad de sus contenidos en el sitio.
Los primeros intentos de Samuel Villarreal (''Kaiser'') de contactar a Peter Mack tuvieron éxito, y Peter pensó que aún podría tener una copia del código en algunos de sus discos antiguos, pero nunca pudo localizarlo.
Dado que tanto el desarrollador como el editor del juego se han desinvertido y disuelto por completo como empresas, y no hay copias conocidas de la fuente en posesión de quienes trabajaron personalmente en él, se debe asumir que el código se ha perdido irrevocablemente.
Esfuerzos de recuperación[]
Se han llevado a cabo múltiples proyectos para aplicar ingeniería inversa al ejecutable de Strife, con objetivos que varían ampliamente en términos de fidelidad y compatibilidad. Hasta la fecha, los autores de portaciones (source ports) involucrados con Vavoom y ZDoom han llevado a cabo proyectos separados de ingeniería inversa.
Samuel Villarreal produjo un primer intento de emulación de Strife en la forma de SvStrife que no implicaba inversión directa, y luego cooperó con James Haley (Quasar) en el proyecto Chocolate Strife, que utilizó herramientas de ingeniería inversa de vanguardia para desensamblar y descompilar completamente cada línea de código en el binario (incluidas partes de bibliotecas como DMX cuando era necesario). El objetivo declarado del proyecto Chocolate Strife desde su inicio fue crear una réplica del código original que estuviera lo más humanamente cerca posible de la perfección, dadas las limitaciones inherentes a la inversión del código compilado (nombres de símbolos, en gran medida, y todos los comentarios son irrecuperables independientemente de las técnicas empleadas).
En 2014, Stephen Kick de Night Dive Studios comenzó un intento de recuperar el código fuente de una copia de seguridad de los activos de Rogue Entertainment junto con el lanzamiento de Strife Veteran Edition, pero hasta ahora no ha tenido éxito.
En 2022, se añadió una restauración fiel del código fuente de Strife al proyecto gamesrc-ver-recreation.
Estructura[]
La estructura del código fuente de Strife se puede determinar directamente a partir de la observación de los binarios, debido en gran parte a la falta de capacidad de enlace a nivel de función del compilador Watcom C/C++ los módulos se conservan en el binario exactamente en el mismo orden que se ha observado en los makefiles de Heretic y Hexen, y hay una superposición del 100% con los módulos en el código fuente de Doom con las excepciones que se detallan a continuación. Las funciones se conservan en el binario en su mayoría en el mismo orden en que aparecen en el código fuente de Doom, excepto en los casos de inserción por parte del compilador, y las funciones que se han insertado también se conservan en sus ubicaciones originales en todos los casos, excepto en unos pocos. Estas cualidades juntas hacen que la inversión del código sea significativamente más simple de lo que sería si el código fuera emitido por un compilador de optimización moderno. Las principales diferencias que se pueden inferir que han existido en un nivel de módulo de código fuente incluyen las siguientes:
- Una región de código nuevo entre p_telept.c y p_saveg.c que implementa el sistema de diálogo, a partir de 0001:0002D990 en el binario 1.2. Este módulo fue reconstruido y nombrado p_dialog.c en Chocolate Strife.
- Una región de código nuevo entre p_user.c y r_bsp.c que implementa el sistema de inventario, a partir de 0001:00030710 en el binario 1.2. Este código se incorporó al final de p_user.c en Chocolate Strife, basándose en su estrecha relación con el código del módulo anterior p_user.c.
- Una región de código nuevo entre m_misc.c y am_map.c que implementa el sistema de partidas guardadas del centro, a partir de 0001:0001B078 en el binario 1.2. Lo más probable es que este código estuviera en m_misc.c en el código original, pero debido a su independencia de otros códigos m_misc, y a las extensas adiciones que se tuvieron que hacer a él por motivos de portabilidad y estabilidad en el proyecto Chocolate Strife, este código se dividió en su propio módulo m_saves.c en ese proyecto.
- El módulo wi_stuff.c falta por completo, ya que Strife no tiene pantalla intermedia.
Curiosidades[]
Se pueden encontrar varios artefactos de desarrollo y curiosidades en los binarios de Strife:
Código que no se encuentra en otra parte[]
- El sistema de vídeo original se conserva del código de DOS Doom, incluyendo el uso del Modo Y no planar modificado, con un sistema de actualización de rectos sucios que actualiza la menor parte posible de la pantalla en cada fotograma, y con un sistema de cambio de página de tres búferes que hace uso de la mayor parte de la memoria VGA disponible. Debido al hecho de que Heretic y Hexen usan un modo de pantalla diferente y un código de actualización reescrito, ninguna versión publicada del código fuente de Doom incluye estas características.
- El binario incluye y utiliza las versiones de ensamblaje optimizadas y automodificables de R_DrawColumn y R_DrawSpan implementadas en el módulo tmap.S. Se han agregado rutinas adicionales para dibujar columnas con 25% y 75% de translucidez.
- El sistema de diálogo hace un uso exclusivo de una característica en DMX que permite que un canal de sonido tenga prioridad absoluta, al pasar un parámetro diferente a la función DMX SFX_PlayPatch que en Doom siempre se pasaba como el valor 100. Esto asegura que las voces nunca se corten por otros sonidos, sin importar cuántos estén sonando.
Código muerto no utilizado[]
- Se incluye código para implementar una llamada de lanzamiento al estilo Doom II que se habría iniciado desde los menús a voluntad. Está inacabado y no funciona en todas las versiones publicadas del ejecutable.
- Se incluye código para dibujar un formato gráfico lineal sin formato con encabezado personalizado, pero este código no se utiliza en ninguna parte del motor.
- El sistema de archivos WAD se modifica para tolerar archivos con un identificador mágico de "RWAD", además de IWAD y PWAD, pero ningún archivo conocido utiliza esta característica.
- El código para el efecto de transición de pantalla estilo Doom todavía está presente y funciona si se modifica el ejecutable para llamarlo.
- El código "Dave's Utils", incluido en un archivo que no se publicó junto con el código fuente de Doom llamado dutils.c, está presente en el ejecutable, pero no se utiliza. Implementa dos tipos diferentes de listas enlazadas.
- Existe una función para realizar una verificación de "bomba de tiempo" para una versión de prueba beta, que involucra el misterioso lump SERIAL. Se desconoce si dicha versión beta alguna vez se distribuyó fuera de las oficinas de Rogue o Velocity.
- La linedef tipo 666 activa una función de pared de empuje experimental no utilizada, lo que hace que una pared se mueva horizontalmente, algo similar a un poliobjeto, pero sin varias partes necesarias del proceso. Esto a menudo da como resultado un Efecto sala de espejos o fallas de recorte. Según Peter Mack, se trataba de una característica puramente experimental que se abandonó desde el principio cuando los programadores no pudieron hacerla funcionar.
- Una serie de cambios realizados entre la v1.2 y v1.31 parecen indicar que se planeó lanzar una nueva versión de demostración que usaría el mismo ejecutable que el lanzamiento comercial, pero aparentemente esto nunca sucedió debido al cierre de Velocity.
Heredados[]
- Dado que el código se basa en Doom 2 v1.666, persisten ciertos errores de esa versión, incluido el hecho de que los rastreadores no se borran al cargar una partida guardada.
Resurrección de código no utilizado en Doom[]
- Las puertas animadas son una finalización implementada en lugar del código de la puerta corrediza que id Software dejó incompleto en la fuente de Doom.
- La transición de pantalla de fundido cruzado o "crossfade" es una reimplementación in situ de un borrado de desvanecimiento de color no utilizado que se intentó implementar en Doom, pero no codificó de una manera que pudiera funcionar con restricciones de paleta de 8 bits. Rogue reemplazó la implementación rota por una que utiliza una mezcla translúcida progresiva.
- La capacidad de las Granadas para rebotar se adaptó de la capacidad de las Almas perdidas, que entonces no funcionaba, de rebotar en pisos y techos.