CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 27 May 2019 06:28

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 123 mensajes ]  Ir a página Anterior  1 ... 5, 6, 7, 8, 9
Autor Mensaje
NotaPublicado: 20 Mar 2010 23:47 
Desconectado
Elfito
Elfito
Avatar de Usuario

Registrado: 18 Mar 2010 11:44
Mensajes: 15
Gracias por las respuestas. Creo que voy a empezar con Inform 6, porque se parece mucho más a java o c, lenguajes con los que estoy algo más familiarizado, aunque seguiré ojeando de cerca el Inform 7.

Espero que se sigan formando discusiones sobre los diferentes sistemas y lenguajes como la que parece que ha dado lugar tras mi pregunta sobre Alabaster, se aprenden muchas cosas de ellas.

Gracias por todo de nuevo. Saludos.


Arriba
 Perfil  
 
NotaPublicado: 21 Mar 2010 23:08 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4645
DrVanHalenFan escribió:

Uto escribió:
Para empezar porque ni Windows ni Linux ni macos escalan nada, lo hacen librerías gráficas independientes (como winglk que se apoya en sdl si no recuerdo mal)

Todas ellas conocidas por su vocación multiplataforma, que significa que más tarde o más temprano acaban recurriedo a las rutinas de bajo nivel del sistema concreto en que se aplican, que pueden ya ser (y de hecho son) mejores o peores en cada caso.

Bueno, por aclararnos: ¿me puedes decir exactamente a que rutina del API de Windows que llama WinGlk o Gargoyle Glk, directa o indirectamente a través de la SDL? Más que nada por entender a cual nos referimos cuando hablamos de ella. Me gustaría saber de que función hablamos y también por qué en Windows es obligatorio escalar con esa función, y no se puede usar otra.

Lo digo porque acabo de mirar el codigo de WinGlk y la versión nueva, la que supuestamente ya esta mejorada por Kinder para un escalado mas rapido, se limita a utilizar una DLL externa llamada ScaleGfx, que antes no usaba. Supongo que me dirás que sin duda esa DLL llama "una función de bajo nivel del SO", aunque en realidad como esta escala rápido, a diferencia de la que tenía el anterior WinGlk, siguiendo tu razonamiento debo pensar que estas en lo cierto, pero claro, esta dll debe estar llamando a la función de bajo nivel de MacOS desde Windows, porque en Windows escalar rápido es imposible por limitación explícita del SO (siempre según tu razonamiento) };)

También he mirado el fuente de GargoyleGlk, y ¡oh sorpresa!, para escalar los gráficos ni siquiera usa SDL, así que veo imposible que SDL este llamando a esa famosa aunque desconocida "función de bajo nivel del SO". GargoyleGlk tiene una función de escalado propia escrita en C que puedes encontrar en el fichero imgscale.c, y que no llama a nada externo, salvo a esto claro:

Código:
#include <math.h>
#include <stdio.h>
#include <stdlib.h>


No me queda muy claro cual de las tres es la librería de escalado de Windows (o de Linux, que este Gargoyle compila tal cual en Linux).

Resumiendo, ninguno de los Glk existentes para Windows, y en el caso de GargoyleGlk, para Windows/Linux hacen uso de las míticas "funciones de escalado del sistema operativo". En cuanto a MacOS, resulta que a diferencia de Windows, tiene muy bien separado lo que es el sistema operativo de lo que es el GUI, por lo cual las posibilidades de que el sistema operativo facilite funciones de escalado de gráficos son aún más complicadas, de hecho, sería el primer unix en incluir algo así. Zoom está usando Cocoa para el tema gráfico, y Cocoa es un framework de desarrollo para MacOS, no un sistema operativo ni parte de él.

En cualquier caso, aunque esas legendarias funciones existieran, y las Glks de Windows las usaran en el pasado o en el presente, eso no significaría que en Windows no se puede escalar más rápido, simplemente significaría que el SO facilita unas funciones de baja calidad, pero oye, que no te apuntan con una pistola para que las uses ¿eh?, que por algo se inventaron cosas como SDL, OpenGL, DirectX, etc.

Citar:
Otra alternativa, claro, es que diese la casualidad de que los autores y testers que usaban Mac se lo hubiesen comprado todos dos días antes mientras que los usuarios de Windows tenían todos PCs de hace varios años. Pero de verdad que me da a mí que no... Y por Dios, no me pongas el ejemplo de Irfanview. Éste, efectivamente, usa sus algoritmos de reescalado propios en los zooms, haciendo unas extrapolaciones muy bonitas que te permiten "acercar la cámara" sin pérdida de calidad... ¡pero a costa precisamente de gastar más tiempo que el propio visor de Windows, que se limita a usar las standard del sistema operativo!

En realidad lo que te había dicho es que el Irfanview escala mas rápido, no mas lento, así que no entiendo de que hablas cuando dices que tarda más, yo lo que he dicho es justo lo contrario, que tarda menos. Ademas no solo lo hace el IrfanView, sino que también lo hacen el Gimp y el Photoshop, y no tengo más ejemplos porque no me apetece instalar más programas. En realidad creo que solo el visor de imágenes de Windows es tan sumamente lento, jamás he tenido problemas para escalar gráficos con otros programas. Supongo que dirás que es que Gimp y Photoshop también usan unos algoritmos de reescalado propios, que deben ser de MacOS, porque son rapidos. El problema no es de Windows, es de usar funciones deficientes cuando se pueden hacer mejores, e incluso, como parece que hizo Kinder, usar otras mejores ya hechas.. para Windows.

Citar:
Uto escribió:
Además había otro problema por ahí com no se que rollo de reglas que se había montado para la conversación que se daba de tortas co el "arrayón" de Inform. Inform tiene un problema de diseño y bastante parche chapuza, y no hay ningún problema en decirlo :)

Efectivamente no pasa nada por decirlo pero hay que decirlo bien ;-) . Puedes pretender ignorarlas, pero se han aportado pruebas contrastables de que el retardo de Alabaster se producía por el tiempo invertido en el reescalado de los gráficos. Se redujo el tamaño de los gráficos y el retardo desapareció.

No pretendo ignorarlas y no pretendo decir que el escalado no tenía parte de la culpa, pero si Emily cambió también algo en el tema de las reglas de entender la conversacion o no se que leches que llevaba Alabaster, por algo sería. La velocidad fue corregida no solo por el cambio del tamaño de los graficos y por el esfuerzo hecho por David Kinder para mejorar las funciones de escalado, sino por el cambio de planteamiento que hizo Emily en su aventura, cambiando código, para evitar la creación desmesurada de objetos que producía su planteamiento inicial, que venía a darse de bruces con el problemilla de Inform.

Citar:
Tu mismo nos has aportado las pruebas de que, para gráficos de gran tamaño, el redibujado de una simple acción "mirar" bloquea a SuperGlus durante varios segundos, como si de un "vulgar" Alabaster se tratase ;-).

En realidad no, yo digo una cosa y tu sales por otra: yo he aportado pruebas de que una imagen del tamaño de las malignas es instantanea en Superglus, y una imagen 16 veces mayor tarda medio segundo. No acabo de entender como te puede tardar tanto a ti, pero mis pruebas dicen justo lo contrario de lo que tu dices que dicen. Escalar un grafico de 1500x3000 no tarda tanto, había más chicha y ya se reconoció así por aquel entonces :)

Citar:
La gente como yo no podremos presumir de tener titulaciones en ingenierías informáticas, como entiendo que es el caso de vosotros, los gurus del CAAD, pero al menos yo prefiero manener la mentalidad y, sobe todo, la actitud de programador, al menos en el sentido de que, ante la presencia de un problema, intentar encontrar la verdadera causa del problema antes que lanzarme con entusiasmo y sin pensar a afirmar que determinadas herramientas son un horror y una chapuza.

Vaya, me vas a hacer llorar :P. En realidad no hace falta ser un guru ni tener ningún título, para entender que entre las funciones de un sistema operativo no esta la de escalar gráficos, y que eso depende de las librería gráficas que funcionan sobre ese sistema operativo, que pueden ser malas, regulares o buenas. Precisamente por el interés en llegar al fondo del asunto se llega a todo el fondo del asunto, no solo a la parte en la que el escalado afectaba, sino también al resto. Si quieres tú te puedes quedar con media solución y quedarte a gusto, pero yo no podría :)

