Va de frames por segundo

sés · 01 de Enero de 1970, 01:00:00 AM

SOBRE GetTickCount()
--------------------

Yo uso: timeGetTime(), que tiene más resolución. Échale un vistacillo.

plugin · 01 de Enero de 1970, 01:00:00 AM

Perfecto, el articulo que comentó Frodrig resuelve todas mis dudas (o al menos funciona bastante bien, jeje). La idea es bastante buena y soluciona los problemas que yo comentaba, asegurando un framerate medio constante. Así que animo a todos los que os interese este tema y no lo hayais leido, que lo hagais (idea simple pero funciona bien).

Pues nada, perfecto. Todo solucionado. Muchiiiisimas gracias por las respuestas (todavía estoy intrigado por la solución que comentaba Emotion iba a poner). Saludos
-plugin

Emotion · 01 de Enero de 1970, 01:00:00 AM

Paciencia es la madre de la ciencia... aun estoy terminando de escribir el .txt que voy a postear... yo lo que prometo lo cumplo...

plugin · 01 de Enero de 1970, 01:00:00 AM

jejeje. Pues nada.... Paciencia tendré. Aunque lo que he implementado ya furula a la perfección (o al menos visualmente no aprecio ningún fallo). Pero el saber no está de más, así que nada, lo que tu dices, tendré paciencia....

Saludos
--plugin

Emotion · 01 de Enero de 1970, 01:00:00 AM

Bueno, pues tal y como prometi aqui esta mi metodo, aunque no quiero que nadie se haga ilusiones, ya que posiblemente mi metodo se sale un poco del tiesto, es decir, mi metodo enfoca una amplia variedad de animaciones o efectos y posiblemente solo querais usarlo para mover unos cuantos objetos con traslaciones normales, etc...

Veamos... yo no estoy a favor de usar, como lei un poco mas arriba, la escala de tiempo en el movimiento de un vertice o modelo completo, ya que para poder tener garantias de que ese metodo funcione, ha de funcionar igual en todas las maquinas, y eso es MUCHO pedir (o suponer, segun sea el caso...). Eso esta bien para los programas de render tipo 3D Studio MAX, Maya, Softimage, Power Animator, etc. donde el objetivo final no es producir secuencias en tiempo real, sino secuencias CG, y como todo el trabajo lo hacen por software (al menos en la parte de control de tiempos), pues pueden tranquilamente confiar en la escala de movimiento por tiempo. Como creo que quieres usarlo para juegos, es mejor que no te decantes por el, ya que puede que no notes tirones o efectos extraños, pero ten en cuenta lo siguiente: pongamos que el metodo que utilizas de escala de tiempo, debido a la precision numerica de la/s variable/s que escojas tiene en total un margen de error de, pongamos por caso, un 15% (es mucho, ya lo se, pero tan solo es un ejemplo...). Eso significa que de cada 100 frames que renderices, en 15 de ellos el movimiento es 'extraño', ya que tus personajes o se mueven mas lentos o mas rapidos de lo normal (para un ojo no excesivamente observador puede pasar por alto, pero para ti o cualquier programador grafico o simplemente un entusiasta de los graficos 3D y la animacion en general, puedes estar seguro que NO va a ser asi...). Este efecto no puede ser evitado actualmente ya que no existe un standard en lo que a render por hardware se refiere (esta claro que estamos en mitad de una guerra por la rotura de las barreras del realismo grafico, pero cada compañia intenta asentar sus propias bases, con lo cual siempre estaremos (o al menos mientras dure todo esto) en mitad del meollo sin poder comprometernos con nadie... y ejemplos hay, como INTEL y AMD, NVIDIA y ATI, y asi sucesivamente...)

Bueno, pero al caso que estamos tratando, y siempre desde mi punto de vista, hay 2 maneras de controlar el flujo de animacion en un juego (o software grafico):

A. escala de tiempo (el metodo del que acabo de hablar)
B. control de tiempo consumido (el metodo del que hablare a continuacion)

Mirad, yo personalmente preferiria el primer metodo, ya que es mas facil y da muy buenos resultados, pero actualmente prefiero usar el segundo ya que me ofrece una alternativa de control mas o menos fiable y con un margen de error bastante mas pequeño que el primer metodo, aunque es mucho mas dificil de implementar, ya que implica diseñar el motor grafico casi desde cero (hay que meterle mano a casi todo el codigo).

El metodo, desde una perspectiva tecnica, es bastante sencillo, pues se basa simplemente en ir tomando una medida del tiempo que consume una u otra funcion del motor en ejecucion, es decir, mi metodo se basa en una tecnica de profiling (igual que el metodo usado por herramientas de debugging y profiling, caso del VTUNE, el SoftICE, etc...)

Este metodo contempla 2 fases en su ejecucion

A. analisis de tiempos (profiling)
B. ajuste de tiempo de ejecucion por ciclo de animacion/ejecucion (es variable, depende de lo que queramos hacer...)

la fase A implica el uso la instruccion RDTSC (ahora hablare de el) o el uso de funciones como QueryPerformanceCounter, timeGetTime o incluso getTickCount (si bien esta ultima es la menos precisa de las tres anteriores, pero tambien sirve para nuestros propositos, si bien no hablare de ella aqui, ni siquiera de las otras, mi metodo se basa en el uso de la instruccion RDTSC, la mas fiable de todas), para saber el numero de ciclos de reloj que consume la ejecucion de una cierta funcion.

Esto es importante, ya que nos interesa saber cuantos ciclos de reloj puede generar un determinado procesador para saber cuantos ciclos de reloj se pueden usar para calcular toda la informacion en 1 fotograma de animacion (y no solo considerando la parte grafica, tambien el sonido, la respuesta del joystick/teclado/raton/pad/etc.. y el juego en red) y a partir de ahi, saber si sobran ciclos de reloj, ya que de no ser asi, pues simplemente pasara lo de siempre (en algunos juegos con ciertas maquinas), es decir, dara tirones, pero si no es asi, podremos saber de forma efectiva cuantos ciclos extras podemos emplear en reprocesar ciertos calculos o añadir mas efectos visuales o auditivos para optimizar y mejorar mucho mas nuestro juego o aplicacion multimedia en general.

el procedimiento usual para medir el tiempo de una funcion seria el siguiente:

1. ejecutamos la instruccion RDTSC
2. almacenamos el valor del TSC en una variable
3. ejecutamos la funcion que queramos (p.ej: renderer->render())
4. volvemos a ejecutar la instruccion RDTSC
5. almacenamos el valor del TSC en otra variable
6. computamos el tiempo invertido, teniendo en cuenta que el computo es el siguiente: (TSC2-TSC1)-1xRDTSC-ElapsedTime(F(t))

*el tiempo invertido en ejecutar la instruccion RDTSC 1 vez (al final) mas 2 veces el tiempo para almacenar el TSC en las variables de contencion y ademas hay que quitar el tiempo empleado en el calculo del tiempo (TSC2-TSC1), en este caso una simple resta, a no ser que queramos añadir algun criterio de comparacion para un mayor control sobre ciertas funciones que hagan uso de ciertos recursos de la CPU o el sistema en general

Bien, ahora la primera pregunta... porque no usar simplemente TSC2-TSC1 para calcular el tiempo invertido en ejecutar la funcion? pues, sencillamente, por que NO es el verdadero tiempo de ejecucion, ya que el tiempo invertido en hacer los calculos de tiempo tambien cuentan, por eso hay que 'limpiarlos' del computo final. De esa manera nos queda el tiempo 'justo' empleado por la funcion que queramos medir... y digo justo porque al final hay que hacer un matiz sobre esto (lo definire como MATIZ1)

Bien, una vez explicado el primer punto de mi exposicion (era el mas dificil y como veis, tampoco ha sido tanto) vamos con el segundo y ultimo punto, que es el ajuste de tiempo

la fase B implica el diseño y posterior uso (si se desea, ya que este paso es puramente opcional, pero añade el 'punto' que le falta a la fase A para ser, literalmente, un metodo completo) de una funcion de delay(), que algunos tacharan como anticuada o algo asi (se suelen usar metodos mas sofisticados), pero que viene de perlas cuando no quieres procesar mas datos en lo que resta de fotograma, y de manera normal, pues hay que 'chuparse el dedo' y dejar que el mismo motor induzca a que la animacion sea demasiado rapida (o lenta... como ya dije, al no haber un standard pueden suceder muchas cosas, aunque esto qeu digo ya lo habreis comprobado por vosotros mismos...)

