Polyteres escribió:lherre escribió:...
Buenas gente. Después de ver lo q has puesto no iba yo muy desencaminado con lo q puse en la página 183
.
La verdad es q he seguido dándole vueltas pq me parece muy interesante. Estoy haciendo unas cuantas pruebas para ver si puedo implementar algo parecido...a ver si posteo los resultados pronto.
QuiNtaN escribió:A ver, para que cada cual valore, he cogido un fragmento de una imagen a 1080p/72ppp y la he reducido a 900p y 720p y reescalado a los 1080p originales. Están puestas en orden 1080p/900p/720p, que cada cual juzgue si hay mucha diferencia o no, yo creo que la diferencia es evidente en las 3 etapas.
Pero es q no es así exactamente. De esa forma lo q estás haciendo es coger una imagen y reducirle el tamaño (con lo cual ya "emborronas") luego vuelves a reescalar (vuelves a emborronar...). Al menos como yo lo veo, tu renderizas el buffer a 960x1080 pero con una relación de aspecto 2:1. Si expandes dicha imagen tendrías las filas pares (o impares):
Pixel_nativo_0 -- pixel_interpolado_1 -- pixel_nativo_2
El pixel interpolado es el q se saca teniendo en cuenta la velocidad del pixel (dirección y módulo) y viendo cual sería el teórico color consultando en las imágenes anteriores y combinándolo de alguna manera.
Como digo voy a ver si saco algo en claro y lo posteo.
Un saludo gente.
Pues, Polyteres, discrepo, al menos en un aspecto: creo que están sacando el render con pixel cuadrado. O bueno, mejor dicho, puede que saquen el render 2:1 con 960x1080, para tener el ratio correcto de imagen (1.778) y luego eliminen las columnas que no interesan (pares o impares, las que toque) y se queden con la de 960x1080 para hacer el cálculo posterior. Aunque es más sencillo hacer eso que un render que vaya línea a línea calculando un pixel sí, un pixel no, un pixel sí, un pixel no, etc.
Esto tiene bastante que ver con lo que puso lherre tiempo atrás (gracias por cierto por traer esta información): compresión temporal y vectores de movimiento de pixel (algo bastante usado en codecs de vídeo). Aquí se usa el movimiento en tres fotogramas de los de 960x1080p. Luego añaden el cálculo para predecir dónde irá cada pixel. Si no se puede obtener el cálculo, sacan el píxel de sus vecinos del frame actual (por lo que no creo que saquen con ratio de pixel 2:1). Y por último, usando el frame anterior (esta vez el de 1920x1080) y los vectores de movimiento mejoran el antialias.
Seguramente cuando no quede bien es cuando falla esa predicción, aún así parece bastante complejo y costoso. Veremos si otros juegos se animan a usar esta técnica.
De todos modos el día 20, salimos de dudas.
Edito: nuevo trailer de Dragon Age: inquisition
http://www.gamespot.com/articles/biowar ... 0-6418148/