CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 24 Nov 2020 19:19

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  Siguiente
Autor Mensaje
NotaPublicado: 18 Mar 2010 18:23 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 11:58
Mensajes: 1817
Ubicación: Madrid
Mel Hython escribió:
Al-Khwarizmi escribió:
Yo probé Alabaster en un Core 2 Quad con 4 GB de RAM donde el Team Fortress 2 va de vicio, y tardaba más de un segundo en responder. Era injugable.


Y lo era... ahora mismo lo acabo de probar en un Duo a 2,33 GHz y menos de 2 GB de RAM, sobre el Git 1.2.4 y contesta de forma instantánea. Versión Release 3 / Serial number 090609 / Inform 7 build 5z71 (I6/v6.31 lib6/12N).

No sé que versión tiene Jarel, ni sobre qué lo está corriendo, pero si queréis quedaros con la cantinela de que Alabaster sigue siendo extremadamente lenta y que es una prueba palpable de que I7 genera siempre una porquería de código, pues bueno, a mí me da igual... lo que si veo es que Alabaster tiene unas cien mil palabras de código, el doble de mi Anillo 3, y que el Lacuna es muuuucho mayor. Aún estoy por ver una aventura en I6 en español, de tamaño equivalente. Sinceramente me parece que I7 favorece relatos mucho más grandes y complejos.


La del IFDB es esa misma de Junio del 2009. La he probado con Git-Gargoyle (1.2.1) (antes lo había hecho con Winglulxe).
El resultado es que la primera orden tiene un ligero lapso, aceptable, pero en las sucesivas estamos en las mismas. El parser se lo tiene que pensar pero bien.
Quizá con la 1.2.4 vaya como dices.

_________________
_/ /\ R e \_


Arriba
 Perfil  
 
NotaPublicado: 18 Mar 2010 18:26 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Mel Hython escribió:
si queréis quedaros con la cantinela de que Alabaster sigue siendo extremadamente lenta y que es una prueba palpable de que I7 genera siempre una porquería de código, pues bueno, a mí me da igual...


Que Inform 7 genera una porquería de código creo que es un hecho manifiesto, porque la manera en que hicieron que Alabaster fuese rápido (que ya me han dicho que así es en los últimos intérpretes, o en algunos) fue coger los "hot spots" del código I7 y meterlos ex profeso en rutinas del intérprete.

Ahora bien, desde luego no niego que ahora las aventuras vayan rápido. Y que el código que genere o deje de generar supongo que será irrelevante desde el punto de vista de que alguien decida implementar una aventura en I6 o en I7, a medida de que la gente se vaya actualizando a esos intérpretes chapuceados con las rutinas esas (aparte de que en aventuras españolas de tamaño medio supongo que no se verá ese problema ni en intérpretes más viejos).

Yo recomendaría elegir I6 ó I7 puramente según qué lenguaje prefiráis: el que prefiera un lenguaje de programación al estilo más o menos tradicional, I6. El que prefiera probar un sistema basado en reglas escritas en lenguaje natural (bueno, por desgracia en Spanglish, de momento), I7.

_________________
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: 18 Mar 2010 19:14 
Desconectado
Archivero
Archivero
Avatar de Usuario

Registrado: 08 Sep 2008 22:04
Mensajes: 295
Los varios niveles de capas de abstracción que el sistema de reglas de I7 produce "por encima" del código final de bajo nivel de I6 conllevan un retardo que los desarrolladores de Inform optimizaron con los llamados "accelcodes", una solución que ellos mismos reconocieron como poco elegante, pero efectiva, y que en cualquier caso era 100% transparente tanto para los autores de aventuras como para los jugadores. Vamos, que te puedes despreocupar tranquilamente por ella.

Este retardo tampoco era apenas perceptible. Otra cosa fue el caso particular de Alabaster, que no era, realmente, "particular de Alabaster", sino "particular de Windows". Para las primeras versiones de Alabaster usaron unos gráficos de tamaño original de varios miles de píxeles de ancho y alto que se redibujaban (y, por tanto, reescalaban) en cada turno. En los MacOS que usaban autores y testeadores eso no suponía un problema, por lo que nadie notó nada raro, pero Windows nunca fue tan eficaz para realizar reescalados de gráficos "al vuelo" a esos tamaños.

Coge un ordenador con un procesador ultra rápido de última geneación y cualquier Windows instalado. Coge un gráfico de tamaño gargantuesco y abrelo con el visor de imágenes estandar de Windows. Usa la ruedecilla del ratón para hacer zoom acercando o alejando la imagen. Podrás ver que cada paso "hacia dentro" o "hacia fuera" supone un reescalado que puede llevar hasta sus 2 o 3 segundos según los casos. Ese mismo era el retardo que padecía Alabaster y que desapareció cuando sacaron una versión con gráficos de un tamaño original más sensato.

En raif se comprobó que, a partir de ciertos tamaños desmesurados, el reescalado producía exactamente los mismos retardos en juegos de Glux, con gráficos, hechos con I6.

En resumen, que mientras no pretendas usar imágenes cuyas dimensiones se midan en varios miles de píxeles de ancho y/o alto no hay un peligro inminente de injugabilidad por retardo. Teniendo en cuenta que la ficción interactiva es un arte en el que las imágenes son opcionales, pues, es un riesgo menor :)

--


Arriba
 Perfil  
 
NotaPublicado: 18 Mar 2010 19:35 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
No es por echar más leña al fuego, pero bueno, voy a echar más leña al fuego... :D

En mi portátil, abro un JPG que ocupa 5 megas o así (creo que eso es bastante grande, no creo que Alabaster los tuviera más grandes), hago zoom hacia adentro y hacia afuera con el visor de imágenes de Windows®, y el retardo en cada paso es prácticamente imperceptible. Y te lo digo yo que soy un tiquismiquis para esto de los retardos (me irritan cosas como el retardo al cambiar de pestaña del Firefox...)

Y aún diré más, en AGE estuve probando el otro día permitir al usuario poner una imagen de fondo en la ventana de la aventura. Esta imagen se reescala automáticamente con la ventana si el jugador le cambia el tamaño a la misma con el ratón. En mi máquina, esto sucede sin retardo visible. Y se va rescalando frame a frame (es decir, suavemente).

Yo no sé si los retardos de Alabaster eran cosa de la multimedia o del código general; pero sí que sé que en cualquier caso hay algo mal hecho, o en la aventura o en I7. No es algo para nada normal que tarde lo que tardaba.

_________________
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: 18 Mar 2010 22:00 
Desconectado
Archivero
Archivero
Avatar de Usuario

Registrado: 08 Sep 2008 22:04
Mensajes: 295
No estamos hablando de "peso" de las imágenes (5 megas o 500) sino de "tamaño a reescalar", que es otro tema. Una imagen puede estar muy eficazmente comprimida y "pesar" sólo unos pocos cientos de KBs, como podría ser el caso si tuviera mucho espacio en blanco (mira, como en Alabaster) pero si el tamaño a reescalar es del orden de miles de pixeles es en el reescalado donde Windows se toma su tiempo. No es algo que me esté inventando, se hizo la prueba en raif en su día y se comprobó que el retardo desaparecía si el gráfico original se reducía. Si no se reducía el retardo era el mismo si metías ese mismo gráfico en un juego hecho en I6. Es más, hasta se llegó a contrastar que ese "lag" sólo se producía en los turnos en los que se actualizaba el gráfico, desapaeciendo en las acciones en las que deliberadamente se dejaba la ventana de la imagen sin cambiar... Chico, más comprobaciones no se pueden hacer...

El retardo en el visor de Windows al hacer zoms era plenamene apreciable en mi anterior ordenador, un Pentium 4 a 2 GHz cuando veía en él las imágenes de mi cámara de fotos, que por defecto sacaba a 3264 x 2448. Podía aumentar el ratio de compresión de las fotos todo lo que quisiera reduciendo así su "peso" (menos "megas") pero mientras siguieran teniendo sus 3264 x 2448, el esfuerzo de reescalado para el sistema, con su perceptible retardo, era el mismo. En mi ordenador nuevo apenas se nota, pero ya hablamos de Core Quad a 2,5 GHz. No sé si entiendes por dónde voy.

En cualquier caso tampoco estoy aquí para estropearte el día, si se trata de decir que Alabaster es indiscutiblemente injugable porque Inform 7 está mal hecho, como todo lo que hacen en la comunidad de habla inglesa, pues lo dejamos así, que a mi no me va la vida en defenderles :) , yo sólo era por aportar datos que se mostraron en su momento. Como dices, no era normal que tardase lo que tardaba, yo sólo estaba exponiendo lo que se investigó en su día sobre el por qué. Mis disculpas si con ello he causado alguna ofensa. No era mi intención.

--


Arriba
 Perfil  
 
NotaPublicado: 18 Mar 2010 22:11 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Por supuesto que no has causado ninguna ofensa; pero yo estaba hablando de lo que veo en mi máquina que no me parecía que concordara con lo que decías.

Si te refieres a imágenes de 3000x2000 y cosas así, ya no lo niego. Yo no tengo imágenes así en el disco duro, las que estaba usando para probar eran de 1600x1200 y similares.

Pero si realmente pusieron imágenes de tres mil y pico por dos mil y pico en una aventura, donde seguramene nunca se puedan mostrar ni a mil por mil porque van a mostrarse en un monitor y aún hay que hacer sitio para el texto... menudos brutos :D

_________________
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: 19 Mar 2010 01:03 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4653
Al-Khwarizmi escribió:
Si te refieres a imágenes de 3000x2000 y cosas así, ya no lo niego. Yo no tengo imágenes así en el disco duro, las que estaba usando para probar eran de 1600x1200 y similares.


Acabo de probar una imagen de 2800x1400 en Superglús, es instantáneo tanto en Git 1.2.1 como en Git 1.2.4, o en Glulxe 0.4.3. Totalmente inapreciable si es que hay alguna lentitud.

http://dl.dropbox.com/u/1832938/Escalados.zip

He tenido que buscar una imagen de 8000x4800 para que empiece a notarse (tarda como medio segundo en cambiarla de tamaño). Lo que si tarda y se nota es en cargarla la primera vez, pero luego en reescalarla no tarda nada.

http://dl.dropbox.com/u/1832938/Escalados_8000x4500.zip

Por otro lado cuando el rollo de la lentitud de Alabaster ya les puse a los del raif un ejemplo hecho en un momento de como Superglús podía pintar un gráfico de fondo, escalado, y además ir pintando sprites en pantalla moviéndose, también escalados, y todo eso a la vez que el usuario teclea y sin que la escritura se resienta.

En resumen, salvo que Emily hubiera metido gráficos de chorrocientos x mogollón, lo que ocurría no podía ser solo por un escalado de gráficos de nada.

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


Arriba
 Perfil  
 
NotaPublicado: 19 Mar 2010 01:34 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4653
Al-Khwarizmi escribió:
Mel Hython escribió:
si queréis quedaros con la cantinela de que Alabaster sigue siendo extremadamente lenta y que es una prueba palpable de que I7 genera siempre una porquería de código, pues bueno, a mí me da igual...


Que Inform 7 genera una porquería de código creo que es un hecho manifiesto, porque la manera en que hicieron que Alabaster fuese rápido (que ya me han dicho que así es en los últimos intérpretes, o en algunos) fue coger los "hot spots" del código I7 y meterlos ex profeso en rutinas del intérprete.


