CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 20 Nov 2019 14:20

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 34 mensajes ]  Ir a página Anterior  1, 2, 3  Siguiente
Autor Mensaje
 Asunto: Buenas noticias
NotaPublicado: 16 Jul 2009 23:10 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2918
Ubicación: España (Galicia)
Hola !

Lo novedoso se ha quedado en el tintero, pero he conseguido que funcione todo para texto + gráfico (lo básico, vamos). Para asegurarme de que todo se reiniciara correctamente, he tenido que reemplazar la rutina restartSub de la librería estándar (?).

Así que saldra en Glulx y Z, finalmente... aunque sin "adelantos teshnológicos", me temo.

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 07:03 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2918
Ubicación: España (Galicia)
Hola !

Finalmente, he conseguido que las ventanas se cierren antes de reiniciar, con lo que efectivamente, el problema queda resuelto. He tenido que reemplazar, eso sí, la función de librería restartSub, con el siguiente código:

Código:
[ restartSub;
    L__M( ##Restart,1 );
    if ( YesOrNo() ) {
        closeAllWindows();
        @restart;
        L__M( ##Restart, 2 );
    }
];


Lo único que he añadido es el closeAllWindows() antes de Restart. ¿Es esto normal? ¿A alguien más le ha pasado?

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 07:30 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4647
Eliuk Blau escribió:
Uto escribió:
- En caso de LOAD/RAMLOAD, lo que se hace es

1) Destruir la ventana grafica si la hay en ese momento
2) Parar todos los sonidos en los canales
3) Cargar


Comprendo. :)

Una acotación: para SGlus, por el punto 2, sería imposible implementar algo como el mecanismo de protección de sonidos de Damusix. Este mecanismo sólo detiene el sonido en los canales si "corresponde" hacerlo para tal o cual canal.

¿QUe significa exactamente "corresponde"?

Eliuk Blau escribió:
Uto escribió:
Notese un detalle importante: Superglus graba en su propio formato, por lo que un "save" no graba los objetos glk. Esto es algo muy dificil de hacer en Inform , pero fácil de hacer en Superglus, donde tenemos acotados los datos.


Inform, o más bien Glulx, tampoco graba los objetos-glk en los archivos de estado (save). Se dumpea el mapa de memoria, sí, pero la parte de los objetos-glk es simplemente "saltada".
En síntesis (porque me fui en la profunda, jajajaja! :oops:), los objetos Glk tampoco son guardados en el formato Quetzal de Glulx-Inform.


Quería decir que Superglus no graba las variables que apuntan a los objetos Glk, ni las carga, por eso no es necesario el identifyglkobject tras hacer un LOAD, pero sí es necesario parar los sonidos, porque tras el load es muy probable que los sonidos que estuvieran sonand ya no tuvieran sentido en la nueva situación. Es cosa del autor decidir que suena en cada sitio mediante los procesos.

Obviamente el "objeto glk" en sí no es grabado en Quetzal, mas que nada porque no esta en la memoria de Glulx, sino alla donde se almacenen las variables usadas por Glk. Entiendo el concepto, pero vamos, que yo siempe he considerado el handler, no el objeto en sí que ya me imagino que existe en algún lado.

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 08:13 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 22 Sep 2004 09:33
Mensajes: 1100
Hola Balta,

baltasarq escribió:
Hola !

Finalmente, he conseguido que las ventanas se cierren antes de reiniciar, con lo que efectivamente, el problema queda resuelto. He tenido que reemplazar, eso sí, la función de librería restartSub, con el siguiente código:


Lo único que he añadido es el closeAllWindows() antes de Restart. ¿Es esto normal? ¿A alguien más le ha pasado?


¿Has echado un vistazo a "La galería Glk de los horrores"?

http://www.caad.es/modulos.php?modulo=descarga&id=1424

Drácula 2 se basaba en él y no recuerdo que hubiera ningún problema...

Saludetes
Mapache


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 17 Jul 2009 09:22 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4647
Al final Glk es como todo, hay que entenderlo, y especialmente estas cosas de los handlers Glk y los save/load/quit son más difíciles de asimilar, pero nada raro si entiendes el concepto de "handler".

Lo que si me molesta un poco de Glk, que no de Glulx, es que cada implementación es de su padre y de su madre, lo cual lleva a incompatibilidades estúpidas. Eliuk se ha encontrado muchas, yo alguna, y Baltasar, como eres casi el primero que intenta usar hiperenlaces, estas abriendo camino :D

Por mi parte me parece que Glk como especificación está muy bien y en realidad solo echo de menos alguna manera de permitir pantalla completa desde el propio Glk, y quizá alguna manera de definir ventanas en posiciones fijas (no necesariamente haciendo split de otra). Hay cosas mejorables, pero nada crítico (los hiperenlaces y el raton es casi lo unico que no he probado, pero la verdad, no me parece critico).

El verdadero problema está en las incorrectas implementaciones, y cuando digo incorrectas quiero decir implementaciones que no cumplen la especificacion (el ejemplo del gestalt que dice Eliuk, donde preguntas si el interprete soporta hiperenlaces y el glk te dice que sí, pero en realidad es que no, es una de ellas).

En cuanto a Glulx, creo que es una maquina perfecta para lo que vale. No me gusta que le metieran las @accelfunc, pero bueno, nadie me obliga a usarlas y aunque supongo que tener dos opcodes más afecta al rendimiento, supongo que será de manera marginal, porque desde luego en Superglus no he notado nada.

Por cierto, que el título de este hilo está equivocado en sí, porque debería ser "la cagada de Glk", que Glulx en sí no tiene la culpa.


PD: También hay que tener en cuenta una cosa: la anterior vez que yo hice cosas con sonido y/o graficos fue para NMP, y obviamente por la epoca pintaba mano la VGA y para hacer sonidos y musica programaba el chip OPL de la Soundblaster y el DSP de la misma. Visto desde esa perspectiva, Glk no esta bien, Glk es impresionante. Quiero decir, que mi punto de vista puede ser sesgado :D

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 14:40 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
baltasarq escribió:
Pues acabo de perder una hora tratando de cambiar los colores en Z, para descubrir símplemente, que Gargoyle tampoco lo soporta. El autor sabrá por qué.


En las versiones antiguas de Gargoyle, sólo en Z. Decisión (o flojera) del autor original de Gargoyle.

En las nuevas versiones de Gargoyle (GarGlk v0.7.0) ya se soportan los colores en Z, por petición expresa de este servidor al mantenedor (y amigo) Ben Cressey. :wink:

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 14:48 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
baltasarq escribió:
Lo único que he añadido es el closeAllWindows() antes de Restart. ¿Es esto normal? ¿A alguien más le ha pasado?


Balta, en realidad... digamos que no es que no sea "normal". En realidad, no es "ortodoxo".

Para manejar la restauración Glk existe el punto de entrada IdentifyGlkObject() de Inform. Es dentro de él donde se debe manejar la correcta eliminación de referencias de los objetos-glk y su posterior "restauración".

Claro, si no lo usas, o la parte que se encarga de "recuperar" las ventanas no está programada debidamente, la otra opción es "hackear" las rutinas de UNDO/RESTORE/RESTART para primero cerrar las ventanas y luego, cuando corresponda, volver a abrirlas. :)

Sí, a Urbatain le pasó en su "Galería de los Horrores", pero luego ya lo corrigió usando IdentifyGlkObject() [aunque su primera opción, según recuerdo, fue hacer el mismo hack que tú].

Saludos!

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 14:55 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
mapache escribió:
¿Has echado un vistazo a "La galería Glk de los horrores"?

http://www.caad.es/modulos.php?modulo=descarga&id=1424

Drácula 2 se basaba en él y no recuerdo que hubiera ningún problema...

Saludetes
Mapache


La "Galería de los Horrores" que está subida al CAAD tiene un bug muy feo, que fue justamente el motivo por el que fue subida a las descargas. :P

Yo corregí ese error (pero vaya que me dio dolores de cabeza), aunque lamentablemente he perdido el código luego de enviárselo a Urba. De cualquier manera, él también lo corrigió por su cuenta, y debe de tener una copia funcional.

Aunque, para usos, yo diría que la Galería es mejor como código "para estudio". Digamos que está programada un poquito "artesanal", para los fines mismos de la aventura de Urba (el mismo lo ha dicho).

Si se quiere usar algo que permita manejar con facílidad el oficio Glk, pues ya se pueden utilizar cosas como SGW, SMW, o mi propia SGW+DMX que es compatible con Damusix. Si se quieren obtener resultados "profesionales", ya se puede usar GWindows (a no tenerle miedo, luego que ya le agarras la forma, el resto es coser y cantar [yo solamente uso esta librería]). Efectivamente, con GWindows puedes crear interfaces de ventanas muy complejas (realmente complejas) sin preocuparte de las restauraciones ni cosas raras. Una maravilla! :)

Saludos! :)

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 15:26 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Uto escribió:
¿QUe significa exactamente "corresponde"?


Bueno, lo puse entre comillas porque involucra "muuuchas cosas", jejeje (muchos cálculos a nivel del Kernel de Damusix). Pero básicamente es lo siguiente (copiado directamente de la doc de Damusix):

[spoiler="Sobre el Mecanismo"]Mecanismo de "Protección de Sonidos" ante UNDO/RESTORE

Damusix incluye "de fábrica" un novedoso mecanismo de "protección de sonidos" ante los comandos UNDO/RESTORE. Por motivos técnicos de Glulx, siempre es necesario recuperar las referencias de los canales de audio Glk cuando el estado del juego cambia de alguna forma. Este cambio puede producirse, justamente, cuando el jugador usa los comandos UNDO/RESTORE/RESTART. La recuperación de las referencias de los canales de audio implica que es necesario siempre actualizar la reproducción en dichos canales, porque de otro modo estos podrían seguir sonando sin ningún control o podrían no reproducir los sonidos que corresponden con el nuevo estado del juego; siendo todas éstas, circunstancias no deseadas e irregulares. Por ejemplo, si grabamos una partida en la que estaba sonando una música de fondo, al cargarla en otro momento debería siempre "re-lanzarse" la reproducción de esa música de fondo. Lo mismo pasa ante UNDO.

Éste es el comportamiento deseado normalmente, pero no el ideal. Imaginemos que estamos jugando con cierta música "sonando de fondo" y luego hacemos UNDO. La música volverá a ser lanzada, desde el principio, aunque sea exactamente la misma que se estaba tocando antes del UNDO. Si hacemos UNDO muchas veces seguidas, este comportamiento "natural" podría llegar a ser muy molesto. Si la música actual es la misma que la música que estaba sonando cuando se grabó la partida, de todas formas se "volverá a tocar" desde el principio, produciendo el mismo feo efecto.

Damusix es la primera extensión para el manejo de audio en Glulx que incorpora un mecanismo para evitar este "comportamiento natural" al cambiar los estados del juego. El kernel de Damusix implementa un complejo sistema de comprobaciones para determinar si es preciso "re-lanzar" un sonido que estuviera "sonando de fondo" al momento de hacer UNDO o al recuperar una partida previamente grabada. Si el nuevo sonido que está "sonando de fondo" actualmente es el mismo que el sonido que estaba "sonando de fondo" previo al cambio de estado, entonces no es necesario volver a lanzar la música porque es evidente que "ya está sonando de fondo". ("Sonando de fondo" quiere decir para Damusix un sonido que ya está en reproducción con repeticiones infinitas.)

[...]

En el muy especial caso de que necesitáramos que Damusix se ejecutara en intérpretes de Glulx que no soporten apropiadamente el opcode @protect (definitivamente NO recomendado), existe una constante de compilación condicional para que la extensión compile sin usar el mecanismo de "protección de sonidos". De esta manera, los sonidos siempre serán recuperados correctamente ante UNDO/RESTORE, pero ya no se comprobará si están actualmente "sonando de fondo", por lo que todo sonido recuperado siempre será "re-lanzado" (el comportamiento tradicional).[/spoiler]

Básicamente, el Kernel comprueba uno por uno en los 10 canales si existe un sonido actualmente "sonando de fondo". Acto seguido, comprueba si ese sonido estaba previamente "sonando de fondo" en el estado anterior al "cambio de estado". Si la comprobación da positivo, quiere decir que el sonido ya está sonando y que no es necesario detenerlo de ninguna forma, solo hay que recuperar su referencia y ya. (Por supuesto, hay una serie de micro-comprobaciones, como, por ejemplo, si actualmente el audio de Damusix está activado o no, o si lo estaba previo al "cambio de estado", etc... Es un mecanismo bastante complejo. :roll:)

Eso. Saludos! :)

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 16:59 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4647
Eliuk Blau escribió:
Básicamente, el Kernel comprueba uno por uno en los 10 canales si existe un sonido actualmente "sonando de fondo". Acto seguido, comprueba si ese sonido estaba previamente "sonando de fondo" en el estado anterior al "cambio de estado". Si la comprobación da positivo, quiere decir que el sonido ya está sonando y que no es necesario detenerlo de ninguna forma, solo hay que recuperar su referencia y ya. (Por supuesto, hay una serie de micro-comprobaciones, como, por ejemplo, si actualmente el audio de Damusix está activado o no, o si lo estaba previo al "cambio de estado", etc... Es un mecanismo bastante complejo. :roll:)



Ehm, o sea , que guardas una lista de los recursos que estaban sonando en cada canal, supongo que usando @protect, y luego repasas en lugar de pararlos porque si. No es dificil de implementar en Superglus la verdad, de hecho yo diría que es más fácil que en Inform, porque ni siquiera necesito un @protect porque no cargo toda la memoria. A ver si me entran ganas y lo implemento.


Dudas:

¿Para que un sonido "perviva" debe coincidir en canal tambien o basicamente con que estuviera sonando en cualquier canal te vale?

¿Que pasa si un sonido antes del cambio estaba sonando en un canal y al cargar o lo que sea te aparece en dos? ¿y al reves? (antes dos, ahora solo uno). Obviamente me refiero al mismo recurso en dos o más canales.

Y esto ya super rebuscado:
Supongo que el hecho de que sea un SFX cortito o una banda sonora de 45 minutos de duracion en ogg es lo de menos, si el sonido estaba sonando, lo dejamos. Imaginemos un sonido que sea un speech de 20 minutos, esta sonando de fondo, grabamos, ponemos veinte ordenes, una de ellas relacionadas con algo que acabamos de oir en el speech, el speech sigue sonando, cargamos, el speech no se reinicia. Ya no volveré a oir la "pista".

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


Arriba
 Perfil  
 
NotaPublicado: 17 Jul 2009 20:38 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Uto escribió:
Ehm, o sea , que guardas una lista de los recursos que estaban sonando en cada canal, supongo que usando @protect, y luego repasas en lugar de pararlos porque si. No es dificil de implementar en Superglus la verdad, de hecho yo diría que es más fácil que en Inform, porque ni siquiera necesito un @protect porque no cargo toda la memoria. A ver si me entran ganas y lo implemento.


Bueno, todo lo que voy a escribirte ahora está planeado, obviamente, de acuerdo a la filosofía de funcionamiento de Damusix. Para otras "filosofías", estoy seguro que varias cosas cambiarán, pero lo que te hable se aplica directamente (y está condicionado) al funcionamiento con Damusix.

Primero que nada, voy a definir algo importante. En Damusix, cuando se habla que un sonido está "sonando de fondo" no significa que el sonido esté simplemente reproduciéndose y ya. En Damusix, "sonar de fondo" implica explícitamente lo siguiente: que el sonido esté actualmente en reproducción, y que tenga, además, repeticiones infinitas. Estas 2 condiciones deben suceder ambas. Si alguna de las 2 no se produce, entonces el sonido no está "sonando de fondo". Teniendo eso claro, ya puedo pasar a explicarte todo lo demás... =)

Sí, efectivamente guardo un array protegido con @protect. La idea es la siguiente: el array tiene tantos "slots" como canales normales existen en Damusix (10) [más 1 slot adicional para guardar el estado de activación del audio de Damusix, pero eso es harina de otro costal]. Por lo tanto, cada uno de los slots representa 1 canal de Damusix. En los momentos oportunos (por ejemplo, cuando se invoca una actualización del Kernel de Damusix con el fin de comenzar a tocar un sonido [o ante los UNDO/RESTORE]) una rutina especialmente programada se encargará de guardar en el array protegido solamente los sonidos en los canales que están actualmente "sonando de fondo". Es decir, si no se cumple esta condición, pues el slot específico para ese canal quedará con valor cero.

Posteriormente, ante un cambio de estado del juego, como el array está protegido, sus datos no son alterados, por lo tanto se conservan tal y como estaban justo antes del cambio de estado. Es en este momento cuando nuevamente la rutina encargada del mecanismo de protección comenzará a hacer comparaciones. Si resulta que el canal X tiene el mismo valor (el sonido) que el slot X del array protegido, es evidente entonces que ese sonido estaba "sonando de fondo" antes del cambio de estado, por lo que no hay que detenerlo. De esa manera se produce el efecto de no "re-lanzar" los sonidos. =) Por otra parte, si la comprobación es negativa, entonces sí hay que detener el canal.

A esto se agrega, como no, el estado de activación del audio de Damusix. Si el audio estaba activado antes del cambio de estado del juego, es evidente que el sonido estaba "sonando", por lo tanto no se relanza. Pero si el audio no estaba activado, y en el nuevo estado del juego ahora el audio sí lo está (por ejemplo, luego de cargar partida), entonces es evidente que el sonido, a pesar de tener "reproducciones infinitas" y de estar "en reproducción" a nivel de las variables de estado del Kernel***, pues es evidente que como el audio estaba desactivado, aunque se cumplan la condición de "sonando de fondo", el sonido NO ESTABA SONANDO. Por lo tanto, la rutina del mecanismo lo relanzará de todas formas.

Como vez, es un mecanismo bastante complejo. :P Pero funciona de mil maravillas. :D

***(En Damusix se puede activar/desactivar el audio de manera limpia. Esto quiere decir que, para el Kernel, todo sigue funcionando normalmente, un sonido en reproducción sigue en reproducción aún cuando el audio esté desactivado. Lo único que cambia es que cualquier rutina de reproducción será negada de manera silenciosa, es todo).


Uto escribió:
Dudas:

¿Para que un sonido "perviva" debe coincidir en canal tambien o basicamente con que estuviera sonando en cualquier canal te vale?


Damusix es muy estricto en cuanto al orden de los canales normales. Por lo tanto, y como lo explique más arriba, la comprobación es básicamente que el sonido en el canal X coincida con el valor en el slot X del array protegido. Si coinciden, quiere decir que el canal (correspondiente a X) cumple las condiciones necesarias para no ser re-lanzado. Estas condiciones son evaluadas previamente para cada sonido que se intente reproducir en Damusix. Y si existe dicho valor en el array protegido, es hecho claro que las condiciones evaluadas fueron positivas.

Uto escribió:
¿Que pasa si un sonido antes del cambio estaba sonando en un canal y al cargar o lo que sea te aparece en dos? ¿y al reves? (antes dos, ahora solo uno). Obviamente me refiero al mismo recurso en dos o más canales.


En Damusix, un mismo sonido no puede estar asignado a más de 1 canal. Por lo tanto, el sonido BIPBIP no puede tener el canal 2 y el 4, por ejemplo. No está permitido, principalmente porque podría volver inestable al Kernel de Damusix, ya que por la filosofía de "abstracción por sonidos", el Kernel necisita el nombre del recurso de sonido, y con él "busca" su canal. Si dos canales tiene el mismo recurso de sonido, el Kernel se confundirá. Lo cual quiere decir que usando canales normales, no se puede tocar el mismo sonido dos o mas veces al mismo tiempo (haciendo que se solapen). Para conseguir este efecto, Damusix proporciona la funcionalidad de "reproducción virtual" (con sus canales virtuales). En estos casos sí se puede tocar un sonido muchas veces y que se "solape" consigo mismo. Pero los canales virtuales no caen dentro del mecanismo de protección de sonidos. No son protegidos.

Por otra parte, imaginando la situación en que el sonido BOOM está "sonando de fondo" en el canal 2 y luego del cambio de estado aparece en el canal 4. Es evidente que en este caso el "esquema de sonido" cambió luego del cambio de estado. En tal caso, se debe re-lanzar el sonido. Si el "esquema" ha cambiado, es evidente que no nos encontramos en la misma "situación de audio" que en el estado actual. Esto debe ser calculado así porque de otra manera pueden producirse inconsistencias en el código, sobre todo si el audio está involucrado en programaciones complejas por parte del programador. Imagina que el sonido BOOM está "sonando de fondo" en el canal 2, pero al carga una partida ahora el sonido BOOM está sonando con 1 repetición en el canal 4. Es evidente que el esquema de audio a cambiado, para evitar cualquier tipo de error se reiniciará los canales afectados (lo que implica relanzar sus sonidos si corresponde). [En este ejemplo concreto, luego del cambio el sonido BOOM en el canal 4 no será relanzado, porque no está "sonando de fondo", sino que tiene 1 repetición. Es un sonido "oneshot" en Damusix, y este tipo de sonido jamás son relanzados por el Kernel, ya que se supone que se tocan 1 sola vez. Cualquier sonido que no tenga repeticiones infintas, es un sonido Oneshot en Damusix].

Uto escribió:
Y esto ya super rebuscado:
Supongo que el hecho de que sea un SFX cortito o una banda sonora de 45 minutos de duracion en ogg es lo de menos, si el sonido estaba sonando, lo dejamos. Imaginemos un sonido que sea un speech de 20 minutos, esta sonando de fondo, grabamos, ponemos veinte ordenes, una de ellas relacionadas con algo que acabamos de oir en el speech, el speech sigue sonando, cargamos, el speech no se reinicia. Ya no volveré a oir la "pista".


Claro, ya no volverá a oír la pista que le ayudará a resolver el puzzle. En cualquier caso, este tipo de usos digamos que no son... "demasiado ortodoxos". No puedes hacer que una parte importante del avance de la historia depende de una funcionalidad (el audio, por ejemplo) que es tan volátil de sistema a sistema, o de intérprete a intérprete.

En cualquier caso, el mecanismo de protección de sonido está pensado para cosas como "músicas" o "sonidos ambientales", que es evidente que se repetirán constantemente. Para algo como lo del speech que dices, sería mejor usar un sonido Oneshot. En cualquier caso, 20 minutos de audio hablado es realmente una exageración... :lol: Jajaja! En fin, vamos, que todo esto depende del buen uso o del mal uso que se le dé a las funcionalidades de la librería.

Imagino que si el audio fuera no demasiado largo (por ejemplo, una voz de alerta que saliera por un altoparlante) podría ponerse "sonando de fondo". Con lo cual se repetiría, sería además protegida, y por otro lado, como se repite el jugador podría detectar de nuevo la "pista", si se la ha perdido. :) Vamos, que todo esto depende de cómo se te ocurra implementar el problema con las herramientas de las que dispones.

Saludos!

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


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 19 Jul 2009 21:54 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4647
A ver si me entran ganas e implemento algo así para los canales de Superglus, de hecho creo recordar que el array de canales ya guarda de por si los recursos que se estan tocando en cada uno, así que creo que me resulta más facil que en Inform en teoría, ni siquiera necesito el protect, pero claro, lo tengo que hacer en assembler, aunque tampoco es para tanto :)

Me dejaré de casos patológicos como el del speech por otro lado :)

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


Arriba
 Perfil  
 
NotaPublicado: 20 Jul 2009 11:51 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2918
Ubicación: España (Galicia)
Eliuk Blau escribió:
Balta, en realidad... digamos que no es que no sea "normal". En realidad, no es "ortodoxo".

Para manejar la restauración Glk existe el punto de entrada IdentifyGlkObject() de Inform. Es dentro de él donde se debe manejar la correcta eliminación de referencias de los objetos-glk y su posterior "restauración".


NO, no estoy hablando de cuando el jugador hace "load" (esto me funciona perfectamente en identifyGlkObject()). sino de cuando el usuario teclea "reiniciar".

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
NotaPublicado: 21 Jul 2009 03:38 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
baltasarq escribió:
NO, no estoy hablando de cuando el jugador hace "load" (esto me funciona perfectamente en identifyGlkObject()). sino de cuando el usuario teclea "reiniciar".


Pues es exactamente lo mismo. IdentifyGlkObject() se ejecuta en las tres siguientes instancias: RESTART/RESTORE/UNDO. Por eso que yo siempre las encasillo igual, las tres.

En el caso de un "load", el esquema de ventanas ya está existente, por lo que simplemente se debe recuperar referencias en IdentifyGlkObject(). En el caso de un "reiniciar", el asunto es un poco más complejo, y te paso a explicar por qué. :)

Resulta que cuando haces un "load", las ventanas ya las abriste previamente en tu rutina Inicializar() [por ejemplo]. En tal caso, como el esquema de ventanas ya existe, simplemente hay que recuperar sus referencias en las variables que correspondan. Esto lo hace IdentifyGlkObject(), solita, automágicamente, si la has programado correctamente.

En el caso de "reiniciar" el asunto cambia un poco. Luego del reinicio el esquema de ventanas sigue abierto (vamos, lo normal), e IdentifyGlkObject() se encarga de recuperar sus referencias en las variables que corresponda (vamos, lo normal). El "pero" es el siguiente: luego de este punto, se ejecutará tu rutina Inicializar(), donde se supone que ejecutas el código que construye tu esquema personalizado de ventanas. ¡Pero el esquema ya está construído! (se construyó en la primera ejecución) :D. La solución es la siguiente:

- O compruebas directamente las variables de las ventanas: si valen cero (no están inicializadas), significa que la recuperación no tuvo éxito (y por tanto el esquema de ventanas aún no ha sido creado [primera ejecución]) y entonces vas y creas las ventanas que necesites. En caso contrario, si las variables tienen algún valor distinto de cero, quiere decir que la recuperación en IdentifyGlkObject() tuvo éxito, por tanto el esquema de ventanas ya está previamente creado, por tanto estamos ante un reinicio, y en consecuencia, no deberás crear las ventanas porque ya existen.

- Esta otra forma es más práctica. En tu código de creación de ventanas, constata primero el valor de las variables de las ventanas. Si valen algo, ejecuta el código para cerrarlas todas. Y luego ejecuta el código para volver a abrirlas. Pero si valen cero, pues te saltas el codigo para cerrarlas y simplemente las abres... sería algo como esto (retocado desde SGW+DMX):

Código:
[ Inicializar;
    if (gg_miVentana) {
      glk_window_close(gg_miVentana,0); ! la cerramos
      gg_miVentana = 0;                 ! y limpiamos referencia
    }
    ConstruirMiVentana();
];


De esta manera, te aseguras que si el esquema de ventanas ya existe (por lo tanto IdentiGlkObject() recuperó la referencia de las ventanas y las guardó en sus correspondientes variables [gg_miVentana, en el ejemplo]), pues como están abiertas, primero las cerramos y luego las volvemos a abrir. ¿Tiene sentido, no? :D

Lo sé, que la Glk no tiene sentido, jajajaja!, pero al menos esta explicación intento que sí lo tenga. :P

Pues eso, que "reiniciar" tiene la única pega adicional que pasa que el código que pones para que abrir las ventanas se vuelve a ejecutar, y como las ventanas una vez abiertas se mantienen así aún cuando reinicies la máquina, primero debes comprobar que no estén abiertas, para intentar abrirlas de nuevo, ¿no? Y eso se logra consultando el valor de sus variables, que se supone que IdentifyGlkObject() a recuperado correctamente si es que dichas ventanas ya estaban abiertas previo al reinicio. :)

Saludos!

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


Arriba
 Perfil  
 
NotaPublicado: 21 Jul 2009 07:26 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4647
Eliuk Blau escribió:
Lo sé, que la Glk no tiene sentido, jajajaja!, pero al menos esta explicación intento que sí lo tenga. :P

Pues yo diría que lo que dices tiene sentido 100%. Creas ventanas, no las destruyes, las vuelves a crear, y tienes exactamente lo que has pedido.

Eso que indicas es un problema de Inform o de su librería, no es ni de Glk ni de Glulx. Si el "reiniciar" de Inform, se haga como se haga, se molestara en hacer las cosas bien no habría ese problema. El problema por lo que veo es que el "reiniciar" de Inform no deja la máquina como estaba al principio, y eso es un error, pero de Inform, porque desde luego dejarla como al principio es posible: Superglus lo hace.

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


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 34 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 6 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:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM