gynion escribió:Pero es que cuando caemos en los off-topics los hilos donde tocarían esos comentarios a lo mejor están tan solo 2 o 3 hilos más abajo
A lo mejor están 2 o 3 hilos mas abajo, pero no ni siquiera normalmente.
robotnik16 escribió:Las demos técnicas son el mejor ejemplo de lo que puede hacer un hardware pero lo interesante sería que todos esos recursos técnicos fueran en beneficio de los juegos, como pregunta titorino... Yo no sé hasta que punto hay margen para implementarlos pero apostaría a que se podrían aprovechar para hacer cosas molonas, más allá de los géneros clásicos, como beat em ups, shooters... (y en éstos también)
Todo lo que pueda hacer con los planos, puede implementarse en cualquier juego sin ningún problema.
Otra cosa es que por ejemplo uses toda la cpu para calcular polígonos, y no dejes ni un ciclo para todo lo demás. Ahí obviamente no podrás conseguir hacer juegos 3D con la misma calidad gráfica.
Sexy MotherFucker escribió:¿Pero en aventuras gráficas, juegos de escenario estático, o plataformas/run and guns patéticos?
En juegos con los que conformas el escenario a base de las tiles que ya tienes preinstaladas en la vram, no vas a notar diferencia. Van a seguir teniendo el mismo aspecto de reutilizar los mismos elementos (solo que con el doble de definición.
Por otro lado, si quieres fondos planos complejos que no repiten tiles, y requieres de un flujo constante de DMA, se obligará al sistema a que un plano no se mueva tan rápido como a 256x224 porque a 512x224 las tiles ocupan mas.
Se puede calcular:
Mover horizontalmente un plano te obliga a actualizar las columnas verticales. Son 28 tiles por cada uno de los dos planos... uno de ellos es a razón de 64 bytes por tile, y el otro a razón de 32 bytes por tile.
Estamos hablando de 1792 bytes + 896 bytes= 2688 bytes por frame para dibujar la columna de tiles de los dos planos.
De esta forma el scroll avanza una pantalla entera cada 32 frames, que es apróximadamente cada medio segundo, y te sobran 3783 bytes para sprites (unos 3,69KB libres de 6,32KB aunque en realidad se queda en 6,14KB de ancho de banda total debido alas condiciones que impone físicamente la WRAM, obligando al sistema a pararse brevemente a mitad de cada line buffer para refrescar las direcciones de memoria ocupadas).
Para mover el plano verticalmente, son 32 tiles por cada uno de los dos planos. Esto hacen 3072 bytes por frame, y deja libres 3399 bytes (3,32KB).
De esta forma el scroll avanza una pantalla entera cada 28 frames, lo que es alrededor de medio segundo.
Y por último, un scroll multidireccional que avanza simultáneamente a la derecha y hacia arriba, está desplazando el scroll una columna vertical y otra horizontal por frame de los dos planos, lo que ocupa 5664 bytes (por frame), y deja libre 624 bytes para sprites por frame (0,61KB).
Eso si, la tasa de relleno aumenta que es un gusto, y actualiza una pantalla entera cada 15 frames. Es decir, el scroll ha movido una pantalla entera cada cuarto de segundo.