Hilo de detalles y curiosidades de N64

EMaDeLoC escribió:@gynion Vamos, que quieres un port 1:1 de la versión arcade. Lo comenté con el sr. Ventura y a ello te remito. Basicamente es imposible. De hecho hasta la versión PC de aquellos años no le llega a la suela de los zapatos.

Si a eso te referías con que no te convencia como quedaría el resultado, haber empezado por ahí y habríamos acabado antes.

Si te he dicho que sí me convence el Sega Rally de Saturn (que lo tuve), no entiendo por qué concluyes que quiero una versión exactamente igual que la del Arcade en el caso del Daytona USA. O sea, no. Por ejemplo, una menor resolución la aceptaría, y eso ya no sería como el arcade, sino peor.

Hablo de un Daytona convincente, que valga la pena, y en N64 no lo veo porque no he visto ningún juego de carreras en esa consola que se acerque, ni aun a menor resolución.

No sé cuántos polígonos mueve realmente el Daytona USA Arcade, en base a las especificaciones de la Model2, serían ~ 8.000 polígonos por frame a 60 FPS, el WDC mueve 3.500-4.000 a 30 FPS, haciendo cábalas podría salir algo resultón con esas cifras, sobretodo porque la model2 hace el sombreado en flat y a la N64 le sale gratis hacerlo en gouraund, pudiendo usar menos polígonos en los coches al no notarse tanto los polígonos , luego el tema texturas, los escenarios usan escalas de grises y colorea los vértices, pudiendo usar las texturas más grandes que puede usar la N64, en teoría sino usas mip-mapping, te ahorras ponerlo a 2 cycles en esos polígonos, luego lo de poner texturas en mosaico es un curro de chinos y no se hasta que punto es recomendable usar tantísimas texturas distintas en un mismo frame, para algún detalle puede servir ,para algo generalizado lo descartaría.

Salud.

EMaDeLoC escribió:

gynion escribió:No macho, has patinao. No me puedo parar a matizar cosas y hacerle entender lo que quiero decir a alguien que me ataca con memes a la primera de cambio, tratándome de Homer. Luego me bajo al barro, y digo que pa cuñao tú, por tal y cual, y dices "aaaaah, menos mal que lo reconoces que eres Homer".

Pues mal, porque si ves que no te han entendido y te haces entender y aclaras tu posición, se termina rápido con los malentendidos y la bola de nieve se para.
Le paso casi lo mismo a uno en el hilo de Viewpoint 2064, que entra cual elefante en cacharreria y lo primero que dice es "niebla64". Luego lloraba porque le llamaban hater de la N64... Pues hay que darse a entender mejor.
Yo mismo voy con ojo cuando menciono defectos de la PS1 y remarco siempre que puedo que es buena máquina, especialmente si voy al foro de PS1. Es una simple cuestión de respeto.


Las otras comparativas son curiosas. El San Francisco fue bastante bien porteado a la N64.

Me parece que el único que lloró fuiste tú. Yo superé la fase de "mi consola es la mejor" hace unos 20 años. Te dije varias veces que leo estos hilos por que me interesa saber los aspectos técnicos basados en fundamentos o conocimentos acerca de la N64. Creo que no es necesario faltar a nadie pera expresar opiniones y es más, al revés en el momento en el que faltas al respeto, tu opinión aunque se muy válida pierde peso por si misma.
Es más por un momento habéis convertido el hilo en el clásico Megadirve vs Supernintendo pero ya con el mismo sistema lo cual de nuevo dice poco en vuestro favor.

Venga un saludete y a seguir en paz.

No es por ser tiquismiquis, pero todo este debate estaría mejor aquí: hilo_hilo-oficial-nintendo-64_2275957_s1450

Creo que la mayoría entramos aquí para leer análisis técnicos o curiosidades de la máquina, que no dudo de que entre toda la avalancha de comentarios que se han soltado se hayan dado datos técnicos; pero lo que subyace como tema principal es algo irreal e indemostrable porque no existe Daytona USA en N64 que analizar. Las cabalas estas también me gustan, pero en su hilo correspondiente.

P.D:

P.D 2:

SuperPadLand escribió:No es por ser tiquismiquis, pero todo este debate estaría mejor aquí: hilo_hilo-oficial-nintendo-64_2275957_s1450

Creo que la mayoría entramos aquí para leer análisis técnicos o curiosidades de la máquina, que no dudo de que entre toda la avalancha de comentarios que se han soltado se hayan dado datos técnicos; pero lo que subyace como tema principal es algo irreal e indemostrable porque no existe Daytona USA en N64 que analizar. Las cabalas estas también me gustan, pero en su hilo correspondiente.

P.D:

PSX hubiera movido Daytona USA a 60fps

P.D 2:

Es broma

Bueno, pues ya pueden cerrar el hilo, porque novedades en lo técnico no creo que salgan más de lo que ya se a hablado.

Salud.

@dirtymagic el hilo tiene bastantes aportes técnicos y recientes. Y si no los hubiera por el motivo que sea, no justifica varias páginas de debate basado en cosas que no existen cuando hay otro hilo para ello. Se cierra y punto, ya se reabrirá cuando aparezca algo nuevo. Saludos.

Me parece bien, pero no me seáis salomónicos, porque para mí si alguien inicia un debate el responsable principalmente es quien lo inicia.

De todos modos, se supone que si lo inicia alguien que según él ha aportado mucho a este hilo (ni lo discuto, ni lo confirmo), se supone que él mismo está dando via libre y el visto bueno a ese debate; y como a mí me gusta ser una persona justa, en este caso no veo por qué desde fuera se nos tiene que decir nada ni a uno ni a otro.

