Hilo de detalles y curiosidades de N64

@Sexy MotherFucker Pero a n64 y saturn les duelen cosas diferentes.

Mi impresión es que dependiendo del escenario, a sprites puros n64 es superior, y con escenarios complejos, forzando perspectivas hacia el horizonte y mucha variedad de texturas, a sprites puros saturn sería superior... algo así.

@Señor Ventura yo sólo puedo hablar de mi experiencia con el catálogo 2D de ambos sistemas; Extensa en Saturn, notable en N64. Y lo que saco en claro es que Nintendo 64 gana la batalla de las transparencias y permite unos efectos "por pixel" usando color combiner y sus movidas mucho más orgánicos que en SS. Ahora también te digo; "Traya" en pantalla, escalados/rotaciones de cualquier cosa, sonido, sofisticación de fondos, etc. De momento me quedo con Saturn.

Por supuesto tengo presente el contexto de las limitaciones de ROM de N64 en la época, los mejores accesos del formato cartucho, y el uso más flexible de la RAM en la Ninti como bien ha explicado @Conker64 en la página anterior

@Sexy MotherFucker Sutil xDD

Yo no he jugado a ambas, pero si se pueden ver cosas.



edit: ¿No hizo conker una demo del metal slug corriendo a 60fps?, del castlevania sotn seguro, pero algo se habló del metal slug, y no se si se hizo algo.

Este vídeo es interesante tanto por el item raro que intentan replicar, como por la información técnica que se da de un periférico que precisamente suele descuidarse, el controller pak.

@EMaDeLoC Vi ese video ayer.

Artículo de una de las viejas webs de la scene que habla del CPak gigante de Datel mencionado en el video con versiones de 4 y 1 MiB (MebiBytes no Mebibits):
https://64scener.com/n64-datel4megcontrollerpak.php

Lo que no explican es por qué un mero mensaje de texto ocupa 26KB, no me importa si son KibiBytes, Kibibits, MegaBytes o Megabits, cualquiera de ellos me parece excesivo. Pensé que quizá es que la carta estaba guardad como imagen, pero luego explican el proceso de cómo la escribieron y resulta que tuvieron que usar kanas en vez de kanjis porque el conjunto de caracteres del juego no tiene kanjis, así que es texto digital, no una imagen...
26K para cuatro lineas cortas de texto... ¿cómo se explica eso?

Las carencias del chip de sonido lo suplen con arte
Acompañado de un entorno 3D fuera del alcance de la competencia,

radorn escribió:26K para cuatro lineas cortas de texto... ¿cómo se explica eso?

¿Anotaciones?.

Señor Ventura escribió:¿Anotaciones?.

Explíquese usted mejor, caballero, que no le entiendo.

Segastopol escribió:Las carencias del chip de sonido lo suplen con arte

¿Que carencias?
La N64 ni siquiera tiene hardware dedicado para sintetizar sonido: mezcla audio en un proceso combinado entre la CPU y el RSP dentro del RCP, lo que resulta en un búfer de audio de 16bit de frecuencia de muestreo variable, que es enviado a al DAC.

radorn escribió:Lo que no explican es por qué un mero mensaje de texto ocupa 26KB, no me importa si son KibiBytes, Kibibits, MegaBytes o Megabits, cualquiera de ellos me parece excesivo. Pensé que quizá es que la carta estaba guardad como imagen, pero luego explican el proceso de cómo la escribieron y resulta que tuvieron que usar kanas en vez de kanjis porque el conjunto de caracteres del juego no tiene kanjis, así que es texto digital, no una imagen...
26K para cuatro lineas cortas de texto... ¿cómo se explica eso?

Hay cierta catidad de espacio del CP que se desperdicia en formateo de datos, tablas, etc. Lo explican sin profundizar en el vídeo anterior.
Por lo que tengo entendido, hay cartas dentro del juego que van saliendo según eventos, y se habrán basado en alguna de estas cartas para hacer la suya. Pero claro, estas cartas "disfrutan" de más espacio (sin perder de vista que es un cartucho) y s posible que vengan en un formato determinado que ocupe mucho aún siendo simple texto. Como no parece que se hayan dedicado a hacerle ingeniería inversa al formato para intentar ahorrar espacio, simplemente han creado una carta dentro del juego y copiado el bloque de memoria donde está para guardarla luego en el CP. Vamos, deduzco por el vídeo que lo han hecho así.
Quizá se pueda guardar cartas en menos espacio, quizá el CP que intentan recrear era solo de 32KB y el juego reconstruye la carta a partir de solo texto sin formato que ocupa mucho menos. O quizá el formato es ferreo, incluye varias páginas de cartas en blanco que no se pueden quitar y no se preocupa en ahorrar espacio y sí o sí te comes 26KB.

