Hilo de detalles y curiosidades de N64

Gracias por el vídeo, @EMaDeLoC.

Precisamente antes de la explicación de la lente de la verdad explica el rubber-banding de los juegos de velocidad con el Star Wars Episode I Racers. Una característica que arruina por completo el multijugador en ese juego. ¿De que sirve que te permitan elegir la vaina de tu partida con las mejoras que has ido comprando si luego van a alterar las características? Lo peor es que los tiempos se guardan como récords, así que puedes hacer trampas y completar una vuelta como 2º con la vaina chetada y hacer pedazos el récord sin que haya ninguna posibilidad de acercarte a él en modo contrarreloj o campeonato.
Aunque una vaina con todas las mejoras y el dopaje del multijugador no es nada fácil de controlar.

Es éste texto?

Depth buffer copy. 'The Legend of Zelda - Majora's Mask' uses many frame buffer tricks. One trick is related to Lens Of Truth (LoT). When Lens is activated, it reveals hidden objects. How it works? First, most of visible objects rendered as usual. When everything is ready, game copies depth buffer to another place. New 16bit color buffer allocated and depth buffer is rendered to it as texture, using BgCopy command. Then game renders fullscreen textured rectangle with Lens texture. That rectangle has minimal depth, so whole depth buffer should be filled with MIN_Z. However, Lens circle has zero alpha, so all its pixels discarded by alpha compare and depth buffer inside the Lens remained intact. Now game renders "hidden" objects. These objects discarded by depth compare outside of the Lens circle. By the way, any "nice" texture for LoT in texture packs breaks LoT functionality: LoT circle must be fully transparent. When rendering of "hidden" objects completed, game copies depth buffer from temporal buffer back to depth buffer, that is restores its state on the moment before Lens texture drawn. Now rest of geometry, which should be above the Lens, can be rendered. For example, show flakes.

Es gracias al Z-Buffer, que te permite hacer las cosas en distinto orden, como volver después y pintar cosas entre medio de un buffer generado, siempre y cuando lo que quede por delante también use información Z, lo de la máscara es algo bastante estándar.

Luego tal y como lo plantean, es un efecto que consume bastante memoria disponible, la lente puede utilizarse en cualquier parte, pero no en todos los lugares aparecen objetos invisibles, así que imagino que hay activadores solo en ciertas zonas donde van a salir para reservar esa memoria extra.

Yo llegué a pasarme más de la mitad del templo de la sombra sin la lente, pensaba que el juego estaba roto

EMaDeLoC escribió:inglés castizo

de guat? xDDD

Lo la explicacion del efecto de las Lens of Truth (¿al español lo tradujeron "lente" o "lupa"? porque con ese mango es una lupa) me recuerda a la conversacion reciente que tuvimos, iniciada por ti, sobre lo de hacer juegos con camaras fijas. Usar dos framebuffers distintos, y luego comparar Z entre ellos y todo eso...

@Sogun El STAR WARS Ep1 Racer en su dia no lo tuve, si no que lo alquilé alguna vez. Tengo una vaga impresion de haberme extrañado sobre las velocidades jugando a dobles, pero nada concreto, mas que nada porque entonces no tenía la menor idea ni se me ocurría pensar en que pudieran o nadie quisiera hacer estas chorradas.
Bien podrían haberlo puesto como opcion y no hacerte tragar con ello a la fuerza.
La verdad es que se me daba bastante bien el juego, o esa era mi impresion a medida que iba mejorando mi conduccion y reflejos, pero el rollito de las mejoras del vehiculo, preocupandose de conseguir dinero y elegir piezas y reemplazarlas por desgaste y todo eso... me daba ya entonces bastante pereza y me obsesionaba no estar seguro de hacer las mejores elecciones, lo que me quitaba bastante de disfrutar el juego. Y ahora es aun peor. La idea de lidiar con el tema de los recambios me quita de jugarlo. Yo quiero un juego donde cojas el coche que mas te gusta y aprendas a manejarlo y tira palante. El rollito tunero no me aburre y me angustia.
Las elecciones complicadas son para la vida, no para un juego.

Conker64 escribió:Luego tal y como lo plantean, es un efecto que consume bastante memoria disponible

Ese inglés es un tanto chusquero y no estoy seguro de entender exactamente lo que dicen.
Lo que me pregunto es si no sería posible primero renderizar la escena normal tal cual, y como ultimo paso fundirle la "plantilla" morada exterior. Luego modificar el Z-buffer para que la zona de la pantalla que corresponde con la planilla de la lente quede con distancia cero. Acto seguido renderizar la geometria "invisible" sobre el mismo buffer y Z-buffer. No se si las herramientas de desarrollo que tenían se prestan a ser usadas así, pero diría que mi metodo es mucho mas barato para conseguir el mismo efecto, que el que describen ahí.

Conker64 escribió:Yo llegué a pasarme más de la mitad del templo de la sombra sin la lente, pensaba que el juego estaba roto

No se si felicitarte por el logro o darte una colleja por melón xDD

@radorn
Es que es un poco jaleo, pero en lugar de eso podríamos simplificarlo.

El efecto de la lente es un efecto 2D, necesitas dibujar un círculo, así que se requiere un buffer diferente al principal.
1) Renderizas la escena principal (buffer 1: color/z)
2) Renderizas la parte oculta en otro buffer (buffer 2: color/z), lo haces conociendo las coordenadas.
3) Aplicas la máscara a buffer 2, la máscara consiste en un rectángulo texturizado con el dibujo de un círculo al cual le añades Z al mínimo, el interior del círculo es transparente, con lo cual la operación no perjudica al interior del mismo, sino a todo lo demás que lleva información del pixel y su Z (operación inversa o silueta).
4) Copias buffer 2 a buffer 1 comparando Z, dado que has pegado un rectángulo con la Z al mínimo en buffer 2, se ha hecho un "dibujo" donde todo el exterior tiene la prioridad de Z al mínimo, al compararse con buffer 1 toda la escena principal resulta estar por encima, excepto el interior que tiene las coordenadas adecuadas para dibujarse aún a destiempo (con objetos por delante y por detrás de la escena)
5) Ahora te queda por dibujar el gráfico transparente de la lente, el contador de energía, etc.. cualquier cosa que quede por encima de esa escena 3D.

When everything is ready, game copies depth buffer to another place.

- Este paso no me cuadra, en teoría solo necesitarían compararse al copiar el uno sobre el otro, salvo que exista alguna limitación en el proceso.

- Requiere memoria adicional para buffer 2, ahí no especifica pero debería ser de un tamaño hasta donde finaliza la zona de visualización de la lente, si tal y como dice se hace una copia del buffer principal a otro lado, eso sería pantalla completa para un efecto que no es pantalla completa con su mal gasto de memoria y proceso, la memoria habría que reservarla en zonas donde aparezcan esos objetos, no al activar la lente en sí.

No se si felicitarte por el logro o darte una colleja por melón xDD

Fue en la primera partida, cuando no sabía inglés y no me enteraba de nada , también intenté el templo de fuego o el del agua sin el traje, con el acojone del tiempo limite

Se me olvidó comentar algo del efecto de la lente, no solo revela lo oculto, también deja ver a través de los objetos.


Aquí cambia un poco el procedimiento y tiene sentido usar un buffer a pantalla completa, pienso que lo mejor sería no hacer nada mientras la lente esté desactivada, pero en cuanto se active mover los objetos que tienen agujerearse a otro buffer, algo así:


La máscara aquí funcionaría al revés, lo de dentro del agujero sí que afectaría a Z, mientras que lo de fuera no, también pienso que no debería ser un rectángulo que pinte en otro buffer, sino que ese rectángulo solo se utiliza para actualizar Z, con lo cual se ahorrarían la mitad de ancho de banda, ya que en la comparación final no importa el dibujado desechable del segundo buffer.

Lo que ahora me pregunto es si llegan a convivir ambos efectos a la vez, porque supone aplicar diferentes máscaras en diferentes tiempos.

@Conker64 No creo que se usen tantos buffers de pantalla para realizar el efecto, creo que se edita el buffer-Z para usarlo como máscara y al realizar la segunda pasada es cuando se hace la comparación con el buffer Z y se borran o añaden cosas, editando el framebuffer existente y ahorrando así memoria.
De hecho creo que solo se añaden objetos, y es según si se tienen que hacer aparecer o desaparecer cuando la máscara funciona por dentro del circulo o por fuera.
Es decir, en esta captura:


El buffer Z se ha editado para que el RCP al hacer la comparación solo admita los objetos dentro del circulo.

En cambio en esta situación:


Es el exterior del circulo el que admite los objetos. Es decir, se ha invertido la máscara.
Claro esta, esto debe ir acompañado de que en la primera pasada, la que pinta todo el framebuffer, tenga que aparecer todo lo aparecible. En el último ejemplo, es la pared de calaveras la que debe verse siempre cuando la lente esta activa, y cuando no esta activa pues el mural.

Y ya que estamos con Ocarina of Time, un vídeo de un angloparlante que se acuerda de lo putas que lo pasamos los españoles con el librito de traducciónes:

@EMaDeLoC
Igual se podría reutilizar el framebuffer, pero creo que no podrías manipular el Z-Buffer principal sin tener una copia y dejarlo "corrupto".

La niebla requiere coordenadas Z para aplicar la distancia gradual, algunos modos de AA también, las superficies opacas deben pintarse antes que las semitransparentes (porque hay que combinar su color con el más próximo anterior), etc

Según gonetz:

When everything is ready, game copies depth buffer to another place. New 16bit color buffer allocated and depth buffer is rendered to it as texture, using BgCopy command.

Por lo menos se haría una copia de Z a otro lado de unos 150KB (ram), entonces se aplica la máscara para dibujar lo que se ve o no se ve a través de la lente y luego se restaura a la escena correcta comparando las nuevas coordenadas con la copia.

@Conker64 Esa parte que citas es un paso que se hace antes de aplicar la textura del efecto de la lente. Es más, creo que te has liado con los pasos que explica gonetz. Yo lo que entiendo es:
-se renderiza la escena normal ( menos los objetos ocultos)
-se copia el frame y el z buffer con bgcopy
-se renderiza la textura del efecto lente: todo lo de fuera del círculo se queda con Z al mínimo y lo de dentro, al ser transparente, se queda como estaba
-se renderiza los objetos ocultos: lo del fuera del círculo queda descartado por comparación Z, mientras lo de dentro al estar intacto se renderiza como una escena normal
-se restaura la copia anterior de buffer z para meter efectos que estén por encima de la lente como los copos de nieve.

Como ves has cambiado un par de pasos.

Sin embargo el último paso no me cuadra. ¿Se dibujan los copos por encima del efecto lente?

Está claro que se usa el buffer z al dibujar los objetos ocultos tanto para efectuar los descartes normales con otros polígonos como para los descartes de dentro o fuera del círculo. Lo que ya no tengo tan claro es que haya varias copias de framebuffer y z buffer ni como se aprovecha la propia textura del efecto lente para ello.

A mí me suena más efectivo que primero se renderice la escena sin los objetos ocultos pero con los efectos de nieve, luego se sobreescriba el buffer z con una máscara del círculo y se rendericen los objetos ocultos y los efectos encima del framebuffer usando el nuevo buffer z como descarte, y ya por último aplicar la textura de efecto lente usando el modo fill o copy (creo que con copy se hacían las transparencias, pero lo digo de memoria y no estoy seguro).
Creo que de esta manera se ahorra que no haya tanta copia y el proceso no consume tanto fillrate como para suponer un problema.

Pero bueno, eso es mi teoría y no tiene porqué coincidir con la realidad.

@EMaDeLoC
Ah, lo de arriba era una forma simplificada de como recrear el efecto, no una interpretación del texto de gonetz, por eso no me cuadraban algunos pasos como copiar Z según lo que yo hubiera intentado hacer

