Va de frames por segundo

[Emotion]

                                Para Dracula:

Gracias tio!! :riendo:

Para Ithaqua:

Pues la verdad es que por ahora, SI. utilizo frames para las llaves, ya que por ahora me es mas comodo trabajar con ellos (puedo sincronizar la reproduccion de un video al mismo tiempo que puedo controlar la vida de un sistema de particulas (simple o complejo) y algunas otras cosas. En cierto modo, se podria decir que el keyframer es el nucleo de mi motor de desarrollo, pero vamos... en general y respondiendo a tu pregunta... SI (que barbaro soy, eh? :riendo:)

Un Saludo
                               

[KILE]

                                Bueno como llego un poco tarde a este post y ya esta casi todo dicho solo puedo hablar de lo ultimo que se ha puesto (Sobre Ithaqua y Emotion). Estoy totalmente deacuerdo en lo que ha dicho Ithaqua y es verdad que con interpolación se suplen todas esas dificultades que no parecen convenver a Emotion, y como bien dijo lo único que varia es la suavidad con la que se realice. Y sobre lo de el sincronismo de musica, voces, efectos y tal, pues sinceramente tampoco se me ocurre una manera optima de hacerlo sin hacer uso de la interpolación. Solamente miremos a las miles de demos que podemos descargar por ejemplo en http://www.pouet.net y veremos como en la mayoría (vamos las que tengan nivel aceptable) tienen una perfecta sincronización de música, efectos sonoros y gráficos, particulas, etc... y os aseguro que el 99% usa interpolación :lengua:
Un saludo                                

[Ithaqua]

                                Drácula : Ya no es problema de la idea, sino del método. No se puede medir el % de rendimiento por frame que 'sobra' de esa manera que él propone.

Emotion: Y si tienes 30 frames, y una máquina te permite dibujar solamente 3 y otra 60, que haces? No hablo de vídeo, hablo de gráficos en tiempo real.
Y eso de sincronizar bien sistemas de partículas etc. ¿Que mejor forma de parametrizarlo que usando el tiempo? El movimiento en física 'real' se parametriza por tiempo (S(t) = funcion_de_t). Es decír, que dado un tiempo t (obtenido del timer por ejemplo) y aplicando las fórmulas, se nos da un valor de posición.

                               

[mallrat]

                                Buenas, este tema si que está generando polémica...

Emotion, creo que estas mezclando los fallos de caché con la alineación de datos, los fallos de caché es algo imprevisible (en general) dado un segmento de código, la alineación puede serlo o puede no serlo, según hagas los accesos a memoria, y el emparejamiento de instrucciones es perfectamente previsible. De todas formas creo que deberías preocuparte de optimizar el motor a nivel algorítmico antes que a bajo nivel.
El tema del delay, lo mejor es que no pongas nada en ensamblador si no estas completamente seguro de lo que haces, hay muchas cosas a tener en cuenta (las definiré como MATIZ-Que-Jode :lengua:). No puedes usar REP NOP, el prefijo REP es solo para ciertas instrucciones (movs, stos ins y outs creo). En resumen, mejor no uses REP MOVSB ni nada parecido, si acaso tendrias que hacer un bucle a mano pero... para que hacerlo en ensamblador? todavía no se lo que pretendías haciendolo así, en cualquier caso no estabas poniendo ESI ni EDI para que apuntaran a algo, ni estableces la dirección de la transferencia (puede ser incrementando o decrementando ESI y EDI -> CLD/STD), y lo del CLI y el STI... no creo que el windows de a las aplicaciones privilegio de E/S para usar esas instrucciones.

Respecto a las consolas, tampoco vas a poderlo hacer a una velocidad fija, tienes que tener en cuenta la selección de 50/60 Hz :triste:  de todas formas en los PC el problema es mayor en ese sentido... puede ir a 20 o a 200 fps, personalmente no me preocupa cuando se va a los 200, me preocupa mas cuando se va a 20, eso es lo jodio. Si lo haces fijo a 75 y te va a 20... que vas a hacer? de nuevo la solución de la interpolación parece la mejor ya que se adapta a los FPS que de la máquina. Ademas si lo haces fijo a 75 y lo ejecutas en un monitor de 85 Hz queda realmente mal, como si los frames no estuvieran espaciados uniformemente (sobre todo si el vsync está activado).

Lo de la sincronización con el sonido, no le veo la pega, insisto en que la animación se verá mas suave, pero durará lo mismo en el tiempo. Precisamente el problema de sincro. lo vas a tener tu si lo fijas a 75 y te va a 40. Tendrás que saltarte frames "a lo bruto" para compensarlo, y eso suele quedar bastante mal.

ale, mas leña pal fuego...

saludos


[ Este Mensaje fue editado por: mallrat el 2002-04-24 02:49 ]                                

[fiero]

                                mallrat:

...no creo que el windows de a las aplicaciones privilegio de E/S para usar esas instrucciones.

Para dejar todos los cabos atados, windows deja usar TODAS las instrucciones de ensamblador habidas y por haber, la única restricción es si accedes a una parte de la memoria que no a sido reservada por tu aplicación, por lo demás no problem, yo lo estoy haciendo todo en asm...

saludetes                                

[Emotion]

                                para Ithaqua:

Bueno, tienes razon... el movimiento se parametriza en funcion del tiempo, pero la medida de los FPS tambien es parametrizable en funcion del tiempo... ya que si tenemos por ejemplo 50 FPS cada frame esta consumiendo 0,02 segundos. Ademas, si quisieras controlar el movimiento de un objeto y quieres usar un segmento de tiempo menor, tendrias que poder generar mas frames EN EL CASO de que quisieras visualizar todos los pasos. De todas formas, lo dicho... a mi el sistema de los frames me funciona (por ahora), cuando me encuentre con el escollo entonces decidire que hacer... tiempo tengo casi todo el del mundo para corregir y depurar...

De cualquier modo entiendo tu punto de vista E INCLUSO lo comparto, solo que yo quiero hacerlo asi y lo voy a hacer asi, ya que no se tu como veras lo del keyframer, pero yo al menos el de 3DS4 usaba frames para las llaves, no tiempo (si no mal recuerdo, ya que louego supongo que utilizaba incrementales para los frames contiguos).

para mallrat:

Lo de que windows no te deja E/S no es cierto, lo que pasa es que segun el manual de INTEL, si se produce la interrupcion 05h mientras el rep esta por ahi dando vueltas, el comportamiento de la instruccion rep es entonces imprevisible, por eso desactivo las interrupciones antes del bucle y despues lo vuelvo a meter.

Aparte de eso, SIGO en mis trece de hacerlo asi, y con respecto a la interpolacion, bueno... quizas la idea de bloquear los fotogramas no sea tan buena como parece, pero aun tengo que hacer unas pruebas, aunque me mantengo en lo expuesto en los otros post... :riendo:

Saludos a ambos
                               

[Ithaqua]

                                Emotion:

Supongo que te funcionará bien porque no estas trabajando con gráficos en tiempo real, sino con imágenes/vídeo o algo parecido no-interpolable.
Por otra parte el 3ds siempre ha usado internamente valores de tiempo para las keys (como cualquier otro programa de animación 3D). Solamente que de forma externa se puede trabajar también a nivel de frames.

Un saludo.


                               

[Emotion]

                                Bueno, la verdad es que debo pedir disculpas ya que meti la pata en mi anterior post, ya que no es el keyframer el que trabaja con frames (es cierto, trabajaba con tiempo), sino que era el video-post el que trabajaba por frames, pero claro.. el video-post no es mas que un compositor y yo me estaba basando en eso... La verdad es que llegados a este punto me quedo bastante confuso, ya que mi sistema, al menos en las pruebas analiticas, funciona, ademas la estructura interna de funcionamiento de mi motor funciona de manera similar al video-post. De cualquier manera, lo siento de veras...

Quizas si me dejaras un mail te podria explicar con algo mas de detenimiento el porque quiero mantener (o me gustaria que en esencia se mantuviera asi) la estructura...

Un Saludo y mis mas sinceras disculpas :triste:
                               

[fiero]

                                Hola Emotion,
¿a que te refieres con lo de que desactivas las interrupciones? ... entonces, cuando machacas una zona de memoria que no es "tuya", ¿no te avisa?, por que sin iniciar ESI y EDI a nada es rarisimo que no te casque siempre en ese retardo...

saludos                                

[Ithaqua]

                                Emotion, todo menos pedir disculpas :ojo:
Para eso estamos todos aquí, para plantear dudas, dar consejos e incluso equivocarnos (o no) :sonriendo:
Hmm, parece que este thread está llegando a su fin. Increible...

                               

[Emotion]

                                para Ithaqua:

Si, la verdad es que me alegro de que todo haya casi terminado, y digo casi por el añadido que voy a hacer al post de fiero, pero vamos... parece que todo toca a su fin... :sonriendo:

para fiero:

Bueno, el manual de Intel dice eso, que si se produce la interrupcion 05h mientras el bucle esta corriendo aun, el comportamiento de la instruccion es impredecible, pero es todo lo que puedo decir, ya que es todo lo que dice el manual. Supongo que por eso es bueno hacer el CLI, aunque no se yo si a Windows le hace mucha gracia, para mi que no, pero si lo dice el manual...

Saludos a ambos
                               

[mallrat]

                                Buenas! aun no está acabao del todo el tema (aunque ya le queda poco...) :lengua:

fiero: Windows NO te deja usar TODAS las instrucciones. Hay algunas instrucciones que sólo las puedes ejecutar si estás en el nivel de privilegio en el que el S.O. te permita ejecutarlas. Para ser mas exactos, el windows NO te va a hacer caso de un STI o de un CLI a menos que estes en modo kernel, así que o haces un driver u olvidate de usar STI o CLI.
Son instrucciones muy concretas, como las de antes o las de E/S por los puertos. En cuanto a las instrucciones "normales", por supuesto puedes usar las que quieras.

Emotion: supongo que te refieres al problema que habia en los 8086 con el rep movsb (o cualquier otro "rep") que se cortaba cuando habia una interrupcion (del tipo que fuera) por simplicidad en el diseño del micro... (que vagos los de intel) pero valía con comprobar si cx habia llegado a cero, con lo cual habiamos terminado. Si no era cero, habia que continuar el "rep". De todas formas ya no tienes que preocuparte en absoluto de eso (si quieres échale un ojo al código ensamblador de strcpy/strcat/etc, seguro que no ves ni cli/sti ni siquiera ninguna comprobacion de que efectivamente ecx=0)

saludos
                               

[Emotion]

                                Ah, pues mira tu por donde... eso no lo sabia...

Gracias por la aclaracion, creo que eso me permitira hacer mi codigo ASM un poco mejor :sonriendo:

Un Saludo
                               

[fiero]

                                vale vale, :riendo: oido cocina, como yo ejecuto mis viejos programas de MS-DOS en windows y CLI y STI me seguian funcionando igual... aunque ya se que eso es otra historia, ya que lo que utilizo es un "emulador" de un 8086 dentro del maravilloso mundo windows. Hacer una CLI o STI del 386 (o superior) cuando trabajamos en modo protegido y en capas superiores al kernel, pues la verdad no lo he probado, pero son instrucciones tan simples que ... en fin ... pensaba... lo siento... ala, a currar.

un saludo                                

[Emotion]

                                Bueno, lo del kernel, realmente es el kernel el que esta por encima de la maquina... al menos organizativamente :sonriendo:

En cuanto a lo del modo protegido, pues mira... pensandolo bien, sera mejor que no le metas el CLI ni el STI, ya que el sistema no puede ejecutar interrupciones de modo real en modo protegido a no ser que las emule o antes de ejecutarlas vuelva al modo real. Es que ahora que caigo, si ejecutas una interrupcion normal en modo protegido lo normal es que te genere el famoso GPF o general protection fault por violar la proteccion de memoria... :sonriendo: