ReC98
versary Edition)
| Ingeniería inversa: | |
|---|---|
| Finalizado: | |
| Independencia de posición: |
¡Consulte la página de inicio para obtener números de progreso más detallados e información sobre el crowdfunding!
Este proyecto tiene como objetivo reconstruir perfectamente el código fuente de los primeros cinco juegos del proyecto Touhou de Zun Soft (ahora Team Shanghai Alice ), que originalmente se lanzaron exclusivamente para el sistema NEC PC-9801.
Los juegos originales en cuestión son:
Como solo tenemos los binarios, obviamente no podemos saber cómo Zun nombró variables y funciones, y qué comenta el código original con el que estaba rodeado. Por lo tanto, lo perfecto significa que los binarios compilados del código en el repositorio REC98 son indistinguibles de las construcciones originales de Zun, lo que hace imposible refutar que el código original no podría haberse visto así. Esta propiedad se mantiene para cada compromiso GIT en el camino.
Además del ángulo de preservación y la visión profunda resultante de la mecánica de los juegos, el código puede servir como base para cualquier tipo de mod, o cualquier puerto a plataformas que no sean PC-98, desarrollado por la comunidad. Esta es también la razón por la cual los valores de REC98 se pueden ver el código legible y comprensible sobre una descompilación pura.
Hay varias por qué lograr moddabilidad a través de la descompilación completa parece ser más valiosa para los juegos PC-98, en contraste con una reimplementación de caja negra al estilo Pytouhou:
Desde que el crowdfunding ha traído un flujo continuo de apoyo, el progreso ha sido estable. La descompilación de TH01 completamente completada en agosto de 2022, y los juegos restantes son solo cuestión de tiempo.
Con los años, este proyecto condujo a una comprensión profunda de los compiladores originales y el hardware PC-98, hasta el punto en que la descompilación en sí se ha vuelto bastante mecánica. Para garantizar que este proyecto siga valiendo la pena para apoyar e interesante para trabajar, su enfoque ha cambiado más hacia una documentación y revisión meticulosa del código original de Zun. El blog del proyecto detalla todos los hallazgos de una manera más legible y posiblemente se ha convertido en la atracción principal, con la reconstrucción del código fuente en sí casi convirtiéndose en un subproducto de la investigación profunda subyacente en estos juegos.
El proyecto también comenzó bastante viable. Durante el desarrollo de los parches de inglés estático para estos juegos, identificamos dos bibliotecas principales utilizadas en los 5 juegos e incluso encontramos su código fuente. Estos son:
ZUNSP.COM de Th03 (accesible a través de ZUN.COM -4 ) es una versión renombrada de SPRITE16.COM de Promisence Soft, un controlador de pantalla EGC de 16 colores, la versión 0.04, que se incluyó con el juego de muestra Stormyspace . Master.lib y el tiempo de ejecución C/C ++ solo constituyen una cantidad considerable del código en todos los ejecutables. En TH05, por ejemplo, ascienden al 74% de todos los códigos en OP.EXE , y el 40% de todos los códigos en MAIN.EXE . Ese ya es bastante código con el que no tenemos que lidiar. Identificar el resto del código compartido en los juegos reducirá aún más la carga de trabajo a una cantidad más aceptable.
Con Dosbox-X y la edición de depuración del Proyecto II de Neko, también tenemos dos emuladores PC-9821 de código abierto capaces de ejecutar los juegos. Estos han ayudado a responder a la mayoría de las preguntas relacionadas con el hardware, junto con libros antiguos sobre desarrollo de PC-98 y pruebas ocasionales en hardware real.
zunsoft.com , op.exe , reiiden.exe , fuuin.exeongchk.comzuninit.com , zun_res.com , zunsoft.comop.exe , main.exe , maine.exeongchk.comzuninit.comzunsoft.comzunsp.com [-4], res_yume.com [-5]), op.exe , main.exe , mainl.exeongchk.comzuninit.com [-i], res_huma.com [-s], memchk.com [-m]), op.exe , main.exe , maine.exeongchk.comzuninit.com [-i], res_kso.com [-s], gjinit.com [-g], memchk.com [-m]), op.exe , main.exe , maine.exeLos archivos cruzados son idénticos a su versión en el juego anterior. Ongchk.com es parte del controlador de sonido PMD de Kaja y, por lo tanto, tampoco necesita ser desmontado; Solo necesitamos mantener el binario para permitir reconstrucciones perfectas de bit de Zun.com.
Este proyecto no incluye ningún datos de activos de las versiones PC-98 originales. Ejecutar los ejecutables compilados aún requerirá una copia existente de los juegos originales.
▶ master : el código original de Zun, sin modificaciones o correcciones de errores (¡está aquí!)
debloated : la versión de investigación del código de Zun que es más fácil de leer y modificar, y construye binarios PC-98 más pequeños y más rápidos. Solo elimina la hinchazón y las minas terrestres; Todos los errores y peculiaridades del código original de Zun se dejan en su lugar. Los puertos deben comenzar desde esa rama , y también es la base recomendada para modificaciones que no les importa la similitud con el binario original.
anniversary : Toma debloated y también corrige errores, logrando una experiencia de juego más suave y sin parpadeas en la plataforma PC-98 y al mismo tiempo deja las peculiaridades en su lugar. Puede ser un puerto de inicio aún mejor para modificaciones y puertos.
BossRush
th03_no_gdc_frequency_check : permite que TH03 se ejecute con el reloj GDC establecido en 5 MHz. El juego original impone 2.5 MHz, pero no lo requiere funcionalmente, incluso en hardware real.
xJeePx : El código cambia para el parche de traducción al inglés de XJeepx 2014.
th01_critical_fixes : corrige dos errores críticos en th01:
th01_end_pic_optimize : acelera el bloqueo de la imagen en las escenas de TH01 al 50% del tiempo de ejecución original. Principalmente sirve como un ejemplo de cómo acercarse al código de bloqueo con EGC con EGC del turbo C ++ 4.0j sin escribir una sola instrucción ASM; El EGC definitivamente no es la mejor herramienta para este trabajo.
th01_orb_debug : muestra la siguiente información en el modo de depuración de TH01:
th01_sariel_fixes : corrige tres fallas de sprites en la lucha de TH01 Sariel que resultan de errores lógicos claros en el código original.
th03_real_hitbox : convierte el mapa de bits de colisión de Th03 en ambos campos de juego. Muy poco reproducible.
Corrección para el th04 Stage 5 Yuuka No-EMS Crash:
th04_noems_crash_fix : aumenta el límite de memoria autoimpuesto del MAIN.EXE .mem_assign_all : elimina los límites de memoria autoimpuestos en todos los ejecutables TH02-TH05, fijando adicionalmente otros bloqueos potenciales fuera de la memoria que pueden ocurrir durante la modificación.Solución para el bloqueo de error de división de Kurumi TH04:
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverSolución alternativa para el bloqueo de error de división de marisa de la etapa 4 de TH04:
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes : rama combinada de todas las correcciones de errores "obvias" que no afectan el juego o las imágenes:
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fix Además, las siguientes soluciones de soluciones para los errores Divide Error de Th04, elegidos por el voto de la comunidad:
th04_0_ring_as_single_bullet (resultados de la encuesta)th04_marisa4_crash_still (resultados de la encuesta) Borland Turbo C ++ 4.0J
Este fue el compilador que Zun usó originalmente, por lo que es el único que puede compilar determinista este código en ejecutables que son perfectos para los originales de Zun. Borland nunca hizo un compilador cruzado dirigido a DOS de 16 bits que se ejecuta en ventanas de 32 bits, por lo que las partes C ++ deben compilarse utilizando un programa DOS de 16 bits.
REC98 también utiliza Turbo C ++ 4.0j para construir las herramientas personalizadas en su tubería de compilación, como el convertidor para sprites codificados. Estos solo tienen que ejecutarse de forma nativa como parte del proceso de compilación, por lo que puede parecer contraproducente compilarlos en programas DOS de 16 bits que luego deben emularse en sistemas operativos de 64 bits. Sin embargo, esto todavía tiene sentido por varias razones:
Por lo tanto, tiene poco sentido agregar la dependencia generalmente bastante fuerte de un compilador nativo de C ++.
Borland Turbo Assembler (TASM), versión 5.0 o posterior, para ventanas de 32 bits ( TASM32.EXE )
REC98 no solo requiere un ensamblador para el código de juego que aún no se ha descompilado, sino también para las bibliotecas de terceros de Touhou de PC-98 y el código de ensamblaje escrito a mano e indecompilable de Zun. Afortunadamente, el ensamblador de 32 bits de Borland se puede utilizar para un código de 16 bits y se ejecuta de forma nativa en ventanas de 64 bits y 32 bits, superando las herramientas TASM.EXE y TASMX.EXE de 16 bits.
Como beneficio secundario, el uso de una herramienta de Windows nativa de 32 bits también permite que las piezas ASM usen libremente nombres de archivos largos que no necesitan ajustarse a la convención DOS 8.3.
Jugador de MS-DOS (incluido)
Un emulador liviano para ejecutar herramientas de línea de comandos de DOS en el subsistema de la consola de Windows, utilizado automáticamente al construir la base de código en sistemas operativos de 64 bits. A pesar de su naturaleza despojada, todavía se ejecuta notablemente más lento que Dosbox, ya que utiliza el núcleo X86 de interpretación de Neko Project 21/W en lugar de un recompilador dinámico, pero la integración de la consola perfecta lo compensa con creces.
La construcción agrupada se optimiza específicamente el perfil para la construcción de REC98, que ejecuta un núcleo X86 reducido que solo emula un 386 sin FPU, paginación o conteo de ciclos. En comparación con las construcciones aguas arriba de Takeda Toshiya, esta construcción acelera el proceso de construcción de REC98 en ≈60% para una reconstrucción completa, ≈80% para compilar y vincular la unidad de traducción más grande y el binario más grande, y ≈70% para la unidad de traducción de tamaño medio y el binario. También contiene una interrupción de errores requerida para ejecutar Turbo C ++ 4.0j en el contexto de un sistema de compilación que no estaba disponible en las compilaciones aguas arriba a partir de junio de 2024.
Consulte bin/README.md para obtener información y construir información.
TUP , para Windows (incluido)
Un sistema de construcción en paralelo sensato, utilizado para garantizar reconstrucciones mínimas. Proporciona un seguimiento perfecto de las dependencias a través de la inyección de código y enganchando el archivo de un compilador que abre Syscalls, lo que le permite agregar automáticamente todos los archivos #include D al gráfico de dependencia de compilación. Esto hace que sea superior a la mayoría make implementaciones, que carecen de esta característica vital y, por lo tanto, son inherentemente inherentes para casi cualquier lenguaje de programación imaginable. Sin abstracciones para compiladores específicos, TUP también se ajusta perfectamente a las antiguas herramientas de Borland requeridas para este proyecto.
La compilación de Windows de 64 bits agrupada incluye una imagen de error importante para ejecutar herramientas de compilación basadas en DOS a través del reproductor MS-DOS que no se ha fusionado en el repositorio ascendente a partir de junio de 2024.
Consulte bin/README.md para obtener información y construir información.
Simplemente ejecute build.bat en cualquiera de las plataformas de compilación compatibles; Hace lo correcto, independientemente del sistema operativo que esté ejecutando. El proceso abortará con un error si ninguna de las herramientas necesarias no se puede encontrar en la PATH de Windows.
¿Los ejecutables finales se pondrán en binth0? , usando los mismos nombres que los originales. Ejecutarlos requiere los activos originales de cada juego en el mismo directorio.
En el X86 de 64 bits, el proceso de compilación utiliza TUP para reconstrucciones paralelas mínimas, pero todas las herramientas de compilación basadas en DOS se emulan. En el X86 de 32 bits, el proceso de compilación recae en un archivo de lotes secuencial que siempre construye toda la base de código, pero todas las herramientas de compilación se ejecutan en el rendimiento nativo.
Nivel 1 : Probado regularmente, el mejor soporte garantizado.
Nivel 2 : Se supone que debe funcionar, factible para apoyar, pero no se prueba regularmente. Los errores críticos en el proceso de compilación se solucionarán de forma gratuita.
Nivel 3 : Se supone que debe funcionar, pero una carga para mantener. Las correcciones para errores relacionados con la construcción requerirían fondos, pero es probable que también se acepten PRS de corrección de errores.
Nivel 4 : explícitamente no respaldado y no es de compra sin rayos serios. Requeriría fondos o tenedores dedicados, es poco probable que se acepten PRS.
TLINK falla con Loader error (0000): Unrecognized Error en ventanas de 32 bits ≥Vista
Dos causas conocidas:
Intente configurar el controlador NTVDM DPMI que se cargará en la memoria convencional en lugar de la memoria superior, editando %WINDIR%System32autoexec.nt :
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosxRequiere un reinicio después de esa edición para entrar en vigencia.
(Fuente)
Intente construir en un shell regular cmd.exe en lugar de PowerShell o Bash.
Ver CONTRIBUTING.md .