Según el texto de gonetz lo que dices es correcto, pero:

-se copia el frame y el z buffer con bgcopy

Dónde copias el frame y el z-buffer? Eso serían 4 buffers (2 originales, 2 copias), el mismo número que he planteado en el texto de arriba, si se copia el z-buffer pero se reutiliza el framebuffer podrían ser 3 en total, donde pienso que daría problemas es intentando el efecto sin copia de z.

Lo cual me lleva de nuevo al mismo texto:

First, most of visible objects rendered as usual. When everything is ready, game copies depth buffer to another place. New 16bit color buffer allocated

- Copia z-buffer a otro lado
- Nuevo buffer de color

Eso serían 2 buffers extra, yo sinceramente no le daría muchas vueltas

--
Las superficies opacas y las semitransparentes no se pintan a la vez, primero van las opacas, imagina que tienes una antorcha de luz que ilumina una plataforma invisible que acabas de revelar con la lente, en ese caso la plataforma invisible se renderiza antes que la luz de la antorcha, es decir no solo van los copos, la lente y los corazones en pantalla, también pueden ir algunos objetos semitransparentes.

Los copos creo que él da por hecho que se entiende que van después del efecto gráfico de la lente, pero no del circulo rojo.

Por ejemplo en Super Mario 64 son una simple "cortina" cerca de la cámara.




Pero en Zelda podrían tener posición 3D individual (no he mirado) o con solo ser semitransparentes ya requieren ser dibujados después, Zelda MM lo tengo pendiente de pasármelo en 3DS antes de trastear

Conker64 escribió:Según el texto de gonetz lo que dices es correcto, pero:

-se copia el frame y el z buffer con bgcopy

Dónde copias el frame y el z-buffer? Eso serían 4 buffers (2 originales, 2 copias), el mismo número que he planteado en el texto de arriba, si se copia el z-buffer pero se reutiliza el framebuffer podrían ser 3 en total, donde pienso que daría problemas es intentando el efecto sin copia de z.

Es lo que no me acaba de cuadrar, que diga que se hacen tantas copias de buffer cuando se puede hacer con una sola siempre que hagas los pasos en el orden que toca a la hora de aplicar el efecto. Así se ahorra memoria.

Conker64 escribió:Lo cual me lleva de nuevo al mismo texto:

First, most of visible objects rendered as usual. When everything is ready, game copies depth buffer to another place. New 16bit color buffer allocated

- Copia z-buffer a otro lado
- Nuevo buffer de color

Eso serían 2 buffers extra, yo sinceramente no le daría muchas vueltas

Pues yo aún le doy un par...
¿Hay un buffer de color? ¿No es lo mismo que el framebuffer? ¿Se refiere a que se cambia la posición del buffer (allocated, redirecciona)? ¿Porqué sería necesario copiarlo o redireccionarlo?

Conker64 escribió:Las superficies opacas y las semitransparentes no se pintan a la vez, primero van las opacas, imagina que tienes una antorcha de luz que ilumina una plataforma invisible que acabas de revelar con la lente, en ese caso la plataforma invisible se renderiza antes que la luz de la antorcha, es decir no solo van los copos, la lente y los corazones en pantalla, también pueden ir algunos objetos semitransparentes.

Si, eso lo sabía, yo me refería a que a la hora de dibujar el efecto gráfico de lente (el halo morado) si podía hacerse con FILL o COPY, porque ahora mismo no sé si FILL soporta grados de transparencia.

Conker64 escribió:Los copos creo que él da por hecho que se entiende que van después del efecto gráfico de la lente, pero no del circulo rojo.

Debe ser eso y que he confundido el efecto de lente con el gráfico del halo morado, y me chocaba meter este último por ahí enmedio antes que los copos.

Conker64 escribió:Se me olvidó comentar algo del efecto de la lente, no solo revela lo oculto, también deja ver a través de los objetos.

Me había olvidado completamente de ese detalle. La verdad es que no volví a tocar el Zelda despues de pasarmelo y completar todas las aventuras secundarias (skulltullas, mascaras, etc), y hacer el bug de la duplicacion de la botella.

Conker64 escribió:Lo que ahora me pregunto es si llegan a convivir ambos efectos a la vez

Tengo la vaga impresion de que si, que en algun sitio escondido hay simultaneamente objetos que aparecen y otros que desaparecen con la lente de la verdad. Si no en OoT, en MM. Pero podría estar equivocado.

Conker64 escribió:Zelda MM lo tengo pendiente de pasármelo en 3DS antes de trastear

Hace años me pasé el OoT en una 3DS prestada. Estuvo bien, aunque me repugnaron las nuevas animaciones amariconadas infantiloides de todos los personajes, especialmente link, que, por lo que recuerdo (a pesar de mis esfuerzos por olvidarlo), hasta meneaba las caderas al andar...
En fin, a pesar de los graficos mejorados (la musica mejora en algunas cosas, pero creo recordar alguna cosilla que me irritaba tambien), tambien hay cosas negativas en estos remakes.
De MM no tengo experiencia personal, pero he visto un video documentando los cambios realizados... y por lo visto la han cagado bastante.
Si te animas con posibles "destripes": Was Majora's Mask 3D a Bad Remake? (N64 comparison and review)
https://www.youtube.com/watch?v=653wuaP0wzs

Resumiendo, mejor juega al original de N64.

EMaDeLoC escribió:Y ya que estamos con Ocarina of Time, un vídeo de un angloparlante que se acuerda de lo putas que lo pasamos los españoles con el librito de traducciónes:

Ja. Los yankies están flipando en colores con la situacion, mientras que los latinoamericanos, italianos, nordicos y europeos del este, están cagandose en nosotros porque ellos no tenian ni libritos xD
Entre otro abanico de opiniones y comentarios.

radorn escribió:

EMaDeLoC escribió:Y ya que estamos con Ocarina of Time, un vídeo de un angloparlante que se acuerda de lo putas que lo pasamos los españoles con el librito de traducciónes:

Ja. Los yankies están flipando en colores con la situacion, mientras que los latinoamericanos, italianos, nordicos y europeos del este, están cagandose en nosotros porque ellos no tenian ni libritos xD
Entre otro abanico de opiniones y comentarios.

En aquella época el Club Nintendo en España tenía mucha fuerza como para meter el librito de marras. Lástima que se quedase en nada...

Hace unos días Gonetz publicó la versión 4.0 de su plugin gráfico GlideN64. Con esta actualización se supone que todos los juegos funcionan en HLE.

Leyendo los comentarios del artículo en su blog enlaza a un vídeo de una persona jugando al Hey you Pikachu! y la verdad es que técnicamente el juego me ha sorprendido muchísimo. Es un juego que nunca me he molestado en investigar y del que no había visto ningún vídeo y no recordaba imágenes.

Geométricamente me parece muy potente. Los modelados de los pokémon son superiores a los de los Pokémon Stadium y se pueden ver muchos de ellos a la vez en pantalla. Las animaciones de Pikachu son muy cuidadas y con muchos detalles (si la boca no fuera una textura que cambia de imagen podría pasar por un modelo de la siguiente generación). Los escenarios también tienen una gran carga poligonal y texturas de 64x64 a 16 colores encajadas a modo de puzzle para que no se repitan los patrones y ganar mucho detalle (en ese sentido recuerda a Rogue Squadron, porque la distancia de dibujo tampoco es muy allá y está peor resuelta la transición con el horizonte, habiendo un popping muy evidente).
De tasa de imágenes va bastante justito, eso sí. Es aceptable para todo lo que mueve y al ser la acción tan pausada no afecta a la jugabilidad. En algunos escenarios más pequeños (pero bastante recargados) como la habitación alcanza los 30 fps sin despeinarse; y en algunos momentos donde empiezan a aparecer bichos y más bichos no se nota que empeore el rendimiento así que el motor gráfico debe estar haciendo aguas por otro lado (¿problemas de fillrate por las texturas?). No tiene efectos gráficos destacables como efectos de luz o sombras en tiempo real.

https://youtu.be/YkgwdRkliZI?t=32m6s

He estado viendo varios vídeos a saltos porque la jugabilidad es muy lenta y aburrida y tampoco me apetece descubrirla. Como digo, hay cosas que me han sorprendido bastante.
¿Alguien llegó a jugarlo en su día? ¿Le sorprendió técnicamente? ¿Se puede hacer algo sin el micrófono aunque sólo sea pasear por algunos escenarios? ¿Es un juego que diera problemas al emularlo? ¿Puede que use su propio microcódigo?


En el blog también hay un enlace a un artículo de olivieryuyu, quien realizó la ingeniería inversa al microcódigo de los juegos Indiana Jones and the Infernal Machine y del Battle for Naboo explicando detalles de cómo funciona dicho microcódigo. Es muy técnico y no logro interpretarlo, quizás alguien tenga interés y pueda explicarlo para la plebe.

Sogun escribió:He estado viendo varios vídeos a saltos porque la jugabilidad es muy lenta y aburrida y tampoco me apetece descubrirla. Como digo, hay cosas que me han sorprendido bastante.
¿Alguien llegó a jugarlo en su día? ¿Le sorprendió técnicamente? ¿Se puede hacer algo sin el micrófono aunque sólo sea pasear por algunos escenarios? ¿Es un juego que diera problemas al emularlo? ¿Puede que use su propio microcódigo?

Para empezar es un juego que solo salió en Japón y EEUU, así que a menos que alguien viviera por allí en la época, ningún europeo lo habrá jugado.
Luego usa un micrófono para dar ordenes a Pikachu. El micrófono se conectaba a una unidad de reconocimiento de voz (VRU) que traducía las palabras en comandos. Estas VRU eran regionales, necesitabas el juego de cada región para usarlas. Encima estaban ajustadas para reconocer voces agudas de niño, así que de mayores vamos a tener que poner voz de pito y aprender inglés o japones.
No sé hasta qué punto se puede jugar sin micro o como se ha resuelto por emulación.
Esta en mi lista de pendientes. Si lo pruebo comentaré por aquí.

Sogun escribió:En el blog también hay un enlace a un artículo de olivieryuyu, quien realizó la ingeniería inversa al microcódigo de los juegos Indiana Jones and the Infernal Machine y del Battle for Naboo explicando detalles de cómo funciona dicho microcódigo. Es muy técnico y no logro interpretarlo, quizás alguien tenga interés y pueda explicarlo para la plebe.

Por lo que leo, el microcódigo de Indi y de Naboo hace lo siguiente:
-ahorra memoria DMEM gestionando mejor las direcciones
-optimiza el modo geometria sacrificando un solo registro
-gestiona mejor las listas de pantalla (display list) que son las que dicen qué polígonos se van a dibujar
-optimiza la ejecución de la lista de pantalla, evitando desperdicio de procesamiento
-mejor segmentación de memoria(mejor organizada)
-la estructura de comandos es diferente y adaptada a cada efecto que se quiera aplicar.

Luego hay una lista de comandos del microcódigo y lo que hace.
Desde luego es impresionante lo que hicieron con esos juegos.
12 luces en esta sala. ¡12!

¿Hay un buffer de color? ¿No es lo mismo que el framebuffer? ¿Se refiere a que se cambia la posición del buffer (allocated, redirecciona)? ¿Porqué sería necesario copiarlo o redireccionarlo?

Sí, color = frame, pero a mi no me da la impresión de que lo copie.

Puede que se refiera que apunta hacia el nuevo z-buffer (tanto si es el frame viejo como uno nuevo), en el manual del RDP es un paso obligatorio :

Initialize the Z-buffer by setting the color image to point to the Z-buffer (Set_Color_Image) and filling with initial depth value.

Necesitas 1cycle para semitransparencias

@radorn
A mi me molan , compré los 2 remakes originales hace ya años.

El OOT me lo pasé en los 2 modos que trae, con el Majoras siempre me pasa lo mismo, lo tengo empezado y creo que llegué a la primera mazmorra, luego lo dejé un tiempo y ahora no sé por donde voy, ni me acuerdo que progreso perdía cuando se acababan los días

@Sogun Tal como dice @EMaDeLoC Pikachu Genki Dechu! (nombre japonés que aun recuerdo de las revistas a pesar de que a mi pokemon nunca me interesó lo mas minimo) o Hey You, Pikachu! en USA, nunca llegó a Europa ni otras regiones.
Yo lo cargué en el 64drive por curiosidad a pesar de saber de la necesidad del VRU, y efectivamente comprobé que no se puede hacer nada sin él. Si no recuerdo mal, a poco de empezar el juego, te presentan a Pikachu, a modo de tutorial, y el juego ya te pide que le hables, y hasta que lo haces, no avanzas. Para hablar presionabas un boton y eso hacía que Pikachu te prestase atencion, y entonces hablas. Si no entiende lo que dices, pone cara rara y sale un bocadillo de comic con un garabato. Sin un VRU no hay mucho o nada que hacer.

Hay otros juegos que usan VRU, como el juego de trenes Densha de GO!!, y parece que Nintendo planeaba añadir compatibilidad a otros juegos tambien pero enterraron la funcionalidad y la han tenido que desenterrar hackers MUY dedicados (y un tanto raros), como Zoinkity:
https://www.youtube.com/watch?v=lFa6GwuG-8I
https://www.youtube.com/watch?v=VxK8XqYecSg
https://www.youtube.com/watch?v=ezx9DOAnKtY

Respecto a la documentacion del microcodigo de Factor5, me sorprende que no hagan mencion de la tan hablada texture-streaming, usando las texturas directamente desde el cartucho en vez de desde la RAM... ¿Será un mito?

Tambien he de decir, que, a pesar de los logros tecnicos de Factor 5, tanto en N64 como en GC, siempre he encontrado un toque de cutrez en sus juegos que no se muy bien como concretar.
Dado que tambien se menciona en el artículo, empezaré diciendo que el aspecto mas claro es la musica MIDI de su sistema MusyX. No se si es por la composicion, o por el nivel de volumen de la mezcla, la seleccion y ajuste de instrumentos, o qué, pero siempre me ha sonado muy artificial, en el mal sentido. Como musica de TV cutre de los 90. En todos los medios se alababa "el grandioso sistema MusyX que ofrece una musica alucinante, increible, etc" pero yo me pongo a escucharla y me suena al MIDI mas cutre que te puedas echar a la cara... Vale, estoy haciendo un poco de hipérbole, pero tengo algo de esperanza de que alguien coincida con lo que intento decir.

Respecto a los graficos, diré que es cierto que hay mucha tecnica impresionante: Alta resolucion y detalle de texturas, muchas luces y otros efectos... Pero por lo general, salvo ciertas excepciones, todo suele tener un aspecto muy "rigido", muy de cartón-piedra. Indiana Jones es un juego que, gracias al 64drive, he jugado bastante a fondo (y abandonado porque mi partida desapareció por corrupcion de la SD o algo... no se, fue hace tiempo) llegando a fases probablemente cercanas al final (incluida la fase correspondiente a la imagen del articulo), y tiene un monton de fallos graficos, y desde luego mucha rigidez por todas partes. No logro encontrar palabras que nombren especificamente lo que intento decir.

@radorn
Comparto algunas de tus opiniones sobre los juegos de Factor 5.

Comenzando por el MusyX, a mí tampoco me gusta cómo suena. Es como si los samples estuviesen muy comprimidos. Para las transmisiones por radio de Rogue Squadron dan el pego pero en diálogos normales como en el Indiana Jones se nota la falta de claridad sonora. Esto también me parece muy evidente en la música e incluso los efectos sonoros. Por comparar, los juegos de Rare son muy superiores en ese aspecto y no sólo por la composición musical o el diseño de sonido. Es como si la "materia prima" fuese peor en los juegos de Factor 5.
MusyX se licenció para otros juegos así que estaría bien saber cuáles lo utilizaron y si esta falta de claridad sonora se repite. De entrada sé que Resident Evil 2 lo utiliza y al parecer de forma excelente.

En cuanto a tema gráficos.
En Rogue Squadron creo que eligieron muy bien dónde utilizar los polígonos y cómo poner las texturas. Les ayuda que no fueron muy ambiciosos en la variedad dentro de un mismo escenario (suelen ser casi todos tierra y roca) y usan paletas de colores agradables.
En Battle for Naboo intentaron ir uno o dos pasos más allá y metieron la pata, al menos los primeros niveles que son los que he jugado. Ahora buscan escenarios más grandes con mayor distancia de dibujo y eso implica polígonos más grandes y escenarios más planos. También meten mucho verde y agua eligiendo muy mal los colores. Encima artísticamente ya salían perdiendo comparando con el material de la trilogía clásica así que queda un conjunto gráfico menos atractivo a pesar de que seguramente sea más impresionante técnicamente.
Del Indiana Jones apenas he jugado el primer nivel y luego he visto cosillas por youtube. De primeras lo que más llama la atención para mal son las animaciones y el diseño de los personajes. En los juegos de naves no hay que animar nada. Luego los escenarios que he ido viendo parecen todos miniaturizados, como si debieran de ser más grandes por la cantidad de detalle concentrado que tienen pero por limitaciones técnicas tuvieron que reducirlos. Y en espacios abiertos el rendimiento es bastante malo para lo que se muestra por lo que he podido ver.


Respecto a la tecnología del streaming de texturas. Lo he dicho ya algunas veces pero me sorprende muchísimo que en Nintendo 64 no saliese ningún juego que utilizara el mismo método de streaming que el Soul Reaver de PlayStation, sobre todo cuando avanzada la generación se hacía hincapié en mundos más y más grandes.
Aquél juego tenía una gran carga inicial (como todos los de Playstation) y luego ya no volvía a cargar mientras el personaje se desplazaba por un mundo enorme al estilo de lo que hizo años más tarde Metroid Prime (sólo que Soul Reaver usaba pasillos en lugar de puertas mientras cargaba la siguiente sala). El CD echaba humo mientras los 2 MB de RAM se iban actualizando constantemente. En teoría con 4 u 8 MB de RAM y un acceso muchísimo más rápido al cartucho se deberían de poder obtener resultados muy superiores y más fácilmente.

Y un poco al hilo de esto se me ocurrió que una manera de solventar el tamaño de las texturas en N64 sería subdividir en polígonos más pequeños el terreno cercano al personaje como he visto que hacen los juegos de PlayStation para disimular la falta de corrección de perspectiva (se hace especial uso de esta técnica en los juegos de velocidad). No sé de ningún juego de N64 que haga lo mismo, aunque quizás Rogue Squadron sea la excepción y F-Zero X hace una cosa muy rara también.
La idea es no limitarse a una textura de 32x32 o 64x64 que se repita en un patrón a lo largo de una superficie sino diseñar una textura de 128x128 por ejemplo, trocearla en texturas del tamaño de la caché, ajustarlas una a una en estos polígonos más pequeños y según se aleje la superficie y ya no necesitamos tanto detalle, se agrandan los polígonos y se usan versiones de esa textura más pequeñas como si fueran mipmaps.
Usando streaming podrías tener texturas base mucho más grandes de forma que no se apreciaran los patrones para nada.
No sé si se me entiende, la verdad es que me explico fatal. Si tengo tiempo esta Semana Santa intentaré montar una demostración.

@Sogun Tendré que ponerme otra vez los juegos y escuchar atentamente, porque en este momento hablo de lo que recuerdo de hace tiempo, pero yo hablo mas bien del timbre de los intrumentos musicales, que suenan a midi cutre y no a los samples de voz.
MusyX ofrece reproduccion de samples mp3, pensado especialmente para dialogo. Perfect Dark y Conker's Bad Fur Day de Rare lo usan, y aparece en la pantalla legal al arrancar, que creo que es lo unico que incorporan. Afortunadamente no usan el resto de su sistema de sonido, que sería especialmente desastroso para la musica . Quizá los de Factor5 le metieron demasiada compresión a los mp3s de dialogo, o quizá el efecto de transmision de radio no sale bien parado con el compresor mp3 que usaron.

Lo de Soul Reaver no se si es correcto llamarlo streaming. Lo digo con humildad. Yo mas bien lo llamaría carga dinámica. Supongo que son conceptos tan cercanos que se tocan... en fin
En cualquier caso, diría que no estás familiarizado con el, porque si que hay un juego que hace algo similar al SR en N64, y se llama Aidyn Chronicles. Es un RPG maligno y cutre, con una musica horrenda y unos personajes feos de narices y una jugabilidad bastante deleznable, que, sin embargo, cuenta con un mundo abierto sin cargas, a excepcion de entrar en edificios cuevas y cosas por el estilo. Es un mundo muy amplio, con una gran distancia de dibujado y en muchos sitios unas vistas verdaderamente impresionantes, como llegar al primer castillo, encaramarse al muro y echar un vistazo al paisaje. Hay progresion de tiempo, con dia y noche, cambios meteorológicos (al menos sol y lluvia), y, hasta hay un calendario donde van avanzando los dias... aunque no he podido averiguar cual es la relevancia dentro del juego ni si tambien hay estaciones.
Guarda en controller pak con el muy razonable tamaño por partida de 28 páginas, que sumando cuatro de ellas hacen 112 de las 123 del CP. Permite guardar desde el menú de pausa en cualquier punto del juego, y hasta almacena una instantánea de baja resolucion de lo que estás viendo en ese momento, a modo identificativo.
Es un juego horrible en muchos aspectos, pero con una factura tecnica y tecnológica impresionante, y me gustaría tener un hack o trucos o el metodo que sea, siempre que funcione en consola, para poder recorrerme todo el mundo del juego, saltandome todos los tediosos combates, pudiendo abrir todas las puertas y demás, sin molestias.

Lo de las texturas si que te ha quedado un tanto confuso. Yo no acabo de visualizarlo y me suena rarisimo. Esperaré a esa mejor explicacion.

No creo que se pueda hacer lo de las texturas, rompería las UV, si que creo es que en los polígonos más cercanos a la cámara se podría mezclar 2 texturas,una de base y otra de detalle, que para texturas de suelo tileadas podrían quedar bien,como se hace en el suelo de los Zelda.

Saludos.

Yo siempre había entendido que cuando decian carga de texturas en streaming del Indiana Jones se referian a que gracias al rápido acceso a datos se iban cargando partes de los escenarios conforme se progresaba. No se si hablais de cargar la textura del cartucho directamente a la TMEM del RCP, supongo que no os referis a eso porque el cartucho con solo 5MB/s no podría aportar los datos a tiempo ni de coña.
Ahora bien, si se trata de ir cargando trozos del mapa y texturas nuevas a la memoria para dar sensación de mapa grande, hay que hacer un poco de mates. Con 5MB/s de ancho de banda, cargar 1MB de datos a la RAM solo costaría 200ms, pero para obtener esa velocidad el bloque de datos debe ser completo, y mientras se hace el traspaso la RAM esta ocupada y no se puede trabajar con ella. Y en la N64 la RAM sirve para todo, así que mientras esta cargando ese bloque la pantalla se quedaría bloqueada durante 200ms al no poder cargar el RCP datos gráficos o de audio.
Si se quiere obtener una pausa razonable hay que disminuir drásticamente los datos a mover y habría que ir a los 50KB o menos, que ya se quedan en 10ms. Es apenas el tercio de lo que dura un fotograma a 30fps, así que como mucho habría un fotograma que saltaría en alguna parte.
Esto conlleva una complicación y es diseñar el escenario para que este dividido en zonas con sus datos propios y que estas no sean visibles desde otro punto del mapa. Aquí tanto el diseñador como el programador se han de comunicar muy bien para planificar algo que sea posible de manejar sin que sea un muermo de habitaciones una tras otra.

En cuanto a lo que comentais de subdividir polígonos (teselación de superficies) tiene dos problemas: la superficie ha de corresponder a un cuadrángulo, lo que limita el tipo de superficie que se va a crear, y la carga poligonal aumenta en 4 por cada polígono original, un cuadrángulo de 2 triángulos se transforma en 4 cuadrángulos con 8 triángulos. Esto último supone que has de usar muchos menos polígonos para el resto del escenario para compensar la subida de carga poligonal, y la consecuencia son escenarios menos detallados y con mayor popping.

Vease por ejemplo el popping de GT2 en PSX:
https://youtu.be/7TKH0z1E5OU?t=285
O el de Wipeout XL:
https://youtu.be/4SJ27_uIHKs?t=192

Para ver mejor el efecto de teselación y su problema, este vídeo de wireframe. Es de Sega Saturn, pero practicamente es identico al de PSX:


A esto hay que añadirle las texturas extra para crear el detalle, una por cada polígono creado, lo que significa que que si un cuadrángulo lo dividimos en 4 necesitamos 1 textura para el cuadrángulo y 4 para las subdivisiones, lo que es un enorme sacrificio de memoria. Hay que recordar que PSX usaba la misma textura, que era dividida para cada polígono nuevo, por lo que no había sacrificios de memoria.
Todo esto supondría una losa enorme en el rendimiento de la N64 y no lo haría viable, solo para obtener algo más de detalle en los polígonos en determinados momentos.

Los suelos con doble textura del Zelda quedaban bien, pero también suponian un coste de rendimiento al tener que pasar el RCP dos veces por el mismo polígono. Creo que sería más óptimo variar ligeramente la iluminación de los vertices y aumentar ligeramente la carga poligonal para obtener un efecto de variedad sin sacrificar rendimiento. Vamos, como algunos juegos de N64 ya hacen:


Y en cuanto a los juegos de Hey you! Pikachu!, tengo ambas versiones con sus respectivas unidades regionales, así que si quereis que los pruebe un ratillo ahora que vienen fiestas decidmelo ya.

EMaDeLoC escribió:Yo siempre había entendido que cuando decian carga de texturas en streaming del Indiana Jones se referian a que gracias al rápido acceso a datos se iban cargando partes de los escenarios conforme se progresaba. No se si hablais de cargar la textura del cartucho directamente a la TMEM del RCP, supongo que no os referis a eso porque el cartucho con solo 5MB/s no podría aportar los datos a tiempo ni de coña.

GoldenEye, y probablemente otros juegos, ya hacen ese tipo de carga dinamica que describes. En GE y PD, la descripcion del escenario tiene unos numeros misteriosos que administran la asignacion de memoria a diversas funciones, uno de ello es la cantidad de memoria dedicada a texturas en RAM. En este motor, las texturas se van copiando desde el cartucho a la RAM segun se necesitan. En ciertos niveles originales del juego es posible provocar corrupcion de texturas, por ejemplo, con el truco de todas las armas. Vas ciclando todas ellas y disparandolas, para asegurar que lleguen a usarse todas sus texturas, y al final, algunas acaban corruptas porque excedes la asignacion. Al menos esa es la teoría. Seguramente @Sogun pueda decir algo mas al respecto.
Hasta donde yo entiendo, esto que hace GE sería lo mismo que tu describes. Si realmente fuera esto lo que hace el microcodigo milagroso de Factor5, no tendría nada de particular ni sería digno de mencion, habíendose hecho desde el principio de la consola, pues GE ya estaba en desarrollo antes de que si quiera se finalizase el hardware de N64.
Yo siempre había entendido que precisamente una de las novedades de ese microcódigo es que permitía al RCP leer texturas directamente desde el cartucho durante el renderizado, ahorrando ancho de banda en el bus de la RDRAM, que ya tiene bastante que con el programa, el framebuffer y el z-buffer... Aunque creo que Indi tambien usa alternativas a Z. ¿Sería imposible que Indiana Jones use chips ROM algo mas rapidos de lo habitual?

EMaDeLoC escribió:Y en cuanto a los juegos de Hey you! Pikachu!, tengo ambas versiones con sus respectivas unidades regionales, así que si quereis que los pruebe un ratillo ahora que vienen fiestas decidmelo ya.

La verdad es que lo del Pikachu me interesa mas a nivel tecnico que jugable. Si se te da bien o has avanzado y tienes lugares interesantes que mostrar y tal, me interesa ver, dado que yo no puedo hacer nada de nada. Pero si es para ver como interactuas con Ratachu mi interes es bastante bajo.
Dado que tienes los VRU/VRS's americano y japonés, si que me gustaría ver las tripas y si hay alguna diferencia. ¿Has visto los videos que puse donde se ve el uso con el juego de trenes (parche inglés) y el Majora (en este caso creo que hay que hacer hacking)?

Como dice @radorn, en GoldenEye se puede elegir la memoria dedicada a texturas y a geometría por separado en cada nivel.

Cuando se carga un escenario todas sus texturas se cargan también en la RAM. Las texturas de las armas, explosiones, agujeros de bala, iconos de munición se cargan según se necesitan. Ahora no estoy seguro de si las texturas de los personajes y objetos se cargan desde el principio o cuando aparecen en pantalla. El Editor tiene una herramienta que funciona junto a Project 64 v1.6 para ver las texturas que están cargadas en la RAM (y te dice la memoria que están gastando) que nos sirvió en el desarrollo de Goldfinger 64 para ajustar la memoria dedicada a texturas y así dedicar más a los escenarios y evitar que trozos de los mismos se queden sin cargar por falta de memoria. Si la memoria dedicada a texturas es insuficiente empiezan a aparecer texturas corruptas.

Esto de los escenarios en GoldenEye es peliagudo porque me parece que también va cargando la geometría desde el cartucho. Los escenarios están divididos en zonas a las que se les da la orden de renderizarse si se está dentro de ellas o si puedes verlas en pantalla (en realidad si ves una cosa llamada portal que está asignado a esa zona y a otra desde la que es visible). Estas zonas se cargan en memoria de golpe, así que si no hay suficiente memoria para albergar todos los vértices habrá alguna zona que no pueda renderizarse hasta que tenga memoria suficiente (por ejemplo moviendo el punto de vista para "liberar" zonas de memoria y hacer sitio para otras). Esto es especialmente problemático en multijugador porque evidentemente hay más zonas en pantalla visibles y lo gordo es que si un jugador está dentro de una de esas zonas que no puede renderizarse el juego se cuelga. Ése es el motivo por el que algunos mapas multijugador sólo puedan jugarse a 3 e incluso 2 jugadores (se cargan todas las texturas del escenario aunque no se vean y luego no queda memoria para que no se queden zonas sin cargar).
En consola no es apreciable pero en emulador se nota más: cada vez que se carga una zona hay un pequeño parón y si se cargan varias a la vez los parones son más evidentes y puedes ver cómo aparece el escenario de un frame a otro. Si alguien carga mi recopilación de mapas multijugador y elige en el modo misiones el nivel de Holiday Island verá que la parte del escenario más distante se renderiza un poco después que el resto (había un vídeo en youtube pero ahora no lo encuentro).

Perfect Dark sin embargo carga todas las zonas directamente en la RAM (por eso tardan tanto en cargar los escenarios) y no sufre los mismos problemas que GoldenEye con las micropausas.
También recuerdo que Perfect Dark tiene una parte de memoria que asignar menos que GoldenEye. Me parece que era la dedicada a texturas.

Según tengo entendido hay varias cosas que se cargan directamente desde el cartucho que ocurre en todos los juegos, como código del juego, animaciones y la música.



He estado mirando vídeos del Aidyn Chronicles y aunque sabía qué juego era no sabía que tuviera unos escenarios tan ambiciosos. Le seguiré la pista más de cerca.

Sogun escribió:Según tengo entendido hay varias cosas que se cargan directamente desde el cartucho que ocurre en todos los juegos, como código del juego, animaciones y la música.

La practica mas extendida en N64, la que recomienda el SDK e implementan la mayoria de juegos, es usar directamente desde el cartucho, por streaming, los datos de animacion y los samples de sonido (los famosos soundbanks), pero no las secuencias MIDI. Por eso cuando haces el truco de inclinar el cartucho a los personajes les da el baile de sambito con coca y la musica se vuelve un sonido estridente pero, dependiendo de la composicion y de la suerte que tengas, aun con los samples corruptos, se puede discernir algun patron de la musica original.
Lo que está sucediendo es que el motor del juego intenta leer los datos de animacion y obtiene basura: resultado, baile de sambito. Y la rutina de reproduccion MIDI está intentando acceder a los samples de sonido, y al obtener basura, las en vez de sonidos de piano, violin o tambor, obtiene samples de basura, y los reproduce con la nota correspontiende.
Si el codigo del juego, entendiendose el motor, la logica, se accediese directamente desde el cartucho, simplemente cascaría el juego.
Mi video donde retiro el cartucho con mi conector T casero y la tecnica de inclinar el cartucho hacen basicamente lo mismo, Mantener la patilla del CIC conectada para que el PIF no pare la CPU pero corta las lineas del bus PI, impidiendo la lectura correcta de la ROM.

Si tienes pensado hacer mapas del Aidyn o de algun otro juego para GE/PD en algun momento, dame un aviso, a ver si me vuelvo a meter un poco en estos temas.
Y hablando de eso. ¿En la comunidad de GE estás al tanto de si se baraja la posibilidad de modificar el foco de vision del juego? Es que hace bastante efecto ojo de pez y siempre parece todo mas pequeño o que está mas lejos de lo debido, desvirtuando la escala de los escenarios. Le restaría algo de vision panorámica, pero me gustaría ver pruebas en ese sentido. Probablemente se podía compensar con el ratio panorámico 16:9 en vez de 4:3.

@radorn

No tengo intención ahora de capturar más mapas para adaptarlos a GE/PD. Y después de Blue Resort y Holiday Island me dije que no más mapas grandes y abiertos .
Para mi compilación de mapas para Perfect Dark voy a repetir los 11 que ya tengo (aunque Holiday Island quedará reducido ya que en PD no se aplica escala a los escenarios) y añadiré algunos mapas de GoldenEye. De momento estoy experimentando con Frigate, Surface, Archives completo y pienso añadir Basement y Bunker directamente de GoldenEye X. Creo que con eso ya tengo todos los huecos completos (contando que conservaré los mapas de Perfect Dark).

Respecto al cambio de FOV no sé si se puede hacer actualmente desde el editor, pero tengo entendido que el emulador de 1964 modificado tiene la opción para hacerlo. Aunque supongo prefieres hacerlo en el hardware original.

Estoy bastante desconectado de la comunidad. Como no tengo mucho tiempo para dedicarle a esto voy por mi cuenta. Se retiró SubDrag y Wreck hace meses que tampoco pasa por el foro. Ahora el foco más activo está en Discord y todavía no me he pasado por ahí, aunque tengo pensado hacerlo.

radorn escribió:En ciertos niveles originales del juego es posible provocar corrupcion de texturas, por ejemplo, con el truco de todas las armas. Vas ciclando todas ellas y disparandolas, para asegurar que lleguen a usarse todas sus texturas, y al final, algunas acaban corruptas porque excedes la asignacion. Al menos esa es la teoría. Seguramente @Sogun pueda decir algo mas al respecto.

Eso me suena más a un mal direccionamiento de memoria, en el que dinamicamente se va cargando las texturas y cambiando la dirección de memoria, pero no esta debidamente ajustada y al cabo de un tiempo se provoca un error y la dirección de memoria apunta fuera de la textura o a memoria invalida.