Por otro lado tampoco hace falta contar con Alabaster para decir que Inform tiene un problema grave de diseño: aunque Alabaster no hubiera existido jamás, podría decirse lo mismo porque el asunto del "ARRAYÓN" es algo publico, conocido, y comentado más de una vez en el raif por Plotkin, Kinder y demás, mucho antes de Alabaster. Y aparte de eso están los @accelcodes de Glulx, hechos para tapar los problemas de I6 que se manifestaron al crear I7, mucho antes de que Alabaster fuera ni tan siquiera una idea remota en la mente de Short. En fin, que lo de Alabaster, solo fue algo más, un punto en el cual Emily metio la pata de dos maneras:

1) Poniendo graficos mas grandes de lo que se iban a mostrar jamás, topandose con un problema de implementación deficiente del escalado de graficos en algunas implementaciones de Glk (en concreto en WinGlk, GargoyleGlk para Windows y GargoyleGlk para linux, al menos)
2) Generando un sistema de conversaciones que generaba una cantidad desbordante de objetos, que se añadían al array de búsqueda secuencial de Inform.

Pero antes de que Alabaster existiera, ya se sabía de ese problema de Inform ,y de muchos otros que fueron parcheados con los @accelcodes.

Y aun así, sigo diciendo, que afortunadamente ese problema no es importante a la hora de desarrollar aventuras, porque salvo en casos muy notables, y gracias a los parches puestos en los interpretes, no se nota, y con el tiempo y mejores máquinas menos se va a notar. Esto queda demostrado por el hecho de que Alabaster, tras reducir gráficos, cambiar el sistema de conversaciones, y tras las mejoras a WinGlk de Kinder, pudo ser jugado sin problemas por mucha gente y ahora es candidata a los XYZZY awards :)

Eso sí, el pobrecito Spectrum tiene una indigestión grave con la búsqueda secuencial de objetos en el array, lo que afecta gravemente a la zxzvm, pero bueno, todos sabemos que la zxzvm iba a estar muy limitada de todos modos :D

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


Arriba
 Perfil  
 
NotaPublicado: 22 Mar 2010 22:40 
Desconectado
Archivero
Archivero

Registrado: 08 Sep 2008 22:04
Mensajes: 271
Uto escribió:
Vaya, me vas a hacer llorar :P

Si necesitas un hombro... :wink:

Vaaale, aprecio de veras el intento de "Ni tu ni yo y la perra gorda pa los dos" :) , que al fin y al cabo ya hizo la propia Short en su blog con meses de antelación, adelantandose a nuestra discusión, posteando esto para que ambos nos quedasemos calladitos y a gusto :P

Citar:
Originally it was specifically the Windows implementation that was especially slow, and this turned out to be because WinGlk had trouble scaling down the larger graphics in a reasonable amount of time. David Kinder is looking at improving some aspects of WinGlk’s behavior, but it turned out to be possible to get a substantial speed gain for Alabaster just by reducing the size of some of the larger images. The difference in image quality should not be visible on anything but a very, *very* large monitor.

Con todo, esta mañana volví a contrastarlo todo con el ordenador del curro, un Pentium 4 2,5 GHz de "antepenúltima" generación, por si acaso tanto Core y tanto nucleo me estaban distorsionando la perspectiva, pero los resultados eran igual de concluyentes. El lag en el prompt producido por el retardo del reescalado, en condiciones similares de potencia de proceso y de tamaño de gráficos, es el mismo en todos los productos que usan la máquina virtual Glulx bajo Windows, es decir, Inform, tanto 6 como 7, y SuperGlus. Supongo que o todos están igual de mal hechos o bien la causa es tan común como externa a todos ellos :) Me quedaré tranquilo asumiendo que no interpretas esto como un ataque o un desprecio a SuperGlus, sino simplemente como un dato que, como autor de la herramienta, te interesará conocer, aunque luego lo vayas o no a tener en cuenta.

Y ahí me callo, que ya os he distraido bastante de vuestros asuntos y a su vez yo estoy a 10 días de límite para hacer algo para una comp y se supone que debería estar dedicándome a ello en vez de venir a molestar aquí. :lol:

--


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 123 mensajes ]  Ir a página Anterior  1 ... 5, 6, 7, 8, 9

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 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