CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 14 Dic 2017 07:30

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 39 mensajes ]  Ir a página Anterior  1, 2, 3  Siguiente
Autor Mensaje
NotaPublicado: 14 Ene 2017 19:15 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
A falta de fuentes del compilador, he podido hacerme una idea de las etiquetas no declaradas usando Superglús 1.0-beta4 pero utilizando una versión moderna, que genera warnings, de glulxa.

Para la prueba uso un viejo cadabra.txp.

El warning más repetido (con mucha diferencia) se refiere a la etiqueta glkresult (la única que he analizado), utilizada en las llamadas a glk para almacenar el valor de retorno. Con dos apariciones, interrupt_proc. Con una aparición, flag2147483646, nombreanterior y canal_sonido.

En otro frente, he estado intentando entender el workaround de glulxe. Si lo he entendido bien, es preocupante. Se ha aplicado para dos opcodes: glk y copy. En el fondo, ambos casos se tratan de la misma manera: si detecta que la escritura va a caer en la dirección 0, simplemente descarta la escritura (si el primer argumento de store_operand() es cero, no se almacena nada).

Para el primer opcode, esto significa que el valor de retorno de la llamada se pierde. Esto no es problemático casi nunca en el código generado por Superglús en el fichero ula, porque rara vez lo utiliza. Pero hay casos en los que sí. En especial me ha llamado la atención durante las rutinas de save/load. En ellas se utiliza el valor de retorno (recordemos, que se ha perdido) para hacer saltos condicionales (jz/jnz) y --aquí entra en juego también el otro opcode parcheado-- se usa copy hacia el stack para utilizarlo en posteriores instrucciones.

Con esto en mente, he probado salvar y cargar en 007. Efectivamente, provocan error:

Código:
Glulxe faltal error: Reference to nonexistent Glk object.


Intuyo que el workaround menos intrusivo (suponiendo que nunca existirá una lectura legítima del contenido original de la posición 0 de la ROM) es considerar la dirección de memoria 0 como de lectura/escritura. Se me ocurren otras posibilidades, pero suenan más complicadas y quizá no factibles en la práctica.

Si, en glulxe, elimino los dos parches actuales en los opcodes y hago este cambio en vm.c...
Código:
 */
 void verify_address_write(glui32 addr, glui32 count)
 {
+#ifdef TOLERATE_SUPERGLUS_BUG
+  if (addr == 0) return;
+#endif /* TOLERATE_SUPERGLUS_BUG */
   if (addr < ramstart)
     fatal_error_i("Memory write to read-only address", addr);
   if (addr >= endmem)


... ya no da error y, como prueba, he conseguido salvar y cargar en Pitufos Crisis (donde tampoco se podía, mismo error que en 007).

[Si este if ocurriera en tiempo de ejecución, se podría hacer algo como lo que dice Fernando, que se pudiera escoger el modo de compatibilidad sobre la marcha, en vez de tener que decidirlo en tiempo de compilación del intérprete. En Quixe intuyo que se tiene que poder hacer algo similar sin afectar al rendimiento, pero tendría que analizar sus fuentes.]

No sé si esto cubre el resto de los bugs provocados por las etiquetas que no he analizado. Tampoco hay que perder de vista que varias obras anteriores a 2009 utilizaron versiones anteriores a la 1.0-beta4 y pueden tener bugs extra. Pero creo que no vamos a peor respecto a lo que ocurre en intérpretes que no validan la escritura. Lo que no sé es si David Kinder activaría esta opción o si volvería a la táctica (como en 0.5.2) de publicar dos ejecutables; esto es similar, aunque bastante más concreto, a lo que hace VERIFY_MEMORY_ACCESS=0.

Lo peor de todo este asunto es que tendríamos que ir convenciendo a cada mantenedor/distribuidor de intérpretes para que hiciera algo equivalente, a riesgo de posibles efectos colaterales en obras de otros sistemas. O a zarf para que añada una feísima excepción en la especificación.

Si pudieramos recompilar o parchear los binarios de todas estas obras con bug (y para ello primero tendríamos que tener perfectamente localizados las variantes y/o diferentes bugs posibles), nos quitaríamos de encima todo este cuento de nunca acabar.

Repasando la lista de obras creadas con Superglús antes de 2009, según el wiki, sin fuentes encuentro (salvo error u omisión): 007, Sherwood, Fray Guillermo, Legado, Catedral, Náufrago, Pitufos y Witchcraft. Aunque si profundizamos un poco más igual aparecen fuentes, como los que hay en la descarga de Pitufos.

Con fuentes, aunque no sé si recompiladas: Rur, Sidra y McArra's.

http://wiki.caad.es/Categor%C3%ADa:Aven ... rgl%C3%BAs


Arriba
 Perfil  
 
NotaPublicado: 14 Ene 2017 22:15 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Fernando Gregoire escribió:
Efectivamente, aunque comparto la preocupación de que los «workaroundeanods» puedan no ser los únicos códigos que tenían el problema, esta versión parcheada no oficial de David Kinder parece, por lo que alcancé a probar, solucionar el problema.
Ahora bien, ¿genera o podría generar la tolerancia a este bug otros problemas colaterales? Si es así, y para al mismo tiempo no complicar a usuarios, se me ocurre que Windows Glulxe podría incluir, sea como opción en la pestaña General o como tipo de archivo, en el diálogo «Selecciona un fichero Glulx», alguna opción de compatibilidad que por defecto no se utilice.


Eso requeriría que Zarf añadiera al código de Glulxe algo parametrizable, en lugar de una opción de compilación. Ahora mismo Windows Glulxe o lo compilas de una manera o de la otra. En mi opinión no debería haberse hecho así, sino que debería haberse hecho dejando escribir en ROM como por otro lado llevaba haciéndose "mil años", pero glulx y glulxe no son míos así que si el autor decide hacerlo así es muy libre de hacerlo. No obstante este estar en manos de un tercero es una de las razones que me llevaron a pasar de la plataforma Glulx de Superglus a la plataforma html/JS de ngPAWS. No dejo de estar en manos de un tercero, pero al menos no es un único tercero, hay mucha gente detrás tomando y consensuando cada decisión :-)

Que conste que esto no es una crítica a Zarf, en el sentido estricto escribir en ROM no es correcto, y pese a esa incorrección ha dedicado tiempo a habilitar opciones para tolerar el bug de Superglús. Quizá está siendo demasiado ajustado en la correción, pero glulxe es suyo y nada tengo que decir.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 04:57 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1609
Ubicación: Argentina
dddddd escribió:
Si pudieramos recompilar o parchear los binarios de todas estas obras con bug (y para ello primero tendríamos que tener perfectamente localizados las variantes y/o diferentes bugs posibles), nos quitaríamos de encima todo este cuento de nunca acabar.


Efectivamente. Por suerte la mayoría —si no todos— los autores de las aventuras que nombras más abajo están —aunque sea ocasionalmente— por aquí, pero habrá que apelar a que después de tantos años aún conserven los fuentes. Como sucedáneo de Witchcraft por suerte Josep Coletas sacó Héroes de la mazmorra, que en definitiva es el mismo juego más las mejoras tanto a nivel de multimedia como de variedad de conjuntos de quests según razas.
En caso de no estar disponibles los fuentes ni los autores surge el problema ético de si correspondería, más allá de ser técnicamente posible, «arremeter» contra binarios que al publicar sin los fuentes los autores quisieron lanzarlos con licencia freeware que, como se sabe, difiere de las libres.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 11:52 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5274
Ubicación: Coruña
Yo creo que, teniendo en cuenta que el objetivo no es cambiar nada de la obra sino simplemente hacer que funcione tal y como los autores quisieron que lo hiciera, frente a algo inesperado que ha hecho que deje de funcionar, no hay ningún problema ético.

Un análogo en el mundo "analógico" sería restaurar películas que no se pueden ver porque los rollos se han deteriorado con el paso del tiempo.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 12:02 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1609
Ubicación: Argentina
Al-Khwarizmi escribió:
Un análogo en el mundo "analógico" sería restaurar películas que no se pueden ver porque los rollos se han deteriorado con el paso del tiempo.


+1. Con ese ejemplo terminas de convencerme de que no habría problema.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 15:00 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Tras estudiar un poco más el asunto, soy bastante optimista respecto a poder parchear los juegos sin fuentes, hasta el punto que los intérpretes no necesiten cambios.

No puedo todavía asegurarlo, pero el plan parece que funcionaría en el par de ulx que he analizado.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 15:13 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
dddddd escribió:
Tras estudiar un poco más el asunto, soy bastante optimista respecto a poder parchear los juegos sin fuentes, hasta el punto que los intérpretes no necesiten cambios.

No puedo todavía asegurarlo, pero el plan parece que funcionaría en el par de ulx que he analizado.