La discusión ha sido iniciada y aprobada por un habitual del hilo, que supongo antes habrá aportado muchas cosas que entran en el topic. Con el inicio de ese debate ha invitado a usuarios random (por ejemplo, al menda) que tuvieran algo que decir o replicar; se ha producido un salseo puntual raro, pero ya se ha reconducido el hilo sin dramas, creo.

gynion escribió:Me parece bien, pero no me seáis salomónicos, porque para mí si alguien inicia un debate el responsable principalmente es quien lo inicia.

De todos modos, se supone que si lo inicia alguien que según él ha aportad mucho a este hilo (ni lo discuto, ni lo confirmo), se supone que él mismo está dando via libre a y el visto bueno a ese debate, y como a mí me gusta ser una persona justa, en este caso no veo por qué desde fuera se nos tiene que decir nada ni a uno ni a otro.

La discusión ha sido iniciada y aprobada por un habitual del hilo, que supongo antes habrá aportado muchas cosas que entran en el topic. Con el inicio de ese debate ha invitado a usuarios random (por ejemplo, el menda) que tuvieran algo que decir o replicar; se ha producido un salseo raro, pero ya se ha reconducido el hilo sin dramas, creo.

No he mencionado a nadie ni he culpado a nadie he pedido que se deje esta tontería por las buenas y os he hasta buscado el enlace para que sigáis donde toca. No he venido a juzgar, he pedido amablemente que uséis el hilo que toca, las razones son obvias; pero en lo personal yo uso este hilo para buscar datos técnicos a veces, si me lo llenáis de páginas con cosas que no son luego al buscar cosas me salen 100 resultados que no tienen nada que ver y menos cuando, insisto: Hay un hilo de N64 para hablar de todo lo relacionado con ella desde quien os compró la consola de niños hasta hipótesis a lo Cuarto Milenio. Dicho hilo también necesita aportes para que no se cierre por cierto.

P.D: Y yo no vengo "desde fuera" estáis en un hilo público, si queréis hablar del tema en privado usad los mensajes privados. El foro no es el salón de vuestra casa para hacer lo que queráis, el offtopic está prohibido aunque todos los habituales del hilo participen en él y te digan que se puede hacer.

Perdonad, al poner el emoticono desde el teclado del móvil, no ha salido, el anterior mensaje era en clave irónica.
Aporta más a este hilo, cualquier conjetura técnica, que muchos de los últimos mensajes que se han puesto aquí, que no tienen nada que ver con el hilo, con rifirrafes personales incluidos, si alguno de los mensajes que pongo no os parece conveniente con el hilo, reportarlo.

Salud.

Señor Ventura escribió:A 640x480 a 5fps y 125.000 polígonos (es 4 veces mas resolución que 320x240), estaríamos hablando de una versión saturn, con detallitos como que el coche del jugador sea como el arcade, y poco mas... pero, ¿realmente iría a 5fps?, porque el cálculo es chustero.

Es complicado de calcular, porque paradojicamente una mayor resolución beneficia a que se exprima el potencial del ancho de banda de la RAM, pero también debe suponer llegar al límite del RCP. Habría que saber la latencia del propio RCP, es decir, el tiempo que tarda entre que termina de recibir los datos de un polígono y empieza a devolver los píxeles renderizados.
He estado revisando algunos juegos en alta resolución de los que mencionó hace tiempo Conker64, el NBA Courtside 2 y el NFL Quarterback Club 2001 y su framerate no es nada malo. Claro que su densidad de polígonos no son para tirar cohetes y el escenario es fijo, y eso ayuda, pero va bien para ver que el ancho de banda de la RAM alcanza máximos de transferencia con más facilidad en resoluciones altas.

@gynion Yo creo que el WDC si se acercaría a lo que deseas, ajustando su jugabilidad y sensación de velocidad, pero hay que echarle algo de imaginación. Échale un ojo al Stunt Racer 64, es el mismo motor del WDC pero la sensación de velocidad esta mejor conseguida. Sigue sin ser un Daytona pero muestra que toqueteando un poco el diseño y la cámara se mejoran las sensaciones de velocidad.

@sgonzalez Yo no tengo fase de mi consola es la mejor, reconozco carencias en la N64 frente a PS1 o Saturn, y de hecho he sido de los pocos, sino el único, en tratar de dar información sobre el talón de Áquiles que es el ancho de banda de la RAM.
Y ya te lo comenté en su momento y te lo vuelvo a explicar ahora: por mucho cariño que le tengas a la consola, si la llamas "Niebla64" la gente se lo va a tomar como una provocación. Es irónico que hables luego del respeto así:

sgonzalez escribió:Creo que no es necesario faltar a nadie pera expresar opiniones y es más, al revés en el momento en el que faltas al respeto, tu opinión aunque se muy válida pierde peso por si misma.

Y tu primera intervención en el hilo fuese "típico niebla64". Luego quéjate de que digan que "niebla64" es un detector de tolais. Te podrás dar por aludido y enfadarte, pero no te voy a dar la razón en eso, como no se la daría a quien grita "viva Franco" en un mitín de Podemos, "fachas" en uno de Vox o el "ahora a hacer la cena" en aquella manifestación feminista.
Y bueno, si te molesta lo que dije de llorar, lo retiro. Era una exageración por tus quejas. Además tampoco venía mucho a cuento mencionar ese episodio por aquí.

@SuperPadLand La verdad es que iría mejor en su propio hilo de especulaciones, pero vendrían los típicos de turno con lo del framerate y la niebla (no va por ti sgonzalez) y no habría una aportación real tipo "el motor gráfico de aquí, la IA de acá, etc".

De todas formas creo que este ejercicio especulativo esta agotado, no veo que dé más de sí.

@SuperPadLand
Me parece perfecto... salvo por el detalle "pequeño" de que esto podías habérmelo dicho por privado, del mismo modo que me dices yo tendría que haber discutido con EMaDeLoC. Estamos en las mismas.

@EMaDeLoC
Es que la cantidad de coches en el Daytona me parece importante, sobre todo en el fácil. En carrera estás como bailando con ellos, dependes también de su posición para que un derrape sea perfecto, tengas que tomarlo por un lado u otro, directamente pasar de derrapar, o esas cosas. Por apariencia o estética, entiendo lo que dices, pero sigo creyendo que hace falta algo más de potencia que la de N64. No por los datos técnicos, sino sin ir más lejos por los ejemplos que me dices, a sumar a los que conozco. Esto es un punto de vista particular, y no dudo de que a otros o a mucha gente le valiera un Daytona de N64. Eso sí, que una versión de N64 mejoraría a la versión de Saturn, no te lo discuto, porque en principio creo que sí.

@gynion Si, sé que es importante, pero ya te digo, ni la IA del arcade es una maravilla, ni ha de suponer un problema por carga gráfica.
Creo que tienes el juego en Saturn, ¿no? Ya te fijarás, ponte detrás de un coche cualquiera durante toda la carrera y verás como se limita a quedarse en un carril y cambiar de vez en cuando. En el arcade aún se pone alguno a hacer un par de eses y ya. No es una IA mucho más compleja que la de un enemigo del Pacman. Por eso digo que en esa parte no habría problema.
Y en cantidad de coches, no más de 10 en pantalla, 4 quizá lo bastante cerca para necesitar algo de detalle en el primer circuito. En los otros circuitos lo mismo, y encima la parrilla es larguísima y están alejados los coches, así que no hay densidad preocupante de coches que causen problemas. Y eso tanto en Saturn como en arcade. Fíjate qué perros que llegaron a ser con los trucos de eficiencia...

@EMaDeLoC
Bueno, ahora juego a la de PS3. La versión de Saturn ni la probé en su momento. Lo que vi no me gustó, los análisis tampoco, y ya. En aquel entonces no sabía lo que era el framerate, pero evidentemente se notaba, a sumar al popping, y ante esa visión pasando. Con Sega Rally fue distinto.
Sobre lo que comentas de la IA, que no es muy compleja... es que aquí lo que habría que valorar es el nivel de complejidad de la IA en otros juegos con menos coches, porque igual resulta que no es ese el principal o único obstáculo.

En el Gran Turismo para PSP, por ejemplo, quitaron 2 coches con respecto a las entregas de PSX y PS2. No sé el nivel de complejidad de esas IAs, pero es que el comportamiento de los coches no me parece que sea excesivamente más complejo que lo que comentas, por tanto me inclino más a pensar que el simple hecho de mover objetos con IA simple ya suponga una carga notable.

@gynion Aunque sea en PS3 sigue siendo la misma IA que en el arcade.
Ahora que lo mencionas, en el juego Motorhead de PS1 tienes la opción de jugar con menos rivales y a 60fps. No sé si es por la IA o por evitar bajadas de 60 cuando se juntan todos cerca. Yo creo que en este caso es lo segundo, pero en el caso de Gran Turismo en PSP me llama la atención. Sobre el papel tiene potencia de sobra. Me inclino también por evitar bajones cuando se juntan todos, los coches están muy detallados.

@EMaDeLoC
Claro, es que el framerate es importante, especialmente en juegos de carreras. Como has dicho, sí me encaja que los posibles problemas o el peso esté más en los detalles, polígonos o texturas de los coches. Puedes detallar menos los coches del Daytona USA, pero tampoco vas a poner literalmente cajas de zapatos.

Piensa en lo que se estaba comentando antes sobre el WDC en el hilo, con respecto a detalles como las curvas, siendo un juego original, el cual no tenía la obligación de parecerse a ningún original moviéndose en un sistema superior. Lo de que a diferencia del F1 World Grand Prix, cuyas curvas son más bien pentágonos, el WDC luce curvas más suaves, supongo que porque a los programadores les resultaría feo no cuidar esos detalles, o le tendrían manía a las curvas tipo F1 World Grand Prix. Quiero decir, lo que para unos no es importante, y por tanto recortable, igual para otros no lo es (F1 World Gran Prix vs. WDC).

He estado probando ahora el SF Rush en el project64, y si bien he de rectificar la opinión sobre las texturas, las cuales son borrosas al estilo N64 pero tampoco me parecen un churro, la impresión es la que te dije, que como juego en sí no está mal, o incluso como juego arcade con aires de Daytona, pero no veo mucho más allá.

@EMaDeLoC Disculpas aceptadas y lo e Niebla64 te lo conté en su día y te lo vuelvo a decir aquí tómatelo con humor, que así es la intención con la que lo dije.
Respecto al Nascar 1999 o 2000, a mi no me valen de ejemplo, tienes la generación de polígonos a poca distancia, disimulando el popping con un "efecto" a parte de tener una tasa de frames baja y/o inestable.

El RR64, lo he jugado mucho, lo tengo en físico y está muy bien pero el poligonaje es inferior al primero de PSX (y a cualquiera posterior), sin embargo está muy bien disimulado, se juntan muchos coches en pantalla y además hay algún efecto muy chulo, como las estelas de los faros, reflejos, etc. Sin embargo, repito a nivel de polígonos lo veo un poco bajo como para meterle un Daytona Usa.

Sin embargo quiero aportar para que los deis unas vueltas un par de ejemplos:
Juego primerizo Automobili Lamborghini , jugablamente castañero, pero visualmente pienso que no está mal, hay carga poligonal decente, la tasa de cuadros es bastante constante y no hay "niebla" (perdón @EMaDeLoC), aqui hay una curva que podría recordar al segundo circuito de Daytona Usa, la única pega que le pongo (además de la jugabilidad) es que las texturas están bastente borrosas y no sé si podrían mejorarse:


Visualmente bonitos y con buena carga poligonal, a parte de los juegos de Boss Game Studio (WDC y Stunntracer), se me vienen a la cabeza el Beetle Adventure Racing que tiene bastante carga poligonal, bastantes coches en pantalla, escenarios muy elaborados y con bastantes efectos, luces, etc. De nuevo la pena es la tasa de cuadros que es irregular en todo el juego y de nuevo que algunas texturas son bastante borrosas, aunque menos que en el Lamborghini:
Esta fase me recuerda un poco de lejos a alguna del Daytona Usa 2, cuando pasas por las cascadas:


Finalmente aunque no es un juego de coches puro, si que me parece uno de los más potentes a nivel visual en el género de carreras en N64, Hydro Thunder! tiene escenarios coloristas, texturas detalladas donde es necesario, mucha carga poligonal, bastantes vehículos en pantalla, distancia de dibujado muy buena, tasa de cuadros bastante estable y si no son 30 fps, se queda muy cerca y además físicas complicadas (simulan inercias en un medio acuoso).

La segunda fase además se desarrolla en una especie de circuito "nascar" acuático y hay momentos que petada de polígonos, comparto este vídeo por que es una de las mejores capturas que he encontrado):


¿Qué opináis vosotros?

Personalmente, creo que después de muucho trabajo de gran nivel, ojo, no valdría cualquier desarrolladora, y además de los consabidos recortes, creo que si se podría hacer una versión de Daytona Usa para N64.

Un saludo

@gynion Si es por el tema texturas, creo que se puede hacer un esfuerzo en enriquecerlas. Hay trucos que dan margen a poner texturas de bastante resolución. Usando el expansion pak puede haber muchas. Lo malo es que también habría que aumentar los polígonos, pero valdría la pena. Todo es compensar de un lado y de otro, poner donde realmente haga falta, etc.
Mira el Hydro Thunder que ha puesto sgonzalez. Salvando las distancias, si que recuerda al Daytona.

@sgonzalez Tranqui, ya dejaste claro que no lo decías de mala fe. Te falló la presentación.


Muy bien traido el Hydro Thunder. La verdad que si recuerda al Daytona USA. De hecho he buscado más vídeos y en los comentarios dicen lo mismo : https://www.youtube.com/watch?v=nevISnmmC0Y
Esta bastante detallado tanto de polígonos como de texturas, y se mueve bien.

Respecto al Automobili, yo creo que aún podría tener más polígonos pero no está mal. Me sorprendió descubrirlo y ver que a base de un buen diseño de circuito casi nunca ves a gran distancia por donde aparece el escenario. Lo que me dejó con el culo torcido es descubrir que solo ocupa 4MB. ¡Es un juego más pequeño que la RAM de la propia consola!
La compresión y los trucos de almacenaje deben ser de los buenos. Y encima de Titus, los que parieron Superman 64.
Eso si, la cagaron con la resolución de la versión PAL multiplicando lineas a lo bruto.


Hago una pausa porque en el otro hilo de la N64 han colgado un notición:

ziu escribió:Se ha filtrado la esquemática de N64,
Ya dicen de hacer réplicas x FPGA ..

https://boards.4channel.org/vr/thread/6387416

Yo no mencioné el Beetle por considerar que por famoso ya lo habríais considerado, además de que no es precisamente un prodigio de rendimiento con toda la carga gráfica que tiene, y la simulación física que hace, viniendo de Paradigm, compañia de simulación que también hizo PilotWings 64 y F-1 WGP, e iba a hacer un simulador de cazas. Me pareció poco adecuado para lo que se pedía. No se a que nivel de modificación estamos apuntando aquí.

El Lamborghini lo consideré pero es bastante cutre y de las primeras generaciones, así que no cuento con que tenga un motor muy potente.

Y el Hydro Thunder... no se... es de lanchas xD

EMaDeLoC escribió:@gynion Si es por el tema texturas, creo que se puede hacer un esfuerzo en enriquecerlas. Hay trucos que dan margen a poner texturas de bastante resolución. Usando el expansion pak puede haber muchas. Lo malo es que también habría que aumentar los polígonos, pero valdría la pena. Todo es compensar de un lado y de otro, poner donde realmente haga falta, etc.
Mira el Hydro Thunder que ha puesto sgonzalez. Salvando las distancias, si que recuerda al Daytona.

Pues hay que echarle un poco de imaginación. Lo he visto, he leído la descripción de @sgonzalez , y lo que puedo decir es que el juego que se acerca por un lado se aleja por otro. En este caso, las lanchas son inertes, y las físicas no son muy allá. Claro, el Daytona USA fue un juego de una fase muy joven en la historia de los juegos poligonales, por lo que igual las físicas no eran tampoco muy avanzadas, y el coche se siente un poco como una tanqueta; pero la sensación es mejor, más creíble y sólida; tiene animaciones del efecto de la suspensión, en las ruedas, sufre accidentes de varios tipos, se va deformando... en fin.

Luego, la referencia evidente que se me viene a la cabeza al ver el Hydro Thunder es el Wave Race 64, y como en el Hydro se ha tenido que prescindir del muy logrado efecto del agua presente en el Wave, quizás para lograr el número de lanchas en pantalla y otros detalles que comentáis.

La N64 puede trabajar directamente en la memoria del cartucho como la neogeo, o tiene q cargar del cartucho a la RAM?

Saludos!

ziu escribió:La N64 puede trabajar directamente en la memoria del cartucho como la neogeo, o tiene q cargar del cartucho a la RAM?

Saludos!

La N64, como consola de 32/64 bit, tiene un mapa de memoria suficientemente grande como para encajar todos los recursos de la consola sin problemas. Al cartucho se puede acceder directamente desde la CPU o el RCP, pero las ROMs del cartucho no son suficientemente rápidas como para poder renderizar accediendo directamente las texturas y modelos desde el cartucho con un rendimiento mínimamente aceptable. Lo habitual es que ese tipo de datos se transfieran rápidamente mediante DMA a la RAM y se usen desde ahí.
Dicho eso, si que hay dos tipos de datos que se leen directamente del cartucho en tiempo real en la mayoría de los juegos: Los samples de sonido para efectos y música MIDI, y los datos de animación de los modelos 3D. Por eso cuando se hace el truco de inclinar el cartucho (que corta las lineas de datos, o, al menos, la linea que activa la lectura, pero no la linea del chip de restricción, pues se apagaría la consola) el sonido se va al garete y los personajes parece que sufren una electrocución de dibujos animados o un ataque epiléptico salvaje.
No es una imposición hacerlo así, pero es la práctica habitual y la que recomienda la documentación oficial.

Además, debido a las limitaciones de espacio de los cartuchos, lo habitual es usar compresión para casi todo. La descompresión se hace por software (cada desarrollador puede usar la compresión que le parezca, inclusive diseñar una propia). Renderizar a partir de texturas y modelos comprimidos no es práctico, como te podrás imaginar. Durante los procesos de carga, se transfieren los datos a RAM mediante DMA, se descomprimen, y pasan a usarse desde la RAM.
Los datos de audio van comprimidos también, habitualmente en un formato ADPCM bautizado como vADPCM (no se que es la "v"), que reduce PCM de 16bit a 4bit por sample sin pérdida de calidad perceptible para el uso que se le da. Hay otros formatos, pero vADPCM es el que proporcionaba Nintendo en el SDK. Esto se decodifica al vuelo en el el bloque RSP (Reality Signal Processor) del RCP mediante el microcódigo de audio durante la síntesis de sonido, así que no require descompresion previa.

radorn escribió:

ziu escribió:La N64 puede trabajar directamente en la memoria del cartucho como la neogeo, o tiene q cargar del cartucho a la RAM?

Saludos!

La N64, como consola de 32/64 bit, tiene un mapa de memoria suficientemente grande como para encajar todos los recursos de la consola sin problemas. Al cartucho se puede acceder directamente desde la CPU o el RCP, pero las ROMs del cartucho no son suficientemente rápidas como para poder renderizar accediendo directamente las texturas y modelos desde el cartucho con un rendimiento mínimamente aceptable. Lo habitual es que ese tipo de datos se transfieran rápidamente mediante DMA a la RAM y se usen desde ahí.
Dicho eso, si que hay dos tipos de datos que se leen directamente del cartucho en tiempo real en la mayoría de los juegos: Los samples de sonido para efectos y música MIDI, y los datos de animación de los modelos 3D. Por eso cuando se hace el truco de inclinar el cartucho (que corta las lineas de datos, o, al menos, la linea que activa la lectura, pero no la linea del chip de restricción, pues se apagaría la consola) el sonido se va al garete y los personajes parece que sufren una electrocución de dibujos animados o un ataque epiléptico salvaje.
No es una imposición hacerlo así, pero es la práctica habitual y la que recomienda la documentación oficial.

Además, debido a las limitaciones de espacio de los cartuchos, lo habitual es usar compresión para casi todo. La descompresión se hace por software (cada desarrollador puede usar la compresión que le parezca, inclusive diseñar una propia). Renderizar a partir de texturas y modelos comprimidos no es práctico, como te podrás imaginar. Durante los procesos de carga, se transfieren los datos a RAM mediante DMA, se descomprimen, y pasan a usarse desde la RAM.
Los datos de audio van comprimidos también, habitualmente en un formato ADPCM bautizado como vADPCM (no se que es la "v"), que reduce PCM de 16bit a 4bit por sample sin pérdida de calidad perceptible para el uso que se le da. Hay otros formatos, pero vADPCM es el que proporcionaba Nintendo en el SDK. Esto se decodifica al vuelo en el el bloque RSP (Reality Signal Processor) del RCP mediante el microcódigo de audio durante la síntesis de sonido, así que no require descompresion previa.

Ok, estaba bien parida la consola,
Supongo q el expansión pak ayudaba sobre todo a q no bajará de calidad las texturas y por eso se ve mejor resolución y gráficos?
O el expansión pak ayudaba en alguna forma q fuera más rápipda la N64 ?

Hubiera ayudado en potencia si se hubieran usado cartuchos grandes con los datos sin comprimir y en alta calidad?
Cuál es el límite teórico de un cartucho de N64?

Saludos!

@ziu El expansion pak simplemente es mas RAM que el programador puede usar. Dado que la consola tiene un sistema de memoria unificada, tener mas RAM permite mas holgura para almacenar un framebuffer mas grande sin tener que sacrificar otras cosas.
El EP no ayuda en ninguna manera a procesar mas rápido nada. De hecho, se podría argumentar que, para usar el EP, si aumentas la cantidad de texturas, o haces niveles mas grandes también puedes acabar haciendo un juego mas pesado de procesar. El EP no es un milagro, es simplemente un recurso al alcance del programador.
La intención de Nintendo ni siquiera era lanzarlo como accesorio independiente, si no como parte del 64DD para hacer caché de disco y que no hubiese tantos tiempos de carga. Luego salió por una historia con el 64DD que se ha comentado ya muchas veces.

El límite teórico del bus de cartucho parecen ser 256MB de ROM. El cartucho flash 64drive HW2 tiene esos 256 de RAM interna, pero reserva una parte de la memoria para uso interno, y una parte del rango de direcciones expuesto a la consola para una interfaz de acceso a funciones específicas del hardware del 64drive, como el USB, el WiFi y algunas cosas mas, dejando 240MB totales para ROM.

ziu escribió:Hubiera ayudado en potencia si se hubieran usado cartuchos grandes con los datos sin comprimir y en alta calidad?

No sin mejorar la velocidad de los chips ROM, que, como ya expliqué antes, era baja.

Se han filtrado sdks software y hardware de wii (diagramas, seguridad,SO)

Pero eso es otra noticia aqui hay demostraciones internas de nintendo con la 64

https://www.youtube.com/watch?v=KJWraDxhYM4

Dentro de la cuenta hay varios

Este es interesante:


Pero quiero echarle las zarpas a esta ROM:


La tetera parece tener alto poligonaje. Me gustaría verla en la consola y no en un emulador. Lo malo es que hay que compilar el código si no hay un alma caritativa que pase la ROM.

Todas las demos parecen funcionar bien en un ED64P v1. Aunque solo la del laberinto es algo jugable (y solo tiene un laberinto que lo resuelves en 30 segundos).

@EMaDeLoC Hay por ahí un enlace con todas las ROMs compiladas. Pincha por el hilo de 4chan, y si no lo encuentras, ya te lo pasaré yo. Es posible que esté en un video de YT que enlazaron desde ahí.

En otro orden de cosas: https://gofile.io/?c=wOvWRO Aparentemente alguien ya ha completado un port de Mario 64 a PC a partir de codigo fuente. En el video donde sale esto dicen que es de la filtración que nos ocupa, pero yo creo que probablemente se hayan confundido y sea de las fuentes de-compiladas del año pasado. Me parece muy pronto para que tuvieran esto funcionando siendo la filtración tan reciente.
NOTA: Parece que requiere DX12... ya no puedo probarlo...

radorn escribió:En otro orden de cosas: https://gofile.io/?c=wOvWRO Aparentemente alguien ya ha completado un port de Mario 64 a PC a partir de codigo fuente. En el video donde sale esto dicen que es de la filtración que nos ocupa, pero yo creo que probablemente se hayan confundido y sea de las fuentes de-compiladas del año pasado. Me parece muy pronto para que tuvieran esto funcionando siendo la filtración tan reciente.
NOTA: Parece que requiere DX12... ya no puedo probarlo...

Interesante. Lo he probado y sí, va perfecto y se ve de lujazo a pantalla completa.

@radorn

Probado!

Que autentica pasada! es un port directo del de N64?

COmo lo han hecho?

ziu escribió:@radorn

Probado!

Que autentica pasada! es un port directo del de N64?

COmo lo han hecho?

Por lo que he leído en GAF.

It's the decompiled version with the Ultralib stuff replaced with SDL2, which isn't that much work compared to the amount of effort which went into the initial decompilation which was a 3 year project, but this is the first person who's been mad enough to actually distribute an exe which is where the streamers are getting it from.

Someone also made a Windows 95 build using DirectX "for the luls" which I tried out a few weeks ago.

@ziu Para detallar un poco mas lo que ha dicho @gelon :
El año pasado se publicó el codigo fuente de mario 64. Pero ese código no salió de una filtración de material confidencial de Nintendo, si no que unos hackers de muy alto nivel detectaron que la propia ROM de SM64 estaba compilada de tal manera que se habían dejado unas "pistas" o "referencias" o no se muy bien que, que daban pistas sobre el código fuente original. Así que al final lograron de-compilar el codigo binario de la ROM a codigo fuente en C, y, si compilas ese codigo C de nuevo, te da la misma ROM exacta, validando el proceso. Así que, a efectos prácticos, desde hace un año está disponible el codigo fuente de Super Mario 64, y, desde entonces, hay mucha gente trabajando sobre el.

Creo que hay otros proyectos para decompilar otros juegos de N64 también. No se hasta qué punto las técnicas de decompilado que desarrollaron para Mario 64 son extrapolables a otros juegos de la consola, o si cada juego tiene que ser hecho desde cero, ni cuan importante es la presencia de esas "pistas" para la tarea. Ya se verá.

Ya hay algun que otro "hack" de mario 64 que en realidad está compilado desde ese codigo fuente. Uno de ellos es Detective Luigi, si no recuerdo mal el nombre, y corre en hardware también.

Este port de PC está hecho a partir de ese código fuente de-compilado.

@radorn Los he descargado, pero ninguno es el de la tetera.
En la documentación hay referencias al iQue y fechas del año 2000. Parece que los archivos forman parte de cuando se hacía la consola china.

Es gracioso el Mario64 PC.

Una captura en ultra panorámico.

Edito: Hoy es el día de Nintendo 64. También se ha publicado un fix de Super Mario 74 que lo hace compatible con la consola real.

http://www.romhacking.net/hacks/5114/

pues es la hostia ese port, solo falta un programa externo sencillo para poder configurar los controles y ya si fuera posible usar un mando de xbox 360 seria lo mejor del mundo, me gustaria ver un remaster a partir de ese port.

EDIT:
Ojala una versión del Mario 64 con soporte para el Expansion Pak y vibración, que tenga algo mas de resolución y el modelo 3D de Mario de la Nintendo DS.

ziu escribió:La N64 puede trabajar directamente en la memoria del cartucho como la neogeo, o tiene q cargar del cartucho a la RAM?

Saludos!

Yo desde luego no lo sé y puede que esté equivocado.

El RDP creo que está alineado a 24bit y en teoría no podría acceder directamente, lo normal es acceder a DRAM, desconozco si se puede mapear TMEM para leer del cartucho, por otro lado puede acceder DMEM cuando está el XBUS activado (para su display list), al estar en el mismo encapsulado es lo más rápido.

El RSP lee de DMEM y puede hacer DMA de DMEM a DRAM y a la inversa, con el XBUS desactivado puede acceder a la RAM para poder trabajar con un display list superior a 4KB, en lugar de DMEM, porque si en la escena hay demasiadas llamadas, como muchos poligonos o sprites no van a caber ahí (salvo que se divida en múltiples listas inferiores a 4KB), tampoco veo nada de llamadas directas al cartucho.

La interfaz de audio solo puede acceder a la RAM, no puede a DMEM, lo cual es raro porque si hay un ucode en el RSP que trabaja con audio tendrá que hacer RAM -> DMEM -> RAM

La CPU puede hacer DMA del cartucho a RAM y es útil para pozos de memoria o cache, como leer poco a poco animaciones, texturas que va a utilizar la escena (si te vas moviendo se cargan 10 en streaming, se borran otras 10 que han quedado detrás), audio, etc sin tener que cargar todo entero en memoria.

Edit, he encontrado: 0xBXXXXXXX cart uncached, 0x9XXXXXXX cart cached, 0x1XXXXXXX Physical, quizás pueda intentar hacer alguna prueba después para TMEM, las texturas.

Edit 2: Probado, no funciona con ninguna de esas direcciones, el documento oficial es correcto al mencionar solo RDRAM salvo que algo se me escape, el hard lee 24bit y se deja 8bit de información (Thx a Krom por la ayuda)

La demo de la tetera es muy de la siguiente generación... el aspecto visual, claro, una ps2 ya sabemos que te planta 25 teteras como esas xD

Esperemos que esto sirva para encontrar un poco de potencia oculta, y si de paso la gc se lleva algo de todo esto, pues mejor que mejor.

@radorn la gente esta comentando que el port contiene bicho, posiblemente un troyano, a mi el antivirus no me ha saltado..

lo he pasado por virustotal y no hay un solo positivo, pero alguien comenta que el ejecutable ese acede al registro a zonas donde no debe y que hasta genera trafico de red, yo eso no lo puedo confirmar.

@Conker64

Q interesante y el documento donde has encontrado estás direcciones de memoria son de los q han filtrado?

Saludos!

@ziu
Ah no, lo saqué de los ejemplos ASM de Krom
https://github.com/PeterLemon/N64/blob/master/LIB/N64.INC#L220

@Conker64 ¿Me estás diciendo que, a pesar de que el audio y animaciones se cargan en tiempo real desde el cartucho (demostrado por los trucos de inclinar cartucho, o mi demostración de sacarlo con un CIC en mi conector T casero), igualmente esos datos se transfieren por DMA constantemente a un buffer en la RDRAM para usarse ahí y desecharse inmediatamente? La verdad, suena a auténtico desperdicio...

@Natlus Ni idea de lo del virus/troyano/etc. Yo ni siquiera puedo cargarlo, me pide una dll que empieza por d12, o sea Direct-X 12, y en este momento estoy usando una tarjeta del año catapun porque la que tenía se me murió. Además de que uso W7 y creo que ni siquiera podría instalar DX12.

@radorn
Bueno el problema es que no hay chip de sonido y los diferentes canales tienen que mezclarse y procesarse en un buffer o bien por la CPU o por el RSP, luego la interfaz de audio lee esa región de memoria.

Ahí lamentablemente no hay mucho que hacer, salvo que hubieran puesto algún chip de sonido con su cache dedicada para hacer esa operación.

Por ejemplo en la demo del Castlevania que hice no vuelco los OGG a la RAM, solicito pequeños bloques suficientes para llenar el buffer según se reproduce.

@Conker64 Si claro, entiendo perfectamente que los samples llegan al RSP, este los mezcla según la secuencia y eventos de efectos que toquen en ese momento, y a medida que mezcla va escribiendo el resultado a un buffer que luego sale por el AI para llegar al DAC.
Pero yo no estoy hablando de eso, si no de lo que dijiste antes sobre que el RCP (o especificamente RSP y RDP, no estoy seguro) no puede acceder directamente al cartucho.
Que tiene que habilitarse un búfer de audio en la RDRAM para almacenar el audio ya sintetizado antes de salir no tiene discusión. Es lo mismo que con el framebuffer.
Lo que no me queda claro con lo que dices es si, durante el sintetizado/mezcla del audio, también hay que transferir los SAMPLES desde el cartucho a la RDRAM por DMA antes de que el RSP pueda usarlos para mezclar.
Eso es lo que me suena raro y derrochador. Los samples de sonido de los soundbanks entiendo que están en su forma lista para usar en el cartucho, y no empaquetados en bloques de datos comprimidos, como pasa con texturas y otros datos, precisamente con la intención de ser usados directamente y no tener que estar moviendolos a una memoria mas rápida como si pasa con las texturas y modelos.

El hecho de que haciendo los trucos de cartucho antes mencionados no afecten a los gráficos y, dependiendo del juego, al desarrollo normal de la partida, y, sin embargo, destruyan el sonido y las animaciones, da a entender que texturas y modelos están en RAM ya, mientras que animaciones y sonidos se usan directamente desde el cartucho... como sugiere la documentación.

Si no he entendido mal, tu ahora sugieres que, en realidad, los samples y datos de animación, si bien no se cargan enteros en RAM antes del comienzo de la partida, si que tienen que cachearse en RAM temporalmente para que los use el RSP, un proceso que, a la vista del fenomeno de inclinar/retirar el cartucho, tiene que hacerse constantemente, y que los datos cacheados se descartan inmediatamente despues de usados, teniendo que re-transferirlos desde el cartucho a RAM una y otra vez. Esto se me antoja verdaderamente contraproducente y redundante y un auténtico desperdicio de ancho de banda.

En fin, que me estoy volviendo loco con el tema... a ver si me lo puedes aclarar.

EMaDeLoC escribió:En la documentación hay referencias al iQue y fechas del año 2000. Parece que los archivos forman parte de cuando se hacía la consola china.

Parece que ese es el origen de la filtración.

@EMaDeLoC Siempre puedes confiar en China para filtrar cosas: Viruses pandémicos, documentación confidencial sobre consolas antiguas... valen para todo

Lo siento por Nintendo por el NintendoLeak... pero algo así a los usuarios retro nos abre una montaña de posibilidades: ¿mejora de emuladores existentes hasta el infinito, aparición de clónicas chinas de N64 "on a chip" (N64 mini china), aparición de BETAS nunca vistas (Mother64...) ?

Quién sabe cómo acabará esto, si es un bombazo o si es un bluff.

Para mi no es un bombazo si no sirve para elaborar herramientas de desarrollo que den un extra de rendimiento al hardware.

Lo de los emuladores está bien, pero entre eso, y descubrir cosas del tipo “usar los multiplicadores del ppu1 fuera del modo 7 para obtener un extra ENORME de procesamiento”, pues me quedo con las posibilidades de la scene porque al fin y al cabo los emuladores ya existen.

@radorn
El audio se va cargando en bloques, necesitas un espacio cache para las múltiples lecturas y un buffer para la mezcla de canales.

Cuando cargas algo del cartucho también le puedes indicar a la CPU que haga una copia en su cache, si tiene que trabajar con esa información no accede a la RAM, hasta que le haga falta otro bloque, las llamadas al cartucho para espacio cache no son a cada frame, pero para abastecer al buffer si que podrían ser en intervalos muy cortos, en mis demos llamo un frame sí, un frame no, con lo cual viene bien que lea de RAM (mover de RAM a RAM es también más rápido que de cartucho a RAM).

Las únicas memorias que puedes sugerir para trabajar son los 8KB de datos de la CPU (donde ya se hace una copia) y los 4KB de DMEM (no veo como llamar a cartucho), eso sí, dependiendo de como montes el sistema de sonido puedes sacar partido a las 2, como que la CPU es más rápida en RAW PCM, el RSP mezclando y aplicando efectos, de hecho hasta podrían repartirse la faena y trabajar en paralelo, leyendo de ese bloque de RAM.

En algún formato que pueda leer directamente mejor claro, así no hay más pasos transparentes que puedan consumir ciclos.

Lo que quiero decir es que todos los componentes necesitan mirar RAM continuamente para abastecerse y los juegos de hecho no están exentos de fallos por tener un buffer demasiado corto, el Fifa 99 en alta resolución si lo pones en ángulos de repetición donde afecten mucho al rendimiento acaban por hacer tartamudear al audio.

EMaDeLoC escribió:@radorn Los he descargado, pero ninguno es el de la tetera.

No se qué habrás descargado tu, pero después de descargar un monton de cosas y empezar a probarlas, tengo un teapot.n64 que es exactamente eso y funciona. Por desgracia usa renderizado en oscuro y corrección gamma junto con el filtro anti-dither, dandole ese aspecto super borroso de juegos como StarFox/LylatWars o Mission:Impossible.
Vuelve a revisar, y si no lo encuentras ya lo subiré yo.

@Conker64 Voy a tener que rumiarme un poco mas tu explicación para digerirla, pero ya veo que finalmente si que se hace caché temporal. Lo que me resulta contradictorio es que no aprovechen directamente para cargar todos esos datos directamente en la RDRAM en vez de estar llenando y vaciando esa caché constantemente, ocupando el bus de la RDRAM con todos esos DMAs desde el cartucho cuando todos sabemos lo sobrecargado que está ya ese bus.
O sea, podría entender poner un cierto límite temporal de estancia en RAM para datos que lleven sin usarse un buen rato, si uno necesita los recursos, pero ocupar ese carril tan transitado ya con esta tarea cuando ya lo tenemos saturado con el tráfico de la CPU, el buffer de video, el acceso a texturas y modelos, y samples, y el zbuffer y tantas cosas mas... no se, acabo de quedarme tonto.
Tanto tiempo repitiendo que los samples de sonido y las animaciones se leen directamente de la RAM sin más y ahora resulta eso es así solo a medias y que al final se cachean...

@radorn Pues miré todos los enlaces de descarga del hilo de 4chan y no lo encontré, no sé si es que esta la información oculta a través de otro hilo, pero también mire alguno que otro.
Al final resulta que yo tengo otra ROM con la tetera de una recopilación de GoodN64. No es la misma, puesto que la del vídeo manejas la sombra y en la que tengo es la tetera dando vueltas y puedes cambiar ajustes de luz, textura, etc. El modelo de la tetera parece bastante bien cargado de polígonos.

Me ha llamado la atención la diferencia entre filtrado bilineal y trilineal con mipmap, se aprecia menos pixelación en la textura.


Lo malo es con mipmapping se puede perder mucho detalle o hacer efectos raros, como pasa con el fondo de la tetera aquí.


He mirado como queda en mi CRT de 17" y la verdad es que no se nota tanta diferencia entre bilinieal y trilineal, excepto eso raro del fondo de la tetera. Por mucho que el VI produzca borrosidad horizontal en CRT se ve estupendo, con o sin trilineal. Si además el uso de mipmap te capa a la mitad el tamaño de la textura, pues yo preferiría más detalle que se nota más.

Y estoy contigo, es un desperdicio no poder cargar un sonido desde el cartucho si no es con una cache en la RAM. Para eso se carga todo lo posible en la RAM y así se reducen las esperar leyendo de la ROM.

La demo Fogworld de la filtración está interesante, donde puedes desactivar la niebla, aumentar el fov, cambiar el culling, modo wireframe, medidor de rendimiento, etc.

El resto de demos son bastante meh.