CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 25 Mar 2019 02:58

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 10 mensajes ] 
Autor Mensaje
NotaPublicado: 20 May 2009 13:54 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 11:58
Mensajes: 1817
Ubicación: Madrid
Me salen dos errores y una ristra de warnings listando todos los archivos multimedia del fichero .BLI: "declared but no used"

Extracto de los mensajes de compilación:
Código:
[size=9]Incluyendo Spanish: Mensajes y rutinas de idioma [INFSP 0.8]
[DAMUSIX: <(DA): Ad(M)inistrador (U)nificado de (S)on(I)do en Glul(X)>]
[DAINUNEK: <(DA): (IN)icializacion (UN)ificada de (E)xtensiones en Gl(K)>]
[DAINUNEK: Auto-Implementando Punto de Entrada IdentifyGlkObject()]
[DAINUNEK: Auto-Implementando Punto de Entrada HandleGlkEvent()]
[Including <infglk>]
Including bres resource declarations generated on 3998072-12-3998072
plantilla.inf(313): Error:  Expected routine name but found HandleGlkEvent
> [HandleGlkEvent
plantilla.inf(313): Error:  There is no action routine called "SalidasSub"
> [HandleGlkEvent[/size]


Tengo definida mi propia rutina HandleGlkEvent, y de los mensajes de compilación deduzco que Damusix, a pesar de ello, incorpora la suya, por lo que posteriormente aparece un error al encontrarse duplicada la función.

Por otro lado, tengo un IdentifyGlkObject para actualizar las ventanas gráficas exclusivamente, y no sé si interferirá con el de la librería Damusix que se encarga de restaurar el tema de sonidos.

¿Alguna idea?

PD: Eliuk, las preguntas que tenía ayer ya estaban respondidas en la documentación, referentes a los canales rotativos y un viejo problema con los fades.

Y las funciones "minimalistas", como las llamas, me están viniendo de perlas para adaptar todo lo que tenía hecho (estoy aplicando Damusix sobre código ya hecho, no empezando de nuevo), cambiando las funciones de Efectos con la sintaxis de Damusix. De este modo podré también portar fácilmente aventuras antiguas, manteniendo prácticamente todo el código original.

Saludos

_________________
_/ /\ R e \_


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 20 May 2009 14:13 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 11:58
Mensajes: 1817
Ubicación: Madrid
Bueno, me contesto a mí mismo. La respuesta estaba un poco más abajo de donde me quedé en las instrucciones. Tenía que declarar las funciones conflictivas antes de Damusix, e incluir la referencias pertinentes.
...
De todas formas, aunque ahora compila... en cuanto tiene que salir un gráfico o sonido se cuelga.
"Wrong number of arguments to a GLK funtion"

Pero voy a seguir mirando, porque esto será por algún fallo en las funciones que he hecho para pasar de Efectos a Damusix.
...
Continúo.
Me casca al intentar cerrar la ventana gráfica. Es decir, al llamar a esta función:
Código:
[EliminaVentanaGrafica ;
   if(gg_picwin == 0)rtrue;
     glk_window_close(gg_picwin);
     gg_picwin = 0;
rtrue;
];


Entonces me pregunto si pudiera ser que los "ROCK" del sonido, Constant DAMUSIX_GG_ROCK = 510; 511,512,513..., pudieran estar situados de alguna forma dentro de esta ventana gráfica, y por tanto haya que cerrarlos antes. Si no, no me lo explico.

...

Última hora:
El problema estaba en la librería infglk.h. La suministrada con Damusix debía tener alguna diferencia con la que tenía. Al restaurar la antigua, ya funciona. (Quizá le hice alguna modificación por los conflictos entre SIX e infglk).

_________________
_/ /\ R e \_


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 02:35 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
No Jarel... es un error en tu código que, por si acaso, es un error común que se nos pasa a la mayoría.

Restaura la INFGLK.H que viene con Damusix porque es la última y las más nueva y completa (v0.7.0). La única diferencia que tiene con la antigua (v6) es que implementa las rutinas Glk con cantidad de argumentos variables (una cosa técnica), y en tal caso todos y cada uno de los argumentos deben ser declarados SIEMPRE. En la antigua versión 6 los parámetros no declarados eran inicializados como cero; en esta versión simplemente no son inicializados.

Sabiendo eso, el error concreto en tu código está aquí:

Código:
glk_window_close(gg_picwin);


Eso debería ser...

Código:
glk_window_close(gg_picwin,0);


El último argumento (0) es totalmente "esotérico", como le llama Cadre, jejeje, y la verdad es que no sirve para nada, pero siempre debe estar en esa llamada. SIEMPRE. Y muchos autores no lo ponían simplemente porque en la INFGLK.H v6 cuando no lo incluías ella "asumía" el valor cero. INFGLK v7 implementa las rutinas usando cantidad de argumentos variable (que funciona más rápido, en teoría; y es más "limpia", porque hace llamadas directas a GLK, no hace nada más "entremedio"), por lo que ningún argumento es "asumido" y tienes que ponerlos explicítamente, y viste, ahí salta el error... :)

Restaura la INFGLK.H que viene con Damusix (hazme caso, es más "correcta" que la versión 6, porque hace solamente la llamadas que debe hacer [es más limpia] y además implementa las últimas funciones incorporadas a la Glk)... y tú agrega un cero final en todas las llamadas que tengas a glk_window_close(). Con eso se arregla. :)