radorn escribió:Yo siempre había entendido que precisamente una de las novedades de ese microcódigo es que permitía al RCP leer texturas directamente desde el cartucho durante el renderizado, ahorrando ancho de banda en el bus de la RDRAM, que ya tiene bastante que con el programa, el framebuffer y el z-buffer... Aunque creo que Indi tambien usa alternativas a Z. ¿Sería imposible que Indiana Jones use chips ROM algo mas rapidos de lo habitual?

Volvemos a las mates de nuevo: a 5MB/s una textura de 4KB tarda 0'8ms, a 560MB/s (RAM) tardaría 0'000000071ms. La penalización de rendimiento es brutal, por ahorrarte 71 nanosegundos estas tardando 100.000 veces más. Es mejor que cargue alguna textura en memoria de vez en cuando que ir cargando texturas desde el cartucho. Esto permite que el escenario sea más variado pero no produce mejoras de rendimiento. aunque tampoco lo lastra en exceso.

radorn escribió:La verdad es que lo del Pikachu me interesa mas a nivel tecnico que jugable. Si se te da bien o has avanzado y tienes lugares interesantes que mostrar y tal, me interesa ver, dado que yo no puedo hacer nada de nada. Pero si es para ver como interactuas con Ratachu mi interes es bastante bajo.
Dado que tienes los VRU/VRS's americano y japonés, si que me gustaría ver las tripas y si hay alguna diferencia. ¿Has visto los videos que puse donde se ve el uso con el juego de trenes (parche inglés) y el Majora (en este caso creo que hay que hacer hacking)?

Pues hace un tiempo que los tengo pero no he podido ponerme con ellos. Pero si el gameplay no te interesa si que puedo subir fotos de sus tripas, aunque seguramente serán idénticos con excepción de un chip para cada región.
Y ya que mencionas el Densha de Go, lo probé por curiosidad y me pareció bastante malote. Hasta que me encontré por tierras niponas una subasta de Ebay del mando que imita los controles de un tren real. No digo lo que me costó por vergüenza y por no mancillar el honor del vendedor, pero fue todo un chollo. Pues fue probar el juego con el mando y el cambio es radicalmente espectacular. Te engacha cosa malísima. Eso si, es difícil, muy difícil, no te pasa ni una, pero se rige por las normas de los trenes de allí y son así de rigurosos y chungos.

A la vez que le haga fotos a los VRU se lo haré al mando y explico un par de cositas.

@EMaDeLoC Lo unico que pretendía decir con lo de GoldenEye y las texturas, es que al menos cierta parte de ellas se va copiando a RAM según se necesita, que es de la forma que tu decías interpretar el streaming de texturas de Indiana Jones, y mi razonamiento era que si es así, qué sentido tiene anunciarlo como una característica novedosa cuando se lleva haciendo desde el principio y, francamente, tampoco suena a nada especial. No lo cargas al principio, lo cargas un poco despues... albricias...

Respecto a lo de la velocidad del cartucho, justo ahora acabo de encontrarme esto:
http://en64.shoutwiki.com/wiki/N64_Memo ... terface.29

PI (Parallel Interface)

More on the Peripheral interface.
The PI is the 16-bit parallel bus connection the N64 Game Pak or the N64 Disk Drive. The average transfer rate for the Game Pak is about 5 megabytes per second. (The peak performance is about 50 megabytes per second.) The PI uses DMA transfer to move information from the Game Pak or N64 Disk Drive to RDRAM (data accesses the ROM through the PI registers).

Podría no ser imposible despues de todo. Quizá los de Factor5 (segun he leido por ahí, muchos de los programadores provenían de la demoscene alemana, o sea, expertos en exprimir hardware, con trucos y optimizaciones super ajustadas) encontraron la manera de optimizar los accesos a ROM directos desde el RSP de manera que aprovechasen esos picos de velocidad. Despues de todo, las texturas se siguen cargando secuencialmente en la TMEM y mientras se dibuja con una se va preparando el siguiente acceso o algo así.
Con picos de 50MB/s bien temporizados, no veo tan imposible hacer streaming de texturas tal como cuenta la leyenda. Despues de todo, ¿cuánta carga de texturas únicas tiene cada pantallazo realmente?

Pasando ya a temas menos tecnicos. Yo tambien probé el Densha con el cartucho flash. La primera vez en japonés, sin enterarme apenas de nada, y, obviamente la cagué, y creo que tambien probé brevemente la traducción.
La cosa es que no le encuentro la gracia a conducir trenes de pasajeros a lo profesional, respetando velocidades, horarios, la comodidad de los pasajeros y tal. Eso en la realidad puede ser hasta gratificante, pero en un juego... no le encuentro la gracia a jugar a trabajar, la verdad. Demasiado masoquismo xD
Supongo que el mando especial ese le añadirá cierto aliciente, y hasta puede enganchar. Y creo que se supone que son lineas reales de Japon no? Supongo que para un japonés que se monte en esas lineas puede tener gracia extra, y pasar por algun sitio y reconocer la estacion donde se suelen subir o incluso reconocer su casa si está al lado de las vias. Si los graficos fueran mejores (la verdad, no son para tirar cohetes, y la distancia de dibujado tampoco es apoteósica) hasta podría encontrarle aliciente a ver los paisajes.
No se, la experiencia Densha De GO!! no me convence, al menos no en la version de N64.
Una vez un ex-amigo me mostró otro juego japones de Dreamcast, en este caso de conduccion de autobus urbano... tambien a lo profesional. No se. que es lo proximo, taxi? Patrulla de policia? Barrendero/basurero? Vigilante nocturno? Telefonista? Secretaria? Pero nada de situaciones humoristicas y de fantasía, no, todo profesional.

radorn escribió:Respecto a lo de la velocidad del cartucho, justo ahora acabo de encontrarme esto:
http://en64.shoutwiki.com/wiki/N64_Memo ... terface.29

PI (Parallel Interface)

More on the Peripheral interface.
The PI is the 16-bit parallel bus connection the N64 Game Pak or the N64 Disk Drive. The average transfer rate for the Game Pak is about 5 megabytes per second. (The peak performance is about 50 megabytes per second.) The PI uses DMA transfer to move information from the Game Pak or N64 Disk Drive to RDRAM (data accesses the ROM through the PI registers).

Podría no ser imposible despues de todo. Quizá los de Factor5 (segun he leido por ahí, muchos de los programadores provenían de la demoscene alemana, o sea, expertos en exprimir hardware, con trucos y optimizaciones super ajustadas) encontraron la manera de optimizar los accesos a ROM directos desde el RSP de manera que aprovechasen esos picos de velocidad. Despues de todo, las texturas se siguen cargando secuencialmente en la TMEM y mientras se dibuja con una se va preparando el siguiente acceso o algo así.
Con picos de 50MB/s bien temporizados, no veo tan imposible hacer streaming de texturas tal como cuenta la leyenda. Despues de todo, ¿cuánta carga de texturas únicas tiene cada pantallazo realmente?

Aún suponiendo que se pudieran alcanzar esos 50MB/s, sigue siendo 10 veces más lento que la RAM. No tiene sentido retrasar la rasterización cargando una o dos texturas del cartucho en cada frame dibujado (cada vez que se dibuja un frame se cargan texturas de nuevo) por ahorrarte unos KB de memoria. Es mucho mas ventajoso la rapidez de carga y acceso de la RAM que esos KB que ocupan las texturas.
Hay que ver las cosas en perspectiva: con 200KB de memoria tienes para 50 texturas (recordemos que estan limitadas a 4KB de tamaño máximo). El mito de la compresión de texturas es eso, un mito, la compresión venía de la falta de espacio en cartucho y en especial de modelos 3D, animaciones y sonidos (un segundo de audio WAV a 16bit y 8KHz equivale a 4 texturas, y el sonido no es de una calidad para tirar cohetes). Pero por temas organizativos y de carga optima es mejor meter en el mismo bloque de memoria comprimida los modelos, los sonidos y las texturas que se van a utilizar.
¿Y por qué se anunciaba a bombo y platillo lo del streaming? Primero, creo que el concepto de carga en streaming que pensabas es equivocado. La idea es dividir los datos en dos partes: los que se van usar continuamente y los que se iran usando solo en determinadas circunstancias. Por poner un ejemplo, si en Indiana Jones el prota empieza en una selva, pasa por una cueva y llega a un templo, es un desperdicio de RAM ocuparla en texturas y modelos del templo cuando el personaje se encuentra aún en la selva. Lo ideal es ir cargando las partes necesarias para que se puedan manejar continuamente e ir borrando las que no se vayan a usar, ocupando su espacio con carga nueva.
Esto en esa época era algo nuevo en consolas, ya que normalmente cargaban todo de una vez porque los niveles cabian dentro, eso si la memoria del cartucho no era una propia extensión de la memoria del sistema. Con la carrera de demostrar mejores prestaciones técnicas la gran velocidad de acceso a datos del cartucho frente al CD le daba una ventaja que había que destacar por tema de marketing, motivo para anunciarlo a bombo y platillo.

radorn escribió:Supongo que el mando especial ese le añadirá cierto aliciente, y hasta puede enganchar. Y creo que se supone que son lineas reales de Japon no? Supongo que para un japonés que se monte en esas lineas puede tener gracia extra, y pasar por algun sitio y reconocer la estacion donde se suelen subir o incluso reconocer su casa si está al lado de las vias. Si los graficos fueran mejores (la verdad, no son para tirar cohetes, y la distancia de dibujado tampoco es apoteósica) hasta podría encontrarle aliciente a ver los paisajes.

Pues lo gracioso es que era un juego lo bastante popular como para tener su versión también en PSX y Saturn y hasta continuanción en Dreamcast, PS2, PS3 y otro montón de plataformas.
Los japos, que estan locos.

radorn escribió:No se. que es lo proximo, taxi? Patrulla de policia? Barrendero/basurero? Vigilante nocturno? Telefonista? Secretaria? Pero nada de situaciones humoristicas y de fantasía, no, todo profesional.

Luego la gente se preguntará porqué nos sigue gustando lo retro...

EMaDeLoC escribió:Pues lo gracioso es que era un juego lo bastante popular como para tener su versión también en PSX y Saturn y hasta continuanción en Dreamcast, PS2, PS3 y otro montón de plataformas.
Los japos, que estan locos.

Si, estaba al tanto. Consolas domesticas y portatiles de todo tipo, mobiles, e incluso recreativas.

Ese Taxi Rider de PS2 que pones, he visto un video y parece bastante arcade, con personajes SD, tiempo limite con extensiones y todo eso, y en el video el jugador conducia como un maníaco en contra direccion y no pasaba nada. No es tan loco como crazy taxi, pero simulacion no es.
Este juego de Dreamcast al que me refería. Tokyo Bus Guide:

Lanzado 3 años despues del primer Densha de GO!, claramente inpirado por el. ¿Que hacen trenes? ¡Pues nosotros buses! Tienes que encargarte de abrir y cerrar las puertas en las paradas, que paguen el billete y se sienten, tienes que anunciar las paradas, respetar las normas de circulación, respetando los limites de velocidad, poniendote en el carril correcto, usando el intermitente, asegurarte de conducir de manera agradable, sin frenazos ni acelerones repentinos para no sobresaltar a los viajeros... profesional...

Los otros dos si que son mas de simulacion. El freddy's ese, al que nunca he jugado, no tengo ni idea de qué va. No hace falta que nadie me lo explique. Si me interesa, que va a ser que no, ya lo buscaré xD

En fin, volviendo al tema...

