Hilo de detalles y curiosidades de N64

@Conker64 es que algo no me cuadra, si precisamente los postprocesos que nas perjudican al rendimiento en n64 no requieren tantos recursos, ¿por qué 4000 polígonos por segundo la sujetarían a los mismos 20fps que la versión ps1?, ¿sin esos post procesos rendiría mejor en ps1 que en n64?, ¿no tiene n64 una ventaja haciendo streaming de texturas para aumentar mucho la complejidad?.

@Señor Ventura
Me he basado en el rendimiento que conseguirían en su momento, sabiendo lo que hicieron con Castlevania, etc

Con las pruebas y conocimientos de ahora, a esa resolución, N64 puede hacer algo superior, no ya de rendimiento, sino algo, con tecnología superior.

Ni siquiera he tenido en cuenta el uso de coma flotante o subpixel, que darían mucha más suavidad a movimientos cortos de cuerpo o desplazamientos lentos de cámara (que los hay) en las escenas cuando hablan los personajes.

Conker64 escribió:@Señor Ventura
Me he basado en el rendimiento que conseguirían en su momento, sabiendo lo que hicieron con Castlevania, etc

Con las pruebas y conocimientos de ahora, a esa resolución, N64 puede hacer algo superior, no ya de rendimiento, sino algo, con tecnología superior.

Ni siquiera he tenido en cuenta el uso de coma flotante o subpixel, que darían mucha más suavidad a movimientos cortos de cuerpo o desplazamientos lentos de cámara (que los hay) en las escenas cuando hablan los personajes.

Espláyate, quédate agusto.

Saca todo lo que tengas con respecto a esas expectativas. Se de dos zumbaos que están deseando leer algo así

@dirtymagic Sigues con lo del FF7 en el motor de OoT?
No te creas que me olvido de esa maravilla...
Si hubiera alguien capaz de crear el engine de lucha por turnos y añadirlo 🤤

@Conker64 Eso eso! Explayate! Tenemos ganas de análisis estilo Conker!

@Conker64

dirtymagic escribió:@radorn ¿que tiene de especial el SH de PSX en cuanto texturas?

Como dije en el mensaje original, no lo se. Era especulativo por la percepción general de mayor carga de texturas por limitaciones de almacenamiento.

@Segastopol RUSH 2049 sin duda tiene uno de los mejores motores 3D de la consola, con un aspecto super sólido, nítido, largas distancias... En algunos de los entornos esta calidad queda especialmente patente. Obviamente también depende de los modelos y texturas, pero eso no hace de menos el logro del motor.

Vaya marrón xD, para una respuesta de ese tipo tendríais que darme unos cuantos días para poder elaborarla, mirar bien las demos de Tiny3D, hacer pruebas, etc pero no me refería a nada particular, aclaro más abajo.

Seguro que os gusta este video, reciente, que profundiza en como funciona Silent Hill 1, que en parte luego puede ayudar para poder analizarlo:


- Desde efectos sencillos para crear cosas que parecen complejas
- Ver lo que hace el juego sin niebla y la verdadera distancia de dibujado
- Las estancias son simétricas y paralelas, con una distancia suficiente para ser descartada por bloque, el juego se mueve entre posiciones y salta de un punto 3D a otro, incluso a zonas repetidas pero que cambian por ser otro segmento
- Los interiores funcionan como exteriores, las salas están organizadas de la misma manera, salta de un punto 3D a otro, y no tiene porque ser en un orden concreto
- Está lleno de detalles escondidos, de texturas raras que esconden secretos, etc

En cuanto a N64, este otro ya se puso, pero para quién no lo recuerde, ya hay microcódigos para usar otro tipo de iluminación más avanzada, incluso la más básica en el 2:07 sirve, sin condicionar geometría, va por su cuenta.


Eso a lo que me refería, exploraría nuevas formas de usar la linterna, que es un aspecto esencial del juego, adaptaría geometría donde se necesite, si los mapas pueden ser menos complejos (dibujar lo mismo con menos) se puede invertir en otros apartados, como mejores modelados para los personajes o criaturas, miraría como sacar provecho a renderizar por subpixel que el juego tiene movimientos de personaje/cámara donde se siente tosco, y el 2 CYCLE podría ser interesante para crear las transiciones de un mundo a otro.

@bluedark
Sí ,pero lo tengo muy parado ya que este verano he estado trabajando en festivales y ahora estoy reformando la cocina.
Rehice Midgar, y ahora el modelo tiene más detalle gracias a que la mayoría de estructuras tiene LOD.
También pase la parte de sector 8 de la intro y la estación del sector 1 a Fast64 y Decomp del Zelda ( los videos que puse están hechos con una herramienta para hacer Mods de Zelda que se llama SharpOcarina), también mejore las texturas de la estación del sector 1, ahora la mayoría usa mezcla de 2 texturas, mi idea es optimizar esta última en varias estancias, ahora mismo es todo una misma malla y empezar a hacer el exterior e interior del reactor 1, pero todo esto para cuando termine de reformar la cocina.
Te pongo imagenes en spoiler


Salud.

-> Silent Hill en N64.
Debería de sentirle a la N64 como un guante. Al menos en lo que se refiere a mostrar en pantalla algo similar/igual/superior y con un rendimiento similar/igual/superior. No lo he jugado así que no me aventuro a decir si se podría meter todo el juego en un cartucho como se hizo con el RE2. ¿Son comparables en cuanto a cantidad de cinemáticas y diálogos doblados?
Un juego con distancia de dibujo escasísima, con muchos polígonos pequeños en la parte visible donde poder encajar texturas pequeñas a modo de puzzle para disimular los patrones, ¿con pocos enemigos en pantalla?, resolución por debajo de 320x240... No parece que la Nintendo 64 fuese a tener problemas con eso.
¿El juego más parecido sería Nightmare Creatures?

Para conseguir el efecto de niebla en PlayStation de la forma en que lo hace Silent Hill se gastan una burrada de recursos. Hay que doblar la geometría de los escenarios y superponer en cada polígono otro semitransparente con el color de la niebla e ir calculando la cantidad de transparencia según la distancia. En los personajes en lugar de eso colocan un polígono semitransparente entre el modelo y la cámara y descartan los píxeles que quedan fuera del modelo. Creo que fue @Misscelan quien puso un vídeo donde se explicaba cómo lo hicieron. En Nintendo 64 te lo hace el hardware directamente y, aunque no sale gratis, no consume muchos recursos.

@Conker64 menciona que Silent Hill utiliza un "filtro ruido". La verdad es que no lo noto. Creo que simplemente es dithering con el patrón que sea para simular grafientes de color, pero no cambia de frame a frame como sí lo hace el dithering de tipo ruido que tiene N64. Ambas consolas no pueden mostrar suficientes colores en pantalla para evitar saltos de color en degradados y emplean dithering para suavizarlos. Según la señal de vídeo (si no es RGB o S-Video) los colores se funden en la pantalla y las transiciones son más agradables (cómo hace Megadrive para simular transparencias con tramas). Nintendo 64 además del dithering reescala la imagen y puede aplicar un filtro de emborronado que actúa también como otro paso de antialising, aunque esto se puede evitar (sólo Quale 64 permitía hacerlo en las opciones).

En lo referente a texturas. Nintendo 64 tiene 4 kB de caché frente a los 2 kB que tiene PlayStation, pero ya he mencionado en mensajes anteriores que a efectos prácticos no hay ventaja. En texturas a color (de 4 y 8 bits de profundidad) los 4 kB se dividen en dos trozos: 2 kB con la imagen de la textura y otros 2 kB (¡desaprovechadísimos!) con la paleta de colores. En texturas de 16 y 32 bits de profundidad no se divide la caché (no hay paleta, ya que estás texturas usan color verdadero), pero son texturas tan pesadas que no permiten resoluciones superiores. Al final N64 y PS1 manejan texturas del mismo tamaño (¿N64 permite texturas en escala de grises más grandes?). No me queda claro cómo maneja la PS1 las paletas de colores en las texturas, pero creo que no utilizan la caché y toda su memoria se usa en la imagen de la textura.
La ventaja de N64 es que sí que tiene más RAM para almacenar las texturas (y muchísima más si se usa el Expansion Pak). El problema es saber lo que ocupan todas las texturas de Silent Hill y si cabrían en un cartucho.

@Sogun Es curioso, pensaba que el desaprovechamiento de la caché de texturas era la insistencia en usar mip mapping para todo, pero que si prescindes de esto te quedan 4KB con no muchas condiciones.

¿Entonces realmente solo se dedican 2KB a caché de texturas?.

@Sogun Yo diría que las únicas texturas que PSX no podría poner serían las de 128*64 en i4 y las texturas de 64*32 16 bits ya que ocupan 4KB y bueno si cuentas las texturas IHQ que con 2 cycles mezcla una textura de 32*32 16 bits con una de 64*64 i4 , teniendo una textura de 64*64 con 16 bits de profundidad.

Salud.

@Sogun
En PSX el formato va en la página, ahí defines la profundidad, tamaño, etc lo cual es necesario para saber cuanto reserva del pozo de 1MB.

El filtro ruido si no está en el 1 es probable que se añadiera en posteriores, es un filtro intencionado, como filtro de película o granulado, y es bastante marca de la casa en los survival, a mi no me gusta nada y lo desactivo siempre que tengo oportunidad, de hecho hay modos VI en N64 como el random dither que permiten crear una especie de granulado activo a "coste 0", random dither además de en el VI también se encuentra disponible para superficies.

En Silent Hill 4 se llama "efecto ruidos", en PC con resoluciones altas apenas se nota, en consola, que ya de por si es baja resolución, si lo acompañas con una pantalla moderna, queda un efecto "poco agraciado"


Lo de TLUT es una pena, si mal no recuerdo leí debates de como poder acceder a la parte restante de la memoria en cache, pero no sé en como quedó, de nuevo, podría preguntar en discord al respecto, por la experiencia que tuve trabajando con texturas, hay que ser muy preciso con la información que le das la consola, o recibes basura a cambio, no te quiero decir haciendo cosas exoticas.

Luego hay que tener en cuenta que, una paleta de 8 bits son 256 colores, 0-255 registros, si almacenas valores de 16bit (colores), cada valor toma 2 bytes, con lo cual ya te salen 512 bytes de información (0.5KB), de guardar valores de 32bit, a suponer, por el modo 32bit, ocuparía el doble, ahora no recuerdo si el comando acepta diferentes tipos, o solo espera 16bit, tendría que mirarlo, pero vamos que como mínimo te llevas un 25%,

Quizás la verdadera pena son las textura de 4bit, podrían haber añadido un registro de 16 valores, para poder usar por lo menos los 4KB enteros, ya que al final resulta ser el formato más utilizado, pero supongo que eso aumentaría la complejidad del chip, que además ya tenía huecos destinados al usar el mip mapping.

@Conker64 el filtro de ruido sino me falla la memoria es en los posteriores al 1, en el de PS1 el "ruido" era el dithering que es exagerado en este juego. Quizás en los siguientes lo pusieron como filtro opcional para mantener el estilo forzoso que impuso el primero.

Ya se ha comentado bastante pero por añadir algún detalle más.

Como comentó shogun, para renderizar la niebla gris de forma orgánica se renderiza por debajo un polígono con gouraud y por encima el texturizado con transparencia (lo mismo que hace el Soul Reaver).

Se reusa el cálculo de los vértices de polígonos. El coste mínimo por transparencia es similar al de n64, sin coste si se encuentra en la cache de texturas (en la n64 sin coste si está en el span buffer). Si la línea de cache del buffer de color no está ya dentro de la cache de texturas es otro ciclo y lo mismo si la línea de la textura está fuera también. Osea el triple de lento si todo está fuera, con el problema añadido de que cuantás más líneas del buffer de color te traigas más posibilidades hay de sacar lineas de textura. Supongo que por eso la resolución es un poco más baja de lo normal.

Aquí quería puntualizar que como ha comentado también shogun, las caches funcionan de manera diferente. En n64 todos los datos tienen que estar dentro antes de renderizar el polígono (con las restricciones pertinentes de la separación por bloques). En PSX no hay limite en el hardware, ya que se traen líneas de 8bytes en 8bytes según se vayan necesitando. El límite son texturas de 256x256@4bpp autoinpuesto por software por las variables que almacenan las coordenadas en los paquetes que se mandan a la GPU (las variables son de 8 bits). El CLUT se alamacena fuera de los 2k de la textura de cache. Pero bueno aparte de las pocas texturas que entrarían en VRAM estaría el problema de que si los datos almacenados estuviesen en perpendicular a las coordenadas UV podrías perde la cache en cada pixel (si estuviesen en la misma dirección solo se produciría perdida en 1 de cada 16). Así que a efectos prácticos lo suyo sería usar 64x64@4bpp para que no tuvieses que sacar ninguna línea de la cache por otra nueva.

Volviendo a Silent Hill, aparte de la niebla estarían los efectos de iluminación. Cuando estás a oscuras, el degradado a negro no requiere de doble pase, el trabajo de la GPU se reduce pero se descarga en la CPU. El GTE tiene una función para calcular la iluminación de 3 vertices en 44 ciclos que es extremadamente rápida pero Silent Hill tiene un porrón de polígonos que iluminar por frame.

En las dos consolas, es necesario teselar ya que solo pueden hacer iluminación por vértice y con polígonos grandes quedaría bastante mal (los ejemplos de Tiny3d son por vertice, el ejemplo de limitar la iluminación dentro de un radio también se podría hacer en ps1 ya que tiene un buffer de 1bit para hacer masking).

El unico problema que podría ver en la n64 dentro del 3d, es el de que Silent Hill usa bastante variedad de texturas y eso implica cambios constantes en la cache, pero sin un test real serían todo suposiciones.

En todo lo demás no veo ningún problema, lo contrario creo que traería otras mejoras sobre todo en el tema del subpixel, en ps1 siempre se nota más a bajas resoluciones y en Silent Hill es el caso.

@dirtymagic
Ese sector 8 tiene pintaza!

@Conker64 A eso me referia, solo a lo grafico, sin contar el sonido y los FMV

Señor Ventura escribió:@Sogun Es curioso, pensaba que el desaprovechamiento de la caché de texturas era la insistencia en usar mip mapping para todo, pero que si prescindes de esto te quedan 4KB con no muchas condiciones.

¿Entonces realmente solo se dedican 2KB a caché de texturas?.

Cuando las texturas usan mipmapping los 2 kB con la información de la textura también contienen los niveles de mipmapping, reduciendo todavía más la resolución de la textura.
El editor del GoldenEye/Perfect Dark te permite generar tus propios niveles de mipmapping y aprovechar mejor esos 2 kB. Te permite incluso eliminar algunos niveles. La paleta sigue siendo la misma, pero cada nivel puede ser una imagen diferente y así puedes conseguir algunos trucos chulos.
Si no lo haces así y dejas que la consola genere los mipmaps automáticamente la textura base ocupa 1kB, los mipmaps 1kB y la paleta 2kB. El resultado son texturas de 32x32 píxeles a 8 bits de profundidad de color con mipmapping activado o texturas a 4 bits de color de 64x32.

Había empezado a escribir una serie de ejemplos de cómo se almacenan las texturas en la caché y cómo calcular los tamaños para optimizar los 4 kB pero hace tanto tiempo que no hago nada de esto que lono lo recuerdo bien. Investigando se me hizo tarde y quería continuar con el mensaje esta mañana, pero no guardé bien el borrador. A ver si más tarde hago algunas pruebas y confirmo cómo funciona lo de los tamaños porque tiene algo de miga. Como adelanto, en varios sitios se dice que la textura cuadrada más grande que puede dibujar Nintendo 64 es de 90x90 en escala de grises a 4 bits (si haces los cálculos salen 4050 bytes que entran en los 4096 bytes de la caché) pero no es así. En realidad es más pequeña. Me sonaba que eran 88x88 pero según los cálculos que estuve haciendo el límite son 80x80 con mucho espacio de la caché desaprovechado. Quiero hacer unos test para confirmarlo y luego escribir otro mensaje aquí. Quizás ya lo mencioné de pasada hace tiempo.

@dirtymagic
Sí. Las texturas en escala de grises pueden ser de mayor tamaño en N64 ya que al no haber paleta se usan los 4 kB para la imagen de la textura si no piensas usar mipmaps.
¡Impresionantes tus avances en el proyecto de FF7! Tiene una pinta espectacular.

@Conker64
Creo que el tamaño real de las paletas sería:
Para texturas de 8 bits de profundidad (256 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 256 entradas / 8 = 768 bytes
Para texturas de 4 bits de profundidad (16 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 16 entradas / 8 = 48 bytes
No hay canal alfa. Las semitransparencias se realizan en la geometría (el polígono entero o por vértices e interpolando).

Sogun escribió:@Conker64
Creo que el tamaño real de las paletas sería:
Para texturas de 8 bits de profundidad (256 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 256 entradas / 8 = 768 bytes
Para texturas de 4 bits de profundidad (16 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 16 entradas / 8 = 48 bytes
No hay canal alfa. Las semitransparencias se realizan en la geometría (el polígono entero o por vértices e interpolando).

Estarías desperdiciando espacio...

Recuerdas esta demo? Subí el ejemplo en 2018, la tienes en github.


De todas formas te explico la parte que importa, las paletas las construyo así (paleta 4bits, 16 colores):


Esos números ya están puestos directamente en 16bit (0-65535) con una herramienta que escribe por mi ese tipo de información, el RDP tiene comandos donde usa RGBA, en otros espera "packed colors", no quiere los componentes por separado, ese array se sube tal cual al comando del chip.

Cuando usas 16bit de color se espera RGB555, al ringbuffer se envían comandos de 64bit, en 2 tiempos de 32bit, a veces es necesario repetir la misma información, en los 16bit altos y en los bajos, el RDP es muy majo, veamos un ejemplo:



Luego eso lo mandas directamente al chip:


Al comando 0x37, que corresponde al de fill color, se le envía la variable que hemos trabajado en el código anterior, en los segundos 32bit.



Las texturas en formato Color Index (4/8bit), por lo que estoy viendo, usarían los 2KB enteros en 8bit (512x4), se suben 4 copias de la misma para tener acceso a 4 bancos simultáneos:



Y son en formato 16bit color, no se admite 32bit para CI, la textura solo en los primeros 2KB, la paleta solo en los segundos 2KB.

Otros tipos de textura pueden usar la zona restante de TMEM (RGBA,YUV,IA..) o toda la memoria, según el manual.

Me sabe mal tener la teoría tan olvidada..

No sabía que la res de PS1 era más baja de 320x240 así que para N64 mejor que mejor para ofrecer la misma res, pero a 20 estables o quizás 30 (hablo en la época o con Kaze usando una máquina del tiempo y viajando al pasado a enseñar).

@SuperPadLand la resolución más baja de PlayStation es 256x240, aunque el estándar de la mayoría de juegos es 320x240.

Silent Hill se ejecuta en un framebuffer total de 320x240, pero no rellena toda la pantalla, por lo que en la práctica la resolución/área visible es algo menor dejando marcos negros alrededor.

Resident Evil 4 en GC hace lo mismo; la salida de vídeo escupe 640x480, pero el Flipper no renderiza toda la pantalla, sino que tiene márgenes negros arriba y abajo.

Sogun escribió:En texturas a color (de 4 y 8 bits de profundidad) los 4 kB se dividen en dos trozos: 2 kB con la imagen de la textura y otros 2 kB (¡desaprovechadísimos!) con la paleta de colores.

Pregunta: ¿se pueden usar todas las texturas de 8 bits que quieras con una sola paleta, e incluso solo tener que cargar la paleta una vez por frame usandola para todas las texturas?

La pregunta va también para @Conker64

Yo supongo que sí. No recuerdo ninguna obligación de cargar textura y paleta al mismo tiempo. Aunque 256 colores son pocos, en determinados escenarios podrían ser más que suficientes (SM64, por ejemplo). Usar texturas de 2kb ahorra espacio en cartucho y RAM y ancho de banda de esta última. Y las texturas de 32x32 (o 43x43 según N64Squid, pero creo que dan problemas y no se pueden repetir por no ser potencias de 2) creo que son resolución suficiente para dar detalle a muchos polígonos.

Sobre Silent Hill, hay que tener en cuenta que hay muchas texturas de rejilla, por lo que tienen huecos que necesitan alfa. Creo que formatos de textura con paleta o de Intensidad no valdrían al no tener alfa (a menos que con paleta haya valores reservados para alfa) y habría que tirar por texturas de 16bits. Aunque creo que el color combiner permitiría crear efectos de rejilla con texturas sin alfa y sin ocupar espacio físico, solo unas líneas de código.

El problema serio que le veo a Silent Hill es la música, que está en formato XA y ocupa bastante espacio. Lo bueno es que en general es bastante repetitiva, podrían limitarse a varios loops reproducidos en cierto orden o incluso mezclarse unas pocas pistas de estos loops para crear música de mayor calidad. En cualquier caso ocuparian memoria y espacio y habría que apañarselas para meterla en el cartucho.

Sexy MotherFucker escribió:@SuperPadLand la resolución más baja de PlayStation es 256x240, aunque el estándar de la mayoría de juegos es 320x240.

Silent Hill se ejecuta en un framebuffer total de 320x240, pero no rellena toda la pantalla, por lo que en la práctica la resolución/área visible es algo menor dejando marcos negros alrededor.

Resident Evil 4 en GC hace lo mismo; la salida de vídeo escupe 640x480, pero el Flipper no renderiza toda la pantalla, sino que tiene márgenes negros arriba y abajo.

Hablo de la resolución interna o nativa o como se llame.

@EMaDeLoC
Sí se puede cargar una paleta de 8 bits o ¿8 o 16 de 4 bits? y subir a la cache sólo las imágenes que usen esa paleta.
Depende para qué 256 colores pueden ser suficientes.
Las texturas CI tanto de 8 como 4 bits, permite transparente pero no transparencias y la I el negro es transparente si configuras la textura como recorte.

CI4 con transparencia


I4 con el negro como transparente.


Salud.

No te acabas este hilo, que gozada...

Entonces si es posible aprovechar los 4KB para una textura siempre y cuando sea en escala de grises, ¿y 4BPP?. A 8BPP hay que guardar la paleta en la caché, ¿es eso?.

@SuperPadLand yo también te hablo de ésas. Resoluciones nativas de PlayStation:

- 256x240.
- 320x240. La que usa Silent Hill. Pero de ese total sólo rellena 292x224, quedándose 1 marco negro rodeando el área visible del juego:



- 384x240.
- 512x240.
- 640x240.

Etc. Eso en progresivo y NTSC. En entrelazado y PAL varía.

Super Mario 64 también escupe 320x240 y también renderiza unas líneas por debajo, aunque nada tan cantoso como en el Silent Hill.

Realmente N64 y PS manejan rangos de resolución muy similares; son en esencia máquinas de 240p que también hacen sus pinitos en "HD", pero este último no es su hábitat natural. Aunque el tamaño máximo potencial del framebuffer es mayor en N64 que en la Play.

Luego, también en Nintendo 64, está todo lo que escale el "VI", pero yo ahí ya me pierdo, ya que nos salimos de lo " Nativo".

Por lo que he entendido, la interfaz de vídeo siempre escala automáticamente a 480p. Si el frame buffer es menor, entonces interpola pixels, y de ahí la imagen borrosa.

@dirtymagic Vale, acabo de ver que el formato del TLUT o paleta puede ser RGBA o IA, por lo que sí, acepta transparente.

@Señor Ventura No existe "escala de grises" como textura en la N64, sino Intesidad o Intensidad con Alfa. Esta intensidad se refiere al color del triángulo o polígono. Si el triángulo es blanco, el valor 255 será el blanco y el valor 0 será el negro, siendo los valores intermedios una escala de grises. Pero si el triángulo es verde, 255 será el verde puro, 0 el negro y los valores intermedios los pasos de este verde al negro. Y así con otros colores que se pinte como rojo, azul, morado, naranja, etc, y supongo que también si cada vertice es de un color y se hace un degradado.
En cierta forma vendría a ser la "luminosidad", pero luminosidad es erroneo y confuso. Si el triángulo es de color azul oscuro, el valor 255 no va a dar un azul luminoso, solo el mismo azul oscuro.

Hace tiempo @Conker64 mostró un ejemplo de una textura con intensidad en el OoT:


La puerta de la derecha es una textura de Intensidad en espejo. El polígono esta pintado por vertices de marrón y la textura cambia los niveles de intensidad para darle profundidad y relieve a dicho polígono.


Para tener escala de grises, o bien se usa un polígono blanco con textura de intensidad, o una textura de color que solo uses grises.

A decir verdad no soy gurú de las texturas de la N64, pero creo que las de Intensidad trabajan como he dicho.

Sexy MotherFucker escribió:@SuperPadLand yo también te hablo de ésas. Resoluciones nativas de PlayStation:

- 256x240.
- 320x240. La que usa Silent Hill. Pero de ese total sólo rellena 292x224, quedándose 1 marco negro rodeando el área visible del juego:



- 384x240.
- 512x240.
- 640x240.

Etc. Eso en progresivo y NTSC. En entrelazado y PAL varía.

Super Mario 64 también escupe 320x240 y también renderiza unas líneas por debajo, aunque nada tan cantoso como en el Silent Hill.

Realmente N64 y PS manejan rangos de resolución muy similares; son en esencia máquinas de 240p que también hacen sus pinitos en "HD", pero este último no es su hábitat natural. Aunque el tamaño máximo potencial del framebuffer es mayor en N64 que en la Play.

Luego, también en Nintendo 64, está todo lo que escale el "VI", pero yo ahí ya me pierdo, ya que nos salimos de lo " Nativo".

Bueno pues me refiero a esa ventana con marco negro de 292x224 que son las res "raras" que sacaba yo en emulador al hacer screenshots sin adulterar al principio. Después como quedbaan como el culo en el blog puse que fuese transformado a 320x240

@EMaDeLoC
Sí así funciona las texturas en I y IA.
@Señor Ventura
Las texturas que ocupan los 4KB son
64*32 16 bits
128*64 I4 ( 16 niveles de intensidad de grises fijas)
128*64 IA4 (8 niveles de intensidad de grises fijas más 1 bit alfa)
64*64 I8 ( 256 niveles de gris)
64*64 IA8 ( 16 niveles de intensidad de grises fijas y 16 niveles de alfa)
64*64 IHQ ( mezcla de una textura de 64*64 I4 con una de 32*32 16 bits permitiendo una textura de 64*64 con 16 bits de color, necesita 2 cycles en el RDP)
Obviamente puede cambiar la proporción de la textura, pero en potencias de 2 si se quiere repetir o espejar.

Salud.

@SuperPadLand yo recuerdo que una vez te pregunté sobre la resolución de algunas conversiones de CAPCOM para PlayStation y tu emulador daba 368x224. Pero en realidad son 384x240p con recortes en negro.

Sexy MotherFucker escribió:@SuperPadLand yo recuerdo que una vez te pregunté sobre la resolución de algunas conversiones de CAPCOM para PlayStation y tu emulador daba 368x224. Pero en realidad son 384x240p con recortes en negro.

Es que las capturas según como configures te saca solo la imagen gameplay pura o con los bordes negros, en N64 incluso podías elegir captura desde chip gráfico o como se llame o en la salida de vídeo. Con el segundo método sacas 320x240 o resoluciones estandar, con el primer es donde vi las resoluciones raras de N64 stock y también de los hi res, por ejemplo FZero iba a 296x208 y fue la más baja que me tope del catálogo que elegí para el top. En esos años tenía mucho tiempo para mirar esas cosas, ahora tiro palante total la mayor parte de la gente aunque se lo des masticado tampoco hace caso y yo no necesito esos datos para nada.

EMaDeLoC escribió:Pregunta: ¿se pueden usar todas las texturas de 8 bits que quieras con una sola paleta, e incluso solo tener que cargar la paleta una vez por frame usandola para todas las texturas?

La pregunta va también para @Conker64

Sí, dirtymagic ya comentó pero además añado que subir textura y subir paleta funciona por 2 vías distintas, la textura usa los comandos load_tile o load_block, y la paleta load_tlut.

Puedes conservar la paleta tanto en 8bit como en 4bit, a lo largo del hilo puse un ejemplo del Goldenaxe II de Mega Drive, que usa 16 colores para todo el layer, así que solo cargué la paleta 1 vez para dibujar todos los tiles del scroll.

Uno de los parámetros es decirle desde que punto de la tabla empieza, con eso podrías recorrer las 256 entradas.

Con lo que quiero decir, que no solo puedes tener diferentes texturas 8bit para 256 colores, también puedes almacenar 16 paletas distintas para 16 texturas (o más) de 4bit también, y dejarlas en memoria si es suficiente, o incluso usar texturas de 4 y 8 bit, de una misma entrada de 256 posiciones.

O no necesariamente subir 256 colores, si una textura de 8bit solo tiene 40 colores, se puede subir solo esa cantidad, el resto no se refrescan, pero tampoco se van a usar.

dirtymagic escribió:@EMaDeLoC
Sí así funciona las texturas en I y IA.
@Señor Ventura
Las texturas que ocupan los 4KB son
64*32 16 bits
128*64 I4 ( 16 niveles de intensidad de grises fijas)
128*64 IA4 (8 niveles de intensidad de grises fijas más 1 bit alfa)
64*64 I8 ( 256 niveles de gris)
64*64 IA8 ( 16 niveles de intensidad de grises fijas y 16 niveles de alfa)
64*64 IHQ ( mezcla de una textura de 64*64 I4 con una de 32*32 16 bits permitiendo una textura de 64*64 con 16 bits de color, necesita 2 cycles en el RDP)
Obviamente puede cambiar la proporción de la textura, pero en potencias de 2 si se quiere repetir o espejar.

Salud.

Ya veo... no permite 8 bits y 4 bits de color a mayores resoluciones.

@Misscelan

El coste mínimo por transparencia es similar al de n64, sin coste si se encuentra en la cache de texturas

Precisamente en Digital Foundry explicaron que la niebla del Silent Hill 2 de PlayStation 2 es más densa y de mejor calidad que la de la versión para Xbox por eso mismo: la memoria de vídeo de la Ps2 es una caché EDRAM de 4MB con un bestial ancho de banda, y todas las capas de transparencia para los polígonos de la niebla y esas movidas que habéis explicado le salían GRATIS. Por eso aunque la GPU de Xbox le da 5 vueltas a la de Ps2, ese tipo concreto de efectos de Backbuffer/frontbuffer la Sony los hace al vuelo, en cantidades industriales, y sin coste, mientras que el NV2A de la caja porno consume muchos ciclos al generarlos de forma externa.



Volviendo a Nintendo 64, qué duda cabe que acogería un SH con unos gráficos mucho más orgánicos que en PlayStation.

Y falta le hacía; ya que fue una consola que en 5 años de vida sólo acogió un/1 Survival Horror: Resident Evil 2. Encima 1 año y pico más tarde que en la competencia . Qué HAMBRE pasaron los pobres usuarios de N64 amantes de este género en los 90. Bueno de éste y otros muchos...

Mientras tanto, en la Sony: saga Resident al completo desde 1996. Silent Hill. Para site Eve 2. Dijo Crisis saga. Gallerians. Countdown Vampires. Etc, etc, etc. PlayStation acogía como siempre a todo el mundo.

Vale, vale. Me tomo la pastilla y me voy a acostar

@Sexy MotherFucker si aceptas Galerians como Survival horror en N64 puedes considerar survival horror a Nightmare Creatures, Shadowman, los Castlevanias y Doom 64.

@SuperPadLand NC: hack and slash. ShadowMan plataformas/shooter de exploración. Castlevania lo mismo. Doom FPS.

¿Gallerians qué sería?

Sexy MotherFucker escribió:@SuperPadLand NC: hack and slash. ShadowMan plataformas/shooter de exploración. Castlevania lo mismo. Doom FPS.

¿Gallerians qué sería?

Es un RPG, todos tienen en común la estética oscura o como quieras llamarlo, si consideras a uno juego de "miedo" pues van todos. De hecho creo que en playmania metieron al Shadowan en un reportaje de "mejores juegos de terror" de PS1.

@SuperPadLand yo jugué al de Ps2; ¿es más o menos igual?

@Sexy MotherFucker Si gustaban los fps y los plataformas pues la elección era evidente, también la calidad importa y en ciertos géneros era una diferencia abismal, los Banjoo eran brutales y algo simplemente irreproducible o reproducible con unos resultados esperpénticos.
Igual en rpgs pues ahí si que se paso hambre, y en otros tantos géneros, tampoco hay que ser fanboy, yo heche de menos un strifa y otros tantos, sobretodo el resistent, el primero, yo jugué al 2 en la 64 y años después jugué al uno y para mí es el Mario 64 de los survivals, el ejemplo a seguir, el puto amo
hicieron un gran trabajo con quake II pero aún así goldeneye era una exhibición, en texturas, control, fluidez, animaciones, IA, a años luz con mecánicas solo al alcance del mundo del pc, para igualar a eso no hay subdivisiones ni trucos que valgan y los escenarios de PD disiparon cualquier duda al respecto.
PlayStation ganó por méritos propios, un gran catálogo de ensueño, pero la N64 fue una gran consola también, innovadora y capaz de lucharle de tu a tu a esa apisonadora incluso torciendole el brazo en no pocas ocasiones.
Midway con ese tardío Rush2049 que a veces queda eclipsado por el WDC, yo creo que no se pone en la balanza los saltos, físicas de impactos, incluso el viento, estos elementos solo estaban presentes arcades, aún el primer Rush 64 ya tenía todas estás características y por poner en perspectiva ponemos poner de ejemplo en primer Rush de ps1 y ver como gestiona todo.

@Segastopol la diferencia es que incluso en los escasos géneros en que Nintendo 64 era la mejor, PlayStation SIEMPRE ofrecía una contraoferta sobresaliente para que nadie se quedase insatisfecho, mientras que al revés eso no pasaba en muchísimos géneros.

Esa es la diferencia; en la Play había oferta de calidad para cualquier gusto. En N64 no, y encima escasa. Luego a no ser que seas un nintendero cerrado, o sólo te gusten 2-3 géneros en concreto de los que tiene fuertes, Nintendo 64 nunca debería ser la consola con la que encerrarse en un búnker nuclear para nadie con un mínimo de sensatez.

Pero bueno esto es 1 hilo técnico, no lo desviemos. Culpa mía por sacar el tema

Sexy MotherFucker escribió:@Segastopol la diferencia es que incluso en los escasos géneros en que Nintendo 64 era la mejor, PlayStation ofrecía una contraoferta sobresaliente para que nadie se quedase insatisfecho, mientras que al revés eso no pasaba en muchísimos géneros.

Esa es la diferencia; en la Play había oferta de calidad para cualquier gusto. En N64 no, y encima escasa.

Pero bueno esto es 1 hilo técnico, no lo desviemos. Culpa mía por sacar el tema

No pasa nada, si es innegable.
Y se agradecen tus post

Reconduciendo:



Nada mal el frame-rate eniendo en cuenta que este juego emplea la Nintendo 64 muy a fondo; 10 frames en la cinemática con lluvia a nivel partículas me parecen hasta muchos.

Conker64 escribió:

EMaDeLoC escribió:Pregunta: ¿se pueden usar todas las texturas de 8 bits que quieras con una sola paleta, e incluso solo tener que cargar la paleta una vez por frame usandola para todas las texturas?

La pregunta va también para @Conker64

Sí, dirtymagic ya comentó pero además añado que subir textura y subir paleta funciona por 2 vías distintas, la textura usa los comandos load_tile o load_block, y la paleta load_tlut.

Puedes conservar la paleta tanto en 8bit como en 4bit, a lo largo del hilo puse un ejemplo del Goldenaxe II de Mega Drive, que usa 16 colores para todo el layer, así que solo cargué la paleta 1 vez para dibujar todos los tiles del scroll.

Uno de los parámetros es decirle desde que punto de la tabla empieza, con eso podrías recorrer las 256 entradas.

Con lo que quiero decir, que no solo puedes tener diferentes texturas 8bit para 256 colores, también puedes almacenar 16 paletas distintas para 16 texturas (o más) de 4bit también, y dejarlas en memoria si es suficiente, o incluso usar texturas de 4 y 8 bit, de una misma entrada de 256 posiciones.

O no necesariamente subir 256 colores, si una textura de 8bit solo tiene 40 colores, se puede subir solo esa cantidad, el resto no se refrescan, pero tampoco se van a usar.

Ostras, pues eso da muchas posibilidades. Esogiendo bien la paleta artística de los niveles y ordenando paletas de 16 colores en una mayor de 256 con todos los colores distintos, habría texturas de 16 colores de 64x64 y de 256 colores de 32x32 o 43x43. Es decir, habría gran cantidad de detalle con un coste reducido de espacio de RAM y cartucho (255 texturas y una paleta en 512KB, y sin comprimir) y consumiendo poco ancho de banda de RAM (menos de 2 milisegundos de transferencia).

Eso si, necesitaría un gran esfuerzo y coordinación para condensar todo el apartado artístico del nivel en una paleta de 256 colores y también limitaría las posibilidades de variedad cromática, además de alargar el desarrollo.

Sexy MotherFucker escribió:@SuperPadLand yo jugué al de Ps2; ¿es más o menos igual?

La secuela no la jugué, creía que ayer te habia puesto un vídeo de un combate del de PS1, te lo paso ahora: https://youtu.be/acpf76CJ4NI?t=518

El de PS1 lo que tiene de miedo es más que nada lo susceptible que fueras de enano a su historia porque todos sabemos que pensar en seres humanos con poderes psíquicos mortales pues da cague, pero vamos que no deja de ser como decir que el primer Parasite Eve es un Survival Horror. Porque sino hasta la mansión bo de Mario 64 es de miedo.

EMaDeLoC escribió:

Conker64 escribió:

EMaDeLoC escribió:Pregunta: ¿se pueden usar todas las texturas de 8 bits que quieras con una sola paleta, e incluso solo tener que cargar la paleta una vez por frame usandola para todas las texturas?

La pregunta va también para @Conker64

Sí, dirtymagic ya comentó pero además añado que subir textura y subir paleta funciona por 2 vías distintas, la textura usa los comandos load_tile o load_block, y la paleta load_tlut.

Puedes conservar la paleta tanto en 8bit como en 4bit, a lo largo del hilo puse un ejemplo del Goldenaxe II de Mega Drive, que usa 16 colores para todo el layer, así que solo cargué la paleta 1 vez para dibujar todos los tiles del scroll.

Uno de los parámetros es decirle desde que punto de la tabla empieza, con eso podrías recorrer las 256 entradas.

Con lo que quiero decir, que no solo puedes tener diferentes texturas 8bit para 256 colores, también puedes almacenar 16 paletas distintas para 16 texturas (o más) de 4bit también, y dejarlas en memoria si es suficiente, o incluso usar texturas de 4 y 8 bit, de una misma entrada de 256 posiciones.

O no necesariamente subir 256 colores, si una textura de 8bit solo tiene 40 colores, se puede subir solo esa cantidad, el resto no se refrescan, pero tampoco se van a usar.

Ostras, pues eso da muchas posibilidades. Esogiendo bien la paleta artística de los niveles y ordenando paletas de 16 colores en una mayor de 256 con todos los colores distintos, habría texturas de 16 colores de 64x64 y de 256 colores de 32x32 o 43x43. Es decir, habría gran cantidad de detalle con un coste reducido de espacio de RAM y cartucho (255 texturas y una paleta en 512KB, y sin comprimir) y consumiendo poco ancho de banda de RAM (menos de 2 milisegundos de transferencia).

Eso si, necesitaría un gran esfuerzo y coordinación para condensar todo el apartado artístico del nivel en una paleta de 256 colores y también limitaría las posibilidades de variedad cromática, además de alargar el desarrollo.

No sé en 3D, pero en juegos 2D 256 colores bien elegidos pueden dar buen jugo. Además imagino que se podrá hacer algún truco del almenduco para de esos 256 sacar varias tonalidades diferentes y multiplicar. Y en 3D para cartoon o cell shading también no?

SuperPadLand escribió:No sé en 3D, pero en juegos 2D 256 colores bien elegidos pueden dar buen jugo. Además imagino que se podrá hacer algún truco del almenduco para de esos 256 sacar varias tonalidades diferentes y multiplicar. Y en 3D para cartoon o cell shading también no?

Con la N64 se pueden mezclar colores con el filtrado bilinea, aunque no da como para dar un color nuevo ni este color tendría el tamaño del pixel de los colores de origen. Osea, no veo factible esa posibilidad.

Otra cosa es usar el Color Combiner para alterar los colores existentes y crear otros efectos. Mismamente, transicionar una textura de hierba verde a hierba seca según se multiplique o divida el color.
Luego aparte tenemos gourad y pintado por vertices con el que se pueden conseguir distintos efectos.

Para una estética cartoon se necesitan pocos colores. Puede que 32 o 64 sean suficiente. Al fin y al cabo son paletas muy reducidas. Quizá con texturas de 16 colores o de 8 con transparencia hay de sobra para ciertos modelos o sprites.

@Conker64 Creo que no has visto lo que decía antes del Color Combiner para unas texturas de rejilla de Silent Hill. ¿Lo ves posible? Yo he visto videos de Kaze creando patrones de copos de nieve en los que se revela el polígono, por lo que un patrón de rejilla aplicado a toda la textura no me parece ninguna locura. Permitiría usar una textura genérica de panel de hierro oxidado como si fuese una rejilla de distinto tipo (de valla, de suelo, etc) en la que cambiando las coordenadas muy poco daría variedad, haciendo que dos rejillas no fuesen iguales.

@EMaDeLoC
¿Con lo de la rejilla te refieres a esto?

Es una textura de 64x64 en I4 de la rejilla con los remaches mezclada con 2 texturas de 32x32 de 16 bits para darle color de fondo.

Salud.

Sexy MotherFucker escribió:Reconduciendo:

Nada mal el frame-rate eniendo en cuenta que este juego emplea la Nintendo 64 muy a fondo; 10 frames en la cinemática con lluvia a nivel partículas me parecen hasta muchos.

Otro que captura el NTSC-J de las consolas como NTSC-M y queda todo oscurecido

@dirtymagic Si, eso, pero creo que se puede hacer con el Color Combiner y se tendría la ventaja de ahorrar una textura y que con solo variar un par de parámetros se puderian hacer varisa variaciones de rejilla. Creo que también permitiría que no hubiese límite de resolución, los huecos no se verian pixelados o con degradado de transparencia por mucho que se acercara la cámara a la rejilla. Y no estoy del todo puesto, pero creo que usar solo el CC es más barato en rendimiento que mezclar dos texturas.

@radorn hola que es NTSC-M?

@EMaDeLoC
¿Puedes enlazar el vídeo de Kaze donde dices que hace eso?
Salud.

@dirtymagic







Viendolo ahora, parece que se aplica por pixel de la textura, así que no tendría el zoom infinito que decía, pero igualmente parece más limpio que una simple textura con pixeles transparentes.