Doom III a 60 FPS

pos esta muy bien, pero como no me explique alguien mas detalladamente lo que ha contado el tio yo no pillo el concepto ese de que algunos saltos solo se pudiesen hacer a determinados FPS, eso como puede ser?

De todas formas todo esto es referente a la version de PC, en la xbox ya se vera como queda la cosa

Salu2

Bueno, en Meri. hacen referencia a ambas versiones, además, si lo hacen para PC y dicen que serán 60 forzados, con los PC's malos también, así que me hace pensar que en xbox también.

Escrito originalmente por Juaner
pos esta muy bien, pero como no me explique alguien mas detalladamente lo que ha contado el tio yo no pillo el concepto ese de que algunos saltos solo se pudiesen hacer a determinados FPS, eso como puede ser?

significa q el motor de físicas en Quake 3 y anteriores era dinámico, y a determinadas imagenes por segundo (pocas) el motor de físicas actuase de forma diferente, provocando mayores "efectos físicos" a menores imagenes por segundo, de lo qeu sería deseable.

El pavo esta diciendo, q el motor de "eventos" en el juego, esta fijado a 60 "eventos" por segundo. Es decir, todo se lee 60 veces por segundo, y provoca, q solo se puedan generar 60 imagenes diferentes por segundo, aunque tu tarjeta gráfica sea capaz de mostrar 500 imagenes por segundo, y a su vez, provoca, q a 10 imagenes por segundo, el juego sea igual q en un equipo a 300 imagenes porsegundo, a excepción de la fluidez del mismo en cuanto a imagenes, nada más.

Es como los simuladores de conducción, varios de F1 en PC, aunque tu PC solo sea capaz de mostrar por ejemplo, digamos que 40 imagenes por segundo, estan realizando todos los calculos de inteligencia artificial o físicas incluso a "400 eventos por segundo" independientemente de la tasa de imagenes q sea capaz de mostrar tu equipo.

Salu2

PD: Esto afecta a Xbox y PC, a ambas plataformas, y si lo portan a otra plataforma como GC o PS2 pasaría lo mismo, eso sí, para evitar q solo haya 60 imagenes diferentes, aunque el PC pueda mostrar 500, es tan "simple" como aumentar la velocidad del motor de físicas.

si es que asi da gusto

gracias por la explicacion

Escrito originalmente por shadow land


[...]

El pavo esta diciendo, q el motor de "eventos" en el juego, esta fijado a 60 "eventos" por segundo. Es decir, todo se lee 60 veces por segundo, y provoca, q solo se puedan generar 60 imagenes diferentes por segundo, aunque tu tarjeta gráfica sea capaz de mostrar 500 imagenes por segundo, y a su vez, provoca, q a 10 imagenes por segundo, el juego sea igual q en un equipo a 300 imagenes porsegundo, a excepción de la fluidez del mismo en cuanto a imagenes, nada más.
[...]

Yo más bien diría 60 "ciclos de eventos" por segundo, para evitar confusiones .

Voy a intentar aclarar algunas cosillas q creo que no han quedado claras.

En primer lugar tengo que decir que normalmente en los juegos hay dos cilos o "bucles" principales:

- Ciclo que actualiza la posición y estado de los objetos en el mundo, incluida la camara que simboliza al jugador, en el caso de un FPS (este ciclo solo emplea la CPU y suele incluir tambien los algoritmos de AI, comunicaciones, etc)
- Ciclo que dibuja la escena, en función del estado de los objetos (este ciclo incluye tanto a la CPU como a la GPU)

En realidad hay muchas mas cosas, pero vamos a quedarnos solo con esto. Además aclaro que estos ciclos normalmente se implementan en hilos de ejecucion independientes, aprovechando la supuesta multitarea de nuestros sistemas.

Lo que Carmack quiere decir es que el primer ciclo (el de actualizacion de posiciones encargado de animar los objetos, la AI, etc) se va a ejecutar a 60 Hz.

60 Hz significa 60 veces por segundo, no podemos decir 60 fps (fotogramas por segundo) porque este ciclo no entiende de fotogramas ni de pimientos morrones, ya que a este ciclo no es el que dibuja / renderiza los fotogramas.

Logicamente, el primer ciclo (el que anima) consume mucho menos potencia de proceso que el segundo (el que pinta la escena), asi que lo que Carmack ha dicho basicamente es que van a obligar a que el primer ciclo se ejecute 60 veces por segundo, mientras que el segundo ciclo, el de pintar los fotogramas se va a quedar con la potencia de calculo que sobre de la ejecución del primer hilo.

Esto tiene como principal ventaja que la animación y el gameplay no va a alterarse y va a ser identico tengamos el sistema que tengamos, y que en un equipo potente se puedan hacer exactamente los mismos movimientos que en uno no tan potente.

Por otro lado los sistemas que no esten tan bien equpidos no tendran potencia de proceso suficiente como para que el segundo hilo se ejecute tantas veces como el primero, ofreciendo menos de 60 fps, lo cual creo que sera lo habitual para casi todos nosotros. Asi que digamos a modo de ejemplo que en un sistema limitado el segundo ciclo se ejecutaría una vez por cada 2 veces que se ejecute el primero, dando como resultado una tasa de 30 fps, pero una animación precisa e identica a la de un sistema mas potente.

Un inconveniente, si puede llamarse asi, es que aquellos sistemas que vayan abiertamente sobrados de potencia, no va a poder aprovecharse esta potendia sobrante en absoluto, ya que, por dar cifras de ejemplo, si puediran llegar a pintarse 120 fps, seria un tanto absurdo ya que el fotograma 1 sería identico al 2 y no apreciariamos que hay dos fotogramas en vez de uno, y asi con los fotogramas 3-4, 5-6, 7-8....

Resumiendo Dice Carmack que:

- no habra mas comportamientos extraños debido a las diferencia de potencia entre sistemas.
- el limite superior de fotogramas que obtendremos será de 60 fps
- no existe limite inferior garantizado de fotogramas, asi que a algunos de nosotros nos seguira llendo a 1 fotorgrama cada 10 minutos

Mausidio tu si que has dado en el clavo[oki]

Muy buena explicacion.

Podremos darles a los monstruos 60 balazos por segundo


<-[bye]->

Escrito originalmente por JohnDoe
[b]Mausidio tu si que has dado en el clavo[oki]

Muy buena explicacion.

Podremos darles a los monstruos 60 balazos por segundo


<-[bye]-> [/B]

60, o 300. 60 eventos no limita nada, solo es el motor de físicas/IA.


el ejemplo es PGR 2, funciona a 30fps, pero el resto del juego funciona a 60Hz (físicas, sonido, IA, control...)

Salu2

A ver si lo he entendido bien. Os referis a que cuando los graficos se ralentizan tambien se ralentiza el juego en si? Es decir, que ya no pasara eso de que el juego pega unos botes y cuando se estabiliza ya te han matado y no te has enterado de na? o es al reves?

Escrito originalmente por central98
A ver si lo he entendido bien. Os referis a que cuando los graficos se ralentizan tambien se ralentiza el juego en si? Es decir, que ya no pasara eso de que el juego pega unos botes y cuando se estabiliza ya te han matado y no te has enterado de na? o es al reves?

algo así, hasta de ahora, sus motores funcionaban de tal manera, que el motor de eventos, y el motor gráfico, funcoinaba a la vez. Aquí, el motor de eventos, va aparte del motor gráfico, es decir, el motor gráfico va por un hilo, y el de eventos, por otro. Pero el de gráficos, depende del de eventos, y mientras puedas calcular el de eventos, aunque solo veas una imagen por segundo, eljuego seguira actuando internamente de forma normal, aunque solo veas eso, una imagen por segundo.

Salu2

Escrito originalmente por central98


A ver si lo he entendido bien. Os referis a que cuando los graficos se ralentizan tambien se ralentiza el juego en si? Es decir, que ya no pasara eso de que el juego pega unos botes y cuando se estabiliza ya te han matado y no te has enterado de na? o es al reves?

Al revés, ahora no se relentizará el juego, sino que se producirán tirones(ahora estás aquí, luego apareces 10 metros más adelante), así que con equipos lentos las teletransportaciones están aseguradas .

Escrito originalmente por Mausidio
[...]

Por otro lado los sistemas que no esten tan bien equpidos no tendran potencia de proceso suficiente como para que el segundo hilo se ejecute tantas veces como el primero, ofreciendo menos de 60 fps, lo cual creo que sera lo habitual para casi todos nosotros. Asi que digamos a modo de ejemplo que en un sistema limitado el segundo ciclo se ejecutaría una vez por cada 2 veces que se ejecute el primero, dando como resultado una tasa de 30 fps, pero una animación precisa e identica a la de un sistema mas potente.

[...]

En la última frase, yo más bien diría un entorno preciso e idéntico al de un sistema más potente, porque lo que es la animación no me la quiero ni imaginar a 8fps .

Escrito originalmente por shadow land


60, o 300. 60 eventos no limita nada, solo es el motor de físicas/IA.


el ejemplo es PGR 2, funciona a 30fps, pero el resto del juego funciona a 60Hz (físicas, sonido, IA, control...)

Salu2

Lo de 60 balazos por segundo era solo una pequeña ironia

<-[bye]->

Hola,

pues eso, que no entiendo dónde está la novedad de todo esto.

La multitarea hace años que se inventó y supongo que desde entonces muchos juegos la han aprovechado para separar el motor físico del motor gráfico, no?

Por ejemplo, si capturásemos solamente 30 eventos del ratón por segundo, en un fps,cuando diésemos vueltas rápidas quedaria aun peor de lo que ya queda ahora.
(creo que los ratones pueden llegar a dar 200 eventos por segundo).

Lo que creo que ellos harán, que quizás ahora no se hace, es limitar las imágenes por segundo a 60fps puesto que no tiene sentido pintar mas de una vez para cada "recolocación" del mundo.
Pero el motivo de esto cual es? Que no se caliente la tarjeta gráfica? O quizás guardar CPU para el tema de multiplayer?

ya veremos.

dew!

no tiene nada que ver con el multiproceso ni nada...

el juego ira a 60hz, y la tarjeta gráfica podrá mostrar 300 imagenes por segundo, pero solo veras 60 diferentes, ya que solo se calculan 60 "pasos" de acciones cada segundo, nada más.

Los juegos de F1 buenos (no las mierdas que hay enconsola), suelen funcionar con motores de físicas entre los 150 y los 400Hz, y eso es independiente de que el juego luego solo muestre 10 o 100 imagenes por segundo, si la CPU puede con el motor de eventos sin problemas (cualquier CPU media a dia de hoy), el juego será igual de preciso con una tocho gráfica, y con una cutregráfica. Y en la mayoría de los juegos, salvo simuladores... esto no era así... solía ir todo unido...

Esta es la razón de que algúnos juegos de consola en su versión 50Hz, vayan más lentos que en su versión 60Hz. Se debe a que todo va unido en un único proceso y un único hilo, como consecuencia, independientemente del tipo de SO que se corra debajo.

Salu2

En el caso de los juegos de F1 incluso podeis comprobar por vosotros mismos los efectos de las fisicas a 200hz y 400hz.

En los F1 de ISI, F12002, F1C,(los distribuidos por EA) solo hace falta irse al fichero "vuestrojugador.PLR" que esta en el directorio SAVES y cambiar esta linea.

Half Rate="0" // 0 = super-high physics rate, 1 = normal

Con un 1 = 200Hz
Con un 0 = 400Hz