Y como hacerlo? pues hay varios metodos, pero el mas facil aunque no el mas (aparentemente) directo es recurrir a la deteccion de la velocidad del micro (paso 1) y luego acuñar la informacion obtenida en un registro para su posterior uso (paso 2).

luego definimos 2 pasos basicos para hacer que este metodo funciones:

A. medida de tiempo de proceso del microprocesador (o, simplemente, medida de frecuencia)
B. creacion funcion delay()

la fase A implica, en este caso (aunque anteriormente dije que no iba usarla) el uso de la funcion QueryPerformanceFrequency(), la cual nos da de forma aproximada la velocidad del microprocesador en MHz, si bien este valor nos lo da en forma real y nosotros debemos pasarla a forma entera

Una vez hallada la velocidad de trabajo del microprocesador, simplemente hay que hacer un calculo, que es simplemente:

Nc=V·1000000

es decir, Nc (numero de ciclos) queda representado por la velocidad por 1 millon (esto es facil de entender), de forma que al final nos queda el numero de ciclos que podemos usar en 1 segundo, pero para refinar mas aun el calculo hemos de dividir eso entre el numero de frames por segundo que deseamos mantener en la aplicacion, es decir, el computo final quedaria asi:

Nc/F=1000000·V/Nf

donde usamos las siguientes variables:

Nc/F = numero de ciclos/frame. ESTE es el valor que nos interesa
V = velocidad de proceso (en MHz) del microprocesador
Nf = numero de frames, es decir, cuantos frames queremos en un segundo (tipicamente 25/30/50/60, pero evidentemente puede ser mas, mucho mas... :riendo:)

Pues bien, para que sirve todo esto que he dicho? para una cosa muy simple... cada vez que ejecutais una funcion en vuestro motor de juegos, ejecutais el profiling y vais restando el valor obtenido a la variable Nc/F. De esta forma siempre sabreis el numero de ciclos que os sobran (u os faltan) por cada fotograma. Si os sobran, usad un delay() (que explicare a continuacion) o usadlos para computar mas efectos u optimizar procesos dentro de vuestro motor.

la fase B implica el diseño de una funcion para poner al microprocesador en IDLE durante el periodo de tiempo que le especifiquemos. Normalmente suele haber por defecto en C/C++ una funcion delay() cuya precision viene dada en milisegundos, una medida que, en mi opinion, es bastante corta para ciertos propositos. metodos como el QueryPerformance<...> son muy buenos, ya que tienen una precision de 1 microsegundo.

una funcion ideal seria la siguiente:

void delay(unsigned long ns)
{
for (long i=0;i {
__asm nop
}
}

pero esta funcion no tendria ni de lejos una precision de nanosegundos (que seria lo ideal). Cual es el problema? pues muy sencillo... como hay microprocesadores con diferentes velocidades, en cada microprocesador una sola instruccion no empleara el mismo tiempo en ejecutarse, con lo que el mismo microprocesador nos obliga a optimizar el codigo para que el ajuste de tiempo sea lo mas preciso posible. Por esa razon dije que mi metodo tiene un margen de error muchisimo menor, sin embargo no esta exento de el. Nada es perfecto...

La funcion que yo utilizo por ahora es la siguiente:

void delay(unsigned long dc)
{
__asm cli;

__asm mov ecx,dc;
__asm nop;
__asm rep movsb;

__asm sti;
}

Hay funciones mucho mejores para hacer delay de alta resolucion (estoy seguro de ello...), aunque no puedo ayudaros mucho al respecto, ya que cada uno implementa su propio metodo para hacerlo (no existe solo un camino...)

Y es todo lo que por ahora se me ocurre. Tengo la sensacion que me dejo algo en el tintero. Si notais que falta algo, dadme un toque e intentare completarlo (o corregirlo)

MATIZ 1

la funcion para calcular el tiempo de ejecucion de una funcion es bastante preciso, PERO (y siempre hay un pero), tiene un efecto secundario... y es que esta sujeto a posibles ciclos extra empleados por el micro para alinear datos en la cache, sincronizar transferencias de memoria, ciclos de autocomprobacion, etc. es decir, que este computo es un tanto ideal, luego en la practica pierde un poco de precision por el hecho de que el sistema a veces te juega malas pasadas por eso...

Saludos

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-04-22 11:39 ]

Ithaqua · 01 de Enero de 1970, 01:00:00 AM

Sinceramente, me parece un método completamente enrevesado :sonriendo:
Es decir, hacer un profiling manual en TODAS las funciones me parece muy muy muy bestia para lo poco que pretendes obtener (y mal a mi modo de ver).

Primero de todo, porque no tienes en cuenta en absoluto a la tarjeta gráfica (la cpu puede estar "necesitada" de datos aún corriendo el juego a 2fps, por problema de fillrate por ejemplo). ¿Es significa que la CPU esta procesando una burrada de datos con respecto a lo que debería? no.

Básicamente tu sistema solo sería "útil" cuando procesamos -CPU- menos datos de los que deberíamos. Pero eso no significa ni mucho menos que vayamos sobrados (por lo que comenté antes, la aceleradora también existe). Y si encima fuerzas un delay() despues de eso, ya la cagamos :sonriendo:
Y en caso de que una tarjeta pueda pasar por ejemplo la barrera de los 50fps ¿para que detenerla? para eso están.

Sobre la pérdida de precisión, es una exageración el ejemplo que comentas. No por el 15%, que como dijiste era ilustrativo, sino porque el error es ínfimo (inapreciable). Si hubiese algún problema, sería en el caso de que el márgen de error fuese muy grande, y el método utilizado propenso a aumentar dicho error. Por ejemplo, usando un incremental de tiempo:
tiempo += tiempoframe;
en el que sucesivamente se va añadiendo tiempo a una variable, en vez de tomar el valor absoluto de nuestro timer.

Si tantas esperanzas tienes en este método, me gustaría ver algún test tuyo en el que realmente se vea la diferencia de calidad entre un sistema y otro. Pero realmente creo que no lo has probado o al menos no a fondo :sonriendo:

Un saludo.

Emotion · 01 de Enero de 1970, 01:00:00 AM

Hola Ithaqua,

Bueno, pues en parte tienes razon, en parte, desde mi punto de vista, no (y no por tu planteamiento, que es ABSOLUTAMENTE correcto, sino por mi manera de ver mi motor de desarrollo).

Veras, mi metodo no debe seguirse a la ligera, ya que hay que saber utilizarlo, ya que si no se produce lo que tu dices, un desperdicio casi total de la CPU, pero como metodo de profiling es muy bueno y te permite ver mas o menos por donde estas tirando ciclos de reloj que luego te pueden venir bien. En mi motor de desarrollo esta esa opcion, pero incluso habiendola, la opcion es... remota (utilizo un sistema de depuracion a 2 maquinas, ya hablare de ello en alguna ocasion). lo que SI utilizo ahora mismo, es ese metodo, pero hago la primera medicion al principio del fotograma y la ultima medicion al final. Asi pierdo algo de precision en la medida por lo que dije del alineamiento (y como dejo pasar muchas funciones, el margen de error se vuelve mas grande), pero me permite saber cuantos ciclos me sobran... No obstante, es como he dicho, solo es una medida. Yo en cuanto hago un .exe, en el bucle lo quito de en medio, a no ser que quiera depurarlo luego...

Sin embargo, o al menos minimamente estaras deacuerdo conmigo en que escalar el movimiento de vertices atendiendo a un criterio tan simple como el de 'scale=1/timebase' y aplicarlo a todo es una locura, ya que la diferencia de velocidad entre maquinas echa a perder el metodo en una bateria de pruebas. Esta bien para experimentar, pero creo que como una manera de programar juegos con salida economica pues... como que lo veo un poco... digamoslo asi... impreciso :sonriendo:

En cuanto a lo de probarlo, pues tienes razon... no lo he probado del todo, aun estoy analizando un modelo mas de analisis de tiempos... en fin... arduo y a veces creo que inapreciable trabajo... pero si quiero hacer un motor de desarrollo de alto rendimiento, hay que pringar... :triste:

En cuanto a lo de detener la animacion mas alla de los 50/60 frames, es por simplicidad... veamos... para que quieres mas de, pongamos por ejemplo, 100 frames por segundo (o 50) si, a nivel del cerebro, no puedes percibir mas de 18 frames? el cerebro procesa señales a 18Hz, nada mas... es cierto que el movimiento se aprecia mas suave, pero aun asi no me propongo llevar mi motor hacia la barrera de los 120 frames o mas... ni mucho menos... tengo mis razones, y ya se que parecen un poco... estupidas (para que vamos a negarlo), pero cuando pueda lanzar el motor entero con sus herramientas y todo, entonces entenderas porque lo hago... :sonriendo:

Un Saludo

plugin · 01 de Enero de 1970, 01:00:00 AM

Joder!! Perdonar mi expresión y, quizás mi ignorancia, pero me ha parecido una pasada tu respuesta... Creia que ibas a proponer una mejora al tipico bucle de juego y lo que predicas es un gran trabajo extra que para mi caso creo no me vale mucho (creo). Estoy haciendo un engine para aventuras gráficas (de ahi la otra pregunta). Las animaciones de los personajes no son muy complejas (no es una aventura en plan serio) y tienen de media unos 10 frames reproduciendose a 12 FPS. Tal y como esta ahora implementado es siguiendo mas o menos lo expuesto por JAvier Arevalo en el articulo que se hacia mencion unos post mas arriba. Pues con dicha implementación y esa calidad de animaciones me parece bastante bueno el método. Ahora bien, si lo que tu comentas es para un motor en 3d, la cosa seguramente cambiaría...... Cuando termine este engine pasaré a experimentar con las 3d y quizás las cosas cambien.

Pues nada, aún así agradezco las respuestas, nunca se sabe cuando puedes utilizar los conocimientos que aprendes en este mundillo. Saludos
--plugin

Emotion · 01 de Enero de 1970, 01:00:00 AM

Para plugin:

El metodo que explique no es solo para 3D sino para 2D tambien, lo que pasa es que es mucho codigo, en eso SI que te doy la razon, sin embargo, hoy en dia, que un codigo pese mucho no significa que sea muy lento... tal vez para producir no mas de 12 frames no te venga bien darte la paliza de programar, pero si quieres conseguir mas, en el orden de entre, digamos... 30 y 120... pues te viene bien intentarlo, ya que te permitira suavizar mucho las animaciones, al precio, eso si, de perder algunos ciclos de reloj en comprobaciones.

De cualquier manera, si el metodo que utilizas te va bien, no te merece la pena complicarte con el mio, ya que mi motor tiene soporte para multiprocesador a traves de multithreading, planos multiples de render, listas de objetos, cache dinamica/estatica.. y ahi SI que viene bien implementar el metodo...

Por cierto, ya que mencionas el texto de Arevalo, he aqui una razon por la cual decidi escribir la gran parrafada de antes:

(extraido de la ultima parte del post)
"in the range 20-60 frames per second (fingers crossed)", que traducido literalmente del inglispitinglis es "en el rango de 20-60 FPS (crucemos los dedos)"

Crucemos los dedos?? si su metodo es asi, tal y como dije, te funcionara bien a ti, pero si lo pruebas en otra maquina, ya veras.... o mas rapido o mas lento, pero no lo podras controlar... :riendo:

Saludos
_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-04-22 20:39 ]

KAKSTAR · 01 de Enero de 1970, 01:00:00 AM

Para Ithaqua:

--Y en caso de que una tarjeta pueda pasar --por ejemplo la barrera de los 50fps ¿para --que detenerla? para eso están.

Respecto a la frase que comentas, creo que sí, las targetas estan para eso, pero como comenta Emotion el cerebro no és capaz de percibir más de 25 cuadros por segundo, más o menos (aunque a más cuadros más suavidad).

El inconveniente que le veo és que si podemos ejecutar el quake 3 a 200 FPS hay muchos cuadros que no llegarán a verse, por tanto hemos echo calculos innecesarios cuyo tiempo se podria haber dedicado a otras cosas como iluminación...

hasta luego.

Ithaqua · 01 de Enero de 1970, 01:00:00 AM

Sobre la frase de los 18fps/25fps o cuanto queráis. Esa frase la he leido mil veces y la gente la interpreta mal. NO significa que no notemos diferencia entre 25 y p.ej. 60 frames por segundo (que lo notaremos, cualquiera puede comprobarlo). Significa que el cerebro humano no puede distinguir cuando se 'cambia' de imágen, que no tiene nada que ver en este caso.
Si hablamos de suavidad, hablemos de que el cerebro humano es capaz de ver más suave y fluida una imágen de 60 frames por segundo, que una de 30.

Sobre lo que dices Emotion, de usar un valor de tiempo para parametrizar movimientos. Esta clarísimo que este método no va a funcionar al mismo framerate en todas las máquinas. ¿Es eso malo? en absoluto! es JUSTO lo que buscamos.
Si tu tienes un buen sistema de animación, en el que puedes interpolar movimientos -y NO te basas en que tu animación tienes 30 frames, ni uno mas, ni uno menos- Puedes hacer que esa animación corra a 50 frames por segundo en una máquina que dé de sí, y 10 frames por segundo en una máquina que no.
¿Cual es la diferencia? Que en una va mas suave y en otra mas escalonada. ¿Hay diferencia de rapidez? NO, ¿Hay diferencia de suavidad? SI. ¿Se desperdicia tiempo? No.

Tu ejemplo de movimiento += k*inctiempo indica precisamente eso.
Dados un t inicial y un t final, ambas máquinas van a dibujar el movimiento con la misma rapidez (pongamos, una animación que dura 10 segundos). ¿Que diferencia hay entre una máquina potente y una lenta? Que la máquina lenta a lo mejor puede dibujar 20 frames en esos 10 segundos, y la máquina potente puede dibujar 2000. La animación de la máquina potente se verá mas suave, pero ambas ejecutarán el movimiento en esos 10 segundos con la misma rapidez.
Eso sí, no puedes pretender utilizar este método y luego usar animaciones o movimientos que no permitan interpolación. O al menos que no se puedan evaluar para un tiempo dado, porque no te va a servir de nada. Pero eso no será problema del timing, será problema de que tu sistema de animación es malo :sonriendo:

Saludos.

mallrat · 01 de Enero de 1970, 01:00:00 AM

Buenas! menudo lio que se está organizando...

Emotion, lo que tu haces es simplemente algo para monitorizar el rendimiento de un bloque de código, por cierto échale un ojo a este link:

http://cedar.intel.com/software/idap/media...df/rdtscpm1.pdf

explica tu sistema con mas detalle, aunque se puede resumir en mirar el TSC al principio y al final del bloque y restarlos, y convertir el valor en ciclos en algo mas util como milisegundos. De todas son un poco pijos si de lo que se trata es de medir el tiempo que tarda en ejecutarse algo que tardará mucho mas que leer y restar el TSC.

Por otra parte si lo usas para medir lo que tarda en ejecutarse un frame, para eso te valia con el timeGetTime (salvo que vayas a mas de 1000 FPS :lengua: por cierto eso es en win98, en el win2k la precision no tiene porque ser de 1 ms, hay que usar timebeginperiod y timeendperiod por si acaso) de todas formas tu sistema de limitar a 50 FPS y desperdiciar el resto es muy válido, aunque yo no lo usaría ni loco, prefiero que vaya lo mas suave posible, y aquí habria que aclarar otra cosa.
Se está hablando de que no se reconoce mas de 25 FPS (bueno emotion, en tu caso 18, lo siento pero deberías hacertelo mirar... de verdad no distingues mas de 18 fps? :lengua: tonterias aparte, lo de los 20~25 FPS es para tener la sensación de movimiento continuo en vez de imágenes sueltas... pero claro que se nota la diferencia entre 30 y 60 FPS por ejemplo, y se nota bastante.

Estoy completamente de acuerdo con Ithaqua, a ver... el hecho de que vaya a FPS variable no significa que una animacion de 10 segundos termine antes en un ordenador rapido, significa que hay mas interpolaciones entre los frames de la animación para que se vea mas suave. Por otra parte actualmente no sirve de mucho medir lo que dura el render porque la aceleradora hará las cosas cuando pueda, por decirlo de alguna manera.

Una cosa importante Emotion, el delay ese que usa el rep movsb, adonde apuntan ds:esi y es:edi? miratelo bien porque podrías estar machacando la memoria aleatoriamente...

Bueno, en cualquier caso, Emotion... "motor de alto rendimiento?" :loco: espero que de verdad sepas lo que estas haciendo, ya escribirás un "postmortem" explicando lo que fue bien... y lo que fue mal... :ojo: suerte!

saludos

Emotion · 01 de Enero de 1970, 01:00:00 AM

Para mallrat:

Gracias por el .pdf de INTEL :sonriendo: la verdad es que el metodo que yo uso es exactamente igual, aunque ellos ponen un monton de instrucciones...

De cualquier manera, y como dije justo en el anterior reply, solo uso el profiling para ver cuanto tarda la funcion en ejecutarse, aunque como dije eso depende de que no haya en ese momento datos para alinear en la cache, ciclos de saturacion en la via de multiejecucion (vias U y V) y alguna que otra cosa mas...

No obstante, eso de la interpolacion de fotogramas, pues hombre... a mi no me parece bien, ya que si lo dejo suelto no dara el mismo tipo de velocidad en todas las maquinas y yo quiero hacer como en las consolas... porque matarse a programar para mostrar 100 frames si con 60 o digamos 75 vas que te matas?

En fin... ah, por cierto, gracias por el toque en la funcion de delay, la verdad es que normalmente no me da problemas, excepto en un par de funciones, seguramente sera por eso, por haber pasado por alto los indices a memoria, lo que pasa es que esa instruccion nunca la he usado con otro prefijo que el movxx, se podria usar 'rep nop'? es decir, dejar el codigo asi?

mov ecx,ns
rep nop

en lugar de

mov ecx,ns
nop
rep movsb

??

Para Ithaqua:

Ahh, por cierto... de todas formas he de decir algo, y es que aparentemente no pensais en un tema importante: el sonido. Si, puede que querais dejar correr la aceleradora a sus anchas, pero cuando tengas que sincronizar imagen y sonido ya me diras como... y no me refiero a la musica de fondo, sino un dialogo hablado donde se vean expresiones labiales... como lo haces si dejas que el motor corra sin freno? :sonriendo:

Saludos a ambos :riendo:
_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-04-23 09:49 ]

[ Este Mensaje fue editado por: Emotion el 2002-04-23 09:51 ]

Ithaqua · 01 de Enero de 1970, 01:00:00 AM

Comentario a algunas frases de Emotion:

"No obstante, eso de la interpolacion de fotogramas, pues hombre... a mi no me parece bien, ya que si lo dejo suelto no dara el mismo tipo de velocidad en todas las maquinas"

En todas las máquinas irá igual de rápido, insisto que lo que cambia es la suavidad. Lee el ejemplo otra vez y lo entenderás. Es de cajón.

"y yo quiero hacer como en las consolas... porque matarse a programar para mostrar 100 frames si con 60 o digamos 75 vas que te matas"

Eso es imposible conseguirlo, una consola es una máquina standard. Todo lo que vaya a 60fps en una irá a 60fps en otra. Bienvenido al mundo del PC donde tienes mil configuraciones, y por tanto rendimientos, distintas.

"Si, puede que querais dejar correr la aceleradora a sus anchas, pero cuando tengas que sincronizar imagen y sonido ya me diras como... y no me refiero a la musica de fondo, sino un dialogo hablado donde se vean expresiones labiales... como lo haces si dejas que el motor corra sin freno?"

Otra vez: interpolación.
No es lo mismo mostrar una animación que consista en, por ejemplo, 100 frames, que mostrar una animación que consista en 10 segundos.
En el primer caso la máquina mas rápida ejecutará esos 100 frames en menor tiempo. En el segundo caso, la potencia de la máquina hará que en esos 10 segundos se vean más o menos pasos intermedios.
Sigo sin entender como no comprendes esto. ¿Tu guardas acaso las keys con un valor de frame, y no de tiempo? ¿Como interpolas con el primer método?

Objeto.Transforma(Timer.Segundos());

Es tan simple como eso.

Saludos.

Drácula · 01 de Enero de 1970, 01:00:00 AM

¡Cuanto energía estais echando en este post!

Creo que ambos teneis razón, pero no tiene que ver lo que dice uno con lo que dice otro. La idea de Emotion me parece muy buena:aprovechar la potencia de tu máquina que sobra en pos de una mayor calidad, en lugar de una mayor suavidad.
E Ithaqua dices que viva la suavidad(en resumidas cuentas)

Pues eso, que teneis ambos razón. Ahora ya depende de cada uno.

Foros

Va de frames por segundo