radorn escribió:¿Que carencias?

Un troll va diciendo por ahí que la ausencia de chip de sonido en la consola es una chapuza.
No le des ninguna importancia.

@EMaDeLoC Conozco el formateo del CPak. De hecho hace años trasteé con el en un editor hexadecimal, el plugin de control para emuladores N-Rage (del que existían múltiples versiones), el Adaptoid para conectar mandos de N64 a PC por USB, que tenía un driver de 32bit para copiar y pegar notas desde el navegador de windows a formato "a64" (un formato de texto que representaba guardados de CPak, con ciertas limitaciones, y total falta de soporte para guardados japoneses, también compatible con el plugin N-Rage)... en fin, que hice cosas

El CPak, como sabemos, tiene 32KiB o 32768 Bytes. Esto se dividen en 128 "páginas" de 256Bytes cada una, de las cuales las primeras 5 son el "formato", quedando 123 libres para su uso en "notas" de juego. El sistema de ficheros del CPak, por así decirlo.
Si no recuerdo mal, la primera página era una cabecera que nunca entendí bien, luego hay dos páginas que contienen un mapa de las páginas ocupadas, repetido por redundancia, y las últimas dos páginas las 16 entradas de las "notas" de juego, cada una 32bytes.

Por cierto que usaron el mismo sistema para las tarjetas de memoria en GC:
Memory Card 59 es resultado de que 64 bloques totales, menos 5 para sistema, dejan 59 para guardados.
Así mismo:
251 = 256 - 5
1019 = 1024 - 5
2043 = 2048 - 5

Pero todo eso no tiene nada que ver con mi asombro por el tamaño que parece ocupar la dichosa cartita.

Yo no se cómo funcionan los datos guardados de AC/AF/DnM, pero entiendo que tiene chip de guardado interno, probablemente o S-RAM o Flash, y una batería para el reloj interno. Por lo visto también usa el CPak para cosas adicionales. Si me dijeran que es que para guardar una carta hay que guardar la partida entera y por eso ocupa 26K (104 páginas... si asumimos 26K justos, que tampoco lo aclaran), pues vale, aunque no le encuentro mucho sentido porque entonces significaría que la famosa carta de tezuka vendría acompañada de una partida entera del juego que presumiblemente reemplazaría la del jugador... no se.

A mi 26KiB me parece una exageración simplemente para contener una carta de 4 o 6 lineas de texto de pocos caracteres que perfectamente podrían caber en una sola página, dos como mucho. Y esto no tiene nada que ver con el formateo del CPak. Para que tenga sentido, tengo que pensar que contiene algo más, pero en el video no dicen que contenga otra cosa que la carta. Y en mi desconocimiento de la franquicia Animal Crossing, pues...

No presentan el fichero de 26KiB con toda naturalidad como que es "la carta", pero yo no le encuentro sentido. Tiene que haber algo mas que no explican en el video.

radorn escribió:

Señor Ventura escribió:¿Anotaciones?.

Explíquese usted mejor, caballero, que no le entiendo.

¿Que no solo contenga código?...

No estoy entendiendo una mierda, pero teniendo 32kb de memoria no podrían haberlo usado de tarjeta de memoria para guardar partidas?

@SuperPadLand Podrían, pero el juego tiene guardado interno igualmente. No recuerdo de qué tipo, seguramente S-RAM de 32K (igual que el CPak) o Flash 128K Podría ser SRAM porque el juego ya lleva una pila para el reloj interno.
En cualquier caso, Nintendo siempre puso guardado interno en sus juegos propios, nunca dependió del Controller Pak.
No veo probable que fueran a depender del CPak como metodo de guardado principal, y menos en un juego como Animal Crossing. A Nintendo le gusta controlar al jugador, no los veo poniendo las partidas del juego en un medio transferible...

El CPak fue usado principalmente por terceros para ahorrarse el coste del chip de guardado en el cartucho.

radorn escribió:@SuperPadLand Podrían, pero el juego tiene guardado interno igualmente. No recuerdo de qué tipo, seguramente S-RAM de 32K (igual que el CPak) o Flash 128K Podría ser SRAM porque el juego ya lleva una pila para el reloj interno.
En cualquier caso, Nintendo siempre puso guardado interno en sus juegos propios, nunca dependió del Controller Pak.
No veo probable que fueran a depender del CPak como metodo de guardado principal, y menos en un juego como Animal Crossing. A Nintendo le gusta controlar al jugador, no los veo poniendo las partidas del juego en un medio transferible...

El CPak fue usado principalmente por terceros para ahorrarse el coste del chip de guardado en el cartucho.

Eso son algunos juegos no todos, otros necesitaban de tarjeta de memoria para guardar, otros como MK y Diddy Kong usan la memoria para guardar los fantasmas, etc. Traer un sistema de guardado de serie y compartido para todo les permitiría fabricar sus juegos más baratos sin esa RAM y esa pila extra y también ayudaría a las third a no depender de encarecer su placa o forzar al jugador a comprar una tarjeta extra para poder jugar a lo suyo. Todo ello sin impedimento de que en determinados juegos se diseñasen para no usarlo como ese Animal Crossing de ser necesario para Nintendo.

Es que me parece raro que Nintendo haya gastado en memoria en este addon y la haya dejado sin usar cuando le permitiría mejorar su propio margen de beneficios vendiendo sus juegos al mismo precio, pero sin añadirle memorias y pilas.

Lo qu no sé es si 32kb son un espacio suficiente para guardar varios saves.

@SuperPadLand En los pocos juegos en los que Nintendo usó el CPAK su utilidad casi siempre estuvo orientada a datos secundarios, no como método principal de guardado. Todos los juegos de Nintendo y Rare usan chip interno en cartucho como método principal de guardado, y la mayoría de ellos no usan el CPAK en absoluto.

radorn escribió:@SuperPadLand En los pocos juegos en los que Nintendo usó el CPAK su utilidad casi siempre estuvo orientada a datos secundarios, no como método principal de guardado. Todos los juegos de Nintendo y Rare usan chip interno en cartucho como método principal de guardado, y la mayoría de ellos no usan el CPAK en absoluto.

Lo sé, pero no quita que el hardware que tenemos en casa todos, incluye en el jumper 32kb de memoria que podrían haber sido una tarjeta de memoria que el usuario no tuviera que comprarse aparte. Y hay juegos de Nintendo&Rare que usan estas memorias aparte de para guardar.

SuperPadLand escribió:

radorn escribió:@SuperPadLand En los pocos juegos en los que Nintendo usó el CPAK su utilidad casi siempre estuvo orientada a datos secundarios, no como método principal de guardado. Todos los juegos de Nintendo y Rare usan chip interno en cartucho como método principal de guardado, y la mayoría de ellos no usan el CPAK en absoluto.

Lo sé, pero no quita que el hardware que tenemos en casa todos, incluye en el jumper 32kb de memoria que podrían haber sido una tarjeta de memoria que el usuario no tuviera que comprarse aparte. Y hay juegos de Nintendo&Rare que usan estas memorias aparte de para guardar.

¿A que te refieres con que el jumper tiene 32Kb?¿el Jumper Pak,que se usa como la terminación de la memoria RAM?

Salud.

@SuperPadLand Igual que @dirtymagic estoy bastante confuso con lo que pretendes decir aqui.
El Jumper Pak es un terminador del bus RDRAM porque el diseño de ese tipo de memoria lo requiere. Los PCs que salieron con RDRAM, donde la cosa no caló, también necesitaban terminadores en las ranuras vacías, o el PC no podía arrancar.
Ese bus es para RDRAM y nada mas. No sería buen diseño hacer un adaptador para poner algún tipo de memoria no volatil en esa ranura para guardados... Sería caro adaptar el bus RDRAM para leer otro tipo de memoria y luego qué haces si quieres poner un Expansion Pak?

Y en cualquier caso, yo no estoy especulando sobre cómo podría haber sido la consola en un mundo alternativo.
Todo esto empezó con el tema de las cartas de Doubutsu no Mori ocupando 26KiB en el CPAK, que me parece un tamaño exagerado. Por especular comenté la posibilidad remota de que además de la carta incluyese otras cosas, como un backup de la partida entera, cosa que luego pasé a descartar como altamente improbable por la implicación de que eso sobreescribiría la partia del jugador en el cartucho y que además no sería propio de Nintendo el permitir ese tipo de manejo de datos en unjuego first party como ese. El estilo NIntendo es que el mundo del cartucho es el mundo del cartucho y ya. Y eso me deja sin pistas para explicar por qué una dichosa carta de apenas 100 caracteres ocupa 26000 en el CPAK o qué otra cosa podría haber ahí que explique semejante tamaño de datos.