EMaDeLoC escribió:Aún suponiendo que se pudieran alcanzar esos 50MB/s, sigue siendo 10 veces más lento que la RAM. No tiene sentido retrasar la rasterización cargando una o dos texturas del cartucho en cada frame dibujado (cada vez que se dibuja un frame se cargan texturas de nuevo) por ahorrarte unos KB de memoria. Es mucho mas ventajoso la rapidez de carga y acceso de la RAM que esos KB que ocupan las texturas.

Bueno, es que no se trata de ahorrar memoria, si no de ahorrar ancho de banda en el bus de la RDRAM, que tiene que soportar trafico bidireccional para darle de comer a la CPU, renderizar el framebuffer y el Z-buffer (con re-lecturas por cobertura y comparacion y para combinacion de colores, si corresponde), el buffer de audio, la lectura del displaylist, etc... Teniendo en cuenta que uno de los cuellos de botella de la N64 es precisamente el acceso simultaneo a una RAM unificada que tiene una latencia considerable, desplazar, si es posible, alguna de esas colas de trafico a otro bus, parece algo deseable, ¿no crees?
No es cosa de RAM si no de BUS.

EMaDeLoC escribió:con 200KB de memoria tienes para 50 texturas (recordemos que estan limitadas a 4KB de tamaño máximo)

Con TLMMI el doble, dado que no pueden ocupar los 4KB para dejar sitio a los mipmaps.

EMaDeLoC escribió:El mito de la compresión de texturas es eso, un mito, la compresión venía de [...]

No sé por qué me cuentas todo eso...

EMaDeLoC escribió:¿Y por qué se anunciaba a bombo y platillo lo del streaming? Primero, creo que el concepto de carga en streaming que pensabas es equivocado. La idea es dividir los datos en dos partes: los que se van usar continuamente y los que se iran usando solo en determinadas circunstancias. Por poner un ejemplo, si en Indiana Jones el prota empieza en una selva, pasa por una cueva y llega a un templo, es un desperdicio de RAM ocuparla en texturas y modelos del templo cuando el personaje se encuentra aún en la selva. Lo ideal es ir cargando las partes necesarias para que se puedan manejar continuamente e ir borrando las que no se vayan a usar, ocupando su espacio con carga nueva.

Lo que describes, eso de meter y sacar cosas de la RAM (almacenamiento primario, rapido) desde el cartucho o disco (almacenamiento secundario, lento) segun requiera la situación, no es streaming, si no cacheado, y no del que hace la policía. Copiar cosas de un almacenamiento mas lento a uno mas rapido para usarlas durante un proceso, aumentando el rendimiento, es cachéar. Igual que las texturas se cargan en la TMEM en vez de hacer que el RSP lea los pixels de la textura directamente desde la RAM. Lo llamamos "cargar el nivel" o lo que sea, pero es una forma de cacheado. En vez de la forma automática que se hace en muchos ámbitos, es un cacheado mas manual, selectivo, y muchas veces incorpora procesos como descompresion, conversion, y otros, pero, si lo piensas, es cacheado a fin de cuentas. Pones lo que vas a usar inmediatamente "a mano" y quitas lo que ya no vas a necesitar.
A esta forma de cacheado se le puede llamar streaming en el sentido de que esas cargas y descargas de la caché se hacen de forma ininterrumpida y transparente para el usuario (escondiendola con trucos como pasadizos largos y serpenteantes entre una zona y la siguiente), comparado con los procesos mas habituales que interrumpen brevemente el juego mientras se carga o cachea lo nuevo. Pero en mi opinion es un uso un tanto generoso del termino.

Una cosa donde la PS1 si hace streaming, por ejemplo, es en el uso de STREAMS (que apropiado) XA de audio y video, que se leen directamente del disco, tal como si fueran audio en CD sin ser movidos previamente a la RAM para ser leidos desde ahí. Esto es mucho mas similar a lo que estamos hablando aquí con el Indiana Jones.
Todos o casi todos los juegos de N64 hacen habitualmente dos tipos de streaming: Los samples de audio que usa el proceso de renderizado MIDI, y los datos de animacion para los objetos. El RCP los lee directamente de la ROM sin ser copiados a RAM primero. No es una formula fija del hardware, si no una recomendacion del SDK que la gran mayoría de los juegos siguieron y para la que las librerías oficiales están preparadas y optimizadas.
ESO es streaming puro y duro.

Para ahondar en el concepto streaming, tambien está el caso del audio y video en internet. La implicacion del concepto en este caso es que el material se reproduce a medida que los datos van llegando del servidor remoto, y no hay que descargar una copia completa del archivo antes de empezar la reproduccion. Eso no quiere decir que no se pueda usar un buffer, cosa muy recomendable, ni que el buffer enorme, o incluso hacer una caché tan grande como la pista entera. Sin embargo la idea es reproduccion inmediata con lo que sea que tengas. El resto son añadidos.

En el caso del streaming de texturas desde el cartucho en N64, lo que hace que sea streaming y no una carga o cacheado normal, es precisamente que no se hace una copia local, si no que se usa "directamente". En este ámbito, podríamos considerar que la TMEM, que es normalmente considerada una caché, vendría a equivaler al buffer de un video o audio.

En fin, es todo disquisicion semántica, y al final ni tu ni yo sabemos a ciencia cierta qué hace realmente el microcodigo de Factor5 y en qué consiste el tan traido y llevado "streaming" de texturas. Yo siempre he oido, en muchos ambitos, que lo novedoso es que lee las texturas directamente desde el cartucho durante el renderizado en vez de cachearlas en la RAM, y por ahora no he oido ningun argumento definitivo para descartarlo. De todos los motivos que has dado, el unico que veo que tiene potencial para desbaratar "mi" teoría, es el del limitado ancho de banda del PI, pero como ya hemos visto, podria no ser tan definitivo, y yo entiendo que ahorrar trafico en el bus de la RDRAM, uno de los cuellos de botella de la consola, supondría un gran beneficio.

radorn escribió:Bueno, es que no se trata de ahorrar memoria, si no de ahorrar ancho de banda en el bus de la RDRAM, que tiene que soportar trafico bidireccional para darle de comer a la CPU, renderizar el framebuffer y el Z-buffer (con re-lecturas por cobertura y comparacion y para combinacion de colores, si corresponde), el buffer de audio, la lectura del displaylist, etc... Teniendo en cuenta que uno de los cuellos de botella de la N64 es precisamente el acceso simultaneo a una RAM unificada que tiene una latencia considerable, desplazar, si es posible, alguna de esas colas de trafico a otro bus, parece algo deseable, ¿no crees?
No es cosa de RAM si no de BUS.

Es que no ahorras ancho de banda.
Según el esquema del RCP del manual que suponemos exacto:


Y este otro esquema de otro manual de 1999, supongo que una revisión ya que incluye el 64DD:


El RCP usa el mismo bus para conectar el RSP y RDP con los distintos perifericos, incluidos la memoria y el cartucho. Eso es como un cuello de botella pero al ser interno seguramente tendrá ancho de banda de sobra para para cubrir las tareas necesarias.
El caso es que a menos que el bus sea de doble canal, que lo dudo mucho, o el esquema se equivoque, que siendo oficial debemos suponer que no, solo puede haber un bloque de datos moviendose por él a la vez.
Si se cargaran las texturas del cartucho directamente a la TMEM, nos encontramos con que mientras se hace la carga por el bus no puede pasar nada más hasta que la textura se haya cargado. Y como la velocidad del bus no podrá ser mayor que la velocidad del cartucho, tenemos que el resto de dispositivos deben esperar a que se cargue la textura para pasar información.
Ciertamente se trata de un tiempo muy corto al ser tan solo de 4KB máximo, pero sigue siendo varias veces más lento que usar la RAM. De nuevo estas ralentizando un trabajo por ahorrar un poco de RAM y nada de ancho de banda, no sale a cuenta la penalización de rendimiento.
Por dar una idea de como se vería penalizado, en el mismo tiempo que se cargaría una textura de 4KB desde un cartucho a la velocidad pico de 50MB/s, se habrían cargado al menos 11 texturas desde la RAM. Y eso si existieran los cartuchos con esas velocidades, que dudo mucho que hubiesen aumentado el coste del cartucho en mejor ROM para un proceso que no supone ventajas técnicas.

En cuanto a la diferencia entre cachear y streaming... Practicamente no hay, los dos terminos se refieren a la carga de datos desde otro dispositivo, aunque streaming se relaciona más para datos en la nube y cachear a una memoria específica situada entre la CPU y la RAM (las famosas caches de nivel 1, 2 o 3 de los procesadores actuales). Pero los dos procesos son muy similares en la base.

Lo del mito de la compresión de texturas lo he comentado porque esta implantada la creencia que eran las texturas las mayores perjudicadas por la falta de espacio de los cartuchos, pero en realidad hay otros datos que ocupan más y se ven más afectados en calidad por ese límite.

@EMaDeLoC En esos esquemas falta una cosa, a mi juicio. Ahí se ve un bus que recorre el RCP y conecta el RSP, RDP, y la I/O y luego sale como RBUS. Si nos lo tomamos al pie de la letra los componentes internos del RCP se conectarían mediante protocolo RDRAM, lo cual no tiene sentido ninguno. RDRAM es un bus externo para un tipo de memoria concreto y necesita un controlador. Para los propósitos de esta conversacion, esa flechita que sale del bus interno debería tener, antes de salir, un bloque que representase dicho controlador. Ese controlador lidia con el modo de acceso y las latencias de la RDRAM y tendrá sus buffers FIFO y demás. El I/O y la RDRAM no están conectados exactamente al mismo bus, y no veo imposible que el arbitraje de todo eso, teniendo en cuenta la latencia de la RDRAM, permita, mediante programacion creativa, unos accesos optimizados.
El bus interno del RCP puede ser mucho mas rapido que el acceso externo a la RDRAM, intercalando trafico entre los diversos componentes sin pasar necesairamente por la RDRAM y su bus.
Fijate que el RCP accede incluso a la CPU principal de la consola mediante la interfaz I/O.

Ese bus interno del RCP no creo que sea un bus compartido donde todos los componentes tratan de hablar a la vezcon colisiones y demás, ni tampoco por turnos preestablecitos, en anillo, porque desperdiciaría mucho tiempo en turnos innecesarios. Mas bien, lo logico sería que haya hay un controlador, que arbitra todo el trafico, con búfers FIFO y demás refinamientos, y seguramente obedezca las pautas que ordene el RSP, que es donde se ejecuta el microcódigo.

EMaDeLoC escribió:En cuanto a la diferencia entre cachear y streaming... Practicamente no hay,

Totalmente en desacuerdo, por lo que he explicado anteriormente.

@radorn Buena observación. A los esquemas les falta detalle sobre los controladores de memoria, aunque en el segundo ya especifica un bus de RAM (RBUS) y un bus serie (SBUS).

Aún así, la TMEM no carga dos texturas a la vez sino una tras otra (creo que puede cargar dos o más si caben, pero no estoy seguro) lo cual lleva a que...

EMaDeLoC escribió:en el mismo tiempo que se cargaría una textura de 4KB desde un cartucho a la velocidad pico de 50MB/s, se habrían cargado al menos 11 texturas desde la RAM.

Y vuelvo a lo mismo, valga la redundancia: en el tiempo que cargas una textura del cartucho habrías podido cargar y procesar varias texturas desde la RAM. Por mucha latencia que tenga la RAM de la N64, no se compensa cargando datos directamente desde el cartucho al RDP.

Creo que te has perdido un poco con la literalidad del concepto "streaming" (o lo que fuese) que usaron para describir la carga de datos nuevos durante la ejecución del nivel. Al menos yo siempre lo había entendido así.

Reconozco que mi razonamiento en este momento es asumir que streaming significa lo de leer texturas de ROM a TMEM sin pasar por la RDRAM, y con los datos que van saliendo voy rellenando los agujeros. Por ahora me convence bastante lo que digo, y sigo creyendo que el unico obstaculo potencial es la velocidad de acceso de la ROM, que reconozco que a 5MB es imposible, pero a 50 podría no serlo tanto, teniendo en cuenta todo lo demás. Pero vamos por partes.

Yo no he dicho que se carguen dos texturas seguidas en la TMEM. Mi enfoque es el que ya dije antes. ¿Estamos de acuerdo en que cada pantallazo no tiene porqué requerir una cantidad ingente de texturas? Y cada una de ellas no tiene porqué ocupar la TMEM entera. Además, recordemos que raramente un juego de N64 corre a 60 o 50 fps, Mas bien tienden a 20 o menos, 30 con suerte. Incluso una escena que use 500KB de texturas, renderizando a 30fps son 15MB/s, así no nos acercamos a esos 50MB de pico, y tengo la impresion de que 500KB de texturas por pantalla es una cifra generosisima. Tambien soy consciente de que estoy haciendo equilibrios con esto, confiandome en exceso en una cifra pico que es 10 veces superior a la cifra de media, pero tambien hay que recordar que esa cifra de 5MB es para transferencia DMA desde el cartucho a la RDRAM y en este caso nos estaríamos saltando la RDRAM por completo, lo cual podría aumentar esa cifra.

@Conker64, tu que has hecho tantas pruebas de este estilo, capturando escenas y analizandolas con conteo de poligonos y demás, ¿te has puesto tambien a medir la cantidad y peso de las texturas en cada escena? Si tuvieras alguna del Indiana Jones fantástico, pero siendo que aún acaba de salir el plugin que lo soporta como es debido, y sin saber si con el se pueden hacer este tipo de dumpeos (con funciones internas o capturando la salida del "backend" grafico), no se si no será pedir la luna xD.

EMaDeLoC escribió:en el tiempo que cargas una textura del cartucho habrías podido cargar y procesar varias texturas desde la RAM

Cargar, si... procesar, ya es otro cantar. Entre textura y textura el RDP tiene que dibujar, cosa que, viendo ese esquema, implica escribir a la "MEM" del RDP y transferir a RDRAM, potencial y, me atrevería a decir que, habitualmente, se producen mas datos salientes al framebuffer que de texturas entrantes se toman, sobre todo si tenemos en cuenta que el frame/color-buffer normalmente tiene un Z-buffer asociado y que del primero a veces hay que releer para combinar colores para efectos de transparencia, y del Z siempre hay que comparar el valor nuevo con el extistente para no cargarse el mapa de profundidad. O sea, que hay UN MONTON de trafico a la RDRAM comparado con las texturas que entran en la TMEM. Si añadimos la lectura de texturas a la RDRAM, como es habitual, pues mas congestion en ese bus, uno de los talones de aquiles de la consola, gracias, especialmente, a la latencia re respuesta.
Yo veo una clara ventaja en aliviar un bus congestionado como es el de la RAM y reconfigurar el RDP para copiar las texturas a la TMEM directamente desde el cartucho en vez de que compitan por el ahogado trafico de la RDRAM.

EMaDeLoC escribió:Por mucha latencia que tenga la RAM de la N64, no se compensa cargando datos directamente desde el cartucho al RDP.

Si aislásemos la carga de texturas en la TMEM, te daría la razon sin mas de que es mas rapido cargarlas desde la RDRAM habiendolas cacheado ahí previamente. Pero, mi enfoque es distinto. No se trataría de ganar velocidad en la carga de texturas, si no ahorrar trafico a la ahogada RDRAM, usando un recurso potencialmente infrautilizado y que potencialmente sería suficiente.
Voy a intentar hacer una lista, así a botepronto, de las cosas que transitan cada bus:

--BUS CPU-RCP:
-entran Instrucciones y datos para ser procesados
-salen datos resultantes e ordenes para otros componentes.

--BUS RCP-PI
-durante el arrangue, se transfieren datos del cartucho a la RAM y se arranca el programa principal, y este carga mas datos de la ROM
-durante el funcionamiento del juego, se cargan todo tipo de datos bajo demanda a medida que los demande la CPU
-El RSP ejecuta en cada frame uno o mas microcódigos de audio y video, y los ejecuta sobre las displaylists y audiolist que la CPU les indique, que, a su vez, resultan en instrucciones de bajo nivel que son ejecutadas por el RSP o RDP según corresponda.
-Alternativamente la CPU puede mandar comandos de bajo directamente al RDP y al RSP para producir audio o video, pero esto es mucho mas lento, pues hay que mandar la un monton de instrucciones de bajo nivel y ser leida desde la RDRAM, en vez de mandar una lista y el microcodigo que la decodifica y produce internamente esos comandos que se consumen directamente dentro del RCP en vez de pasar por la RDRAM.
-Ya sea mediante comandos directos o mediante microcodigos y listas, todo esto resulta en lecturas y escrituras a la RDRAM, el PI (escritura, en juegos comerciales, para SRAM y Flash en puntos concretos del juego, aunque 64DD y cartuchos especiales, como los flash, tambien aceptan escritura en el rango normalmente destinado a la ROM, claro) y resto de los buses en menor medida.
-Los datos que mas habitualmente transitan el PI en cada frame, son datos de animacion que usa el RSP para montar la escena pedida por la CPU (aunque tambien la CPU podría depender de ellos, dependiendo del juego), y samples leidos directamente del soundbank de la ROM para "tocar" la musica y los efectos de sonido.
-Cargas iniciales grandes de niveles y datos asociados, y lecturas esporádicas de otros datos, segun juego, para carga y descarga dinámica.

--BUS RCP-RDRAM
-lectura de instrucciones de parte de la CPU.
-lectura y escritura de datos a y desde la CPU.
-lectura y escritura del frame/color buffer y el Z-buffer asociado
-datos de geometría: lectura para procesdo y DMA desde ROM. Raras veces, también, modificacion: Por ejemplo, simulacion de deformacion de objetos por daños... dependiendo de cómo esté programado.
-texturas: transferencia por DMA desde ROM y lectura por parte del RDP durante el renderizado.

En fin... repito una vez mas, para ser molesto, que la RDRAM está ahogada, y es una de las causas principales de las caidas de rendimiento. Es algo que se dice en todas partes. Veo una clara ventaja en relevarla y cargarle todo lo posible a otro bus. Cargarle las texturas al PI sin cachearlas en RAM parecen una opcion interesante, si logras mantener una cantidad razonable por escena y si no apuntas a un rendimiento altisimo.
De ser todo esto posible, admito que el el ahorro de trafico en la RDRAM tampoco creo que dé como para unas ganancias espectaculares, pero ese poco que se gana, podría dar para estabilizar un poco el framerate, no perdiendo los V-Syncs tan a menudo obligando a repetir cuadros, o alguna otra ventaja.

No se... ojalá tuvieramos datos mas concretos y así no tendría que estar siempre con hipótesis de estas xD

@radorn A ver, empiezo por lo de siempre: no se gana nada de rendimiento cargando la textura directamente del cartucho. La base de tu argumento es que alivias ancho de banda de la RAM y eso sería cierto si la RAM se estuviera utilizando simultáneamente con otro proceso, pero resulta que la RAM solo está conectada al RCP, por lo que si el RCP no la usa, se queda desaprovechada. En el proceso de rasterización se van cargando las texturas en la TMEM conforme se necesitan, una a una. Si cargas una de un medio lento como un cartucho inevitablemente ralentizas el resto. Y aunque el rasterizado de una textura sea lenta, tardar unos microsegundos más de lo normal siempre supondrá una desventaja. Y encima con unos 50MB/s que sinceramente yo no me los creo.
Es decir, tú te estás centrando solo en la RAM y has de incluir todas las partes por las que pasan datos: RAM, bus de la RAM, bus del RCP, TMEM. Ralentiza uno y ralentizas todos, por lo que de nada te sirve aligerar la RAM y su bus si ralentizas aún más el bus del RCP y la TMEM cargando de un medio lento.

Ahora el resto por orden.

No he dicho que tú hayas dicho que se cargaban dos texturas en la TMEM, eso lo he dicho yo porque algo me suena que podria haber más de una textura y así mejorar el rendimiento, pero no estoy seguro de ello. Lo que sí que es indiscutible es que solo puede cargarse una textura a la vez, venga de donde venga, ya que la TMEM no es de doble canal (solo puede entrar un bloque de datos cada vez).

Conker64 dijo hace un tiempo que lo habitual era que un frame tenga unas 15 texturas diferentes, lo cual serian 60KB al máximo tamaño de textura. No parece mucho, pero multiplica por 50.000 polígonos por segundo, cifra también habitual, y como no ahorres texturas en alguna parte la cosa se te puede ir de madre (muchos polígonos usan una misma textura o ninguna, por lo que hay un ahorro importante).

Tu suposición es correcta y se producen más datos durante la generación del framebuffer que datos entrantes durante la carga de texturas. Pero cada retraso en cualquier parte del proceso se va a ir acumulando sin piedad en el proceso completo, ya sea en la carga de texturas desde cartucho, el uso de 2CYCLE en el rasterizado o el buffer Z al generar el framebuffer.
Aparte por la forma de trabajar la memoria y la organización del framebuffer, cada línea dibujada se opera como un bloque de datos independiente. Esto significa que a la hora de enviarlo a memoria se hace todo el proceso de escritura completo: iniciación, dirección donde empezar, tamaño del bloque, envío del bloque en si, finalización. Hacer todo eso miles de veces ralentiza, y por eso para optimizar se quitan líneas de pantalla, las texturas de fondo se ponen en bloques horizontales o se quita el buffer Z si se puede.

Creo que cada vez queda más patente que la generación de un frame es un proceso en el que intervienen muchas partes y todas tienen que rendir al máximo o se perjudican mutuamente. La idea de cargar la textura del cartucho a la TMEM podría funcionar en otra arquitectura preparada para ello, pero para nada sirve en la de N64.

@radorn
Hola, no me he leído muy bien toda la conversación desde el principio pero veo que va de streaming.

Desde el cartucho no podrías cargar directamente las texturas a TMEM, Set Texture Image (comando 0x3D en el RDP) requiere la dirección de DRAM donde se ha almacenado la textura (el puntero), es el primer paso a más bajo nivel antes de cargar una textura o paleta.

No recuerdo ahora mismo si existe algún truquillo oscuro para hacer que lea de otro lado, podría preguntar en el chat si algún día paso.

La CPU se puede configurar para copiar a cache, que el programa solicite una operación sobre esa información y se realice ahí mismo, sin tener que tocar la RAM, eso puede ser útil a la hora de manipular datos siempre que quepan en los 8KB de datos.

Si lo que se ha cargado sirve como información de programa no hay que hacer nada, si es para recurso hay que volcar el resultado a RAM, el RCP no puede acceder a la cache de la CPU.

El número de texturas por escena se podría mirar mejor pero creo que depende mucho del juego, me he encontrado algunos que tienen más de 60 texturas cargadas en RAM, pero en pantalla se muestran menos, a veces tienen las del menú, etc

En 2D pueden llegar a utilizarse muchísimas texturas a la vez, si usaras 320x240 con tiles de 16x16 necesitarías 300 texturas para rellenar 1 solo plano de scroll donde ninguno de los tiles se repite.

@EMaDeLoC Supongo que es es bastante seguro asumir que el bus interno del RCP solo admite una transferencia en cualquier direccion. No se si ese es el caso, pero digamos que si. Lo que no encuentro por ahora es ningun dato seguro de que no puedan tener datos a la espera en algun buffer, y, aprovechandose de ellos, optimizar el uso del del bus, teniendo siempre algo en la cola, por asi decirlo. De esto no tengo la seguridad ni de que si ni de que no se pueda. Tu pareces asumir que no se puede.

----------------------------- ACTUALIZO -----------------------------

Bueno, pues voy a finalizar el debate en tu favor, @EMaDeLoC.
Definitivamente la teoría que he defendido hasta ahora no puede ser cierta. Todos los que han escrito sobre el tema, diciendo que se renderizaba desde el cartucho, no se de donde se lo sacaron, pero se equivocan.
He cargado el Indiana Jones con el 64drive y mi super-duper conector en T, he llegado a la primera fase, esperado a que se quede quieta la camara, he retirado el cartucho, y el juego ha seguido corriendo como si nada, con texturas y todo.
Además, recientemente he hecho unas modificaciones a la carcasa del 64drive para que se vea la luz de la LED de actividad, y no parpadeaba durante la ejecucion, ni siquiera para un efecto de sonido de una catarata que había al fondo.
El hecho es que no parece leer casi nada desde el cartucho en tiempo real, lo cual imposibilita que sean las texturas para el renderizado, pues eso debería mostrar un acceso continuo al cartucho, y no hay ninguno.

Al final, las texturas se van a la RAM tambien y ya no se sabe en qué consiste ese "streaming", si es algo real, especial, en qué beneficia, o si es un mito y/o un intento de marketing para la prensa especializada de entonces. Sa lo que sea no parece que lo vayamos a solucionar aquí. En mi opinion, una caché bien administrada en RAM, donde entran y salen texturas segun el contexto, no me parece algo a lo que se le deba aplicar el concepto de "streaming", y desde luego no me parece nada particularmente novedoso, teniendo en cuenta que otros juegos ya hacían lo mismo o algo muy parecido.

Una pregunta aparte de los ports amateur del Doom 1&2 ,¿hay algún juego de N64 que utilice la técnica del Raycasting?,Doom64 es poligonal, no sé si el DN64 lo es.
¿Y técnicamente es posible mezclar raycasting para escenarios y polígonos para objetos/personajes, y de ser así sale rentable en rendimiento?

Salud.

@dirtymagic De juegos oficiales no me suena ninguno que use raycasting, todos van por 3D incluido el Duke Nukem. De todas formas por aquí hay más conocedores del catálogo que yo.

En cuanto a mezclar raycasting y polígonos, supongo que si podría ser tecnicamente posible. La parte de raycasting la haría la CPU por software, ya que el RCP no esta preparado para ello, y se usaría de fondo para renderizar encima objetos polígonales. No saldría rentable pues no ganas rendimiento y supone un problema cuando haya objetos asomando por esquinas, además de que el raycasting daría escenarios como poco detalle y el trabajo de crear un motor que trabaje con ambos... Vamos, que al final se obtienen mejores resultados y es más fácil de manejar todo tirando solamente del 3D.

Es que como no sé cuánto consumo de CPU sería montar un escenario en raycast para tener de fondo en un juego de lucha y que el RDP se encargue sólo de los luchadores, sombras y tal vez el suelo, más que nada para tener algo más de profundidad que un fondo recreado con imagenes y tal vez poder tener más carga poligonal en los luchadores, había pensado en el raycast más que nada por que funciona en CPU menos potentes que la N64 y a lo mejor salía a cuenta .

Salud.

Con el motor adecuado no consumiría mucha CPU. El Doom de 1993 funcionaba bien en un 486 y la CPU de la N64 es bastante más potente. Pero mezclar ambos modos creo que sería el problema.

Para que te hagas mejor una idea, Mortal Kombat 4 va a 60fps, es todo 3D y se ve bastante bien.

EMaDeLoC escribió:La parte de raycasting la haría la CPU por software, ya que el RCP no esta preparado para ello

Igual me estoy colando, pero, por lo que yo se, programando el microcodigo adecuado, podrías hacer que el RSP calculase lo que quieras. De hecho, en github hay un proyecto (https://github.com/PeterLemon/N64/tree/master/EMU/SNES/) de emulador de SNES para N64 que usa microcódigo para que el RSP emule el PPU, o al menos parte de el. Las demos que hay solo muestran una imagen estática, pero bueno, la idea es el proceso que las genera.
Claro que el RDP se quedaría mirando al techo, supongo.

¿No era tambien que RE2 decodificaba MPEG por RSP?

De todas formas, teniendo todo en cuenta, a mi tampoco se me antoja el raycasting como una gran ventaja en N64. Hay partes esenciales del hardware que desaprovecharías y no tengo muy claro de qué manera se podrían usar conjuntamente con una CPU o RSP que están ocupadas con el raycasting.
No le veo mucha ventaja, no, pero puedo equivocarme.

@radorn Te quedas a media colada. Si, el RSP se puede programar pero partes siempre de que solo maneja polígonos. Recuerda que el modo 2D tanto de N64 como PSX es en realidad polígonos paralelos a la pantalla (a diferencia de Saturn que son sprites con multiples transformaciones), y como es muy potente moviendo gráficos, sería una tontería no aprovecharlo para manejar los sprites y fondos de la SNES emulada.
Así que se podría programar el RSP para manejar un raycasting, pero lo que haría sería traducir el sistema 2D de raycasting a 3D y que el RSP manejara los polígonos... No sería entonces un raycasting real, sino una forma de crear un mapa 3D al vuelo a partir de información 2D. Es como los circuitos de F-Zero, que no son modelos completos en 3D sino curvas de beizer que dibujan el circuito y el juego las interpreta para convertirlas en 3D.

Sobre el vídeo de RE2, he encontrado un artículo muy completo sobre como lo hicieron. Completo a nivel técnico, una maravilla: https://ultra64.ca/files/other/Game-Developer-Magazine/GDM_September_2000_Achieving_Full-Motion_Video_on_the_Nintnedo_64.pdf
Resumiendolo, la parte de descompresión la hace la CPU, y el reescalamiento lo hace el RCP, ya que el vídeo esta a unas resolución menor de 320x240.
Hay un microcódigo para descomprimir JPEG que no sé si se utilizó con el vídeo de RE2. En ese caso el RCP descomprimiría el fotograma de referencia del JPEG, la CPU calcularía los frames intermedios y de nuevo el RCP haría el reescalado de cada frame y su salida a vídeo. Pero tengo mis dudas ya que si la descompresión no se hace por el RDP usando la potencia del rasterizador sino por proceso normal... Pues estaría trabajando de forma muy parecida a la CPU pero a menor velocidad de reloj, por lo que sería mucho más eficiente descomprimir en la propia CPU.
Cuando tenga un rato y me haya leído con tranquilidad el artículo ya lo comentaré por aquí.

@EMaDeLoC El RSP procesa display lists y produce comandos para el RDP, pero tambien procesa audio lists y saca PCM para el búfer de audio. Es un poco mas general que simplemente "procesar poligonos".
Creo que si se podría hacer raycating estilo doom y demás en el RSP y transferir los resultados directamente a un framebuffer si se quisiera y que no está todo limitado a tratarlo todo como un polígono y pasar por el RDP antes de salir en pantalla.
No digo que sea buena idea, solo que se podría.

@radorn Ya, el RCP parte de un MIPS 4000, así que algo si podría hacer, pero la parte principal de proceso está dirigida a trabajar con polígonos y dado como es el raycasting, no creo que el RCP haga algo distinto a lo que haría la CPU pero de forma mucho menos eficiente.

Interesantisimo, yo tengo un doctor v64 que también es una rareza de esta consola

Yo pensé en el raycast más que nada por que es un cálculo en teoría menos complejo que rasterizar polígonos, no encuentro el blog donde salía la fórmula matemática de raycast junto al rasterizado y el raytracing, me suena que hacía 2 operaciones menos.
Pero vamos que es más complejo desarrollarlo que el posible rendimiento que se pueda sacar.

Salud.

@gran_borja V64 normal o Jr?

radorn escribió:@gran_borja V64 normal o Jr?

Pues creo que el normal porque en la carcasa pone doctor v64 solamente.. Tú también tienes uno? Además tengo todo el catálogo en cds...

@gran_borja No, yo nunca tuve un copión de los clasicos, pero cuando los descubrí por internet, pasada ya su epoca, babeaba con el Dr V64 Jr, mas que nada porque era el unico con 64MB.
El V64 normal y el Jr son muy diferentes. Ya diciendome que tienes todo en CDs me aclaras la duda de que es el normal, porque el Jr es basicamente un cartucho muy gordo y todo se carga desde el PC por puerto paralelo. No tiene lector integrado ni nada.

Hay versiones de 32MB (256Mbit) y 64MB (512Mbit) y tambien con varios nombres.
Por un lado el V64 Jr, llamado así por su precio reducido al no tener CD y ser mucho mas pequeño
Pero tambien salieron "versiones profesionales", una como Doctor 512, hecha por la propia Bung Enterprises de Hong Kong, e incluso parece que otra empresa, Mr. Backup, de USA, conocidos por el Z64 (el copión mas avanzado de la epoca), les compró a los de Bung el diseño y lo re-etiquetaron como E64 Cartridge Emulator.
Creo que todas son basicamente el mismo hardware y funcionan con las mismas aplicaciones desde el PC.

Imágenes ocultas para no molestar la navegación


Mas info sobre el V64 Jr https://videogamedevelopmentdevices.fan ... tor_V64_Jr.

Estoy probando a ver cómo quedaría el mítico mapa de Counter Strike de_dust2 portado a Nintendo 64.

Las imágenes pertenecen al motor gráfico de GoldenEye y todavía queda mucho trabajo hasta convertirlo en un mapa funcional, pero como prueba me sirve. De momento tengo todo el mapa cargado al mismo tiempo, lo que significa unos 7500 polígonos (aunque evidentemente no se ven todos a la vez). Moverse por él con un único jugador no es fluído, y funciona a dos jugadores a unos 10 fps o menos (no me he atrevido a comenzar un tiroteo). No he conseguido que cargue a 3 o 4 jugadores, aunque cuando el mapa esté terminado debería ser posible y además ganar mucha fluidez.

Dejo 4 imágenes con 4 configuraciones de texturas distintas y una pequeña explicación del porqué.


Dejo esto para que se vean las distintas alternativas que permitía la caché de Nintendo 64 y como cada opción tenía sus pros y sus contras.
También podéis discutir acerca de qué combinación haríais vosotros. Sería la leche que alguien consiguiera sacar una imagen del Counter Strike 1.6 original en ese mismo punto para comparar.
A ver si mañana busco e instalo el plugin gráfico de Angrylion y saco capturas más acordes con lo que se vería en el hardware original. O si no puedo sacar fotos guarras de la tele, jeje.

@Sogun Personalmente tiendo a preferir el aliasing de texturas al emborronamiento del TLMMI.
Respecto al tema del color, resulta sorprendente todo lo que se pierde a pesar de la aparente monotonía cromática de un escenario desertico como ese. Uno pensaría que no debería haber problema por usar escala de gris y color de fondo, pero supongo que no es tan sencillo. Igual alguien con mucho conocimiento de manipulación gráfica sabría exprimir un poco mas el tema, aunque tambien calculo que habilidades como esa, gracias a las generosas capacidades del hardware actual, están mas bien desaparecidas.

En fin, si quieres captura directa por S-Video, pásame unas ROMs/parches y saco algo.
Aquí algunos ejemplos que grabé hace tiempo: https://www.youtube.com/playlist?list=P ... zkNOf7Rlp4

Por cierto, hace muchos años, creo que antes de que aparecieses por allí, otro usuario, monkeyface, tambien hizo unos cuantos mapas importados de counterstrike. No se si ese estaba... La verdad es que no estoy familiarizado con CS. El caso es que de aquella solo usó texturas CI8 de 32x32, sin coloreado de vertices, sin portales... Aún se acababa de incluir en el editor la capacidad de convertir geometría nueva. Siendo tan viejo seguro que quedó catalogado para la posteridad en el último GoodN64, aunque no creo que corra en hardware.