No, esto no es así. Alabaster ya usaba desde el principio esos @accelcodes, porque ya descubrieron la lentitud de I7 mucho antes de Alabaster. Es decir, antes era aun peor, y fue entonces cuando hicieron la ñapa de hacer macro-opcodes en la máquina Glulx.

Tratare de explicarlo aunque seguro que Eliuk lo haría mejor: el problema fundamental que permanece es que en I6 los objetos se guardan en una lista sobre la que se busca secuencialmente. Esto en I6 es un error de diseño, pero bueno, en I6 en general no hay tantísimos objetos, y no se nota. Lo malo es que en I7, que como sabéis genera codigo I6, cualquier cosa es un objeto, generándose al parecer un número de objetos que comparado con I6 es del orden de 1 a 100. Y entonces el error de diseño de I6 se manifiesta, afectando a I7.

Y con esto no quiero decir que todo lo que se hace el raif sea una mierda, quiero decir exactamente lo que pone en el parrafo de arriba de este, ni más ni menos. Aunque también quiero decir, como ya he dicho en otro mensaje, que ni el error de diseño ni las ñapas que tuvieron que ponerle debiera ser una razón para no usar Inform, ya sea el 6 o el 7.

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


Arriba
 Perfil  
 
NotaPublicado: 19 Mar 2010 10:42 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 09 Sep 2004 12:53
Mensajes: 1150
¿Y no les hubiera salido mejor sacar una nueva versión de Inform 6 que busque los objetos en un árbol?

Y sobre la pregunta original de Mistral, como le han dicho otros, creo que Inform 7 está más que suficientemente maduro como para que tu elección se base en criterios como en qué código crees que serás más productivo programando o te apetece más programar.

_________________
- Lenko -


Arriba
 Perfil  
 
NotaPublicado: 19 Mar 2010 11:15 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4653
DrVanHalenFan escribió:
Este retardo tampoco era apenas perceptible. Otra cosa fue el caso particular de Alabaster, que no era, realmente, "particular de Alabaster", sino "particular de Windows". Para las primeras versiones de Alabaster usaron unos gráficos de tamaño original de varios miles de píxeles de ancho y alto que se redibujaban (y, por tanto, reescalaban) en cada turno. En los MacOS que usaban autores y testeadores eso no suponía un problema, por lo que nadie notó nada raro, pero Windows nunca fue tan eficaz para realizar reescalados de gráficos "al vuelo" a esos tamaños.

No quiero empezar una batalla Windows vs Mac, pero esto que dices no tiene ningún sentido. Es cierto que Emily y sus testers usaban Mac, pero no es por ser Mac por lo que no se dieron cuenta, sino por ser Macs nuevos y potentes, y porque la Glk de Zoom, el interprete Mac, tenía (ya no, David Kinder la cambió) una rutina de escalado más optimizada que la de WinGlk o la de GargoyleGlk.

Citar:
Coge un ordenador con un procesador ultra rápido de última geneación y cualquier Windows instalado. Coge un gráfico de tamaño gargantuesco y abrelo con el visor de imágenes estandar de Windows. Usa la ruedecilla del ratón para hacer zoom acercando o alejando la imagen. Podrás ver que cada paso "hacia dentro" o "hacia fuera" supone un reescalado que puede llevar hasta sus 2 o 3 segundos según los casos.

Pero eso no es culpa de Windows ni del PC, eso es culpa del visor de imágenes de Windows que es una chapuza que no vale para nada. Acabo de coger la imagen de 8000x4500 que use ayer para probar escalados en Superglús, y el visor de Windows va fatal escalando, pero otros programas como IrfanViewer o Gimp escalan sobre la marcha sin enterarse.

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


Arriba
 Perfil  
 
NotaPublicado: 19 Mar 2010 11:17 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4653
Lenko escribió:
¿Y no les hubiera salido mejor sacar una nueva versión de Inform 6 que busque los objetos en un árbol?