@radorn Es especulación, pero ¿y si realmente hay imágenes en el formato carta del juego?
He echado un ojo rápido y las cartas del Animal Crossing occidental de Gamecube son diferentes de las que muestran en el vídeo. Quizá previendo distintos remites o distintas épocas se guarda dentro del formato carta una imagen comprimida o troceada del papel con una temática concreta. Con el formato que maneja la consola ocuparía pocos KB. Quizá el juego por dentro lo maneja de forma eficiente asignando a varios textos una sola carta, pero debido a la forma que el juego accede por CP y a la creación artesanal que han hecho en el vídeo, han tenido que incluir el formato completo que incluye imágenes.

¿Se sabe si el juego ha sido decompilado? Porque con echar un ojo al código fuente se podría saber.

@EMaDeLoC Si las cartas de guardan como imagen, entonces por qué hablan en el video de la limitación del juego de caracteres disponible?
Además, en el juego, por lo que se infiere de lo explicado, también el usuario puede escribir cartas, y se muestran con el papel especial y toda la pesca, así que el juego tiene capaz de armar una carta a partir de texto y algunos metadatos... ese hecho hace poco razonable pensar que fueran a molestarse en guaradar el resultado gráfico como imagen ya que el juego tiene la capacidad de generarlo.
Nintendo, especialmente en esa época, y con la experiencia en los 8 y 16 bits, era minimalista en ese sentido. Contando bytes. Las cosas solo ocupaban lo estrictamente necesario, usando estructuras de datos super eficientes.
No como Turok 2, que ocupa 90páginas una partida, casi el CPAK entero, y luego miras los datos en un editor hexadecimal y parece usar palabras de 32bit para todo: resultando en datos de un solo byte precedidos de 3 bytes a cero. Un desperdicio enorme de espacio para nada.

Mira los tamaños de los guardados en cartucho:
EEPROM 4Kibit = 512 bytes
EEPROM 16Kibit = 2048 bytes / 2KiB
S-RAM 256Kibit = 36768 bytes / 32KiB
S-RAM 768kibit = 98304 bytes / 96KiB (solo usado en Dezaemon 3D, que yo sepa)
FlashRAM 1024 kbits / 1 Mib = 131072 bytes / 128KiB (como una tarjeta de PS1, aunque esas son EEPROM, que me gusta un poco mas que el Flash por durabilidad, aunque quizá me equivoque)

DnM usa S-RAM 32KiB en cartucho, igual que el CPAK (aunque el chip es diferente). Imagino que en el juego también se almacenarán cartas en el cartucho, y que las metes en el CPAK solo cuando las quieres pasar a otro jugador. Me cuesta pensar que con todo lo que debe necesitar guardar ese juego vaya a sacrificarlo todo por una sola cartita.

En fin, yo por mi lo dejo aqui. Mis objeciones y observaciones creo que han quedado claras.
Dejé un comentario en el video, a ver si lo ven y me explican el misterio.

@dirtymagic @radorn os entendí yo mal, creía que habían descubierto 32kb de memoria en el jumper y por eso mis preguntas.

@radorn No me has entendido. No digo que se guarde como imagen la carta entera incluyendo lo escrito, digo la parte del fondo, lo que vendría a ser el papel. El texto serian caracteres normales que luego el juego se encarga de pintar encima de la carta.
Lo habrían hecho así precisamente para soportar cartas personalizadas venidas en CP, o quizá incluso para escribir y pasar cartas por CP normales entre amigos.

https://www.youtube.com/watch?v=0cpjhIS ... LLKQL3t2Qj

@radornkeldam
1 day ago
How is a simple text message 26KiB, anyway?
Maybe this is known to Animal Forest/Crossing fans, but I never liked the series, I'm just here for the N64 tech stuff.

@Scorbunnyear
16 hours ago (edited)
⁠​⁠​⁠ @radornkeldam It requires a letter data file that’s made to store 160 letters. Even if you only have 1 letter in it, you still need the full 103 pages/26KiB of space.

@radornkeldam
1 minute ago (edited)
@Scorbunnyear Thanks for answering.
The thing is I don't play AC/AF/DnM. So I'm a little liost. Why does it "still need the full 103 pages"? What is being stored besides the letter? What does DnM on N64 store on the controller pak that requires all that space? Doesn't the cartridge have internal S-RAM for saves and an RTC? Is it backing up a compressed copy of all the town data or something? Or is it that the CPAK is treated like a big bag to carry things around to other players' homes, snd it makes a big file where you can put a lot of different items?

