¿Quien sabe como funciona el frameskipping? [Archivo] - ZonaDeVicio

Ver la versión completa : ¿Quien sabe como funciona el frameskipping?

xan_vision

07/04/2006, 03:48

Buenas:

En este momento tengo aqui una oficina llena de programadores y revuelta :fieston: a costa de una implementación de frameskipping que pedí que hiciesen en nuestro engine.

El caso es que, al hacerla, evidentemente ha ganado casi el doble de rendimiento, pero alguna gente está dudando del funcionamiento del sistema, y aunque yo intento explicarselo, mis conocimientos tecnicos llegan hasta un limite y hay dudas que no puedo resolver.

¿Podria alguien explicarme como funciona exactamente la técnica frameskip? :confused:

Si para explicarlo necesitais de alguna información sobre como funciona nuestro engine, os proporciono lo que querais.

Por cierto, que la respuesta puede tener "premio" :D : Estamos buscando un programador de apoyo para añadirle mas efectos de ultima generación al engine.

Si a alguien le interesa y se siente capacitado, que avise y le comento todo lo referente a las condiciones de trabajo, las economicas, el proyecto, la empresa, etc... Estoy hablando de un juego importante, de lanzamiento mundial, que reportaría al "elegido" [chuck1] fama, fortuna, sexo, lujo, y demas minucias... [wei4]

Wave

07/04/2006, 03:58

Frameskip dinamico? o siempre el mismo?

xan_vision

07/04/2006, 03:59

Frameskip dinamico? o siempre el mismo?

Siempre el mismo

Wave

07/04/2006, 04:02

xan_vision

07/04/2006, 04:19

Pues en tu engine deberias tener dos partes, una de calculo y otra de pintado.
Frameskip X es: en cada frame haces el calculo, y de esos pintas uno y X no los pintas, luego pintas y luego X no los pintas, y asi.

Quedaria algo asi:
Calculo
Pintado
X veces Calculo
Calculo
Pintado
etc
de este modo con frameskip 0 seria calculo,pintado,calculo,pintado
y con frameskip 1 seria calculo,pintado,calculo,calculo,pintado,etc

Eso es lo que hemos explicado, y la gente lo sabe perfectamente, pero dicen que, teoricamente, no deberia dar ninguna ganancia, porque ¿Que ganas calculando mas veces?, lo que ves en pantalla es lo que pintas, y eso tienes que hacerlo igualmente en cada momento?

Ojo: no tienes que convencerme a mi, eh? que soy un creyente :D . Se que eso que he dicho puede ser una chorrada y no tener sentido, pero es lo que dicen algunos. Lo que trato es de encontrar una forma de explicarselo a un programadores (y avanzados), asi que puedes/podeis poneros muy tecnicos

^MiSaTo^

07/04/2006, 04:26

Imagínate una animación de un hombre corriendo, pues si tiene frameskip 0 se ven toooodos los pasos... pero si tiene más frameskip se salta algunos pasos, por tanto parece que el hombre corre más rápido. De ahí la ganancia (perdonad si he dicho alguna burrada y/o me he explicado muy muy mal)

Wave

07/04/2006, 04:26

Ganas el tiempo que te ahorras en los frames que no dibujas, porque tu juego va a X frames por segundo, unos seran mas rapidos que otros, pero en media tardaran menos que si pintas todos.

una-i

07/04/2006, 04:36

Eso es lo que hemos explicado, y la gente lo sabe perfectamente, pero dicen que, teoricamente, no deberia dar ninguna ganancia, porque ¿Que ganas calculando mas veces?, lo que ves en pantalla es lo que pintas, y eso tienes que hacerlo igualmente en cada momento?

El frame skip solo "vale" si te cuesta pintar más que calcular y si son dos operaciones "separadas", es decir si la "logica" de vuestro juegos es "ligera" y en cambio estais haciendo un renderizado por soft costoso, para que la "acción" no se relentize teneis 2 opciones;

a) Hacer que el "calculo" de la logica en vez de ser fijo sea varaibla es decir, que en vesz de decir posicino_jugador = posicion_jugador+1; lo que diga es posicion_jugador = posicion_jugador + Velocidad_jugador*tiempo;

b) Establecer el numero de "ejecuciones" de logica que hay que hacer por segundo y ejecutar n logicas por cada pintado, adaptandolo para que el "sistema" de la percepción de qu eaunque las cosas van menos fluidas(más a saltos) no hay una relentizacion de la accion.

Tradicional mente en makinas de 8/16 bits, arcades antiguos y consolas viejas, lo que se hacia era una logica tipo B, y como la makina era "fija" no habia fluctuaciones de velocidad, se hacia una ejecucion de logica, se sincronizava con el retrazo y se pintaba.

Como el el refresco era fijo pues la logica podia ser del tipo B y todo funcionaba.

Hoy en dia es frecuente una logica de tipo B mas "adaptable", pero tambine es más compleja de programar y mas "cara", por lo que en sistemas "pequños" movile sy demas aun no esta muy extendida.

P.D: Esto es aplicado a "juegos" en emuladores la cosa es diferente, porque la "logica" equivale a la ejecucion de la emulacion de la CPU y esa no puedes saltartela ni cambiarla, asi que lo único que puedes hacer para "acelerar" es "saltarte" procesos auxiliares, como el render(pintar 1 de cada N frames.. pintar en entrelazado, etc...), o el sonido(mezclando menos canales, a menos frecuencia etc..)

P.D: En los articulos de la ultima GDC hay una presentacino bastatne interesante de titulo algo asi como "Render, update, render rrevisited, a revision of game loops..." que puede ser interesante de leer pero no tengo el link lo siento..

Unai.

antoniou

07/04/2006, 04:40

En realidad no estás calculando más veeces de las necesarias, estás calculando exactamente lo que neecsitas para que el programa funcione, pero lo que no haces continuamente es dibujar en panatalla lo que acabas de calcular. Como dibujr algo en pantalla puede llegar a ser bastante costoso, dependiendo de tu procesador gráfico, te estás ahorrando un montón de tiempo.
Básicamente hay que pensar que los cálculos no te los puedes ahorrar, porque el programa no es adivino y no puede saber (en principio) qué va a pasar más tarde sin haber calculado lo anterior.

Espero haber explicado más o menos bien estas cosillas, aunque tampoco soy muy entendido de esto...

EDIT: ups, se me adelantó un experto :D

xan_vision

07/04/2006, 05:45

Muchisimas gracias a todos por las respuestas. En especial a Unai por la explicacion tan clara y exhaustiva (No te lo agradezco por messenger porque ultimamente no te veo nunca conectado. Andas escapado, cabronazo. De todas formas, por esta respuesta, te debo una caña cuando nos veamos. Por cierto: ¿vas a ir al E3?).

La explicación dice los mismo que se estimaba por aquí. Lo que no sabemos (simplemente porque no nos hemos tenido tiempo de estudiarlo) es, en el tiempo de render, cuanto tiempo está interviniendo la CPU, y cuanto la GPU, para saber cuanto compensa, y como coordinarlas de la mejor forma para que haya los menores tiempos de espera posibles. Como nuestro sistema de render es bastante complejo (no teoricamente, sino por la cantidad de elementos), pues no es facil saber cual se estará ocupando mas. El caso es que parece claro que la mas holgada era la CPU, y que la GPU va bastante ahogada, porque con un frameskipping del 50%, ha ganado entre un 30 y un 40%, dependiendo de la situación. Ya os contaré como evolucióna la mejora, estamos metiendo mas posibilidades de frameskipping para ver como reacciona en diferentes situaciones, como se ve, y como se coordinará mejor.

Pasando a otra cosa, reitero la oferta de trabajo para un programador. Va totalmente en serio. Si hay alguien interesado, que me añada: xan_vision@hotmail.com, y le cuento todo lo que quiera saber, sin compromiso.

Creo que el puesto es muy apetecible porque es para estar todo el dia haciendo "efectitos" de los molones (de los de ultima generación), en un engine que ya es bastante potente y muy maduro, y para un juego que se espera que sea muy importante y al que solo le queda menos de 1 año para acabar el desarrollo.

Muchisimas gracias una vez mas.

azrael

07/04/2006, 06:02

Pero a parte de saltarte fases de dibujado, tambien puedes "inchar" la fase de calculo,no?
Para que tenga en cuenta que dibujas menos, me refiero.
Por ejemplo sin frameskip dibujar cuando esta en los puntos ;
x, x+1, x+2...x+10
con frameskip
x, x+5, x+10
Te saltas los pasos intermedios y lo haces "casi" 5 veces mas rapido, me equivoco?

una-i

07/04/2006, 06:14

Muchisimas gracias a todos por las respuestas. En especial a Unai por la explicacion tan clara y exhaustiva (No te lo agradezco por messenger porque ultimamente no te veo nunca conectado. Andas escapado, cabronazo. De todas formas, por esta respuesta, te debo una caña cuando nos veamos. Por cierto: ¿vas a ir al E3?).

Al E3 no, que va, eso no es para developers :P

en el tiempo de render, cuanto tiempo está interviniendo la CPU, y cuanto la GPU, para saber cuanto compensa, y como coordinarlas de la mejor forma para que haya los menores tiempos de espera posibles. Como nuestro sistema de render es bastante complejo (no teoricamente, sino por la cantidad de elementos), pues no es facil saber cual se estará ocupando mas. El caso es que parece claro que la mas holgada era la CPU, y que la GPU va bastante ahogada, porque con un frameskipping del 50%, ha ganado entre un 30 y un 40%, dependiendo de la situación.

Entonces teneis que balancear la carga.. si no estais usando tecnicas de occlusion culling deberiais de hecharles un vistazo, tambien hacer una pasada inicial para rellenar el zbuffer ayuda si estais usando shaders mu complejos, y por fin el nivel de detalle tambine suele ser otra opcion tanto a nivel de geometria como de animaciones..
Y por ultimo vigilar el ancho de banda que esteis usando en el tema de subir constantes y en cmabios de estado, ordenar vuestras llamadas por shader, material etc... e implementar algún tipo de cahce para no subir constantes duplicadas de los shaders la tarjeta.

Así sin muchos mas datos tampoco se que recomendaros, otras cosas si no es para PC, son los command buffers precompilados que ahoran principanlmente CPU, pero si no estas limitados por cpu...

Unai.

Logann

07/04/2006, 15:42

Com ha dicho azrael si estas programando un engine puedes hacer cosas mejores para aumentar el rendimiento que el frameskip, que es un sistema muy bruto:

No es lo mismo:

dibujar; x++; y-=2; x++; y-=2; x++; y-=2; dibujar;

que dibujar; x+=3; y-=6; dibujar;

(bueno en este caso seria casi lo mismo pero se entiende no?)