Hilo de detalles y curiosidades de N64

No es por ser tiquismiquis... Bueno, si que lo soy, pero eso más que reflejos en tiempo real es usar el framebuffer como enviromental map para aparentar un reflejo. Es de los trucos más simples que hay para conseguir reflejos, el problema, y lo que parece a veces, es que si la pantalla no tiene las suficientes defierencias de color de una zona a otra, el Mario se "camufla" con el entorno y cuesta de verlo. Además se nota la falta del reflejo del cielo que permitiría precisamente evitar ese camuflaje y dar más sensación de reflejo.
De todas formas no es algo fácil de implementar y tiene su mérito.

Los juegos Rally '99 y Rally Challenge 2000, que en realidad son el mismo pero el primero solo salió en Japón con unos cambios menores en el segundo, tiene reflejos a tiempo real. No salió en Europa y nos lo perdimos.




Mi suposición de como funciona es:
-El coche tiene 4 cámaras acopladas en el parabrisas, los laterales y la luna trasera. Un algoritmo basado en la rotación del coche activa las necesarias y además las gira según su poción ante la cámara principal.
-El coche también tiene 4 rectangulos donde están las cámaras.
-La consola renderiza lo que enfoca cada cámara dentro de la región de su rectángulo correspondiente. Como es una región pequeña lo hace muy rápido. Además no usa todos los efectos que aparecen en la cámara principal como la niebla.
-Luego ya me pierdo en como pone los reflejos en el coche, si como textura directamente en los cristales, que no creo porque se distorsionaría; mezclando el render principal y las cámaras mediante croma, que veo más factible; o directamente el render principal sobreescribiendo el framebuffer dejando "huecos" justo donde están los cristales que permiten ver lo de las cámaras porque se han renderizado antes, pero creo que el RCP no permite esa clase de huecos, no al menos así.

Es un efecto que en los cristales queda muy bien y llamativo, dándole bastante realismo.

@cegador
Una pregunta, donde puedo encontrar a ese tal devwizard.
Si es el que creo, es el que quito la ralentización de super mario 64.

@emadeloc
Muy guapo ese efecto de reflejo siendo de 1999.

blade133bo escribió:@cegador
Una pregunta, donde puedo encontrar a ese tal devwizard.
Si es el que creo, es el que quito la ralentización de super mario 64.

Ni idea. Lo menciona en la descripción que he puesto.

¿No era el Rally Challenge uno de esos juegos en que en las repeticiones podías activar un motion blur bastante espectacular? Creo recordar que se podía en varios juegos, incluyendo Ridge Racer, y en todos era con el mismo botón (C abajo, puede ser).

@cegador

Gracias por compartir el vídeo, se me hubiese pasado por completo y es muy chulo.
Pensaba que sería algo hecho a partir de una herramienta externa como reshade y que sólo funcionaba en emuladores. El efecto es muy vistoso pero se actualiza a un menor ritmo que la acción y no es una reflexión como tal sino que "envuelve" a Mario en una textura con lo que se está mostrando en pantalla, haciendo que muchas veces parezca más camuflaje óptico que lo que se pretende. Ya le estaba poniendo pegas y viéndolo únicamente como una curiosidad cuando de repente veo que funciona en la consola . No me esperaba que se pudieran hacer modificaciones de esta forma. Lo mejor es que no parece que se reduzca el framerate en absoluto.
El autor ya está pensando en mejorar el efecto teniendo en cuenta las cosas que he mencionado antes. Habrá que estar atento a los resultados. Me pregunto si este tipo de modificaciones introduciendo nuevos efectos gráficos sólo son posibles en Super Mario 64 porque se dispone del código fuente o si es posible hacerlo en más juegos mediante hackeo tradicional (supongo que lo primero). El siguiente paso podría ser darle a Mario una sombra al estilo de Jet Force Gemini.

Efectivamente ese efecto del Mario consiste en usar la misma técnica de environment mapping habitual pero cambiando la textura fija que normalmente usa por una textura dinámica derivada del framebuffer actual.
Un truco que parecen hacer es que detienen la renderización de la escena antes de pintar a Mario en ella, derivan la textura del framebuffer sin Mario, y entonces la usan para pintar a Mario en el framebuffer.** (correjido mas abajo)
El efecto tal como está ahora hace que Mario parezca estar hecho de cristal, con un efecto de refraccion, mas que de reflexión por ser un metal muy pulido. Pero es muy vistoso igualmente.
Si pudiesen cambiar las normales de la geometría quizá podrían conseguir un efecto mas de reflejo que de cristal, o al revés.

No es el primer juego de N64 que usa el framebuffer para algún tipo de reflejo, aunque no es muy habitual, no solo por el rendimiento, si no porque al ser las texturas de n64 tan limitadas en tamaño, intentar hacer, por ejemplo, un gran espejo en una sala, o quedaría muy borroso/"pixelado" por la baja resolución, o requeriría de hacer un "embaldosado" juntando múltiples texturas e iría lentísimo.

EMaDeLoC escribió:Mi suposición de como funciona es:
-El coche tiene 4 cámaras acopladas en el parabrisas, los laterales y la luna trasera. Un algoritmo basado en la rotación del coche activa las necesarias y además las gira según su poción ante la cámara principal.

Probablemente el algoritmo sea tan sencillo como aprovecharse del backface-culling y no molestarse en generar las texturas que no son visibles a la cámara.

EMaDeLoC escribió:-Luego ya me pierdo en como pone los reflejos en el coche, si como textura directamente en los cristales, que no creo porque se distorsionaría; mezclando el render principal y las cámaras mediante croma, que veo más factible; o directamente el render principal sobreescribiendo el framebuffer dejando "huecos" justo donde están los cristales que permiten ver lo de las cámaras porque se han renderizado antes, pero creo que el RCP no permite esa clase de huecos, no al menos así.

Pues acabo de echar unas carreras y fijándome en los reflejos, veo que cuando algo de lo que se renderiza para los reflejos pasa por las aristas internas de la curvatura del cristal, se ve la doblez en lo reflejado. Además de eso, la superficie del cristal tiene bordes con antialiasing con el resto de la geometría del coche. Yo diría que es render-to-texture de toda la vida.

gelon escribió:¿No era el Rally Challenge uno de esos juegos en que en las repeticiones podías activar un motion blur bastante espectacular? Creo recordar que se podía en varios juegos, incluyendo Ridge Racer, y en todos era con el mismo botón (C abajo, puede ser).

Acabo de echar una partida y tanto la demo del juego como las repeticiones tienen motion blur de ese. No se si hay botón para desactivarlo.

Sogun escribió:Me pregunto si este tipo de modificaciones introduciendo nuevos efectos gráficos sólo son posibles en Super Mario 64 porque se dispone del código fuente o si es posible hacerlo en más juegos mediante hackeo tradicional (supongo que lo primero). El siguiente paso podría ser darle a Mario una sombra al estilo de Jet Force Gemini.

Hmmm. Por un lado dice que el "truco" que ha usado es leer el framebuffer y "sobreescribir la textura de metal". En principio, eso podría conseguirse con hackeo, escribiendo una rutina encajada en algún punto de alguna rutina existente, como han hecho otros muchos, y listo. Lo que no se es si la parte de tomar la textura cuando esté el entorno pero antes de que esté mario sería posible de esta manera. No tengo ni idea de cómo organiza el renderizado de la escena el juego. No se si lo de tener a mario de ultimo es algo que hace naturalmente el juego o habría que modificarlo para ello. Si fuera necesaria modificación, suena al tipo de cosa que requeriría acceso al codigo fuente para no ser una auténtica locura conseguirlo.

**EDITO: yepa, retiro lo dicho. Mario si que está presente en la textura:
https://www.youtube.com/watch?v=AZ0N9wuXN2I?t=1m38s
Paradlo y avanzad fotograma a fotograma (punto y coma) cuando entra por la puerta y veréis a mario "reflejado" en mario.
En principio no habría mucho inconveniente en hacer esto con un hack tradicional. Claro que con el código fuente sería mas facil.

nintendo 64 tiene 4KB de cache de texturas
playstation tiene 2kB(pensaba que tenia 512kb)
sega saturn cuanta cache para texturas tiene? creia que tenia tambien unos 512kB

tenia entendido que nintendo 64 usaba texturas mas chicas que en las otras 2 consolas

cristus escribió:nintendo 64 tiene 4KB de cache de texturas
playstation tiene 2kB(pensaba que tenia 512kb)
sega saturn cuanta cache para texturas tiene? creia que tenia tambien unos 512kB

tenia entendido que nintendo 64 usaba texturas mas chicas que en las otras 2 consolas

La caché de texturas de N64 es distinta a la de PS1. En la PS1 es una caché transparente. Cuando el renderizador de PS1 accede una textura en la memoria de video, los bytes que la conforman se van cargando en la caché y permanecen ahí mientras el renderizador no acceda a datos nuevos. La textura puede ser mas grande que la caché, y la caché se va llenando de los datos necesarios en cada momento. Obviamente esto afecta al rendimiento, pero la textura puede ser de hasta 1024x1024, creo.
En la N64, la textura es cargada de forma explícita y tiene que caber entera en la caché. Además, habitualmente se usan mipmaps, y estos también ocupan datos en la caché, por no hablar del que también es popular el uso de texturas con paleta de color, que tamién tiene que estar en la caché (una lista de hasta 256 colores de 16bit)
El sistema de sprites/texturas de Saturn no se como funciona en este sentido.

1MB es toda la memoria disponible de PSX para gráficos, sean texturas y toda la información relacionada, paletas o framebuffer, a partir de ahí hay que pasar de RAM a VRAM, en N64 se puede usar para gráficos toda la memoria que quede disponible de los 4MB-8MB.

Usar la cache de texturas es fundamental, de todo lo que he analizado de PSX, solo los Resident Evil usan texturas más grandes que la cache para los modelados 3D (y porque el fondo es prerrenderizado), sin quedar muy claro como se distribuyen, ya que esos modelados contienen muchos poligonos pequeños, cuando los escenarios son grandes con cámara libre no me ha parecido ver texturas por encima de los 2KB, entre otras cosas porque además se usas superficies pequeñas por la falta de corrección de perspectiva, hay una famosa cristalera que siempre se usa como ejemplo de un juego que no recuerdo, de una sala cuadrada en una pared plana, que perfectamente podría representarse con más polígonos.

Saturn no tiene cache de texturas, funciona de otra forma, he encontrado un artículo en castellano, es muy largo así que no me lo he leído todavía, pero aquí lo dejo para verlo después:
http://www.davidgamizjimenez.com/es/inpositivegames/sega-saturn-al-limite-ii/

Ese artículo lo había leído, dice que saturn y psx tiene 512kb de cache, pero psx cuenta con ese otro cache de 2k aparte.
Lo que quería averiguar es porque saturn no llega al nivel de texturas que psx, si tienen la misma cache , bueno ahora me entero que psx cuenta con esos 2kB aparte, que no sé si con eso hace la diferencia a su favor o es otra cosa. Sacando que en saturn generalmente no se usan efectos de iluminación y transparencias en tiempo real que eso ayuda a que se vea todo mejor al final.

Saturn cuenta con 512KB de VRAM y otros 512KB para dos planos de framebuffer, ambos conectados al VDP1, aparte de otros 512KB para la VDP2. La memoria de frambuffer esta dividida siendo un doble framebuffer, lo que le permite dibujar un nuevo frame mientras el otro esta siendo mandado a pantalla.
El tamaño máximo de un sprite de Saturn es de 504x255 a 16bits de color, aunque esto se define por unas tablas de color y además se organiza en unidades de 8 píxeles horizontales por 1 vertical... Esto es así a lo simple porque la cosa es bastante más compleja en el manual del VDP1, pero esas son las cifras.
No existe una "cache" en Saturn tal y como la conocemos en PS1 y N64, el VDP1 lee la tabla asociada al sprite directamente de la VRAM y escribe el resultado en el framebuffer que toque, y encima malgastando ciclos de dibujado según lo distorsionado que estuviese el sprite.

PS1 tiene 1MB de VRAM donde se guardan el frambuffer (también doble), las texturas y la paleta de colores. Se organiza en páginas de 256x256 píxeles por lo que una textura te puede ocupar todo eso, pero a costa de sacrificar mucho el rendimiento si la GPU se ve obligada a acudir a la VRAM, de ahí a tener 2KB de cache para agilizar el proceso.
Como te han comentado, N64 tiene 4KB de cache de texturas y puede usar todo lo que necesita de la RAM unificada para guardar texturas.

El tamaño de las texturas de PS1 y N64 dependían de la profundidad de bits de color.
En PS1:
Color de 4bits = 64 x 64 píxeles
8bits = 64 x 32
16bits = 32 x 32
Sin tener en cuenta la paginación de texturas.

En N64 eran estos:
4bits = 90 x 90 píxeles
8bits = 64 x 64
16bits = 48 x 48
32bits = 32 x 32

En comparación la Saturn es capaz de mostrar sprites más grandes, aunque uno solo al máximo tamaño se come la mitad de la VRAM por lo que no es nada práctico, y lógicamente los sprites eran bastante más pequeños y razonables.

El tener memoria dedicada para VRAM y frambuffer supone una ventaja de rendimiento para la Saturn, el problema es que el sobrante del framebuffer, al ser dedicado, no se puede aprovechar. PS1 no desaprovecha su VRAM al incluir el framebuffer, por lo que en la práctica dispone de más memoria de vídeo que la Saturn aún usandola para framebuffer. Encima, al usar VRAM de doble canal (lee/escribe por un lado mientras lee el framebuffer por el otro) su rendimiento no se ve perjudicado, a menos que necesite usar la RAM convencional porque el MB de VRAM se le haya quedado corto. Mientras N64 es más flexible y puede usar 1, 2 o 3MB de RAM para lo que se le antoje: texturas, modelos, audio... El problema es que al estar toda unificada se le produce un cuello de botella muy perjudicial para el rendimiento de la consola.

@cristus espero que esto resuelva tus dudas, incluida la del hilo de Saturn que has puesto.

A efectos prácticos casi que se podría considerar la caché de texturas de Nintendo 64 de 2 KB porque cuando se usa una textura con paleta de colores la mitad de la caché se emplea para almacenar esa paleta (aunque sea de 16 colores y no use apenas nada de esos 2 kB). Y cuando se emplea filtrado trilineal los mipmaps ocupan la mitad de la caché disponible, siendo el tamaño efectivo de la textura de 1 kB en el caso de texturas a color.
Realmente las únicas texturas que aprovechan el 100% de los 4 kB son en escala de grises de 128x64 con 16 tonos o 64x64 con 256 tonos (Perfect Dark tiene varios ejemplos de este tipo). También texturas a color de 16 o 32 bits que no hacen uso de paleta de colores, aunque el resultado final no difiere apenas a simple vista respecto a texturas paletizadas de 8 bits y se necesitan más memoria en el cartucho para almacenarlas por lo que no le veo mucho sentido a usarlas salvo casos muy específicos (Diddy Kong Racing y Jet Force Gemini usan texturas de 16 bits para sus texturas a color. Ahora no recuerdo ninguna textura en estos juegos en escala de grises ).

Es por ello que el 99% de texturas que te vas a encontrar en Nintendo 64 sean de 32x32, 64x32 y 64x64 a 8 ó 16 bits de color o en escala de grises. Juegos como Donkey Kong 64 o Banjo Tooie combinan varias de estas texturas para formar imágenes más grandes pero para ello deben multiplicar la carga poligonal del escenario al tener que estar cada textura pequeña contenido en un polígono (por ejemplo, 4 texturas de 64x64 para hacer una textura de 128x128, empleando 8 polígonos).

Conker64 escribió:solo los Resident Evil usan texturas más grandes que la cache para los modelados 3D (y porque el fondo es prerrenderizado), sin quedar muy claro como se distribuyen, ya que esos modelados contienen muchos poligonos pequeños, cuando los escenarios son grandes con cámara libre no me ha parecido ver texturas por encima de los 2KB, entre otras cosas porque además se usas superficies pequeñas por la falta de corrección de perspectiva, hay una famosa cristalera que siempre se usa como ejemplo de un juego que no recuerdo, de una sala cuadrada en una pared plana, que perfectamente podría representarse con más polígonos.]

He revisado un rippeo de texturas de Metal Gear Solid que tengo y hay una montón de texturas de los escenarios de 128x128 a 16 colores e incluso algunas más grandes de 192x128 y hasta de 256x256. Entiendo que quieres decir que estas texturas en realidad están formadas por trozos más pequeños (de 64x64 o incluso de 32x32) y quien hizo el rippeo las unió en un mismo archivo para facilitar su identificación, tal y como podría hacerse con texturas de Donkey Kong 64, Banjo Tooie o Jet Force Gemini. Después el escenario tiene la suficiente carga poligonal para disimular la falta de corrección de perspectiva y alojar todas estas texturas pequeñas (aunque precisamente MGS con su cámara aérea tendría menos problema para ello).
¿Pero no sería el mismo caso que lo comentas de RE2? Recuerdo que ya hablamos de ellos hace tiempo en este hilo y que incluso hice una imagen de cómo habría que dividir la textura de los modelos de Playstation para usarlas en Nintendo 64 y tener el mismo nivel de detalle, ya que con la cantidad de polígonos que tiene el modelo de la cabeza te da lo mismo usar una textura muy grande o varias más pequeñas. No se hizo así en el juego comercial porque la memoria del cartucho iba apuradísima y en realidad el resultado final era superior en N64 a pesar de las texturas más pequeñas debido a la resolución en pantalla, la precisión subpíxel y el filtrado bilineal.

o sea entendí que saturn podía meter texturas mucho mas grandes que las otras 2 consolas pero para no gastar toda la memoria dedicada(512KB) se limitaba, y el otro problema que tenia, que era memoria dedicada en 3 bloques de 512KB una para cada cosa, o sea que si fuese unificada como en psx hubiese sido mejor para administrarla dependiendo de las necesidades. pero esa desventaja de la memoria dividida era solo para juegos 3d? en juegos 2d ese total de 1.5MB de vram se aprovechaba?

@Sogun
Claro, PSX usa páginas de textura a modo de formato en la VRAM, luego mediante coordenadas sabe localizar información individual, como una textura de 64x64, tal como harías con un spritesheet o una textura en openGL, otra cosa sería que la página entera de 256x256 se use en una sola superficie, creo que eso suele ser la confusión, de todas formas no es como N64 que en la RAM se puede hacer cualquier cosa, la VRAM de PSX es menos flexible.

Si necesitas algunas fuentes, en reddit explican las páginas de textura de PSX:
https://www.reddit.com/r/EmuDev/comments/fmhtcn/article_the_ps1_gpu_texture_pipeline_and_how_to/

De hecho, a la VRAM de PSX se la puede tratar como un array de 16bit (como si fuera todo una imagen) donde cada pixel es un valor de 16bit, hay herramientas que permiten ver que hay dentro con información gráfica:
https://wiki.vg-resource.com/PSX-vram

@cristus Da igual lo que se ejecute en la Saturn, la división se mantiene. Solo se pueden hacer ciertas manipulaciones en el framebuffer que no se este mostrando en pantalla y siempre cosas concretas de framebuffer. Es decir, no se puede usar la memoria de framebuffer para algo distinto como guardar sprites.

Una curiosidad que me encantaría probar

EMaDeLoC escribió:@cristus Da igual lo que se ejecute en la Saturn, la división se mantiene. Solo se pueden hacer ciertas manipulaciones en el framebuffer que no se este mostrando en pantalla y siempre cosas concretas de framebuffer. Es decir, no se puede usar la memoria de framebuffer para algo distinto como guardar sprites.

Entonces saturn tiene 1mb de video ram para almacenar datos gráficos y los 512kb de buffer sirven para trabajar.
hace mucho ya leía en internet que saturn tenía ventaja en 2d sobre Playstation en parte por esos 512KB extras, y por eso metía más cuadros de animación, ahora veo que no necesariamente era por eso. Se piensa que saturn tiene 1.5mb de vram.. por otro lado la mayoría sabe que la superioridad en 2d radica más en que saturn tiene un hardware específico para hacer 2d que funciona como en varias arcade de la época.

Conker64 escribió:Una curiosidad que me encantaría probar

Hubo una época hace 15 años o así, que los proyectores me obsesionaban, pero, la verdad es que no son muy prácticos en general.
Eso si, unas partidas a cuatro con eso no estaría mal.

Demostración y destripe de un 64DD:


Lo pongo aquí y no en el hilo oficial porque los pervertidos que nos gusta las consolas y cartuchos en pelotas frecuentamos este hilo.

¿Se llegó a saber el motivo porque se retrasó tanto el 64DD? Podrían haberlo sacado al año del lanzamiento de la consola con algún RGP interesante y luego pegar el pelotazo con el Zelda.

Pantalla anti piratería en Super Mario 64, cada día sorprende más éste juego.

doblete escribió:

Pantalla anti piratería en Super Mario 64, cada día sorprende más éste juego.

Ayer mismo estuve viendo este vídeo. No deja uno de sorprenderse con juegos de hace más de 24 años.

@doblete @Bimmy Lee Ese video es falso. Parece que a la gente se le ha dado ahora por inventarse cosas sobre Mario 64. Que si el juego tiene una IA super avanzada que va "personalizando tu copia" según como juegues, que si está Wario oculto por alguna parte, que si monedas moradas... o el supuesto Luigi que se supone que estaba oculto hace años ("L is real"). Una mezcla de "creepy pasta" e intento de leyenda "urbana".
Aparte de ese video parece haber, al menos, otro mas, ligeramente diferente.
el tuyo https://www.youtube.com/watch?v=rRftkLddtak
el otro https://www.youtube.com/watch?v=K6I4umr6XBM

El caso es que Mario 64 no tiene protección por la región de la consola, ni por posibles comprobaciones de velocidades para detectar simulación de región, ni por el tamaño de la eeprom de guardado o por su ausencia... Todas ellas las he comprobado personalmente, y no sale ninguna pantalla de aviso antipiratería.
Si realmente hubiera habido tal sistema anticopia, se lo habrían encontrado los de la scene en su época, y habría un crack o algo. Además, Mario 64 es uno de los juegos mas hackeados y documentados que hay. Ahora tenemos incluso el código fuente. Yo creo que lo habrían descubierto hace tiempo si fuera real.

EMaDeLoC escribió:¿Se llegó a saber el motivo porque se retrasó tanto el 64DD? Podrían haberlo sacado al año del lanzamiento de la consola con algún RGP interesante y luego pegar el pelotazo con el Zelda.

Es una buena pregunta. La verdad es que no recuerdo leer nada al respecto en su época de por qué se seguía retrasando una vez tras otra. Yo leía frecuentemente la HC y NA, pero, en retrospectiva, entiendo que otras revistas mas seriasprobablemente habrían dicho algo al respecto de haber trascendido.

Era todo hype sobre el aparatejo y sus potentísismas posibilidades y tal y cual, que si iba a salir este juego o el otro, que si aún seguían preparando esto y lo de más allá, luego unos meses o quizá un año de silencio sobre el tema, y luego, de sopetón en una mera doble página donde mas de la primera media era imagen, y un artículo que básicamente decía "ah, si, que el 64DD ha salido en Japón y nunca va a salir en ningun otro lado. Eso es todo". Me quedé con cara de tonto. "¿Ya está, eso es todo después de años de hype? YO ME CAGO EN TODO LO QUE SE MENEA "

Respecto a los motivos de los constantes retrasos, que resultaron en este lanzamiento tardío, a regañadientes, y sin fe... la verdad es que he visto de todo, y todo muy vago siempre.
Un ejemplo que he oído varias veces y con diversas variantes es que había problemas con el desarrollo del aparato. A qué clase de problemas podría referirse esto ya no lo sé seguro. ¿mecánicos? ¿electrónicos? ¿firmware? ¿software de desarrollo? ¿estabilidad de los datos guardados? Ni idea
En el video dejan claro que había miedo fundado de que los críos estropeasen el lector o los discos magnéticos por manejarlos mal, y que para eso tiene tantas medidas de seguridad. ¿Quizá tenían miedo a que se borrasen los discos magnéticos por acercarles imanes, o el degaussing de las TVs?

El video anti pirateria, está bien currado, así que es fácil caer .

Además es que las rayitas esas son el típico efecto VHS de post-procesado.

Si realmente fuera VHS habría mucha más distorsión, mezcla de color, etc. Se vería mucho más difuminado.

@gelon Si, no lo comenté antes, pero dices bien al señalar el tema del aspecto, que es claramente de filtros para simular VHS. Podrían haberse esmerado un poco mas mas si querían hacerlo pasar por una grabación casera real de hace mas de 20 años.
Aparte de lo que tu has señalado, hay aspectos de la imagen que no son consistentes con un supuesto VHS casero con tantos defectos como simula este video, en el que han puesto distorsión de color, algo de inestabilidad horizontal, bastantes puntitos puntos blancos ("nieve"), algo de ruido de fondo en el audio, pero nada de ruido de fondo en la señal de video, que tiene unos negros demasiado profundos y limpios, con un un contraste muy alto, cuando debería ser bastante pobre, con ruido y un tono grisáceo. Una cinta con los defectos vistos aquí tendría otros que faltan, por tanto es inconsistente.
Aparte de eso ¿cómo es que se pudo grabar esto en cinta si se supone que sucedió por sorpresa, según la descripción del video? ¿Cuando sucedió, tuvo la audacia de apagar la consola sin tocar nada mas y poner el video a grabar a ver si salía otra vez? hmmm sospechoso

Pues a mí me la han colao, los jodíos...

Al parecer un usuario se ha hecho con una copia prototipo del “rumoreado” Panel de Pon 64

Como las viejas teorías apuntaban, al final es cierto y la versión que apareció en Gamecube es un port de lo que iba a ser el descartado Panel de Pon 64



Notición! Alucino con que sigan apareciendo cosas así... A saber que tesoros tendrá Nintendo escondidos, prototipos de Mother 3? Y mucho más seguro

Generalmente los juegos de rompecabezas con fichitas no me interesan, pero habrá que probarlo igualmente.

LINKr2 escribió:A saber que tesoros tendrá Nintendo escondidos, prototipos de Mother 3? Y mucho más seguro

El prototipo que más me gustaría ver sería el Dinosaur Planet original en N64 (sin la temática de StarFox que ganó en su paso a GC). Mas que nada por el aspecto técnico brutal que alcanzaron. Se supone que readaptaron el motor de Diddy Kong Racing, que también fue adaptado para Jet Force Gemini y Mickey's Speedway USA, haciendo de DP el cuarto juego en esta linea hereditaria.
Por si alguien aún no lo ha visto:
https://www.youtube.com/watch?v=cOVBRJToVDY

Uno que también me gustaría ver en una demo mas avanzada es el DIE HARD 64. Salieron 3 ROMs prototipo, pero está muy verde. Pero lo que se ve prometía mucho. Por desgracia creo que no avanzaron mas antes de saltar a GC y darnos una abominación.

O el Harrier 2000, simulador de cazas de combate cancelado, de Paradigm.

ACTUALIZO: Bueno, parece que voy a acabar respondiéndome yo mismo a lo de los formatos de ROMs gracias a una novedad de romhacking:

Acaba de salir un nuevo mod de Zelda que promete 20 horas de contenido: The Legend of Zelda ~Master of Time~



El mod se distribuye en un parche para dos formatos "n64" y "z64". El de z64, en efecto, solo funciona con una ROM en orden big-endian, o ABCD.
Para aplicar el parche marcado como "n64", primero probé con una ROM que puse en orden little-endian (DCBA), sin éxito, y luego la convertí a byteswapped (el clásico V64) y finalmente funcionó.

Así que parece que "n64" es el nuevo nombre que le han dado los despistados y liantes al "v64" de toda la vida.
Podían haber dejado el v64 como estaba, dado que esa ABERRACIÓN nació con el Dr V64 y no tiene sentido ninguno mas que para usar ese cacharro, y, en su lugar, haber renombrado Z64 a N64, como defiendo yo CON RAZÓN.
Lamentablemente, las fuerzas del mal se empeñaron en que había que cambiar uno de los dos y decidieron asignar el nombre bueno (N64) al "formato" malo (V64), dejando al "formato" bueno con el nombre raro proveniente de un copión minoritario que, aunque fué muy bueno para su época, hoy en día es irrelevante...

¡Señor, llevame pronto!

ACTUALIZO again: Hay aún más ironía en los propios parches:
La versión especificada para parchear ROMs ".z64" lleva un "_z64" en el nombre de archivo, mientras que el parche especificado para ROMs ".n64" y que requiere una ROM byteswapped/V64, resulta que no lleva nada en el nombre de archivo, como si quisiera indicar que es el formato "normal" y el z64 es el "raro".
Sin embargo, usando cualquier combinación de parche y ROM, la ROM resultante estará en formato "big-endian" (Z64, o, según mi opinión, el "formato" que verdaderamente merece la extensión .n64).
Para lograr esto, resulta que el parche marcado como "_z64", o sea, "el especialito", ocupa unos 5 megas, mientras que el que no tiene marcas especiales, como si fuera el "normal" ocupa 30 megas, casi tanto como la ROM original que parchea porque tiene que cambiar todos los bytes de sitio aparte de meter el contenido nuevo... y eso que el formato del parche, .bps, lleva algo de compresión en si mismo.

En serio, toda esta situación es kafkiana...

---------------------------------------------------------------------
OTRA ACTUALIZACIÓN MAS (viendo el enorme interés que han despertado estas informaciones )
Otro hack de Zelda, ~The Missing Link~, también resulta tener dos parches para diferentes "formatos" de ROM (y, al igual que el de ~Master of Time~, ambos parches con sus respectivas ROMs de origen producen una ROM de destino que es big-endian, aunque en este caso, curiosamente, ambos parches son prácticamente del mismo tamaño...).
En este caso, la web ofrece tres parches, siendo dos de ellos para ROMs normales de N64 y uno para el WAD de la Consola Virtual de Wii.
De los de N64, uno está anunciado en la web como para ".z64", y el parche que descarga ese enlace lleva "big_endian" en el nombre de fichero. El parcheado funciona correctamente con el "formato" de ROM esperado, así que todo correcto.
El otro parche para N64, por otro lado, esta anunciado como para ".n64", y el parche que enlaza tiene "little_endian" en el nombre de fichero, lo cual, ya no solo ofende en otorgar el nombre "bueno" (n64) al "formato" malo (v64/byteswapped), si no que además, riza el rizo en la perversión de la nomenclatura establecida en el mundillo de N64. Pero esto requiere algo de explicación.

Por alguna razón sobre la que solo puedo especular (aunque creo que mi teoría, que pondré mas abajo, es bastante sólida), los que dieron nombre a los distintos órdenes de bytes en cuanto a ROMs de N64 decidieron tomar como referencia 4 bytes.
De esta manera, el orden big-endian vendría a ser ABCD, little-endian sería DCBA (que no se si realmente hubo algún copión que volcase ROMs de esta manera, pero Tool64 lo tiene, y lo llama, curiosamente "n64"), y lo que hace el Dr. V64, que se bautizó como "byteswapped" es BADC (que, muy apropiadamente, contiene "BAD").

Ahora, además de renombrar como N64 a lo que siempre fué V64, otorgando injustamente el nombre bueno al formato malo, los autores de este ROMhack han tenido la ocurrencia de llamar al orden BADC "little-endian" en vez de "byteswapped", para liar aún mas las cosas. ¿Es que no tiene final el sinsentido?

A ver, que si, que técnicamente "byteswapped" es voltear el orden cada dos bytes, y, técnicamente eso es un "little-endian" de 2 bytes. Pero es que durante años en la scene se había establecido que, trantándose de ROMs de N64, siempre se habla de estas cosas en términos de 4 bytes y no solo 2... ¿así que que cojones?

Mi teoría de por qué en cuanto a ROMs de N64 los "endians" se especifican en términos de 4 bytes es que muy probablemente haga referencia al método básico de deteccion automática de las herramientas para convertir formatos o "hacer byteswap", que se basa en los primeros 4 bytes de las ROMs comerciales, que siempre son 80 37 12 40 en hexadecimal, y, a partir de estos, se corrige el resto de la ROM.

Se empezó con mal pie con el V64 haciendo la tontería del BADC y dando ideas incorrectas a la gente sobre el formato nativo de N64 (si, hasta hace no mucho había supuestos expertos afirmando taxativamente que V64 era el formato nativo de los datos dentro de los chips ROM de los cartuchos, que es falso e irrelevante gracias al formato especial de dichas ROMs con multiplexación de direcciones y datos en el bus, y estoy convencido de que aún quedan quienes lo creen así), pero al menos se llamaban a las cosas por su nombre.
Pero, ahora, la gente parece haberse puesto de acuerdo en cambiar las cosas y todas ellas a peor.
No-Intro estuvo durante años publicando su DAT de N64 en V64/byteswapped, afirmando que ese era el verdadero formato de N64, pero finalmente aprendieron y ahora su DAT por defecto es "Big-Endian" con extensión Z64 (sigue sin ser lo ideal, pero al menos es "tradicional" y conocido). Al menos han aprendido a hacer eso bien, aunque mantienen la opción "Byteswapped" con extensión V64 en su generador de DATs, no entiendo muy bien con qué propósito... hoy en día quien NECESITE ROMs V64 es porque quiere usarlas en un Dr V64, y no deben quedar muchos en uso activo con la explosión de flashcarts y teniendo en cuenta que la mayoria de la gente usa emuladores.

A ver si algún dia, con tantos cambios, se ponen todos de acuerdo en dejar de hacer tonterías y llamar N64 a las ROMs big-endian, como tiene que ser.

---------------------------------------------------------------------
MENSAJE ANTIGUO:

A ver si alguien sabe resolver un misterio que me está rompiendo la cabeza.

En el pasado lo más habitual cuando uno descargaba ROMs de N64 era encontrarselas en "formato" .v64, con los bytes ordenados como BADC ("byteswapped"), gracias a al prevalencia de los copiones Doctor V64, que volcaban las ROMs de esa forma, y de cuyo nombre se deriva la extensión.
No tan habitual, pero tampoco algo extraño era encontrarse las .z64, con orden ABCD ("big endian", el correcto) y nombradas por el copión Mr Backup Z64, que las volcaba así.

En mi opinion deberíamos deshacernos de esos nombres de extensión heredados de esos copiones que ya *nadie* tiene o usa, y tener las ROMs en ABCD con extensión .n64, que es lo que más sentido tiene.
Mi colección personal está toda en "big endian" (ABCD) y extensión .n64, como debe ser.

Sin embargo, ya he visto muchas veces que hay quien descalifica el "formato" .n64 y lo que no se qué orden de bytes se supone que se esconde tras esa denominación.
El ejemplo mas reciente que me he encontrado es este reordenador web, que llama "malignant" a .n64 poniendolo en el mismo saco de .v64:
https://hack64.net/Thread-Web-based-N64 ... v64-to-z64

¿Qué es este ".n64" del que hablan y qué orden de bytes tiende a contener? ¿Álguien lo tiene claro? Yo es que no me he encontrado ningun ".n64" que no fuera big-endian, o sea, igual que .z64. De hecho, me he encontrado ROMs nombradas como .z64 que en realidad eran "bytswapped" al estilo de las .v64 ...

La única pista que tengo al respecto es que la vieja herramienta "tool64", que aparece aún recomendada en mil sitios (a pesar de que ni si quiera lista ROMs que no tengan tamaños exactos de ROMs oficiales, como 4, 8, 12, 16, 24, 32, 40, 48, 64), lista un orden "little endian" (DCBA?) como ".n64", pero yo no creo haberme encontrado nunca ninguna ROM así... aunque podría ser que algún despistado, encontrando esa herramienta, haya pensado que "si se llama N64, será la mejor opción", y se le haya dado por convertir sus ROMs a ese "formato" y las haya distribuído después...
no se... ¡Menudo lío montaron los fabricantes de copiones!
Aún quedan despistados que creen que V64 es el formato "nativo" de N64 por alguna extraña sinrazón.

@radorn vengo de leer sobre inmunología y no he entendido ni la mitad, pero ahora leyéndote a ti creo que inmunología está chupada

No he entendido casi nada, igual es por el cansancio mental, mañana lo releeré de nuevo. Por ahora me quedo con el hack de Master of Time, vi en novedades el otro hack, pero este no.

@SuperPadLand ¿Lograste entenderlo ya?
El tema realmente no es muy complejo en sí. El problema es que se ha liado todo de mala manera por razones históricas debidas a mala práxis por parte de cierto fabricante de copiones, un empeño por "vender" el nombre del copión a través de las extensiones de los nombres de archivo, como si fueran formatos especiales o algo, cuando no son mas que volcados directos del contenido de las ROMs, sin mas modificación que, en ciertos casos, reordenar los bytes de formas estúpidas, y a partir de ahí se ha hecho una bola de nieve de confusión y mala práxis que parece seguir agrandándose aún a día de hoy.
Con lo facil y claro que sería hacer las cosas bien, pero no...

Yo dije hace tiempo que había que poner los puntos sobre las íes de una vez, pero no se hizo y ahora surgen más teonterías que ni siquiera yo podía haber predicho. Es verdaderamente asombroso.

Pero bueno, si todo esto pasa en el mundo real con temas serios, como la plandemia de la nueva subnormalidad, cómo no va a pasar también con las ROMs de N64...

@radorn lo he entendido más o menos, ya sabes que yo de profundidades tan técnicas tampoco controlo. Pero una pregunta esto mismo que cuentas de los formatos de N64 se aplicaría para otras consolas que también tenían varios formatos diferentes? Me suena que NES tenía al menos dos tipos de roms distintas o algo así.

@SuperPadLand De los formatos de otras consolas, así dando un repasillo rápido...

NES: De cara a la consola existen dos ROMs en el cartucho, una de programa, leída por la CPU, y otra de gráficos o "characters" leída por la PPU durante el rasterizado. Un cartucho puede, sin embargo, contener chips especiales, que, presentandose mediante esa "interfaz" de dos ROMs, pueden dar acceso a mas ROM mediante bank-switching. Además, pueden ofrecer RAM y procesado y canales extra de sonido que se mezclan en analógico con los nativos de la consola mediante unas patillas del cartucho (solo en Famicom nativamente, para versiones occidentales de la NES hace falta modificación).
Debido a todas estas complejidades, y a que las propias ROMs no contienen cabeceras internas que describan o identifiquen estas cosas, la scene ha teniedo que inventar formatos de ROM con cabeceras propias añadidas al inicio de la ROM que den información extra que permita describir o especificar las particularidades del cartucho del que sale la ROM.

-El mas popular y antiguo es iNES 1.0, inventado por el autor del emulador iNES, y adoptado ampliamente por toda la scene. Básicamente especifica un "mapper" mediante un número de 8 bit (0-255) y representando cada uno de estos un tipo de cartucho conocido, teniendo que saber el emulador de turno como emularlo correctamente. Lo de "mapper" viene de que uno de los aspéctos mas importantes del las diferencias entre cada tipo de cartucho es el mapeo de memoria del bank-switcher.
En tiempos mas recientes se ha creado iNES 2.0 para expandir y corregir ciertos problemas con la primera versión. Este formato es retrocompatible con emuladores que no son explícitamente compatibles con esta versión, mientras esa ROM en concreto no use las nuevas extensiones del formato.

Además de iNES, existe UNIF, un formato que se creó precisamente como reemplazo para iNES 1.0. En vez de usar números de "mapper" conocidos, donde el emulador tiene que conocer cada mapper y saber emularlo, UNIF usa un estilo mas descriptivo para especificar cómo funciona el cartucho del que sale la ROM, de forma que el emulador no necesita estár explicitamente familiarizado con tantas cosas como en el caso de iNES.
Sin embargo parece haber bastantes problemas con este formato y su desarrollo parece que se detuvo y ahora iNES 2.0 es donde se enfocan todos los esfuerzos.

Debido a esto puede darse el caso de tener una ROM con una cabecera incorrecta y a pesar de estar bien el contenido de la ROM, no emularse bien por estar el emulador intentando, valga la redundancia, emular lo que no es.


SNES: Los propios datos del cartucho contienen suficiente información para que no hagan falta ni formatos ni cabeceras especiales: Todos los formatos y cabeceras que te encuentres son fruto de los copiones de antaño, y totalmente innecesarios, por no decir que estorban. No obstante, por tradición, muchos ROMhacks salen con parches pensados para ROMs con cabecera.
Además de esto, hay una cosa llamada "interleaving" (intercalación), que creo que también es fruto de caprichos de los antiguos copiones, donde la ROM se divide en bloques que se reordenan en cierto patrón.
Los formatos que hay son una combinación de interleaving y distintos formatos de cabecera (512bytes, un sector) añadidos al inicio de la ROM diciendole al copión cosas que necesita saber, porque no lo diseñaron suficientemente bien como para sacar esa misma información de la propia ROM...
Además de esto también están las ROMs multiparte para juegos que no cabían en un disco de 3.5 pulgadas (1.44 MB), habituales en esos aparatos.

MD: Es un caso muy parecido a SNES, pero, en este caso no se si hay cabeceras o no... imagino que las habrá, pero no estoy tan seguro.

De SMS, GG, PCE/TG16 no tengo ni idea de como van, pero creo que tienden a ser simples volcados sin mas complicación, como creo que también es el caso de GB.

De NEO-GEO y otras recreativas, decidieron dumpear cada chip ROM individual con lectores/programadores, y las ROMs son colecciones de varias imagenes ROM en una carpeta o ZIP, teniendo que conocer el emulador cada una... aunque de esto último no estoy tan seguro. La verdad es que le he dado poco a la emulación arcade.

--------------------------------------------

Dicho esto, y volviendo a N64, no hay realmente "formatos". No hay cabeceras en las ROMs asociadas a ningun copión concreto, y la única diferencia es que el V64 se empeñaba en reordenar los bytes en los volcados ROM.
Lo asombroso del caso de n64 es que en realidad no tiene complicación ninguna y aún así no paran de, perdónenme la expresión, joder la marrana. Eso es lo que me saca de mis casillas.

radorn escribió:El prototipo que más me gustaría ver sería el Dinosaur Planet original en N64 (sin la temática de StarFox que ganó en su paso a GC). Mas que nada por el aspecto técnico brutal que alcanzaron. Se supone que readaptaron el motor de Diddy Kong Racing, que también fue adaptado para Jet Force Gemini y Mickey's Speedway USA, haciendo de DP el cuarto juego en esta linea hereditaria.
Por si alguien aún no lo ha visto:
https://www.youtube.com/watch?v=cOVBRJToVDY

Uno que también me gustaría ver en una demo mas avanzada es el DIE HARD 64. Salieron 3 ROMs prototipo, pero está muy verde. Pero lo que se ve prometía mucho. Por desgracia creo que no avanzaron mas antes de saltar a GC y darnos una abominación.

O el Harrier 2000, simulador de cazas de combate cancelado, de Paradigm.

A mi me encantaría jugar a la beta del Conker 64 y a la del resident evil 0. Sobretodo a la del Conker.


PD: El panel de pon éste no deja de ser el pokémon puzzle league que sí que recibimos por aquí.

Que filtren lo que quieran.. tras el Goldeneye de XBLA. Que ese sí tiene una pinta brutalérrima, y se supone que está acabado.

@hyrulen Conker 64 sería un juego diferente al Conker que recibimos?

@SuperPadLand Si, mucho, búscalo y verás lo diferente que era.
Es curioso la historia de estos juegos dentro de Rare. Igual se me cuela algún gazapo, pero creo que la historia es la siguiente. Dream, el precursor de Banjo-Kazooie iba a ser un juego totalmente diferente a lo que acabó siendo. Por lo visto apuntaron muy alto y no acababan de saber qué hacer con lo que tenían entre manos, y entonces vieron el avance del equipo Conker un plataformas 3D estilo mario, y decidieron cambiar de rumbo, y sacaron BK y BT.
Mientras tanto Conker seguía avanzando pero entonces se dieron cuenta de que el mercado estaba lleno de juegos de plataformas del mismo estilo, y parece que no llamaron mucho la atención en uno de los E3, y se arrugaron un poco. Entonces llegó, creo que fue, Chris Seavor y propuso un cambio radical para Conker: De una simpática mascota infantil, a un borrachuzo, pesetero, mujeriego y violento, con un montón de referencias de películas, sangre, tripas, pis, tetas, tacos, engranajes sodomitas...

http://www.nintendoplayer.com/unrelease ... conker-64/

SuperPadLand escribió:@hyrulen Conker 64 sería un juego diferente al Conker que recibimos?

Sí, un poco diferente
https://www.youtube.com/watch?v=M6ceNFV2yz4

@SuperPadLand Un último comentario rápido sobre lo de las ROMs y los formatos.
He recordado que hace un tiempo estuve (y aún estoy) lidiando con varias colecciones de ROMs, rellenando huecos cogiendo de muchos sitios, y en varios sistemas me encontré con ROMs que binariamente eran diferentes, pero únicamente porque tenían una cabecera (header) de algún tipo, pues al quitársela quedaban iguales.

He oído decir a varios expertos que, al menos dentro de lo que son consolas de cartucho, el único sistema que necesita cabeceras es la NES, por lo que ya expliqué.
En el resto de sistemas, ya sean consolas o micros con cartucho, las ROMs parece que se "autodocumentan" mediante información interna nativa, o tienen un formato suficientemente uniforme como para no necesitar que documente detalles del cartucho que de otra forma no se podrían saber.

La supuesta bios del video, ¿es real o falsa?.

@doblete

MVG vuelca el contenido de un cartucho de desarrollo de Turok 3.



Interesante repaso rápido a métodos de volcado y al que considera el método más seguro para tareas con cartuchos delicados.

A Radorn le gustará la mención al 64drive y a la ID del cartucho.

De la megafiltración aquella de Nintendo al final no ha salido ninguna beta o juego cancelado ¿no? Es por si apareció algo bueno catarlo y mirar si lo meto en el top.

@SuperPadLand De los GigaLeak I & II salieron bastantes prototipos para SNES, y no se si alguno de NES. También "poquemones" varios. De N64 creo que no ha habido ningún prototipo completo como tal, aunque si han habido materiales beta, inéditos hasta ahora, que se han introducido, con esfuerzo, en las ROMs de los juegos finales. Entre estos se han vistos niveles de prueba de SM64, un nivel del Zelda que se llegó a ver en videos "beta" de la época, un circuito de Mario Kart 64 que es básicamente un pueblecito con un monton de calles cruzadas...
También se descubrieron modelos 3D del Super FX, como un Yoshi andante y una cabeza de Link de Zelda, de los cuales vi demostraciones donde los insertaban los modelos en StarFox.

@EMaDeLoC una pena que al final la ROM no sea más que la version final con una cabecera distinta.
Ese código ABCD, irónicamente, tiene cierto potencial de impedir que la ROM funcione desde el menú de un cartucho flash.


Tenía bastante escrito al respecto de esto, pero el navegador me la ha jugado y he perdido todo, y ahora no tengo ganas de reescribir. Con suerte veréis la razón con la tabla que os pongo

@radorn algo de lo que citas ya lo vi, pero yo estaba preguntando por cosas como 40 Winks o Sidney 2000 que son juegos cuyas rom están completas, pero que no llegaron a comercializarse en su momento. El 40 Winks por ejemplo lo tengo en mi top, estoy buscando cosillas así.

He estado probando un poco los ports de SM64 en PS2 y 3DS, aunque sé que son prematuros y probablemente a estas alturas existan versiones más actuales.

En 3DS no vi fallos importantes salvo que cuando suenan ciertos sonidos ralentizan el programa (imagino que en el modelo NEW funciona mejor), además de que el sonido tartamudea cuando pasa, eso es más propio de un emulador que de un juego que corre nativamente, imagino que están llenando un buffer como lo haría una N64 y por alguna razón el hilo que usan para el audio no es independiente del resto.

La resolución nativa de 400x240 es un punto, creo que estaban experimentando con un mapa para la pantalla de abajo (como lo haría la versión de DS)


En PS2 necesita trabajo, aún hay algunos fallos gráficos, pero es interesante verlo correr ahí, he probado la versión VA y la 60fps, va mejor la 60fps aunque se ralentiza, también tiene el mismo problema con el audio.

Sin duda es un port que da mucho juego, tan solo serían necesarios 8MB para cargarlo entero en RAM ahorrando trabajo en maquinas con lectores

@Conker64 En una New va perfecto, sin ralentizaciones ni cosas extrañas en el sonido. El incremento de potencia ayuda mucho a la hora de correr este tipo de ports.

Imagino que es imposible por alguna razón porque sino a estas alturas ya habría salido alguno, pero lo pregunto igual ¿Cómo veis de posible algún tipo de hack en las rom de juegos que usaban memory pak para que en los flashcard guarden partida como si el cartucho original tuviera RAM para guardar partida? Es algo que en NES y MS sí he visto, modificando el sistema de passwords de muchos juegos para que el programa los guarde y cargue automáticamente en la SRAM del flashcard.

En N64 imagino que no es tan fácil porque la mayoría de juegos no tienen passwords de guardado así que la modificación no consistiría en el mismo mecanismo, pero igual se puede trampear de alguna forma para que el cartucho crea que usa un memory pak al cargar desde la SD del flashcad.

Conker64 escribió:En PS2 necesita trabajo, aún hay algunos fallos gráficos, pero es interesante verlo correr ahí, he probado la versión VA y la 60fps, va mejor la 60fps aunque se ralentiza, también tiene el mismo problema con el audio.

Sin duda es un port que da mucho juego, tan solo serían necesarios 8MB para cargarlo entero en RAM ahorrando trabajo en maquinas con lectores [360º]

VA es vanilla, la compilación sin parches o flags.

En PlayStation 2 no sé qué planes tiene fgsfdsfgs, pero imagino que podrá mejorar el rendimiento moviendo el sonido al IOP y el tema de la geometría en los VPU. Ahora mismo debe hacerlo todo la CPU.