Closed jsmolina closed 5 months ago
thank you for your great work on this!
Curioso, falla justo en cuanto pulsas la selección de menu? o falla antes de llegar a pulsar?
Curioso, falla justo en cuanto pulsas la selección de menu? o falla antes de llegar a pulsar?
Sólo tengo doom2.wad, no me da ni la oportunidad a escoger opción que ya peta (con cualquier exe)
Cuando puedas envíame la lista de ficheros que tienes en la carpeta raíz, parece que el código de selección de WADs es lo que está fallando.
El mismo error me da a mi en mi Pentium 3 si uso emm386, si uso qemm o dejo solo himem/UMBs, no se cuelga
Vale probaré con el emm386 habilitado, en la ultima versión cambié cómo se asigna la memoria y es posible que esté dando problemas con el emm386. Ahora se utiliza toda la memoria posible, mientras que antes solo se utilizaban 8 Mb como máximo.
Duda, estáis usando Windows 9x o es MS-DOS 6 puro? Si borrais el fichero fdoom.cfg funciona?
Duda, estáis usando Windows 9x o es MS-DOS 6 puro? Si borrais el fichero fdoom.cfg funciona?
En mi caso, DOS puro. Mismo error aunque borre el cfg
He estado haciendo pruebas con mi P3 550 (Katmai), 128Mb de RAM y una Sound Blaster AWE64, y me ha funcionado bien con el EMM386, tanto con el EMS como sin el (con MS-DOS 6.22). Voy a necesitar mas detalles para ver si podemos apuntar a que está fallando exactamente.
EDIT: he ampliado la RAM hasta 384Mb y también sin problemas
He estado haciendo pruebas con mi P3 550 (Katmai), 128Mb de RAM y una Sound Blaster AWE64, y me ha funcionado bien con el EMM386, tanto con el EMS como sin el (con MS-DOS 6.22). Voy a necesitar mas detalles para ver si podemos apuntar a que está fallando exactamente.
EDIT: he ampliado la RAM hasta 384Mb y también sin problemas
Claro, decime en que puedo ayudarte, encantado
Sobre mi PC
256mb ram 1GHZ P3 VIA chipset DOS7 1 particion 128GB FAT32
Deje un Config.sys/autoexec simple
DOS=HIGH,UMB device=himem.sys device=emm386.exe ram (o noems pasa igual)
en autoexec solo unisound para iniciar el awe64
Ahora, si quito emm386 o uso qemm ningun problema
proble desabilitando la cache a velocidad 386, y usando throttle para emular aproximado tu pentium 3 pero igual, no es un tema de velocidad parece
No tengo ninguna particion FAT16 ahora mismo para probar si es un tema de archivos
Creo que la cosa viene al ser DOS7, por lo que veo en mi DOS 6.22 como máximo se mapean 64Mb de RAM, y en el tuyo si que se ven los 256Mb. Voy a instalar un W98 y a ver como se comporta
Actualizo: Pues no, debe venir por otro lado. He probado con Windows 98 SE y los 384Mb de RAM, y de tres maneras distintas y me está funcionando:
He probado con y sin EMS.
¿Que IWADs teneis metidos en la raiz del ejecutable?
yo sólo
Nasm simplemente lo he instalado con brew (brew install nasm) Y watcom he conseguido compilarlo en mi Macbook M1, lo cual me acelera más las pruebas gracias al post: https://web.navan.dev/posts/2024-03-15-setting-up-macos-for-8088-dos-dev.html
export WATCOM=/path/to/open-watcom-v2/rel
export PATH=$PATH:$WATCOM/armo64
export EDDAT=$WATCOM/eddat
# For DOS 8088/8086 development
export INCLUDE=$WATCOM/h
export LIB=$WATCOM/lib286
Lo importante, aquí con el doom1 shareware y doom2 full:
He puesto unos printf para debugar "a lo clásico" (o a lo cutre)
Por los printf, llega al final de LoadIWAD, pero entonces hace el Segmentation Fault como ves entre eso y antes de pintar "DOOM 2: Hell on Earth v%i.%"
@viti95 otro día que pueda añado más printf a ver exactamente qué línea peta. Debería salir al menos un "CPU class detected: %d\n", pero ni eso.
Mmmmm por desgracia el depurador nunca he conseguido que funcione de manera estable en OpenWatcom, así que si, la única manera es hacerlo a la vieja usanza 😅
Es cierto que ahora hay varias maneras de hacerlo más sencillo, es posible depurar en una pantalla externa de tipo MDA / Hercules, a través de puerto serie o a través de un fichero de log (este es el que suelo usar yo). Para usarlo tienes que incluir la cabecera "i_debug.h" donde quieras "depurar" y usar el método I_Printf para imprimir. Para compilar tienes que añadir un nuevo parametro para que funcione: ./build.sh fdoom.exe -clean -debug. Y la configuración de la depuración la tienes en el fichero "dbgcfg.h". A ver si un día me da por editar la wiki y explicar bien esto jaja.
Respecto al fallo que te sucede, lo único que se me ocurre es lo que has hecho, añadir mensajes en la inicialización y ver cuál es el último que llega a ejecutarse.
He aislado @viti95 el 'pete' a setbuf(stdout, NULL);
Qué curioso porque es algo bastante normal de C. Podría ser que venga de algún segmentation fault anterior.
sí quito la línea entonces llega hasta ahí, no pasa de M_LoadDefaults
:
es curioso cuanto menos: d_main.c.zip
estoy probando una cosa: Z_MallocUnowned
no debería reservar length * sizeof(char)
? o sea, estás reservando strlen, pero eso sólo es el número de chars, no cuenta lo que ocupa cada char, no? no conozco bien esa función pero puede ser?
Creo que realmente no cambiaría el resultado, sizeof(char) en Watcom C de 32bits siempre devuelve valor 1. La versión original de la función D_AddFile era esta:
void D_AddFile (char *file) {
int numwadfiles;
char *newfile;
for (numwadfiles = 0 ; wadfiles[numwadfiles] ; numwadfiles++)
;
newfile = malloc (strlen(file)+1);
strcpy (newfile, file);
wadfiles[numwadfiles] = newfile;
}
Lo unico que cambia es que en vez de usar el malloc original de C, usamos la version de malloc interna de Doom (Z_Malloc) para tener mayor control de lo que se asigna en memoria.
Creo que he encontrado el fallo que te está sucediendo. Básicamente me ha sucedido lo mismo bajo 86Box, con una maquina con una configuración totalmente distinta. ¿En la funcion I_ZoneBase (i_ibm.c), puedes probar a modificar el valor de
if (!ptr) heap -= 0x400; // try again with 1Kb less
por 0x20000 (128kb)? Me da la sensación de que alguna función interna de Watcom está intentando reservar memoria al cargar los ficheros, pero al ir tan ajustado (solo deja 1kb libre por defecto) da un fallo dependiendo de los TSR o demás cosas que estén cargadas en el SO.
No se porqué el VSCode me ha cerrado automáticamente la issue cuando he subido el commit, la primera vez que veo algo así 😶
No se porqué el VSCode me ha cerrado automáticamente la issue cuando he subido el commit, la primera vez que veo algo así 😶
sip, es porque has puesto fixes + número de issue 😄, es del propio github, y bastante útil para evitar dejarte issues abiertas.
creo que sólo retrasa (o adelanta?) el fallo, ahora no veo mis prints pero sí veo la franja blanca que hace cuando ya va a cargar...
tengo que decir que desactivando el setbuf y el setDefaults ayer llegué a arrancar el juego.
@viti95 lo reproduje ayer noche en 86box con esta combinación:
y msdos 7 eso sí
Genial, con eso ya puedo replicar en mi equipo la incidencia:
@viti95 con tu último cambio el juego arranca.
Perfecto! Solo quedaría solucionar el texto de los mensajes de carga, que por lo que sea no aparecen. Creo que el setbuf (forzar el stdout a que saque el texto directamente sin necesidad de flush) no está funcionando como debería. No sé si es un bug específico de DOS 7 o que OpenWatcom está haciendo algo raro.
con el último commit va perfecto! he estado jugando un rato a 800x600, con su OPL3 real y suena y se mueve impresionante!
@TheElf01 prueba este, lo he compilado yo en MacOs , a mí ya no me peta😄 fdm600d.zip
my pentium 3 is not able to run latest release (0.9.9b) and also fails on 0.9.9.
In windows 98se: crashes the whole OS in ms-dos, gives a stack trace (see screenshot)
It happens no matter of sound card configuration.
It works on 0.9.5