Creo que me he respondido a mi mismo extrapolando lo que me cuenta este amable comentarista.

Parece ser, como sucede en otros casos, que, siguiendo otra de las prácticas habituales de nintendo, el juego crea una única nota en el CPak que funciona como maleta enorme para transferir cosas entre "ciudades" (cartuchos), de forma que la funcionalidad del juego no se vea limitada por tener otras cosas en el CPak. Recordemos que en el CPak solo puede haber 16 notas individuales, incluso si todas ellas fueran de 1 página, y sobrasen muchas páginas, al no haber entradas libres para notas, se desperdician. Probablemente el archivo de CPak de DnM (Doubutsu no Mori) permita llevar un montón de cosas de un "pueblo" a otro: El personaje para que vaya de visita, mercancías, cartas... que se yo. El archivo del CPak lo ponen por defecto lo suficientemente grande para abarcar toda la funcionalidad que quieren proporcionar en estos intercambios, en vez de usar una nota de CPak para cada cosa, que lo limitaría a 16.
Por lo que recuerdo muchos juegos solían hacer esto: Por ejemplo, Goemon ofrecía tres ranuras de guardado, pero juntaba las tres en una única nota de CPak, en vez de una para cada uno, a lo PS1.

Así que la carta es solo texto, como corresponde lógicamente, pero se guarda en un archivo contenedor con espacio para muchos mas items. Caso resuelto.

Por cierto que las 103 páginas de las que me habla este usuario de YouTube, a 256bytes cada una, dan 25,75 KiB, no 26KiB, pero en fin, detalle menor

Física de movimiento en tiempo real en N64.

doblete escribió:Física de movimiento en tiempo real en N64.

Le he cotilleado otros vídeos de ese juego que está haciendo y es muy top

SuperPadLand escribió:

doblete escribió:Física de movimiento en tiempo real en N64.

Le he cotilleado otros vídeos de ese juego que está haciendo y es muy top

Para mi esta es la primera vez que veo imágenes en movimiento del juego que esta desarrollando .

@doblete tiene este otro:

Esas texturas chaval...

Zoinkity jaquiando las patillas de audio analógico de la ranura cartucho/expansión de N64



Esta es la tipica cosa que normalmente os estaría aclarando yo a vosotros, pero... Sabeis si algun cartucho, accesorio, o lo que sea, llegó a usar las patillas de audio analógico? Se me ocurre que quizá el WideBoy64 las usase, para pasar el audio directamente sin tener que hacer búfer digital. Puede incluso que lo haya leído en alguna parte alguna vez, pero no estoy seguro

@radorn ni idea, pero se puede acceder a ellas desde la ranura superior? Porque en caso contrario, el catálogo de candidatos que pudieron usarlo se reduce a los del 64DD no?

@radorn Pues es muy posible que lo usase el WideBoy64 para sacar el audio.
Placa del WideBoy64:


Yendo a la foto en resolución original, se puede ver que el pin 49, del audio derecho, esta siendo usado, y parece que hay una vía que lleva al pin 24, audio izquierdo, que está al otro lado.

Estaría bien que se usaran en futuros cartuchos homebrew para sacar música. El problema es que los pines van directos al amplificador que hace las veces de mezclador y son de audio analógico, y todos los mods HDMI cogen el audio digital directamente del RCP. Así que las consolas con salida HDMI se quedarian sin ese audio si no conectan el analógico de otra forma.

Tema aparte, veo que el WideBoy64 usa el CIC 6102A. Supongo que será una variación mínima del 6102 que usan la mayoría de juegos NTSC.

SuperPadLand escribió:@radorn ni idea, pero se puede acceder a ellas desde la ranura superior? Porque en caso contrario, el catálogo de candidatos que pudieron usarlo se reduce a los del 64DD no?

Los pines tanto de arriba como de abajo estan directamente conectados. Para seleccionar cartucho o 64DD se usan direcciones de memoria reservadas. Como dato extra, al encender la N64 siempre comprueba si el 64DD esta conectado, si no pasa al cartucho.

@SuperPadLand como te dice @EMaDeLoC , las patillas de arriba y abajo son las mismas, pero en orden inverso. Si alguna vez abres una N64, encontrarás que el conector de cartucho superior es extraible y tiene unas largas patillas que encajan en el conector inferior, que es el que está soldado a la placa. Ya no tengo el hardware para comprobarlo personalmente, pero recuerdo que habían un par de patillas como por la mitad del conector superior que no están conectadas a nada. Quizá me equivoque en esto, pero creo que incluso viendo el conector desde fuera se puede apreciar la falta de esas patillas.

Pero no son las de Audio analógico. Esas están conectadas arriba y abajo y ciertamente se podrían aprovechar para añadir hardware de audio extra en un cartucho a medida, con el inconveniente que señala también EMaDeLoC respecto a los mods de audio y video digital. Si se añadiese audio analógico a un cartucho, un mod AV digital tendría que añadir un ADC (Analog to Digital Converter) conectado a esas patillas de audio, para digitalizarlo y luego mezclarlo con el audio digital habitual del RCP... mucha complicación.

Respecto a lo del 6102A... no lo puedo decir con seguridad, pero yo tuve algún cartucho NTSC en su momento, y creo que tambíen ponía A, así que no creo que sea otra cosa que un 6102 normal. Sería una revisión interna que no afecte al protocolo. No se si habrá un CIC-NUS-6012 sin A o incluso un CIC-NUS-6012B o C o lo que sea. No lo se, pero de existir, seguramente sean funcionalmente idénticos.

@radorn Hay huecos en el slot sin contactos pero a su vez hay un hueco sin pines en la placa base. El resto de pines están conectados a algo, sea funciones, voltajes o masa.

Sobre el CIC, haciendo una segunda búsqueda aparece en otros juegos. Será como dices, una revisión menor que no cambia nada en la comunicación externa.

C&P esto que puse en otro hilo sobre FMV en N64:

En N64 el problema era el tamaño, hoy en día han sacado virguerías, de hecho es la única consola de su gen capaz de mover el formato H264 que apareció en el 2003:



En el último vídeo hay varias demos, puse el minuto de esa porque me parece la más molona. Y en este vídeo de aquí las mismos demos en mpge1 que creo es lo que usaba PS1 nativamente (son de una competición del 2022 de SegaXtreme por si quieres leer más): https://www.youtube.com/watch?v=NDj0BP5JaTc

No me hagais mucho caso, pero creo que el manejo de vectores del RCP es ideal para descomprimir video en MPEG o similares.
El problema es el espacio que sigue ocupando a pesar de la compresión. Por eso en RE2 fueron tan agresivos recortando los videos.

EMaDeLoC escribió:No me hagais mucho caso, pero creo que el manejo de vectores del RCP es ideal para descomprimir video en MPEG o similares.
El problema es el espacio que sigue ocupando a pesar de la compresión. Por eso en RE2 fueron tan agresivos recortando los videos.

En el hilo el autor puso esto de cada demo:

LIVE​
Video: 288x208, 24FPS, 550Kbps (22 Mb)
Audio: 44100Hz, Stereo, uncompressed
No big problems here. The bitrate is a bit lower than others because I felt like it really needed at least 24 FPS. It's not super beautiful but not bad.


ANIM​
Video: 320x176, 12FPS, 1000Kbps (11 Mb)
Audio: 44100Hz, Stereo, uncompressed
Given this is hand-drawn animation, the actual framerate is very low, so I lowered the framerate and bumped bitrate. To me, this looks very good (also the damning moving star scene). It's also at the x264 theoretical encoding perfection bitrate-wise (at this resolution/framerate), because it's using the highest quality setting, unconstrained.


CGI​
Video: 320x176, 20FPS, 700Kbps (14 Mb)
Audio: 44100Hz, Stereo, uncompressed
This was the hardest for some reason. In the end I went with 20 FPS to bump the bitrate to a level where I feel it looks good.

BADAPPLE
Video: 320x240, 24FPS, 400Kbps (11 Mb)
Audio: 44100Hz, Stereo, uncompressed
Looks perfect to me. My player has some bugs at 30FPS which I have not investigated, otherwise it would probably work.

No me esperaba para nada llegar a ver video en codecs modernos en N64. Impresionado quedo.
Imagino que usará uno de los perfiles de complejidad mas bajos, si no el mas bajo, pero aún así... impresionante.
¿También usa alguna variedad de AAC para el audio?

Viendo los tamaños mostrados aquí, sería interesante una comparación con RE2, para ver cuánto podría mejorar la calidad comprimiendo con h264 los mismos videos en el mismo espacio, variando quizá framerates para tener varias opciones.

Tras ver el video me ha saltado esta recomendación. Una demo de N64 en una ROM de 4KB.



Cuando lo leí, sabiendo que una ROM de N64, entre header y bootcode ya ocupa esos 4K exactamente antes de pasar a código ejecutable normal, imaginé que serían 4K a mayores de eso, o sea 8K, pero no, según explica en la descripción, han logrado hackear el asunto y encajar el código de la demo robando espacio al bootcode, tal como se explica en la descripción del video que replico aquí por comodidad:

This is the first 4K intro on Nintendo 64. The ROM is exactly 4096 bytes. Download it from: https://github.com/rasky/small64

This is a high-quality recording of the PAL party version, running on a Nintendo 64 using the UltraHDMI mod for high quality video.

On N64 ROM, the first 4K are reserved for a boot code, so this ROM fits just that. To achieve this, we had to go through several hoops including banging directly the hardware with no SDK, write a custom crinkler-like tool for compression optimization, write a custom minimized RSP microcode for 3D graphics, generate audio on the fly with the CPU, and finally use PC GPU hash cracking to make sure the final ROM matches a "secret" checksum the N64 expects for the boot code.

You can find more technical details in the README in the GitHub repo.

Otra lección magistral de optimización de gráficos de Kaze Emanuar:




Es interesante ver como se puede pasar en los ojos de 4 triángulos a 2, y practicamente cuadriplicar la resolución de sus texturas reduciendo su tamaño.
Una muestra de que los ajustados tiempos de desarrollo y la inexperiencia fueron un obstaculo para aplicar las optimizaciones en los juegos de la consola.

@EMaDeLoC las generaciones todas deberían haber durado 5 años más todas. Evidentemente esto es imposible, pero es que al final N64 salió en el 96 y en el 98 ya Dreamcast forzaba tener que saltar cuanto antes no ponerse a optimizar al máximo. Y lo mismo con las otras de PS2 o GC a 360 pasaron solo 4-5 años. Para ese momento pocas ganas de invertir en I+D y mejoras SDK quedarían porque por mucho que optimices ya va a verse desfasado. Tiras de los motores que ya funcionan para sacar software y ya

Hace varios años me tope que esta chulada de hilo sobre la que fue mi primera consola propia y aun asi desde hace tiempo tengo esta duda, hablando solo de graficos, olviden cinematicas y musica (esta ultima por ahora) silent hill habria sido posible en N64?

@jonathanhg Desde luego, en lo poligonal sin duda, seguramente en el apartado sonoro hubieran habido recortes, pero si pudo con Res2 un Silent Hill facil y con buen control con Z-targeting, que los combates con esas criaturas voladoras eran un horror, en eso Resident un mini punto, apuntado automatico y listo, rapido y efectivo, pero era Capcom

@jonathanhg La cantidad y variedad de texturas podría ser problemática, pero es una objeción general. No conozco la carga total de texturas de SH en PS1, ni el tamaño individual de las más grandes. Aparte de la capacidad de almacenamiento del medio, PS1 y N64 manejan las texturas de forma diferente. Es posible que no se pudiera hacer una equivalencia directa. Pero no tengo detalles suficientes.

@radorn un port 1-1 imposible por las caracteristicas de estas maquinas, pero vamos la 64 va sobradiisima en ese aspecto, y ya en manos de Rare, bueno, eso seria un festival, pero no todo son los graficos, pero en 3D Rare era lo top de lo top, ni nintendo llego a ese nivel de excelencia.
Los unicos Midway con Rush 2049, un port asi directo simplemente no lo mueve la ps, es mas , dudo que una ps pueda mover solamente la carretera sin coches, el culmen de las 64 bits de nintendo

https://www.youtube.com/watch?v=yOuHn2cXkCo&t=1115s
Un juego de Ps1 que mueva la mitad de poligonos con esa amplitud de escenarios, ni de fly
Aun recuerdo comprar el juego en el Game que me llevo mi padre en coche al centro mail de Paseo de Gracia y darme la caja sin el puto juego, que eran caros mas 10.000 pts
Esto en la era de final de las 32 bits jajaja, tremendo, recuerdo subirme al coche, con mis 13 añitos y abrir la caja y vacia
Brutal, que mangantes >.<

@radorn ¿que tiene de especial el SH de PSX en cuanto texturas? son de 32x32 a 8 bits y las más grandes 64x64 en 4 bits y en cuanto variedad no me parece que tenga mucha más que cualquier juego de Rare.Me suena que para hacer la niebla o usaba diferentes texturas según la lejanía o cambiaba de paleta, esto no sería necesario en N64 teniendo niebla por hardware.

Salud.

N64 tiene mayor caché de texturas y contra la creencia habitual la variedad de texturas no es un problema de almacenamiento limitado por la ROM.

En capacidad poligonal no hay problema y además con filtrado y corrección, a mayores la niebla la 64 la hace por hardware en PS1 se gastan recursos para hacerla por software así que todavía iría más sobrada para mejorar otros aspectos.

El único problema sería las FMV y voces aunque creo que no hay muchas importantes y deberían caber todas.

Edit el problema sería decidir si queremos 320x240 20fps o bajar esa resolución y ofrecer 30. En PS1 el framerate es irregular así que tanto una opción como otra no sería mejor ni peor que el original

No podemos saber si a 240p iría ahogada a 20fps.

Señor Ventura escribió:No podemos saber si a 240p iría ahogada a 20fps.

Por pura estadística y viendo las resoluciones internas de cuando hice capturas nativas para el top y viendo la pericia de Konami con los Castlevania lo que me genera dudas es si lograrían 20 estables y no un tiovivo

Sin explicación ni contexto

https://www.reddit.com/r/silenthill/com ... lent_hill/


¿Con esa tasa de polígonos una n64 no iría mínimo a 30fps estables?

@Señor Ventura Supongo que como tiene una distancia de dibujado tan corta, se puede permitir unos escenarios tan densos en la geometría, se ahorra el teselado para evitar el warping y tener una iluminación por vértices más suave, me suena que el Turok 1 tiene también una geometría muy densa aprovechando la niebla tan cercana.
Lo importante no es la geometría total del escenario, sino lo que dibuja en ese momento, 3000-4000 polígonos por frame debería ir a 20-30 fps en esa época.
Salud.

Habría que adaptar donde sea necesario, FMV por imágenes, la música.. y en lo técnico pequeñas diferencias.

Tengo datos analizados de hace años así que puede que tengan algún error.

La resolución es de 292x224, resolución cómoda para N64.


Las texturas son páginas de textura, con los típicos tamaños exóticos y leyendo varias veces de la misma si es necesario, en N64 al ser manual lo más seguro es que se adaptara como se hizo en RE2, a un tipo de textura que quepa en la cache, que acaben siendo más pequeñas o en formato cuadrado no significa que luego no se vean mejor, N64 representa mejor las texturas que PSX.

La página de Harry es de 192x128


La página de Cybil es de 256x128


Son páginas de 4bit (16 colores), luego dependiendo de la zona que agarre, es muy probable que llegue con 2KB.

Harry es el personaje principal, tiene sentido que intentaran optimizar lo que siempre se va a ver en pantalla, y darle más detalle a la poli que aparece solo en escenas.

No he mirado texturas de escenarios, pero viendo la densidad de los mapeados me inclino a que caben en la cache de texturas.
--

De geometría es más denso de lo necesario, pueden ser varios motivos, la falta de corrección de perspectiva y el juego de luces con la linterna, que con una cuadrícula con cierto número puede dar el detalle suficiente como para hacerla realista.

Esta escena engaña, tiene formato cine recortada, así que es probable que mucha geometría quede fuera, incluso fuera del foco de la cámara también se pueden ver elementos:





Pero no sería descabellado decir que habrá buena carga continua, más al añadir otros modelados 3D como personajes o enemigos, 3000 largos por frame, allá donde exista mayor carga.
--

De rendimiento no he encontrado demasiadas muestras, a ojo rasca y de forma abundante, este canal no es muy fiable, por ejemplo cuando no hay movimiento el contador baja a 0 en otros tests, pero bueno en movimiento sirve para hacerse una idea.

No son 30 fps estables, de hecho cada vez que sale 1 enemigo, 1 solo, ya empieza a caer sobre 25-30, hay momentos de 20, 17, 15.. es más o menos la experiencia que he visto en persona.

Los interiores parecen atroces, pero yo lo achaco más a que no está analizando bien por falta de movimiento.


N64 se siente cómoda a 20fps, tanto que muchos juegos funcionan directamente a esa tasa por ser estables, como los Zelda o Wave Race, creo que de ir a 30, con ese volumen de niebla, también haría saltos entre 20 y 30.
--

Efectos:
- Niebla sin problema, y podría ser mejor lograda
- Filtro ruido, sin problema, N64 soporta ruido por hardware para crear estática, no haría falta textura
- Iluminación, sin problema, N64 podría usar otros métodos de hecho, otra cosa es que vayan a lo fácil, sea colorear vértices o similar, estelas y luces transparentes también las manejaría bien, es rápida con transparencias