En teoria analizando la compilación condicional del Glulxe se sabría que opcodes se han parcheado y en que direccionamiento. El único problema es que esos no sean los únicos opcodes afectados. Si alguien tuviera unos fuentes antiguos de Superglús, de alguna de las betas, se podría mirar. Yo he buscado y no tengo nada :-(

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 15:38 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Creo que se te ha pasado un mensaje, Uto. Con los binarios del compilador he podido obtener bastante información que me ha encaminado a cómo plantear el parcheado. En todo caso, si tienes a mano binarios de betas más antiguas podrían venir bien también.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 18:01 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
dddddd escribió:
Repasando la lista de obras creadas con Superglús antes de 2009, según el wiki, sin fuentes encuentro (salvo error u omisión): 007, Sherwood, Fray Guillermo, Legado, Catedral, Náufrago, Pitufos y Witchcraft.

Ahora que he revisado con más calma, efectivamente hubo errores y omisiones. Parece que sin fuentes sólo hay cuatro y en ellas centraré mis esfuerzos.

En orden de antigüedad: Catedral, Sherwood, 007 y Witchcraft.

Si se os ocurre alguna más que no esté en el wiki, avisadme.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 21:23 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
dddddd escribió:
dddddd escribió:
Repasando la lista de obras creadas con Superglús antes de 2009, según el wiki, sin fuentes encuentro (salvo error u omisión): 007, Sherwood, Fray Guillermo, Legado, Catedral, Náufrago, Pitufos y Witchcraft.

Ahora que he revisado con más calma, efectivamente hubo errores y omisiones. Parece que sin fuentes sólo hay cuatro y en ellas centraré mis esfuerzos.

En orden de antigüedad: Catedral, Sherwood, 007 y Witchcraft.

Si se os ocurre alguna más que no esté en el wiki, avisadme.


Por casualidad en esas fuentes no habrá alguna que tenga el fichero .ula, es el fuente en ensamblador que genera el compilador, si está por ahí, en ese fichero estarán las etiquetas malas, si se pasa por el glulxa del Superglús actual, te avisa del error (parcheé glulxa yo mismo para que no me volviera a ocurrir).

Otra cosa que habria que mirar es si no fallan las de Paguaglús, sinceramente no me acuerdo de si la etiqueta mala era mía o de Yokiyoki, probablemente mía pero no estoy seguro al 100%

Edit: no os molestéis, no hay un .ula por ningun lado :-(

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 21:52 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Sigo pensando que te estás saltando mensajes, Uto. Revisa el hilo completo, por favor.


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 23:39 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Ahora que lo pienso... no hace falta encontrar los fuentes de Superglús, la parte que tiene el bug son los fuentes en ensamblador que van en la carpeta "pgl" de Superglús, lo cual quiere decir que cualquiera que tenga una beta antigua de Superglús, la distribución, no los fuentes, tiene los ficheros con su bug, ahí se podría mirar. Lamentablemente, yo tampoco tengo eso :-D

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 15 Ene 2017 23:57 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Buenas noticias, resulta que la beta4 de Superglús aun estaba mal, y esa está descargable. He generado un .ula con dicha versión, y efectivamente el glulxa que iba con esa versión se come el error de las variables, pero el glulxa actual saca warnings cada dos por tres.

Para mi es muy mal momento para ponerme con esto, pero por si alguien quiere investigar para parchear o para reportar a Zarf cuales son los opcodes exactos afectados, dejo este zip:

https://www.dropbox.com/s/4ccaww0c9eu4q ... M.zip?dl=0

En su interior están los ejecutables para linux "glulxaold" (el que se come las etiquetas desconocidas) y glulxa (el actual que muestra warnings). Además, hay un fichero TEST.ula para ensamblar así:

Código:
./glulxa -i TEST.ula -o TEST.ulx

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 16 Ene 2017 00:22 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Me he picao...

Hay varias variables referenciadas por etiquetas afectadas:

- "glkresult" se usa en muchísimos sitios, pero en realidad está definida como "glk_result", esta es muy chunga porque es usada como tercer parámetro de todas las llamadas a glk para retornar un valor. La verdad es que es muy sorprendente que esta función no cause la alerta en glulxe si no está específicamente parcheada. Solo se me ocurre pensar que la escritura en ROM en este caso no la hace exactamente glulxe, sino la librería Glk.

- "interrupt_proc" no es importante, es una etiqueta que no existe si el juego no tiene proceso de interrupción, como es el caso, hay otra etiqueta sí declarada llamada hay_interrupt que si vale 0 no llegamos nunca al sitio donde se llama a interrupt_proc

- "nombreanterior" creo que es la que se ha detectado ahora, la variable realmente se llama nombre1anterior y solo aparece en un sitio: copy 255.l (:nombreanterior).l . Probablemente modificar ese 255 y poner otro valores puede dar una idea de como encontrarlo en un binario para parchearlo y hacer que en lugar de copy 255.l (0) use una variable en RAM. Otra cosa es que no entiendo muy bien es que ese supone que eso limpia el nombre de frases anteriores, no recuerdo muy bien por qué, y si lo está grabando en 0 en lugar de donde esté :nombre1anterior pues no lo limpia, lo cual es lo correcto y de hecho en los fuentes actuales la linea está corregida con la variable correcta pero también está comentada (;copy 255.l (:nombre1anterior).l). Quizá lo ideal sería simplemente cambiar ese copy 255.l (0) por nops

- "canal_sonido" solo se utiliza una vez, en un sitio donde debería poner "canal_efectos", pero como es de lectura no veo demasiado problema. Probablemente no inicialice bien el sonido por lo que veo, o quizá todo lo contrario, lo inicialice incluso si el dispositivo no tiene.

Código:
glk 0xf2.l 0x01.b (:canal_efectos).l
jnz (:canal_sonido).l :inicializar_sonido_no_sonido.l


En fin, revisando todo lo único que parece preocupante es ese copy 255 que como digo, lo ideal es cambiarlo por nops (0x00).

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 16 Ene 2017 00:34 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Uto, ¿has visto realmente lo que dije hace unos mensajes? Estamos duplicando trabajo.


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 39 mensajes ]  Ir a página Anterior  1, 2, 3  Siguiente

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
cron
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM