CAAD

[b:3d0c24e70b]GlulxVM con capacidad de coma flotante[/b:3d0c24e70b]
Al parecer el panorama con Glulx va cambiando...

Hace aproximadamente un mes, Andrew publicó un borrador de lo que será la próxima especificación para la incorporación de operaciones de coma flotante [b:3d0c24e70b]nativas[/b:3d0c24e70b] en Glulx, [b:3d0c24e70b]sin necesidad de tirar de librerías[/b:3d0c24e70b] cómo se venía haciendo actualmente (I7 es un gran ejemplo), cuyo uso producía una enorme pérdida de tiempo de procesamiento debido al trabajo extra de cálculo que no supondría problema que viniera ya incorporado (esto se nota, sobre todo, en algunas aventuras con gráficos reescalados).

[b:3d0c24e70b]Hace unos días, Andrew ha anunciado la liberación de Glulxe 0.4.6 (el intérprete de Glulx estándar) y Quixe 1.0.2 (el intérprete de Glulx web), que ya traen incorporada la nueva funcionalidad de coma flotante.[/b:3d0c24e70b]


Ya hay parches del compilador de Inform para poder crear aventuras que aprovechen este nueva funcionalidad, pero decir que sólo funcionarán en intérpretes que acepten la nueva especificación de GlulxVM versión 3.1.2 (Glulxe y Quixe antes mencionados). Se deberá esperar un poco hasta que David Kinder publique versiones actualizadas de los intérpretes Windows Glulxe y Windows Git, así como Ben Cressey libere nueva versión de Gargoyle.

¿Impacto? Pues no mucho, la verdad. Pero será increíblemente útil para la multimedia, sobre todo en la gráfica, para poder reescalar sin pérdidas de precisión (o al menos no notorias) y para dibujar sprites en posiciones porcentuales relativas sin margen de error (o al menos no notorio) tal como ya hace la genial extensión Glimmr para I7, pero tirando para ello de otra extensión de soporte que emula cálculos con decimales (y como emulación tal, lentitud también).

A ver si alguien se aventura a generar binarios del compilador! :D

[url=http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/b515dbc8d10a90a9]And also, that Glulx floating-point spec[/url]

[url=http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/82955056d67b2edf]Glulxe, Quixe updates[/url]

Cuando salga una nueva versión de Windows Glulxe actualizaré.
Sin embargo,

• ¿Qué es aquello de la coma flotante?
• ¿Tiene alguna utilidad fuera de lo que son gráficos?

¡Saludos!

Matemáticas de coma flotante, amigo mío

Más info sobre el tal en:
http://es.wikipedia.org/wiki/Coma_flotante

Y pues, es más que seguro que alguien le encontrará alguna otra utilidad práctica, qué se yo, en el audio quizás o en motores o cálculos de probabilidades en futuras extensiones.

De momento, la utilidad evidente en en la gráfica.

Saludos!

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

Utilizar la coma flotante para reescalado de gráficos en 2D ha sido siempre un error, cualquier rutina de toda la vida para hacer estas cosas rápido precisamente lo que buscaba era evitar la coma flotante, que introduce lentitud innecesaria. Solamente si fuera necesaria una precisión enorme sería importante la coma flotante, y dudo que eso ocurra en una aventura.

Por otro lado, me parece muy triste que en Quixe se metan funcionalidades nuevas antes que las viejas (¿graficos?)

Ya escribiré mas cosas que ahora me tengo que ir pitando

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

Ah... yo me llevo muy mal con las matemáticas así que tendré que ver ese enlace a la Wikipedia si quiero entender de qué se trata.
Y en cuanto a la manifestación de tristeza de Uto por la incorporación de cosas nuevas antes de las viejas, yo pienso que no es totalmente malo. Me parece una buena forma de demostrar que tal proyecto está vivo y promete un gran nivel de banguardia. Por otra parte, es cierto que tienen que ocuparse también de las cosas viejas porque más allá de la obviedad de que al ser viejas son estables y ya están desarrolladas, son las que comúnmente se utilizan en la actualidad.

¡Saludos!

Ah sí, lo acabo de ver en Wikipedia y es algo que conozco hace tiempo; lo que sucedía era que no me suelo referir a eso con tal nombre. Ahora que entiendo la relación con las matemáticas pregunto, ¿estas operaciones de correr la coma se aplica en el reescalado de gráficos para que sea altamente preciso el valor al que se lleva, no?

¡Saludos!

Es simplemente porque Andrew quiso meter la coma flotante y ya. Podría haber sido igualmente útil la coma fija de toda la vida. El caso es poder tener acceso a los decimales.

Contrario a lo que dice Uto, al reescalar gráficos es una necesidad poder contar con cálculos decimales. Y también al tener que posicionarlos en posiciones relativas condicionadas por un factor o porcentaje de posicionamiento. Esto sucede porque a veces los números no dan exacto, y el margen de error puede ser relativamente grande. A veces en una compleja interfaz gráfica, un margen de un pixel de error (un pixel corrido) puede arruinar todo el despliegue de una bonita interfaz.

La afirmación de Uto sólo me parece válida en los casos en los que, por ejemplo, se debe pintar sobre un buffer gráfico (en la memoria) por medio de un método llamado Blit, y luego ese buffer se manda a la memoria de video o sencillamente se manda a alguna rutina de pintado. En este caso, el buffer corresponde a la superficie completa del lienzo que se debe pintar, por lo tanto el reescalado es super sencillo. (Es lo que usualmente hacen librerías de C++, o parecido a lo que hacen las modernas tarjetas gráficas de ahora con aceleración de video).

Por supuesto, Glulx no cuenta con estas características, por lo tanto la necesidad de operaciones con decimales al dibujar gráficos es un bonus requerido y que faltaba hace tiempo que se integrara de una buena vez.

Entiendo que Uto cascarrabee un poco, porque como es el único mantenedor de Glulxa (el compilador de assembler de Glulx) le tocará trabajo adicional (encima que no es su obligación) para añadir estas nuevas características y que luego se puedan usar en SuperGlús.

Saludos!

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

No es que sea un gran experto en hardware así que puedo equivocarme; pero por lo que tengo entendido, esto ya no es así en la mayoría de los procesadores desde hace años.

Efectivamente, por ejemplo en los 386, 486, etc.; las operaciones en coma flotante eran muuucho más lentas que las de enteros. Pero en el Pentium empezaron a preocuparse por esto y metieron una unidad de coma flotante cañonera que prácticamente igualaba las cosas. Y en sucesivas generaciones de Pentiums y AMD's esto ha ido mejorando de tal manera que ahora se suele considerar que la aritmética en coma flotante es más rápida que la de enteros (aunque esto tampoco quiere decir que tengamos que hacer operaciones de enteros en la FPU, porque las conversiones de un tipo a otro sí que tienen un coste bastante elevado).

Donde sí que sigue siendo lenta la coma flotante es en arquitecturas que no tienen FPU. Esto no sucede por ejemplo en los PC's; pero si una aventura quiere ejecutarse en un móvil sí que debería intentar evitar la coma flotante para ir rápido, ya que muchas arquitecturas de móviles no tienen unidad de coma flotante.

Alguna información sobre estos temas:
http://stackoverflow.com/questions/2550 ... n-hardware
http://www.gameprogrammer.com/4-fixed.html

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

Muchas... tiene utilidad en todo lo que requiera un cálculo matemático cuyo resultado no tenga por qué ser un número entero. O sea, para cualquier cosa que requiera una expresión matemática o un modelo en una aventura. Ejemplos:
- Calcular la probabilidad de acertar con un arma en función de tu habilidad con el arma, y luego aplicarla para decidir si el golpe acierta o no.
- Calcular el daño que haces con el arma siempre que sea algo más complicado que una simple tirada de dados (por ejemplo, si quieres que el daño siga una distribución normal, o si quieres que se multiplique por un coeficiente no entero que dependa de la fuerza, etc.)
- Hacer una red neuronal para decidir cómo reacciona un PSI ante algo.
- Calcular heurísticas para un algoritmo de búsqueda A* que permita a un enemigo buscar el camino óptimo para encontrarte y atacarte.
Etc. etc.

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

En realidad no, ni soy el único mantenedor de Glulxa, porque no soy mantenedor de Glulxa y que yo sepa no hay ningún mantenedor "oficial" de Glulxa, ni tengo ninguna necesidad de añadir funcionalidades que a Superglús no le hacen ninguna falta (Glulxa soporta una versión de la maquina glulx bastante antigua, y lo que es por mi, y por el proyecto Superglús, no se va a actualizar, dado que a Superglús no le hace ninguna falta ninguna de las novedades que han salido en los últimos años:

- @mcopy, @mzero, @malloc, y@mfree (Superglús no necesita por ahora de memoria dinámica, y aunque mcopy podría sustituir algún bucle de copia de memoria que hay, la verdad es que el esfuerzo de cambiar el codigo de Superglus, añadido al esfuerzo de meter @mcopy en Glulxa y el riesgo de que al hacer los cambios aparezcan bugs, todo para ganar un nanosegundo una vez cada tres horas, no merece la pena. Si alguien reporta que Superglús tarda muchísimo en grabar una partida o en reiniciar el juego, que es donde se usa, ya me lo planteo).

- @accelparam (Supergús no requiere del parche chapucero de los @accelparams)

- Coma flotante: no consigo encontrarle una utilidad, y desde luego los gráficos no son una, salvo que alguien quiera hacer un engine 3D en Superglús, en cuyo caso yo recomendaría que se lo hiciera mirar XD. En 2D no tiene un gran sentido habida cuenta que los display son discretos, no continuos, y que afortundamente 2^32 es un numero muy grande que permite trabajar con las unidades multiplicadas por 2^16 o más para finalmente dividir y así no perder precisión, a la vez que continuas usando aritmética entera, mucho más veloz computacionalmente hablando y de manera genérica que la aritmética de coma flotante. Incluso si en PC no es así, cosa que dudo porque por ejemplo los cálculos realizados en Superglus son en muchos casos instrucciones SHR y SHL que dudo que haya nada más rápido que eso, seguirán quedando dispositivos que, como el muy bien dice, no tengan FPU, que encima son los dispositivos "más débiles". Y si la perdida de precisión no existe hoy por hoy, y a eso le sumas que encima vas a perjudicar a los dispositivos más pequeños, para mi es un NO rotundo al uso de coma flotante para el escalado de gráficos. Otra cosa será el día que los monitores normales tengan resoluciones de 672345723523x7823672362, entonces lo mismo se quedan cortos los 32 bits para hacer los calculos con enteros.

Otras utilidades de la coma flotante podrían aparecer desde luego, siempre es posible que en un juego alguien necesite almacenar un valor real (número real) pero no me parece ni importante ni mucho menos prioritario. Al-khwarizmi plantea algunas, y desde luego estaría muy bien que se pudiera y tener eso, pero vamos, me parece bien pero no es para tirar cohetes. Tiraría cohetes si mañana dicen que se da soporte OGV en Glk, eso sí estaría bien XD

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

Aparte del tema de la coma flotante, comentar que esta nueva especificación Glulx me decepciona, aunque ya me lo esperaba, con el tema de los parámetros de 8 y 16 bits que tantos problemas dieron con Git y Superglús.

Como habréis podido ver, dichos parámetros pasan a estar "deprecated", pero Andrew ha ignorado (aunque la verdad no me esperaba otra cosa, tengo la impresión de que me tiene en una blacklist o algo) mi recomendación de que en la propia especificación se indicara que en caso de encontrarse con un parámetro de este tipo, la recomendación para los interpretes fuera tratarlo como si fuera de 32 bits. Eso habría hecho funcionar en Git las aventuras de Superglús antiguas que usan dichos parámetros. Tras leerme las especificaciones nuevas veo que se ha limitado a indicar que estan deprecated sin añadir ninguna información, lo que probablemente puede incluso llevar a que los nuevos interpretes que pudieran aparecer en el futuro ni siquiera implemente dicha funcionalidad, haciendo dichas aventuras, que eran perfectamente acordes a las especificaciones, incompatibles con dichos futuros interpretes además de con Git. En fin, sigh....

Nota: cuando cambié Superglús para que no usara dichos parámetros, ya observe que Yokiyoki los habiá utilizado porque los valores contenidos nunca iban a superar esos límites, y en ningún caso para hacer algún calculo cíclico en el que se quisiera intencionadamente que dichas variables se desbordaran, por tanto cambiarlas a 32 bits no tenía nungun efecto secundario. Si simplemente los interpretes trataran dichas variables de 8 o 16 bits como de 32 bits esas aventuras funcionarían. Espero que al menos David Kinder, que andaba por el hilo, haya tomado nota, pero no puedo estar persiguiendo a cada nuevo autor de intérpretes

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

Muy aclaradoras las respuestas de todos.
En cuanto a la explicativa opinión de Uto, si crees que Andrew Plotkin te tiene en lista negra, que otro haga la recomendación , total las especificaciones todavía son un borrador. Por otra parte, preocuparse por Git lo veo como una pérdida de tiempo, si total Glulxe y sus variantes por ejemplo para Windows no consumen muchos recursos (piensen que funcionaba en mi ordenador viejo de 128 MB de RAM), por lo que no veo necesario crear un intérprete que quite características de la máquina sólo por un poco más de velocidad; ¿a caso es muy común la utilización de Glulx para cosas más complejas que aventuras conversacionales?
Distinto es, y estoy de acuerdo, en los dispositivos móviles, donde ciertas arquitecturas no están soportadas, o tienen poca memoria RAM provocando que se cuelguen o las aplicaciones se cierren. En esos caso sí sería necesario usar funciones que consuman la menor cantidad posible de recursos del sistema.

¡Saludos!

1) Los borradores de Andrew usualmente son ley. No puedes luchar contra eso. A mí me ha mandado a guardar silencio una vez y la otra me dijo que un problema (con la nueva spec) debería ser solucionado por los propios programadores de librerías (es decir, le lanzó la pelota a otros). Así que comparto el sentimiento de Uto.

2) Git es un intérprete dentro de los "importantes". Hay tantos intérpretes que utilizan Git como tantos que utilizan Glulxe, aunque sea el de referencia. I7 usa por defecto Git, aunque permite elegir usar Glulxe. Zoom usa Git. Spatterlight usa Git. Gargoyle usa por defecto Git, pudiendo elegirse Glulxe. En fin... El caso es el siguiente: "no es asunto de recursos". Ninguno de los dos intérpretes ocupará demasiados recursos. Es asunto de velocidad. Recordar que estamos hablando de máquinas virtuales. Git es un intérprete definitivamente más rápido que Glulxe, y la diferencia es notoria. Es más rápido porque optimiza todo el código de Glulxe, en el que se basa (y en versiones antiguas, quitaba funcionalidad no utilizada en Inform). En las versiones actuales pasa muy contento todos los Glulxercise, así que es totalmente compatible con Inform o SuperGlus (en la nueva versión lanzada por Uto), etc. De hecho, las actualizaciones en Git fueron en parte conseguidas por mi insistencia de agregar una funcionalidad faltante que impedía que Git ejecutara correctamente aventuras que usaran Damusix. Se lo pedí directamente a David Kinder. El tipo es genial. Nunca tiene reparos en ayudarte, si puede. A la semana ya tenía corregido Git, en su código fuente oficial (del que ahora es mantenedor).

3) Debido a la salida de I7, fue necesario optimizar la velocidad de los intérpretes y usar todos los trucos sucios necesarios (sépase, nueva spec de Glulx con aceleración) para que las aventuras funcionaran lo más rápido posible, porque su lentitud era evidente e irritante. Sobre todo considerando que eran lentas incluso aquellas que no usaban nada de multimedia, solo texto plano. De esto ya hemos hablado mucho, antes de tu llegada al CAAD y pues quedó relativamente consensuado que las aventuras de I7 son definitivamente más lentas que las aventuras de I6 de toda la vida, debiéndose probablemente a un problema de optimización del preprocesador NI. En mi caso, además creo que se ha puesto de manifiesto que la arquitectura de VMs ha demostrado no estar a la altura para soportar la cantidad de procesamiento por turno de las aventuras generadas por el nuevo I7. Se requiere, en mi opinión, de una nueva VM, generada desde cero. O quizá de un concepto deferente de VM, quizá de un motor. En fin... el tema da para mucha discusión constructiva.

Saludos!

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

Pues en ese caso hay que arreglar las cosas con Git, no sabía que se usaba tanto; sólo tenía conocimiento sobre Gargoile e I7. En cuanto a David Kinder comparto tu opinión que es un tipo genial; las veces que me contacté con él ha hecho avances positivos sin tener problemas; por ejemplo, cuando le pregunté sobre los problemas de accesibilidad que yo tenía en Windows Frotz y le dije que estaría bueno que pusiese una función de texto a voz como en Windows Glulxe, primero me dijo que alguien había tomado el código de Windows Frotz y le había puesto funciones de voz, bajo el nombre de WinFrotz TTS; yo le contesté que lo tenía pero que no guardaba y recuperaba partidas correctamente, que la última versión se basaba en Windows Frotz 1.4 cuando ya estaba el 1.15, que daba error con las voces Loquendo al escribir rápido debido a que anunciaba las palabras al escribirlas,..., me dijo que en ese caso consideraría la adición de soporte de voz en la próxima edición de Windows Frotz y es así que lo hizo; poco tiempo después de esta comunicación vi en el CAAD la noticia de que había salido Windows Frotz 1.16 cuyas novedades eran la actualización de algunos enlaces de Internet en el menú de ayuda, correcciones varias y el soporte de voz con el motor SAPI 5.

¡Saludos!
PD: ¿Hay Git para dispositivos móviles con Symbian 6, 7 y 8?

Precisamente el principal problema es que Gargoyle usa Git como interprete por defecto para Glulx. Lo cual lleva a que cada pocos meses salga la pregunta de alguien que ejecuta una aventura antigua de Superglus y le sale el error de "8 and 16 bits local variables are not supported".

En cualquier caso, como ya comenté, el problema no es que Git lo arregle o no, el problema es que deja colgando el problema para cualquier interprete futuro que esté por venir. En el fondo son 6 o 7 aventuras las que tienen el problema, pero lo tienen por razones externas a ellas y a Superglús. Esas aventuras funcionan en glulxe y otros interpretes, pero es bastante cansino tener que decirlo cada vez, cuando arreglarlo definitivamente habría sido cosa fácil indicándolo en las especificaciones. Pero vamos, que ya estoy acostumbrado a que Superglus no exista para Andrew, no es nada nuevo, de hecho si tuviera ganas, que no las tengo, cambiaría Superglús para que usara una máquina virtual decente, en lugar de Glulx. Dudo que nunca tenga ganas de acometer semejante cambio, asi que tendre que asumir que Glulx es en el fondo la "I7 Virtual Machine" y seguir siendo un "alien" en ese mundo.

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