Debe ser que no. En su momento lo comentaron pero mi conocimiento de Inform no me dio para entenderlo, y tampoco me importaba demasiado, la verdad.

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


Arriba
 Perfil  
 
NotaPublicado: 19 Mar 2010 11:25 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Si realmente los objetos se almacenan en una lista secuencial como decís... hacer que en un sistema que se supone orientado a objetos, los objetos se busquen secuencialmente, es una barbaridad de antología. Desde un punto de vista de diseño no le veo justificación posible. Ni a mí cuando empecé a hacer el AGE, estando en primero de carrera, no habiendo estudiado nada de algoritmos y complejidad, sabiendo poco del lenguaje, creyendo que una clase era un struct con funciones, y no teniendo la eficiencia como una prioridad en el diseño, se me ocurrió ni por un momento hacer semejante cosa.

_________________
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: 19 Mar 2010 18:25 
Desconectado
Archivero
Archivero
Avatar de Usuario

Registrado: 08 Sep 2008 22:04
Mensajes: 295
Uto escribió:
No quiero empezar una batalla Windows vs Mac


Ni yo. Soy usuario de Windows y no tengo previsto cambiar a Mac en el futuro. Pero si las rutinas de escalado en MacOS resultaron ser mejores que las de Windows tampoco pasa absolutamente nada por decirlo. Los Macs de los unos y los Windows de los otors eran máquinas de similares generaciones, pero en los Mac no se detectó el retardo y en Windows sí. Simplemente sucedió así y no tengo ningún problema en reseñarlo, a pesar de no tener ninguna simpatía (ni falta de ella) por los Macs en particular.

Uto escribió:
ya les puse a los del raif un ejemplo hecho en un momento de como Superglús podía pintar...


Y ya te dijeron en raif en su momento que ninguno de los gráficos que usabas tenía un tamaño que supusiera un esfuerzo de reescalado apreciable en tiempo de retardo. Lo que también hicieron en raif fue subir un fichero de prueba en I6 (recalco lo de 6) usando un gráfico de Alabaster con el tamaño usado originalmente en Alabaster (1036 x 3713) en una localidad. En otra pusieron el mismo gráfico a unos más sensatos 129 x 464. En una tercera habitación no pusieron ningún gráfico.

Se podía comprobar, o al menos así sucedía en mi Pentium 4 a 2 GHz de entonces, que el retardo en la habitación del gráfico grande en cualquier turno cuya acción requiriese actualiza la ventana de la imagen era idéntico (sobre 1 o 2 segundos) al de Alabaster en Inform 7. En la localidad del gráfico "pequeño" sencillamente no era apreciable y, por supuesto, menos aún en la que no tenía nada. Por pura coña tengo el fichero (ya no está online, o el link desde google-groups no va) y ahora en mi Core Quad la diferencia se sigue notando, aunque el retardo en sí no llega ni al medio segundo y no supone un handicap de jugabilidad, claro. Claro que también en mi ordenador nuevo el "injugable" Alabaster original va como la seda :D

Citar:
He tenido que buscar una imagen de 8000x4800 para que empiece a notarse (tarda como medio segundo en cambiarla de tamaño). Lo que si tarda y se nota es en cargarla la primera vez, pero luego en reescalarla no tarda nada.


¡Qué listo, Calisto! :P En Alabaster el lag era notorio en cada turno (y ya lo dije antes) porque las acciones del jugador podían tener un efecto inmediato (lag mediante :P ) en cada turno y por eso en cada turno la imagen se actualizaba. En tus ejemplos parace que no hay retardo más allá de la carga original... hasta que haces cualquier cosa que obligue a la imagen a redibujarse, simplemente una acción "mirar" sirve, y te encuentras con que el prompt se queda bloqueado con un lag similar al de Alabaster (un medio segundo apenas apreciable en tu primer ejemplo de 2800 x 1400 y varios ya muy apreciables segundos en el caso de 8000 x 4500). Como ves, tu SuperGlus no está exento de este mismo problema... porque no es un problema de SuperGlus, sino de ineficacia de reescalado en Windows en general. E insisto, no pasa absolutamente nada por decirlo :)

--


Arriba
 Perfil  
 
NotaPublicado: 20 Mar 2010 19:39 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4653
DrVanHalenFan escribió:
Uto escribió:
No quiero empezar una batalla Windows vs Mac


Ni yo. Soy usuario de Windows y no tengo previsto cambiar a Mac en el futuro. Pero si las rutinas de escalado en MacOS resultaron ser mejores que las de Windows tampoco pasa absolutamente nada por decirlo. Los Macs de los unos y los Windows de los otors eran máquinas de similares generaciones, pero en los Mac no se detectó el retardo y en Windows sí. Simplemente sucedió así y no tengo ningún problema en reseñarlo, a pesar de no tener ninguna simpatía (ni falta de ella) por los Macs en particular.

Efectivamente no pasa nada por decirlo pero hay que decirlo bien. Lo que no se puede decir es que un problema de velocidad de escalado en Windows y poner el visor de imágenes de Windows como ejemplo cuando en realidad era un problema de la rutina de escalado de WinGlk y GargoyleGlk ( la de Linux también). Decir que "Windos escala peor de manera genérica " no es solamente absurdo sino que es falso. 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)

Citar:
Uto escribió:
ya les puse a los del raif un ejemplo hecho en un momento de como Superglús podía pintar...


Y ya te dijeron en raif en su momento que ninguno de los gráficos que usabas tenía un tamaño que supusiera un esfuerzo de reescalado apreciable en tiempo de retardo.

en realidad no me dijeron nada, salvo que lo hicierna días después, cuando yo ya no leía el hilo.
En cualquier caso mis imágenes de fondo eran graaaandes y además pintaba sobre ellas con transparencias de png.

Yo no pongo en duda que las rutinas de escalado no fueran malas, pero no eran tan malas para aquello, y mis ejemplos iban simplemente encaminados a mostrar que con glulx podiase hacer algo mucho mas complejo que lo que hacia emily sin producir aquel desastre, porque necesitar un quad core para una AC solo puede calificarse de desastre.

Al final resulto que aunque las rutinas de escalado fueran pobres, la culpa la tenía en mucha mayor medida el pobre diseño de Emily, que había metido imágenes enormes, que encima pintaba a cada turno, incluso cuando no cambiaban.

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 :)



Te contesto aquí a lo de abajo que no consigo queel teléfono me haga mas scroll XD

no se como te tarda tanto, para mi el "pequeño" es simplemente instantáneo y el otro tarda medio segundo en reescalar. Obviamente eso de repetiría a cada paso pero no creí que tuviera que clonar alabaster para hacer un ejemplo, creí que con mostrar lo que tarda un escalado entenderíais que los demás, a cada turno , tardarían lo mismo. Yo mismo estuve probando mis ejemplos maximizando y "mediomizando" la ventana, que fuerza el reescaladi mejor que "mirar" porque ademad fuerza reescalados diferentes. Y obviamente ensuoerglus tiene que ir igual de mal, precisamente eso es lo que me sorprende, que no ocurra, y por eso pienso que hay mas mierda debajo de ese primer alabaster.


Ah, y te insisto una vez mas en que Windows no tiene ningún problema para escalar gráficos, ni para fregar platos. No puedes tener un problema para hacer algo que no haces. El problema esta en las librerías hechas para Windows, nada mas. Un Mac es un PC, si se puede con Mac se puede con Pc, otra cosa es que poder es una cosa y hacerlo es otra.
Lo que también hicieron en raif fue subir un fichero de prueba en I6 (recalco lo de 6) usando un gráfico de Alabaster con el tamaño usado originalmente en Alabaster (1036 x 3713) en una localidad. En otra pusieron el mismo gráfico a unos más sensatos 129 x 464. En una tercera habitación no pusieron ningún gráfico.

Se podía comprobar, o al menos así sucedía en mi Pentium 4 a 2 GHz de entonces, que el retardo en la habitación del gráfico grande en cualquier turno cuya acción requiriese actualiza la ventana de la imagen era idéntico (sobre 1 o 2 segundos) al de Alabaster en Inform 7. En la localidad del gráfico "pequeño" sencillamente no era apreciable y, por supuesto, menos aún en la que no tenía nada. Por pura coña tengo el fichero (ya no está online, o el link desde google-groups no va) y ahora en mi Core Quad la diferencia se sigue notando, aunque el retardo en sí no llega ni al medio segundo y no supone un handicap de jugabilidad, claro. Claro que también en mi ordenador nuevo el "injugable" Alabaster original va como la seda :D

Citar:
He tenido que buscar una imagen de 8000x4800 para que empiece a notarse (tarda como medio segundo en cambiarla de tamaño). Lo que si tarda y se nota es en cargarla la primera vez, pero luego en reescalarla no tarda nada.


¡Qué listo, Calisto! :P En Alabaster el lag era notorio en cada turno (y ya lo dije antes) porque las acciones del jugador podían tener un efecto inmediato (lag mediante :P ) en cada turno y por eso en cada turno la imagen se actualizaba. En tus ejemplos parace que no hay retardo más allá de la carga original... hasta que haces cualquier cosa que obligue a la imagen a redibujarse, simplemente una acción "mirar" sirve, y te encuentras con que el prompt se queda bloqueado con un lag similar al de Alabaster (un medio segundo apenas apreciable en tu primer ejemplo de 2800 x 1400 y varios ya muy apreciables segundos en el caso de 8000 x 4500). Como ves, tu SuperGlus no está exento de este mismo problema... porque no es un problema de SuperGlus, sino de ineficacia de reescalado en Windows en general. E insisto, no pasa absolutamente nada por decirlo :)

--[/quote]

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


Arriba
 Perfil  
 
NotaPublicado: 20 Mar 2010 23:01 
Desconectado
Archivero
Archivero
Avatar de Usuario

Registrado: 08 Sep 2008 22:04
Mensajes: 295
Uto escribió:
Te contesto aquí a lo de abajo que no consigo queel teléfono me haga mas scroll XD

Eso también te lo intenté explicar en otro hilo, pero de igual manera no me hiciste ningún caso: los teléfonos molan, pero no son la herramienta ideal pàra según qué cosas (postear en los foros, jugar a aventuras conversacionales...) :-)

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. 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!

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ó. Se usaron los mismos gráficos (junto con versiones de diferentes tamaños) en una prueba con I6 y se comprobó que el retardo era el mismo en las localiades (y con las acciones) que redibujaban los gráficos de gran tamaño (que no con los pequeños). 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 ;-). Si hubieramos de usar ese detalle para juzgar a SuperGlus por el mismo rasero resultaría que es una herramienta desastrosamente diseñada cuyos juegos son inutilizables porque se hizo con criterios que ni el bueno de Al-Khwarizmi hubiera usado en primero de carrera :-) . Pero la realidad es que el problema resulta manifestarse por igual en Inform 6 que en Inform 7 que en SuperGlus... por el simple motivo de que no es problema de Inform 6, ni de Inform 7, ni de SuperGlus, sino de que todos acaban tropezando en el mismo obstáculo: el reescalado en Windows produce un retardo perceptible a partir de tamaños del orden de los miles de píxeles. Que nadie, por favor, interprete esto como un intento de ofensa a Windows, a Inform, o a SuperGlus, (ni a Al-Kwarizmi ni a Uto :-) ) es simplemente un hecho.

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.

--


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  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