Lo sé porque cuando le puse la última INFGLK a DA-GWindows me saltó el mismo error y por varios meses estuve averiguando por qué fallaba... hasta que me leí detenidamente la Spec de Glk sobre glk_window_close() y descubrí que el error es simplemente porque la mayoría no sabemos lo del cero final (aunque Cadre también lo dice en su manual Gull).

Saludos! :D

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Última edición por Eliuk Blau el 21 May 2009 09:03, editado 4 veces en total

Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 02:38 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
jarel escribió:
Entonces me pregunto si pudiera ser que los "ROCK" del sonido, Constant DAMUSIX_GG_ROCK = 510; 511,512,513..., pudieran estar situados de alguna forma dentro de esta ventana gráfica, y por tanto haya que cerrarlos antes. Si no, no me lo explico


No, los Rocks de Damusix están especialmente planeados para que no "topen" con otros Rocks... a menos que no estés siguiendo la "convención estándar" respecto a los rocks. En la convención, los canales de sonido comienzan del 410 hasta aproximadamente el 610, y luego creo que vienen los rocks de archivos externos, streams y todas esas cosas.

Es una convención para que las rocks no se "topen". Verás que Damusix deja un poco más de 100 rocas disponibles por si el usuario quiere crear sus propios canales, aparte de los de Damusix.

Y el error que te produce, bueno, ya lo he respondido en el post inmediatamente superior a este. :)

Saludos! :)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 08:10 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 11:58
Mensajes: 1817
Ubicación: Madrid
Eliuk Blau escribió:
Sabiendo eso, el error concreto en tu código está aquí:
Código:
glk_window_close(gg_picwin);


Eso debería ser...
Código:
glk_window_close(gg_picwin,0);



Efectivamente, eso arregla el cuelgue con la nueva librería. ¡Muchas gracias!

_________________
_/ /\ R e \_


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 13:21 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4643
Eliuk Blau escribió:

Código:
glk_window_close(gg_picwin);


Eso debería ser...

Código:
glk_window_close(gg_picwin,0);




Un poco chapucero el cambiar el interfaz de la librería rompiendo la compatibilidad. Habria sido más fácil dejar el interfaz como estaba y crear otras funciones tipo

Código:
fastglk_window_close(gg_picwin,0);


que hicieran la funcionalidad sin parametros variables.

O al menos poner un

Código:
 #define fast


que obligue a poner los parametros.

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


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 19:22 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
No Uto... no es a eso a lo que me refería...

A ver... la antigua InfGlk v6 lo que hacía era "setear" un poco a mano cada uno de los argumentos pasado a la rutina... por ejemplo...

Código:
[ glk_window_close win result;
    glk(36, win, result);
];

... o esto, que es más o menos lo mismo...

[ glk_window_close win result
    ret;
    ! Must push arguments onto the stack in reverse order
    @copy result sp;
    @copy win sp;
    ! And now the @glk call
    @glk 36 2 ret;
    return ret;
];


En este caso, es evidente que 'result' siempre valdrá cero si no ha sido inicializada. Esto lo hace el propio compilador Inform, como todos sabemos. Adicionalmente a esto, en rutinas Glk más complejas, con más argumento, la InfGlk solía hacer un "ordenamiento" de argumentos (les asignaba valores a cada uno, dependiendo de ciertos factores... etc.). Es decir, a veces hacía "procesos" adicionales a la única llamada a la Glk.

En la nueva librería (v7) no se hacen este tipo de cosas. Se utiliza la funcionalidad de cantidad de argumentos variables. En este caso, los argumentos se guardan en una pila de la memoria y luego se recuperan mediante un par de llamadas de ensamblador.

Eso sería algo como esto...

Código:
[ glk_window_close _vararg_count ret;
    ! glk_window_close (win result)
    ! And now the @glk call
    @glk 36 _vararg_count ret;
    return ret;
];


Resulta que la pila guarda un array con slots suficientes para cada argumento... y si haces, por ejemplo...

Código:
glk_window_close(win);


... creará una pila de sólo 1 elemento. En cambio si haces...

Código:
glk_window_close(win,0);


... creará una pila de dos elementos. Es evidente que la primera forma provocará un error porque la llamada @glk para cerrar una ventana requiere dos argumentos... y la pila solo tendrá uno.

Esta forma es mucho más rápida, y práctica, porque el código es más sencillo (de la InfGlk). Además que se han quitado todos esos "ordenamientos" y procesos adicionales a la llamada @glk, porque ahora es la propia pila la que hace esto. Y es como SIEMPRE DEBIÓ SER. :)

Lo que pasa es que la v6 de InfGlk fue hecha un poquito "al lote" como decimos por aquí (descuidado). InfGlk 7 es la forma correcta de haber implementado eso desde el principio, y es, de hecho, la que se usa en I7.

Saludos!

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Última edición por Eliuk Blau el 14 Ene 2010 01:56, editado 2 veces en total

Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 21 May 2009 23:12 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4643
Te habia entendido perfectamente Eliuk, y sigo pensando lo mismo, ese cambio es una chapuza: no se cambia el interfaz, se amplia, o al menos se da un "modo de compatibilidad".

Obviamente no se cambia a no ser que no haya más remedio, y ese no es el caso.

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


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 22 May 2009 01:35 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Uto escribió:
Te habia entendido perfectamente Eliuk, y sigo pensando lo mismo, ese cambio es una chapuza: no se cambia el interfaz, se amplia, o al menos se da un "modo de compatibilidad".

Obviamente no se cambia a no ser que no haya más remedio, y ese no es el caso.


Ya, es que estuvo mal hecho desde el principio...

Pero sí, tienes razón. Aunque en este sentido estamos cagados... el autor es Dios aquí. :P Y si el gringo lanza esta versión así... pues obligados a usarla. Aunque insisto, es mejor que la previa.

Se puede seguir usando la previa, pero uno no tendrá acceso fácil a las funcionalidades Unicode o a los streams de memoria... :P En fin...

P.S: En todo caso, lo de pemitir glk_window_close() sin el cero final es definitivamente un error. InfGlk no intenta ser una librería para facilitar el uso de Glk, sino que es simplememente un wrapper "inteligible" que intenta ser lo más fiel a la Spec original y a las llamadas a cada una de las funciones Glk (lo cual significa respetar igualmente todos y cada uno de sus parámetros). En eso falló en la v6. Claramente un error por parte del autor (o del script generador en Perl :lol: )

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 22 May 2009 07:19 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4643
Eliuk Blau escribió:
Ya, es que estuvo mal hecho desde el principio...

P.S: En todo caso, lo de pemitir glk_window_close() sin el cero final es definitivamente un error. InfGlk no intenta ser una librería para facilitar el uso de Glk, sino que es simplememente un wrapper "inteligible" que intenta ser lo más fiel a la Spec original y a las llamadas a cada una de las funciones Glk (lo cual significa respetar igualmente todos y cada uno de sus parámetros). En eso falló en la v6. Claramente un error por parte del autor (o del script generador en Perl :lol: )


Efectivamente, ahora es como debio ser desde el principio, lo cual esta bien, pero claro, también ha roto la compatibilidad hacia atrás, y jarel no será el último en tener ese problema.

Yo como jamás he usado el wrapper (porque no uso Inform) no sabía que el viejo estaba "mal hecho", la verdad es que me acabo de enterar.

También cierta culpa la tiene la implementación de Glk, en la que algunas llamadas devuelven cosas "per se" y otras llamadas devuelve void pero luego devuelven algo en el GlkResult. Esa dualidad es la que probablemente trataba de corregir el wrapper 6, porque es mucho mas "natural" que glk_window_close tenga este formato:

Código:
int glk_windows__close(int recurso)


que este
Código:
void glk_windows__close(int recurso, int &result)


Ahora, el segundo, por muy antinatural que sea, es el que trae la spec, vaya por dios :D

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


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 10 mensajes ] 

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