Hilo de detalles y curiosidades de N64

Sí, para evitar más confusión:

RCP pre lanzamiento: 60.85Mhz (muchos de los benchmarks a ésta velocidad)
RCP final: 62.5Mhz

CPU R4200 en documentos de 1995/94
CPU R4300i final, abaratamiento de costes, bus de 32bit, alguna optimización en enteros..

Conker64 escribió:RCP pre lanzamiento: 60.85Mhz (muchos de los benchmarks a ésta velocidad)
RCP final: 62.5Mhz

Leches, ¿era más lento? Y yo asumiendo que habrian recortado velocidad y no aumentado.

Con esto del cambio de microcódigos se me ha ocurrido que quizás podría conseguirse un Wave Race a 30 fps en lugar de los 20 fps a los que funciona realmente.
Supongo que requeriría de trabajo extra porque existe un código de Gameshark para desbloquear el framerate y el juego funciona muchas veces a 30 fps (e incluso se llega a poner en algún punto a 60 fps) pero va todo acelerado. La verdad es que sería un juego muy interesante de probar.

Recuerdo que cuando salió el Star Fox 64 en la consola virtual de Wii el emulador iba tan sobrado que se habían eliminado las ralentizaciones y la gente se quejó porque esos tirones quedaban bien y facilitaban tiroteos masivos (era una especie de tiempo bala). Al final relanzaron el juego "embrutecido" para que se jugara como en el hardware real.

Mmmm, PilotWings 64 y Bomberman 64 creo que tienen el framerate desbloqueado también. PilotWings 64 se pone a 60 fps en el hardware original si se mira directamente al cielo y Bomberman 64 funciona en emuladores a 60 fps pero en consola lo recuerdo muy lento (sólo lo he jugado en PAL). No creo que puedan funcionar a 60 fps, pero 30 fps estables ya sería de agradecer.

@Sogun Las diferencias de velocidad en emuladores no son siempre trasladables de vuelta al hardware.
Esto lo entiendo a un nivel muy superficial, no tanto a nivel programático, pero, una de las cuestiones es que, emulando N64 mediante HLE, si bien hay limitaciones que tienes que respetar por compatibilidad, una cosa que no te limita es la velocidad de proceso. Hay cosas en las que CPU y RCP tienen que estar muy sincronizados, los voy a llamar, quizá incorrectamente, "simétricos". Mientras que otros son asimetricos, en el que basicamente la tarea se completa "cuando esté". A esto lo llamaré "asimétrico".
El proceso de renderizacion en N64 generalmente se lleva a cabo con el motor del juego corriendo en la CPU, ejecutando la logica del juego, y, en cada punto temporal de la ejecución, actualizando el estado del juego y produciendo una display list que representará visualmente ese estado para el jugador, siendo la mision del RCP convertir eso en una imagen proyectable en la pantalla.
Tecnicamente el proceso de renderizado es una tarea que potencialmente podría llevar hasta el infinito completar, pero esto son cuestiones teoricas que no nos preocupan dado que una de las tareas de los programadores es asegurarse de que eso no pase, y que, además, cada pantallazo se pueda completar en un tiempo razonable.
Hay motores y motores y algunos hacen que el ritmo del juego dependan, de manera total o muy estricta,de la velocidad de renderizado, con lo cual si sube o baja tambien se mueve el juego a camara lenta o rapida. Otros son mas adaptables y adaptan el ritmo del juego a la velocidad de renderizado disponible (siempre dentro de unos limites, claro... no creo que, por poner un ejemplo, la logica de ningun juego pudiese extrapolar el paso del tiempo entre pantallazos separados por 10 segundos o mas, sin colgarse).

Lo que pretendo explicar con todo esto es que, en un emulador que haga HLE del RCP o el RDP o lo que corresponda, es muy posible, y es lo que creo que sucede, que, en motores de los asimetricos, el RDP dice "ya acabé" antes que en el hardware, porque su proceso no está totalmente atado a los ritmos y limites del hardware real, al reemplazar la ejecucion del microcodigo sobre los displaylists, por unos procesos aproximados por ingenieria inversa que producen un resultado similar al original, pero que, en esencia, poco o nada tiene que ver con el. De esta manera, a ojos del motor del juego, solo tiene que satisfacerse lo que, en esencia, equivale a "displaylist recibido > procesando > listo", la CPU recibe el mensaje y envia el siguiente displaylist si lo tiene. En emulacion HLE este proceso puede ser potencialmente varias veces mas rapido que en consola, y, si el motor está diseñado para aprovecharlo, el resultado es mas framerate.

En fin, no estoy muy fino en este momento, y creo que he dado muchas vueltas y me he repetido, pero espero que la idea se entienda.

La optimización de microcódigos podría, potencialmente, reducir el tiempo de proceso por cuadro, y si el motor se aprovecha de ello (o se puede modificar para que lo haga), el resultado evidente es mayor rendimiento.
Tambien estaría bien buscar la mejora o eliminacion de filtros y otras cuestiones. A fin de cuentas, el RCP usa microcodigos precisamente por flexibilidad. Ya era hora de poder moldear esa masilla

@EMaDeLoC
Yo le hubiera subido algo más ya que estaban

En N64 al tener memoria unificada todo lo que sea sanear accesos iba a mejorar el rendimiento global, yo creo que hasta cogiendo la libultra + el código de un juego y compilando en GCC 8.x ya se obtendrían algunas mejoras sin tocar nada de nada.

Dado que eso no es posible, salvo que empiecen a filtrarse códigos como el del Mortal Kombat, mirar lo de los uCodes + las llamadas internas de libultra no es mala idea.

@Conker64 Siempre que sale el tema del overclock en consolas, hace que me pregunte qué factores exactamente les llevaron a no darle un poco mas de caña al hardware.
Osea, se que mas ciclos es mas desgaste y mas posibilidad de devoluciones en garantia (o ganarse la reputacion de chapuceros), mas requerimiento de refrigeracion y mas posibilidades de variacion entre una maquina y otra y eso no es aceptable en una consola, especialmente las de entonces, que no tenían CPUs con las modernidades de la autoregulacion del rendimiento en funcion de la carga y temperatura, y basicamente eran maquinas sencillas, de modo único y donde la consistencia asboluta entre un ejemplar y otro es esencial.
Sin embargo, como aficionados, siempre nos queda la duda de si se pasarían de precabidos, y cuales fueron los motivos concretos de la especificacion final.

@radorn
Supongo que eso que dices, jugar con las frecuencias es una opción con riesgo, siempre me ha parecido que la memoria iba bien calentita.

Otra opción de aumentar el rendimiento sin tocar frecuencias podría haber sido añadirle 2MB de baja latencia a la CPU y eliminar la expansión, si tenemos en cuenta que es muy raro que un programa supere 1MB, aún le quedaría otro para crear las variables, estructuras, etc

La RDRAM que lleva la consola en realidad no es mala para renderizar, especialmente cuando son bloques grandes, pero la CPU desde luego entorpece ahí.

Aunque claro el precio.., pero es lo primero que hubiera pedido a la carta de los reyes

Buscando información sobre los ucodes existentes en la N64 para comprender la viabilidad en su reemplazo me encontré con la siguiente información

Dark Rift: Único juega que usa el Turbo3D.
https://www.ngemu.com/threads/dark-rift ... ed.100661/
https://gamefaqs.gamespot.com/boards/20 ... 440?page=7

T3DUX: ucode evolución del Turbo3D que es usado en varios juegos japoneses
(Last Legion UX, Shin Nihon Pro Wrestling Toukon Road - Brave Spirits and Shin Nihon Pro Wrestling Toukon Road 2)
https://github.com/gonetz/GLideN64/wiki/T3DUX-ucode

Hilo donde explican como descargar algunos ucodes:
https://hack64.net/Thread-Fast3D-Microcodes

GLideN64:
Listado de ucodes implementados por este plugin de video
https://github.com/gonetz/GLideN64/tree ... src/uCodes

Pues si el Dark Rift usa el Ucode Turbo3D (600.000 pol/seg sin correcion de perpectiva,iluminación,antialiasing y filtrado bilinear de texturas) lo disimula muy bien por que a mi me parece que tiene la misma calidad y rendimiento que la Fast3D (¿90.000 pol/seg? con todos los efectos activados).

Salud.

@dirtymagic
Dark Rift siempre ha dado problemas de emulación, con la descripción "Missing players", lo más probable es que el uCode rápido solo se aplicara en los personajes (dónde está la mayor cantidad poligonal) y usaran un uCode estándar para los escenarios, que vienen con su filtro, corrección de perspectiva, etc

Como ya sabréis corre a 60fps, eso es un buen indicativo

(Ya me quedan menos mensajes)

A mi no me parece que mueva más polígonos que por ejemplo MK4 que también va a 60fps, cuando la carga poligonal con el Turbo3D debería ser más elevada.


Salud.

No tiene porque mover más, simplemente a ese equipo con las herramientas de ese momento usar ese uCode les dio el rendimiento extra para llegar a 60fps estables.

Ni siquiera se sabe si intentaron primero con Fast 3D y luego con esa solución, con el mismo tipo de assets.

Pues le he echado un ojo al Dark Rift y tienes que fijarte mucho pero si, se ven pequeños defectos aquí y allá, lo más evidente son texturas que se retuercen un poco según la orientación del polígono. Pero tienes que tener al personaje en primer plano y que tenga un polígono grande con una textura bien visible para notarlo, y aún así no molesta. Así que en plena batalla ni se nota.
Lo que me ha llamado la atención es que las texturas tengan filtro bilineal, y efectivamente en el manual de programación de todo lo que no soporta el Turbo3D no se menciona ese filtro.
Pero claro, que no tenga clipping ni luz dinámica supone varios inconvenientes extra.

Y a mi también me parece que podría usar el Fast3D y alcanzar el mismo framerate sin demasiado esfuerzo.

Sobre el ucode T3DUX por lo que indican es una evolución del Turbo3D el cual no conocia.

¿Veis alguna de las caracteristicas del turbo3D que indique en efecto parte de ese ucode?
¿Que nivel de poligonaje existen en esos juegos?

Parece que ya puedo poner imágenes, a partir del próximo aporte intentaré centrarme más en los juegos, con algo de análisis por encima, creo que será más ameno.

BENCHMARKS
Así que vamos con los datos que estaban pendientes, las siguientes imágenes están sacadas de PDF oficiales.

Los datos de geometría nunca han estado claros, pero aquí tenemos un tabla oficial de benchmarks usando el micro código pre lanzamiento Fast 3D, como se ha ido comentando a lo largo del hilo, pintar con solo goraud tendría un rendimiento mucho más elevado que hacerlo texturizando todas las superficies, también tenemos el impacto del Z-Buffer por separado.



Se asume conseguir tan solo un 50% de esos resultados en un entorno de juego real, donde además de generar polígonos hay iluminación, clipping, etc.. faltaría por confirmar si el programa y el audio van en ese porcentaje, en tal caso, recogiendo el peor dato (los 124K), nos quedarían 62K, lo cual es bastante realista, muchos juegos de lanzamiento estaban en la franja de los 60K, hasta los 120K+ que llego a mostrar en World Driver Championship.



Pero el cálculo no es tan sencillo, ya que el número de polígonos que podremos pintar depende del fillrate, pintar rectángulos es más rápido que pintar triángulos, además, para conseguir un pico similar al de los benchmarks hay que hacerlo en grandes superficies, en éste caso hablan de bloques de 320x240, dónde así le sacan más partido a la RDRAM.

En su día hice un test exactamente igual, con los mismos resultados en copy: 88Mpx, en libn64 los resultados serían superiores.

c write = color write, copia directa
rmw = read-modify-write, copia con varias operaciones
block load = rendimiento subiendo texturas a TMEM (4KB cache)
z = z dando por saco



A partir de ahora los siguientes benchmarks son con el RCP a 60.85Mhz, antes de que lo subieran de rendimiento para el lanzamiento final de la consola.



Qué tal los sprites? Bueno aquí tenemos una gráfica dónde he marcado un test exactamente igual que ya he mostrado algunas veces:



Como vemos el rendimiento es prácticamente el mismo, sprites de 16x32x16bits, que libdragon no llegue a los 60fps puede deberse a que me vi forzado a usar AA para 60hz (bug consola), los textos están pintados con la CPU y a que probablemente libultra sea algo más rápida que libdragon, incluso con el clock a 60.85Mhz, definitivamente lo es cuando se usa el RSP, pero en este test no es necesario.



En el siguiente texto se explica en que consiste el test y en confirmar varios apuntes que se han ido dando desde hace años:
- Texturas, rectángulos o triángulos con mayor tamaño horizontal que vertical: Mayor rendimiento, el RDP lee y escribe por linea horizontal, cuando llega al final salta a la siguiente, esos ciclos pueden ahorrarse con éste tipo de composición, además de otro tipo de optimizaciones
- Importancia en el alineamiento



Vale, pues ya tenemos geometría del Fast 3D por un lado y fillrate máximo teórico por el otro (el cual no es demasiado dependiente del micro código, sino del modo de ciclo empleado), qué pasa cuando los mezclas? Pues la siguiente gráfica:

La gráfica muestra una curvatura de rendimiento número de polígonos VS el tamaño de los mismos:
- Más pequeños, mayor cantidad de ellos
- Más grandes, mayor utilización del fillrate disponible



1) Corresponde a Turbo 3D
2) Corresponde a Fast 3D



Ahora ya empezamos a tener una buena lista de datos, nos dicen que el equilibrio perfecto entre el RDP y el RSP son triángulos de 32 pixeles, así que probablemente la lista de arriba del todo tenga como referencia triángulos de un tamaño similar, entre 18-32, obviamente están hablando de la base del triángulo, si fuera por cada lado serían del tamaño del triángulo 1 de ésta imagen que he compuesto, pero en realidad son como el tríangulo 2. (8*8/2 = 32)



Eso es, la consola podría poner 180K triángulos goraud del tipo 2 de esa imagen, que parece pequeño? Pues en absoluto, los modelos 3D suelen estar compuestos de muchos polígonos pequeños, aún más si se trata de resolución 320x240, ahora si se acercaran a la pantalla? Pues mal asunto, pasarían a ser gigantes, pero hay juegos que saben mantener siempre la cámara bien alejada, ah sí, esos triángulos estirados horizontalmente como debe ser.



En Dark Rift desde luego se preocuparon por conseguir los 60fps.



Otro ejemplo: Fighters Destiny 2, muchos polígonos pequeños para los luchadores, sin embargo han optado por un fondo compuesto por tiles de 64x32 en lugar de estirarlos, bueno peor sería que fueran de 32x64..



Pasamos al audio, siempre se ha dicho vagamente que la consola puede poner 100 voces, usando un 1% para cada voz, bueno vamos a matizar un poco con la siguiente gráfica donde se usa a la CPU y se muestra el porcentaje de uso:

- Como vemos el porcentaje varia no solo con el tipo de frecuencia utilizado, sino con los fotogramas a los que funciona el juego, éste dato en realidad es curioso, porque aunque el programa funcione a 60fps podrías colocar un semáforo para que el audio se actualice menos veces por segundo, aumentando el tamaño del buffer que envía por cada ronda.



El porcentaje de uso utilizando un micro código de audio para el RSP, dado que en éste test se menciona el uso de reverb, es probable que también esté aplicado en el de CPU, parece que el caso del RSP no es el número de eventos lo que más consume, sino la frecuencia utilizada.



No es de extrañar que Boss Studios moviera el audio a la CPU en el temprano Top gear Rally.

* Los tests no representan el rendimiento definitivo de la consola, sino el de los micro códigos: Fast 3D, Sprite2D y la librería inicial de audio.

@Conker64 Me has inducido felicidad para todo este finde.

La verdad que todas esas cifras "pico" dan buena idea del rendimiento de la consola y son buena base a la hora de diseñar un juego en la consola. Lo que hace inexcusable lo que algunas desarrolladoras hicieron con algunos juegos teniendo la revisión de los microcódigos que mejoraban esos datos.

Me ha gustado mucho que pusieras la parte del audio porque es un gran marginado cuando se habla de rendimiento de la consola. La verdad que comerse hasta el 30% del rendimiento en el sonido es un gran sacrificio, pero dudo que un juego de entonces necesitase 16 voces a 60fps. Creo que con 8 ya sería un apartado sonoro notable y a 30fps comerse el 15% ya es más asumible. Y no es lo ideal, pero 32khz es una calidad sonora bastante buena. El problema aquí si que es el espacio del cartucho, ya que el sonido sin una buena compresión ocupa mucho.
Entiendo que sería de ayuda usar la CPU para mezclar voces o música y así quitarle algo de carga al RSP.

Por cierto, con eso de que empeora el rendimiento del audio a 60fps se puede considerar otra prueba del cuello de botella que es la memoria y que mejora su rendimiento cuanto más grande sea el bloque de datos que haya que manejar.

@Conker64 excelenteeeee....

@EMaDeLoC
No pierdes casi nada, por no decir nada, poniendo el audio a 32kHz de muestreo. Eso da para 16kHz de ancho de banda de audio. ¿Tienes una TV de tubo? ¿Oyes el pitido? pues eso son 15.6kHz de audio. ¿Es un sonido que te interese oir? crees pierdes gran cosa por no oirlo? Puede aportar ALGO de claridad extra a sonidos con componentes de alta frecuencia, como platillos, cristales rotos, alguna explosion... cosas así. Sin embargo, para que realmente digas "hm, aqui falta algo", tendrías que estar haciendo un test de audicion, oyendo una y otra vez la version con y sin para decir, "ah, si, hay una diferencia". Si el original no lo tiene, tampoco es algo que vayas a echar de menos, mucho menos si estas metido en el juego...
Todo esto suponiendo que tu oido de para tanto.

En mi opinion no pierdes nada por poner el audio a 32. Yo hasta lo pondría un poco mas bajo si con eso gano rendimiento en otras areas. De hecho, salvo que haciendo pruebas con los efectos de sonido y la musica viese que realmente se pierde algo significativo al bajar de 32, yo empezaría con el juego a 22 o 24, y luego, si veo que puedo, lo subo.
Muchos juegos de N64 van a 22.5, incluso juegos muy apreciados, y no he visto a nadie quejarse de que el sonido suene amortiguado ni nada por el estilo. El problema de la calidad de los samples es otra cosa.

Hace meses colgué en el hilo (y "copipasto" mas abajo) una lista con todas las frecuencias de muestreo de los ripeos USF.
Hay ejemplos de juegos con gran musica, como Goemon, que van a frecuencia de CD ~44.1, es cierto, pero estoy seguro de que resampleas eso a 32, y sigue sonando cojonudamente sin perder casi nada, porque la clave, me parece a mi, es la calidad de los samples y la densidad musical de la composicion, no tanto que vaya a 44.1kHz



Para que veas, muchos de los grandes no llegan ni a 24, y algunos de los que mas suben tampoco son recordados por su departamento sonoro, vamos, que yo no me preocuparía, Empezaría con 22-24 y ya mas tarde, si eso, reajustas y se lo subes. Lo principal es exprimir el rendimiento en la imagen.

Ahora que habláis de la calidad de sonido...

El otro día me puse con Diddy Kong Racing en el flashcart y me llamó la atención que se oía fatal. ¿sabéis si bajaron la calidad de sonido en este juego en concreto? ¿puede ser que mi ROM esté mal?

@cegador
Podría ser que se te hayan corrompidos los datos en la SD, si, pero, con esa descripción es dificil de decir.
¿Que quieres decir exactamente con que "se oía fatal"?

@radorn Ahora mismo no podría describirlo:

Una bajada de calidad respecto a los otros juegos que estuve probando.

Lo probaré este finde y prestaré más atención y os comento.

Edito: Lo estoy escuchando en videos de youtube y a mí se me oía peor, seguiremos informando

@Conker64
¡Excelente información! Voy a estudiarla meticulosamente porque tras una primera lectura hay cosas que me sorprenden y otras a las que no les encuentro el sentido.

Así de primeras, viendo la gráfica de la Figura 1-2 queda claro que el rendimiento de la consola está limitado por el fill-rate y no por la cantidad de polígonos.
Según interpreto, el techo de triángulos por segundo que puede mostrar la N64 es la barra horizonal A: unos 150.000 triángulos por segundo -> 2500 polígonos en pantalla a 60 fps.
Lo que me raya es lo del tamaño de los polígonos, siendo el rendimiento peor cuando más grandes son (aunque a partir de cierto tamaño apenas afecta). El cruce de la curva 2 con la línea A da unos 18 píxeles por triángulo; pero 18 píxeles de área y no triángulos de 18x18 píxeles. Si cogemos los 2500 triángulos de antes nos sale una área de 45000 píxeles, que es una resolución entorno a los 240x180 píxeles (una resolución normal de 320x240 son 76800 píxeles). Si queremos llenar más pantalla hay que tirar de más polígonos (por lo que ya no alcanzamos 60 fps) o hacer los triángulos más grandes (por lo que también baja la cantidad de triángulos por segundo que se pueden mostrar, perdiendo los 60 fps).

Haciendo números buscando una resolución de 320x240 y un rendimiento de 60 imágenes por segundo:
-Hay que asumir que el fill-rate supone una losa y que el techo son los 100.00 triángulos por segundo de la línea C. Esto da 1666 triángulos en pantalla a 60 fps.
-Entonces el tamaño de polígonos óptimo es de 32 píxeles por triángulo, pero tampoco puedes rellenar toda la pantalla (son 53312 píxeles -> resolución de pantalla cercana a 256x210)
-Para llegar a 320x240 hay que usar polígonos más grandes. A partir de triángulos de 128 píxeles parece que el conteo se estabiliza a unos 38.000 triángulos por segundo (633 triángulos a 60 fps). Con 633 triángulos llenas 81024 píxeles, que es un poco más de los 320x240 que ando buscando.
-Conclusión: para un juego de 320x240@60 fps puedes mostrar unos 650 polígonos en pantalla con todos los efectos activados. Pero si usas Turbo 3D te da igual empezar a quitar efectos y filtros porque no puedes aumentar el número de polígonos. Habría que cambiar a Fast 3D para conseguir un nuevo techo de unos 140.000 triángulos por segundo (2300 triángulos en pantalla) y aún así te daría lo mismo usar texturas o no. ¿Y se supone que esto es en condiciones óptimas y que un juego comercial andaría al 50% de rendimiento?

Super Mario 64 con sus 320x224@30fps dibujaría en pantalla 1300 triángulos según los cálculos que he hecho y me cuadra bastante.


Sé que no es una ciencia exacta y que cuando se empiezan a mezclar triángulos pequeños de los personajes, triángulos más grandes para los escenarios pero en muy poca cantidad, skyboxes en otros modos (GoldenEye lo hace con rectángulos en lugar de triángulos) y efectos como transparecias los resultados son impredecibles. También habrá otros microcódigos posteriores que mejoren el rendimiento. Sin embargo ¿Lo he planteado mal o son mis pesquisas válidas?


Otra cosa. Cuando se menciona que dibujar rectángulos es más rápido que dibujar triángulos ¿Se refiere que un un rectángulo es más rápido que dibujar dos triángulos (te ahorras 2 vértices)? ¿O un rectángulo más rápido que un triángulo (no le veo el sentido)? También me gustaría aclarar si se pueden crear modelos tridimensionales con estos quads (como Saturn) o si están restringidos a cosas 2D. Modelar los escenarios con quads podría ser una alternativa muy válida.

Por último, cuando dice que es mejor renderizar "a lo largo" que "a lo ancho". ¿Tanta diferencia en el rendimiento hay como para que se tenga en cuenta? Ya me habían comentado que las texturas es mejor almacenarlas como 64x32 en lugar de 32x64 (supongo que por la forma en que se lee la información), pero es la primera vez que lo leo aplicado a los polígonos mostrados en pantalla.

Sogun escribió:Por último, cuando dice que es mejor renderizar "a lo largo" que "a lo ancho". ¿Tanta diferencia en el rendimiento hay como para que se tenga en cuenta? Ya me habían comentado que las texturas es mejor almacenarlas como 64x32 en lugar de 32x64 (supongo que por la forma en que se lee la información), pero es la primera vez que lo leo aplicado a los polígonos mostrados en pantalla.

Es posible que se deba a como se ejecutan los bucles para renderizar la pantalla, que se harán por líneas horizontales.
Intentaré explicarlo de forma que lo entienda quien no ha programado nunca.
Para renderizar algo en pantalla primero haces una línea y cuando acabas sigues con la segunda, y luego la tercera, y así hasta cubrir todas las líneas. Para renderizar un pixel de cada línea se ejecuta el algoritmo correspondiente y al acabar se pasa al siguiente pixel. Cuando se acaban los píxeles de la línea, entonces se pasa a la siguiente línea.
Cuando se pasa de un pixel a otro, solo se hace una suma para indicar al algoritmo que trabaje con el siguiente píxel. Pero para pasar a la siguiente línea, se hace la suma, salta la condición de fin de línea, se suma uno al número de línea y se pone a cero el número de pixel para que el algoritmo empiece desde ahí. Es decir, para pasar de una línea a otra se hacen varias operaciones más que para pasar de un pixel a otro.
Imagina entonces que has de dibujar 100 píxeles de una misma línea. Además del algoritmo harás 100 sumas. Pero si dibujas 100 píxeles en una columna, es decir, 100 líneas de un pixel, harás 100 sumas de pixel, saltará el fin de línea 100 veces y pondrás a cero el número de pixel otras 100 veces, además de ejecutar el algoritmo. Estarás por tanto ejecutando más operaciones para dibujar una columna que una línea.

Supongo que Conker64 me corregirá, pero así en lo básico debe ser algo así la diferencia de rendimiento.

@Sogun
Sí, la gráfica engaña un poco porque da por sentado un incremento igual del área de todos los polígonos, pero en un juego real habría todo tipo de tamaños.

Tiene toda la pinta de que por ejemplo 1 solo triángulo de un área de 512 sería más rápido que 16 con área de 32 (512), creo que los cambios no serían proporcionales, ya que a la RDRAM se le da mejor pintar zonas grandes y hay menos cálculos claro.

Donde llegan a la conclusión es que de ser todos los triángulos de un mismo tamaño, el punto óptimo sería 32.

Otra cosa. Cuando se menciona que dibujar rectángulos es más rápido que dibujar triángulos ¿Se refiere que un un rectángulo es más rápido que dibujar dos triángulos (te ahorras 2 vértices)? ¿O un rectángulo más rápido que un triángulo (no le veo el sentido)? También me gustaría aclarar si se pueden crear modelos tridimensionales con estos quads (como Saturn) o si están restringidos a cosas 2D. Modelar los escenarios con quads podría ser una alternativa muy válida.

- A la hora de dibujar rectángulos no hay que calcular los coeficientes de cada esquina, sombra, textura ni z-buffer, por ejemplo para formar el coeficiente de texturas se requieren 8 comandos de 64bits, ni redondear coma flotante con floorf para cada vértice, luego la figura resultante es más fácil de dibujar para el chip.

Los rectángulos tienen funcionalidad limitada, no puedes proyectar, ni rotar sin hacer movidas raras, no sé hasta que punto podrían usarse en 3D, según como los configures son una copia 1:1 de la textura, rectángulo y textura de un mismo tamaño, eso es muy rápido.

Por último, cuando dice que es mejor renderizar "a lo largo" que "a lo ancho". ¿Tanta diferencia en el rendimiento hay como para que se tenga en cuenta? Ya me habían comentado que las texturas es mejor almacenarlas como 64x32 en lugar de 32x64 (supongo que por la forma en que se lee la información), pero es la primera vez que lo leo aplicado a los polígonos mostrados en pantalla.

Sí, renderizar a lo ancho es más rápido que a lo largo, el chip está optimizado para pintar así y como dice EMaDeLoC hay operaciones extra en los saltos de linea.

Eso incluye cualquier tipo de dibujado, en un triángulo el chip acaba rellenando esquinas de muy pocos pixels, en un rectángulo depende, si es a lo ancho todas las lineas forman la misma longitud y hasta se puede llegar a alinear con la memoria (por lo menos en tests específicos).

Esto me hace pensar que las resoluciones estiradas no serían mala idea, en plan 640x240.

En el caso de los sprites la diferencia es muy notoria si nos fijamos:
16x32 = 1140
32x16 = 1610

@EMaDeLoC
Tiene sentido lo que dices porque efectivamente hay más operaciones pero no sé hasta qué punto sería destacable la diferencia y si tu explicación se aplicaría más a resoluciones que a la forma en la que se dibujan los polígonos en la pantalla. Sí que sería más eficiente renderizar a 480x240 que a 240x480 según lo que comentas.

Aplicado a polígonos tendría sentido si también se hiciera una operación cada vez que se cambia de polígono, que supongo que es lo que ocurre:
-Para un fondo de 320x240 píxeles formado por "tiles" horizontales de 320x6 píxeles se haría una operación de cambio de polígono por línea, la operación de cambio de línea y otra operación de cambio de polígono cada 6X+1 líneas. En total 240*2+240+39=759 operaciones.
-Para un fondo de 320x240 píxeles formado por una malla de "tiles" de 64x32 píxeles se harían 8 operaciones de cambio de polígono por línea, la operación de cambio de línea y otra operación de cambio de polígono cada 32X+1 líneas. En total 240*9+240+9=2169 operaciones.
-Para un fondo de 320x240 píxeles formados por una malla de "tiles" de 32x64 píxeles se harían 18 operaciones de cambio de polígono por línea, la operación de cambio de línea y otra operación de cambio de polígono cada 64X+1 líneas. En total 240*18+240+3=4563 operaciones.

Sí que se observa un incremento importante en el número de operaciones pero habría que ver si hacerlas supone un coste despreciable en el proceso y el rendimiento se ve afectado por otras tareas. Tendría sentido tenerlo en cuenta en hardwares poco potentes, pero creo que no es el caso de la N64.

Ahora me surge la duda de los tiles de 320x6 porque tenía entendido que una textura no podía ser más grande de 256 píxeles en una dirección. Pero la pantalla de título de Mario Kart 64 tiene tiles que ocupan todo el ancho de la pantalla y creo que de 4 píxeles de altura... No, acabo de comprobarlo y son tiles de 320x2 píxeles aunque no sé si de 16 o 32 bits (no necesitan paleta y caben en la caché).


EDIT
@Conker64.
Mientras escribía y hacía mis cálculos has publicado tu mensaje.

Se me había olvidado comentar que en mis cálculos anteriores si en lugar de triángulos se usasen rectángulos te ahorrarías la mitad de cambios de polígono por línea así que sería más rápido.
Ya veo que dices que estos rectángulos no se pueden proyectar así que quedarían relegados al uso de fondos. Lo cual tampoco está tan mal si puedes pintar en pantalla rápidamente texturas a resolución nativa y con 16/32 bits de profundidad de color. Para ello habría que usar un método similar al de Super Mario 64 o Super Smash BROS (fondos 2D que parten de imágenes de mucha resolución) en lugar de skyboxes de juegos como Diddy Kong Racing o los Zeldas. Para un port de Tekken 3 vendría de perlas.

De todas formas está el cielo de GoldenEye (y por tanto Perfect Dark) que el propio Martin Hollis nos explicó en el foro de shootersforever que funcionaba de esta manera:

"A technical note on the emulator screenshots: Because we used a fairly undocumented and not-encouraged low-level RDP drawing command to draw the sky in one primitive (4 sided triangle, if you like) no emulator has been able to draw the sky, as far as I know. I'd be happy to fill in the general details if someone wants to tackle the problem, basically it sets step rates for the attributes per change in x and y for the rectangle; I guess only GoldenEye does this, because, well, I thought it was a good idea. Probably not a good trade-off of programmer time to performance gain in retrospect, and worse, none of the emulators can draw the sky which is a shame."

Luego Zoinkity le corrigió:

"Oh, it is supported now by Glide.

The actual problem had to do with how that code compiled. It made a series of RDP half commands that split up the generated low-level RDP tri commands, and up until the Glide project neither of those were emulated (at least within GE's microcode emulation). Crazy code too. It's rather handy that the next generation of microcode removed the requirement for the half commands, so the RSP simply passed RDP commands along without modification.

Of course, low-level emulators have never had a problem with it, for obvious reasons."

Y Martin Hollis lo confirmó:

"Ah I see the sky is handled by Glide. Yes the standard microcode needed to be fed two half RDP commands so the RSP would assemble and pass on. It is pretty cool to see people working these things out from the other end, as it were."

De ahí entiendo que está dibujado a partir de un rectángulo con una textura que se repite varias veces en ese rectángulo y a la que se le aplica corrección de perspectiva, filtros y scroll. Algunos emuladores no lo pueden renderizar en absoluto y alguno (Rice) sólo dibuja el rectángulo con la textura tal cual (y la textura se aplasta y estira dependiendo de la porción del cielo que se ve, ocupando todo el "vacío":

@Sogun
Anda el post de Martin Hollis tiene 7 años ya, yo pensaba que sería algo reciente

Lo del rectángulo es interesante, por ejemplo según configuración el filtrado solo funciona si la textura es más grande que su tamaño original, en este caso claro, está estirada.

Cuando una textura se repite puede invertirse vertical o horizontalmente, aquí parece una imagen cíclica que encaja por cualquier lado, aunque igual de hacerlo el patrón sería menos visible:


Luego estaría la movida rara con el scroll, por un lado hay un movimiento continuo (fácil) y luego la sensación de profundidad que se adapta a la proyección, lastima que no comentara que comando a bajo nivel tan poco documentado se refiere, imagino que la mayoría de emuladores solo entendían que ahí había que dibujar un rectángulo con textura pero no que hacer con él.

--
Estoy mirando qué juegos podría revisar, creo que la idea esa que hay en el otro hilo de jugar conjuntamente a algún juego no vendría mal

@Conker64 he visto un vídeo donde dicen que Fighters Destiny 2 funciona a 60 fps, y en un post tuyo antiguo dices que maneja 2200 polígonos por frame lo que daría 130-135 k pol/seg lo cual me parecería raro, o la geometría que sacastes no tiene descarte de polígonos mediante clipping y backface culling (con este activado supongo que recortaria a 1200-1500 pol/frame algo más viable con el potencial de la N64) o el juego no va a 60fps.

Salud.

@dirtymagic
Dónde viste ese vídeo?

No recuerdo que ningún Fighters Destiny fuera a 60fps.

Conker64 escribió:@dirtymagic
Dónde viste ese vídeo?

No recuerdo que ningún Fighters Destiny fuera a 60fps.

Aqui:


Dice que en el segundo le dieron un subidón de frames hasta los 60 FPS, lo que no se si lo dice a ojimetro.

Una duda que me ha quedado, ¿con que sacas más rendimiento con texturas cuadradas o con rectangulares en horizontal?

Salud.

@dirtymagic
Ah creía que igual sería algún análisis, lo acabo de probar en consola y a ojo parecen 30, desde luego la parte del mapa 2D de la ruleta donde puedes hacer scroll son 30, ahí es más fácil de ver si estás familiarizado con la programación 2D.

A igualdad de tamaño la textura horizontal es más rápida que la cuadrada

@dirtymagic ni caso al tipo ese en otro vídeo dónde enseña su colección de megadrive habla de su reproducción del snowbros como si fuese original.

Pues acabo de ver otro video de juegos de N64 de otro canal y dice que el sin and punishment va a 60 fps, yo creo que la gente se a jugado los juegos en emulador o como había muchos juegos con framerates bajitos o inestables,que cuando hay uno a 30fps estables da la sensación de ir mucho más suave.

Salud.

He sacado algunas capturas nuevas directamente de la tele

El emulador de Game Gear, no tiene un menú como tal, en el pack que dispongo son roms separadas inyectadas junto al emulador en un v64, el rendimiento no es muy allá, el sonido mejor bajar el volumen de la tele , el vídeo viene configurado con random dither, eso no debería usarse en 2D.


El emulador de NES ya es más conocido y bastante exótico, con el marcador de fps en hexadecimal, el cual rara vez llega a 60fps, Little Samson es un buen juego sin duda, pero el emu no soporta todos los mappers disponibles, así que hay otros como Akumajou Densetsu que no arrancan.


Y aquí tenemos el menú del emu, take screenshot me inquieta pero no voy a pulsarlo no vaya a ser que me destroce el controller pak.


Command & Conquer en modo Hi-res, debo decir que me fascino cuando lo alquilé en su día.


La sala de Quake 2 con el extraño círculo en el medio, sí, por alguna razón dejé el juego en ese nivel y me da pereza continuar, pero todo lo que jugué estaba genial, el caso es que si terminas la fase con más armadura y munición se conservan para el próximo nivel, así que siempre guardo cuando sale una partida "óptima".


Oops, ha salido todo ésto al pulsar L en el menú de pausa de Zelda Master Quest beta, mejor no tocamos de momento, no vaya a romperse algo.


Yo lo que quería era volar, lo que sorprende del Zelda es que la mayoría de mapeados fueron estudiados minuciosamente para saber donde rellenar y dónde no, total quién iba a pensar que iba a volar a esa altura para ver Lon Lon Ranch, creo que se puede llegar a rascar más de esa beta y estaría bien analizarla.


Siempre pongo imágenes del cementerio, pero ésta vez he conseguido capturar un rayo.


Leon tiene el calzado muy limpio, en realidad no es de las imágenes donde más destaca la nitidez del modelado sobre el escenario.


En Perfect Dark siempre me ha gustado ese detalle con el reflejo, las plantas y rocas con sombra, lo hacen más sofisticado y alejado de los escenarios en forma de cubo, es un detalle tonto pero está ahí, bueno en realidad ocultaron un ítem junto al charco así que desde luego no querían que el trabajo pasara desapercibido.


.. si miramos el lado positivo el modelado como la textura tienen la suficiente calidad como para que el móvil lo identifique como una cara.


Vale ahora si lo dejo..

Estupendo aporte, pero siempre me quedo con ganas de más.

Conker64 escribió:Oops, ha salido todo ésto al pulsar L en el menú de pausa de Zelda Master Quest beta, mejor no tocamos de momento, no vaya a romperse algo.

Traduzco, para quien interese, las etiquetas en rojo.
De izquierda a derecha y de arriba a abajo:
Rupias - Corazones
Objetos (Items)
Key (evidentemente)
Amor/Equipamiento - Extraños (creo que se refiere a los NPC y su relación)
Map
Sellado - Piedras espirituales (la piedras Sheikah seguramente)
Ocarina
Recoger - Kisosuta (¿?) - Fragmentos

No he encontrado que es kisosuta, pero el google translate me lo quiere corregir como gasosuta, que es gasolinera. Kiso es beso (kiss), y quizá, puede, tal vez, se refiera a estaciones de beso, o en el Zelda donde se encuentran las hadas ya que dan las magias lanzando un beso. Un poco rebuscado, lo sé, pero no se me ocurre otra cosa.

Conker64 escribió:Y aquí tenemos el menú del emu, take screenshot me inquieta pero no voy a pulsarlo no vaya a ser que me destroce el controller pak.

No lo puedo asegurar, pero creo que los pantallazos se guardan en el rango ROM y tienes que extraerlo manualmente desde el PC por USB. En la epoca de los copiones, en la que todo este hardware se conectaba al PC por perto paralelo, era un estandar de facto usar el rango 0x200000 para enviar archivos a un programa ya subido a la N64. El propio Neon64 inicialmente se creó para ser cargado por copion (o con un AR/GS, hackeando, con codigos, un bootloader que arrancaba el emu enviado por paralelo al cargar la partida 1), y carga la ROM presente en el rango 0x200000. La puedes pre-incrustar en la ROM del emu o cargarla despues enviandola a esa direccion a traves de tu copion o AR/GS. Por eso el emu tiene una pantalla de inicio y hay que presionar START antes de que arranque el juego. Así puedes mandar una ROM diferente sin re-arrancar la ROM del emu, que, especialmente usando un cartucho de trucos, se hace muy tedioso.
Se puede hacer lo mismo hoy en dia con el 64drive por USB (¿tambien por ED64?). Cargas el emu y luego puedes estar enviando ROMs por USB todo el dia sin apagar la consola, copiandolas al rango 0x200000.
Creo que los pantallazos tambien se guardan en el rango ROM de la N64, pero en un sitio diferente a 0x200000, claro.

Respecto al CPak, incluso si lo usas solo para guardar partidas de NES, ¿no usa acaso su propio formato? Creo que guardaba hasta 3 partidas de NES en un formato incompatible con el oficial que usan los juegos licenciados.
Aunque no hagas pantallazos, no puedes usar el mismo CPak para Mario 64 y Super Mario Bros. xD. Hay una version especial de Neon64 en 64drive que guarda en SRAM de cartucho, y ahora el menu lo que hace es crear una partida en la SD, como si fuera un juego normal, cuando cargas una ROM de NES. Puedes usar el CPak tambien, si te empeñas, pero no tiene sentido.
¿Tambien existe eso en ED64?

EMaDeLoC escribió:Traduzco, para quien interese, las etiquetas en rojo.
De izquierda a derecha y de arriba a abajo:
Rupias - Corazones
Objetos (Items)
Key (evidentemente)
Amor/Equipamiento - Extraños (creo que se refiere a los NPC y su relación)
Map
Sellado - Piedras espirituales (la piedras Sheikah seguramente)
Ocarina
Recoger - Kisosuta (¿?) - Fragmentos

Actualizo lo que hay en negrita:
Sellado se refiere los 6 sabios sellados de la segunda parte del juego:


Mientras que las piedras espirituales son las de la primera parte:


@radorn El ED64 tiene USB, pero desconozco como funciona para realizar debug de ROMs o pasar ROMs nuevas.
No he probado a realizar capturas de pantalla en emulador de NES, así que ni idea de donde guarda las capturas. Si tengo un momento compruebo esto último.

EMaDeLoC escribió:Amor/Equipamiento

El ED64 tiene USB, pero desconozco como funciona para realizar debug de ROMs o pasar ROMs nuevas.

https://krikzz.com/store/home/28-everdrive-64-v3.html
Ahí hay una seccion de descargas donde está esta utilidad de linea de comando http://krikzz.com/pub/support/everdrive-64/loader64.exe
No teniendo un ED64, no tengo ni idea de como funciona. Es posible que necesites un driver para el chip USB del cartucho.

@EMaDeLoC


Veo útil el de cambiar de mapa, porque la beta ya empieza con casi todo desbloqueado, aunque imagino que para betatesting vino genial ese menú para poder probar situaciones y ver si había incompatibilidades, en plan si hacías las cosas en diferente orden te quedabas sin poder avanzar por cierto bug.

A ver si hago un análisis de tipo "curioso" de la beta, aún conozco un bug relacionado con los bombchus que nunca he visto a nadie comentar en internet y se lía parda, porque deja al juego todo roto y empiezan a pasar cosas.

@radorn
No podía parar a mirar demasiado, en realidad saqué muchas más capturas de otros juegos pero mientras en el móvil no se veían mal, al pasarlas a pc para recortarlas y subirlas se veían los colores quemados, etc

Aunque creo que las que he puesto se ven muy bien, teniendo en cuenta que sujeto el móvil con una mano a un palmo de la tele

Está muy bien esa info, en el caso del ED64 el emulador de NES viene asociado al OS, solo tienes que buscar una rom de NES y ejecutarla, el menú la reconoce y la inyecta al emu de NES, no sé si en el 64drive es así.

Yo tengo el ED64 2.5 y cometí el error de pillarlo sin USB, por suerte solo me costo 84€ o así en 2012, eso me ha lastrado bastante a la hora de programar con la SD para aquí y para allá, me llegue a cargar una y el slot del portátil está así así, le sumamos que los emus están muy verdes en PC y programar en la consola de ésta manera es lo más cercano al infierno

@Conker64
Si, el 64drive tambien integra Neon64:

radorn escribió:Hay una version especial de Neon64 en 64drive que guarda en SRAM de cartucho, y ahora el menu lo que hace es crear una partida en la SD, como si fuera un juego normal, cuando cargas una ROM de NES.

La verdad es que no lo dejé muy claro, pero me refería a cargar ROMs de NES desde el menú del 64drive. Crea un archivo SRAM como si fuera un juego de N64, y usa el mismo mecanismo para guardar.

Conker64 escribió:Yo tengo el ED64 2.5 y cometí el error de pillarlo sin USB, por suerte solo me costo 84€ o así en 2012, eso me ha lastrado bastante a la hora de programar con la SD para aquí y para allá, me llegue a cargar una y el slot del portátil está así así, le sumamos que los emus están muy verdes en PC y programar en la consola de ésta manera es lo más cercano al infierno

La verdad es que no consigo encontrar ninguna informacion clara sobre el USB del ED64. Mas allá de decir que transmite a 800KB/s, no aclara que capacidades tiene, ni cómo usarla. Mientras que el 64drive lo documenta en el manual y la aplicacion por linea de comando trae una seccion de ayuda que explica todos los modificadores.
En su momento, en una instalacion anterior de mi PC, y cuando tenía la consola montada al lado, monté, mediante accesos directos en el menú "Enviar a", opciones para enviar ROMs con todos los tipos de guardado, envio de archivos al rango 0x200000 y alguna cosa mas. Desde entonces la aplicacion USB tiene alguna opcion mas, aunque son basicamente para el HW2 que no tengo.

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

https://themanbehindcurtain.blogspot.co ... ality.html
Efectivamente, es como yo pensaba. La funcion de pantallazos guarda la imagen en el rango ROM y es necesario extraerla manualmente. El 64drive permite acceder a la RAM interna por USB para lectura y escritura, como hacían varios de los copiones antiguos, facilitando esta funcionalidad. El ED64, parece que no ofrece esto.
En los foros de krikzz https://krikzz.com/forum/index.php?topi ... 6#msg53036, saturnu dice:
"the usb-screenshot feature is disabled, 'cause it's 64drive specific - the way the usb communication is working.
the 64drive can dump memory cartspace offsets native while running, the ed64 would need fifo routines inside the neon64 program."
Lo cual no exacto, puesto que, como ya dije, los antiguos copiones tambien tenían funciones similares por puerto paralelo. Simplemente el ED64 prescindió de ello.

La rom de zelda debug la tienes traducida, si vas a acceder a todas las funciones necesitaras los cheats y 3 mandos
el mando uno control
El mando 2 configuraciones el mando 4 camera debug (para crear las cinematicas y tal) tambien puedes ver la ubicaciones de los npcs
@Conker64

@Flash-Original Sorprendentemente para mi mismo nunca me he metido con las versiones debug de Zelda mas allá de un intento inicial que acabó con mucha confusion. No sabía que había que usar 3 mandos.
La verdad es que la scene de los Zelda de N64 parece haber sido victima de tantos altibajos y descentralizacion, que es dificil disfrutar de sus frutos salvo que te metas muy a fondo. Y, de forma similar a Mario 64, la mayoría de los hacks no funcionan bien o en absoluto en el hardware original...

@radorn


A mi sobretodo donde más me interesarían las capturas nativas es para cuando exista 3D 100% acelerado en homebrew, aunque yo compilaría con las librerías del ED64 para tener acceso a la SD, sacando el framebuffer, convirtiendo con libpng y enviando el archivo a la SD.

@Flash-Original
Ya ni recordaba eso, creo que cuando la probé hace ya unos años con ayuda de la info de tcrf me puse a conectar el mando en diferentes puertos porque solo tengo 1

Hay mas cosas pero eso es todo lo que recuerdo

Si recuerdo el GS del menu de trasteo te lo digo que servia para ver la lista desplegable

Si os da por trastear tambien las traducciones en el mando 1 dale al D-Pad a la izquierda o derecha en menu de pausa y te cambia el idioma al volver al juego
En emulador se rompe mucho, en consola solo en sitios determinados dependiendo de la versión del debug
Tambien puedes quitarlo y pasarlo a otro puerto

las grabaciones funcionan con direcciones hexadecimales



https://tcrf.net/Proto:The_Legend_of_Ze ... ster_Quest Aqui tienes todas las funciones y demas



Los cuatro puertos se usaban para testear en profundidad en vez de ir probando de uno en 1 lo testeaban todo entre 4 mandos.
Creo que no es el unico que lo usa
A proposito el mando 2 lo de la memoria son todo el mando R +`lado izquierdo L + derecho en la pagina 2 del L+d-pad amarillo derecha pagina 2 tienes la camara aunque es automatica no te deja cambiarlo

@Conker64 unas preguntillas rápidas sobre la parte técnica de la consola que me vienen rondando desde hace tiempo.
-¿Son posibles juegos 2d en 640x480? Entiendo por tus benchmarks que al RDP le sobra potencia para moverlo pero creo que aquí el límite sería el ancho de banda de la memoria. Y en este punto si sería mejor una solución intermedia de una resolución de 640x240 estirada por el VI que rebajara los requisitos del sistema.

-Esta es más complicada. ¿Se pueden renderizar partes concretas de un frame 3D o solo el frame completo? Por ejemplo, tener un escenario 3D con cámara fija, el juego la renderiza una vez, y después en vez de renderizar todo el escenario hacerlo solo en una región concreta donde esté el personaje con el fin de alcanzar artificialmente los 60fps con altas resoluciones. Obviamente se genera un doble gasto de framebuffer al necesitar un fondo limpio, pero habría libertad para mover la cámara según necesidad del juego. Es un poco complicado pero me gustaría saber si, ya que la CPU puede alterar el framebuffer, si el RCP puede renderizar porciones concretas de la pantalla.

@EMaDeLoC No soy @Conker64, como es evidente, pero intentaré responder a lo que pregutnas xD
Luego que me corrija si he dicho alguna burrada.

Si se pueden hacer 2D a 480 o 576 (renderizado progresivo, pero salida entrelazada descartando la mitad de las lineas, claro). Toma como ejemplo el cuaderno de los Bomber en Zelda Majora, o, tambien, otros menús de bastantes juegos, principalmente deportivos. Al ser la salida entrelazada, lo recomendable sería limitar a 30-25 cuadros tambien.
Y siempre puedes renderizar por debajo de eso y "estirar" por VI hasta 480i o 576i
La regla general es que puedes renderizar lo que quieras como quieras y luego decirle al VI cómo sacarlo por el bus de video hacia el DAC. Alguna limitacion habrá en los parámetros que acepte el VI, pero la diferencia no va a estar en si has renderizado en 2D o 3D. A fin de cuentas todo es cosa de microcódigos y displaylists (a no ser que seas masoca y renderizes a golpe de CPU). El resultado siempre es un framebuffer que luego tienes que pasar al VI.

Con respecto a lo de las camaras fijas, una posible solucion que se me ocurre sería renderizar el fondo sin objetos moviles a un framebuffer con su correspondiente Z-buffer, y guardarlo para toda la sesión, y, en otro buffer, renderizar solo los objetos moviles y efectos dinamicos y en cada refresco de pantalla, sobreimponer, comparando las Zs del buffer de escenario con el de los objetos.
Otra variacion de esta tecnica sería renderizar el fijo sin Z y luego tener una version del escenario con LOD reducido y renderizarla junto con los objetos moviles, pero sin dibujar ningun pixel del escenario, todo "transparente", usando la geometría solo para los Z-compares necesarios para la covertura.
Tambien se podría usar covertura tradicional por orden de dibujado precalculado, sin Z, aprovechando que el escenario es fijo.

Y para extender esta interesante sugerencia que has hecho, se me ocurre que disponiendo de suficiente almacenamiento dinámico (que se yo, un EP mas grande, sumando hasta 12 o 16MB de RAM, o usando la RAM de los cartuchos flash en modo RW, especialmente los 240MB del 64drive HW2), tambien se podrían prerenderizar diferentes angulos de un mismo escenario, incluso con variaciones de iluminacion o alguna otra floritura, para ofrecer algo mas que una simple camara fija, o reducir el tiempo de transicion entre una y otra.
Los escenarios renderizados de esta forma podrían ser mucho mas detallados claro, y ser renderizados en diferido... en paralelo si me apuras, aunque eso ya es rizar el rizo. La verdad es que es una idea con muchas posibilidades

EDITO: La verdad es que con el sistema de 2 framebuffers que propongo, hay un problema. Una vez renderizado el fondo, no se qué tecnica sería mas apropiada para el rendimiento. Copiar el fondo a un nuevo FB y renderizar los elementos dinámicos sobre esa copia o renderizar sobre un FB limpio con alpha y luego sobreimponer antes de mostrar. Supongo que copiar es mas económico, con un coste comparable a un limpiado de pantalla, comparado a tener que leer de dos fuentes a la hora de mandar al VI o, peor, generar un tercer FB donde ambas capas estén sobreimpuestas...
Si, creo que hacer una copia del framebuffer del fondo y luego renderizar lo dinámico sobre el es lo mas apropiado.

@EMaDeLoC
1) Depende de lo que quieras mostrar en pantalla, si vas a usar tiles de 64x64 que se repiten continuamente o solo cubren regiones pequeñas de pantalla podrías poner unos cuantos planos de scroll.

Ahora si vas a recargar textura en cada tile que pintes, es decir, los planos no van a repetirse, creo que aún podrías poner 2 planos completos y unos pocos sprites sin pasarse, si quieres mantener los 60fps, eso a 640x480 reales y 16bit.

Si no te importa bajar a 30, normalmente el rendimiento se duplica con un margen mayor, es decir podrías poner un poco más del doble de lo anterior.

2) Sí, al RDP hay que indicarle ancho, alto, profundidad y posición de memoria, con eso ya lo tienes listo para pintar, recortar extremos, etc da igual el número de buffers, eso sí tiene que ser memoria continua previamente reservada.

Cuando ya has terminado el buffer tienes que copiarlo al framebuffer principal, para ello lo haces moviendo bloques de lineas para entenderse, la RDRAM es efectiva moviendo grandes bloques continuos de memoria.

Otra posible idea sería definir zonas de pintado dentro del framebuffer, es decir si la pantalla es de 320x240, le dices vale, pero yo solo quiero pintar a partir del punto 32x16 y quiero que sea de 160 de ancho x 120 de alto, con ello ahorrarías tener que mover bloques de memoria.

Al fin y al cabo depende del tipo de efecto que estés buscando, podrá hacerse de una forma o otra.

--
Lo que cuenta radorn es interesante, luego me lo miro mejor que ahora tengo que marchar.

Gracias a los dos.

radorn escribió:Y para extender esta interesante sugerencia que has hecho, se me ocurre que disponiendo de suficiente almacenamiento dinámico (que se yo, un EP mas grande, sumando hasta 12 o 16MB de RAM, o usando la RAM de los cartuchos flash en modo RW, especialmente los 240MB del 64drive HW2)

Mmmm... Creo que la consola no puede leer de ninguna manera más allá de los 8MB máximos de RAM. No digo que no se pueda meter más memoria, que se puede, digo que efectivamente acceda al rango de 8-12MB o más.
En cualquier caso, yo pienso en lo que se puede hacer con los requisitos originales de la consola sin mods ultramegapro.

Conker64 escribió:Si no te importa bajar a 30, normalmente el rendimiento se duplica con un margen mayor, es decir podrías poner un poco más del doble de lo anterior.

Con 30fps y 640x240 creo que saldría un 2D muy decente visualmente. No tengo nada concreto en mente pero me habría gustado que hubiera salido un 2D potente en la consola a más de 240p. Creo que habría sido un genero que habría dado mucho de si.

Conker64 escribió:2) Sí, al RDP hay que indicarle ancho, alto, profundidad y posición de memoria, con eso ya lo tienes listo para pintar, recortar extremos, etc da igual el número de buffers, eso sí tiene que ser memoria continua previamente reservada.

Cuando ya has terminado el buffer tienes que copiarlo al framebuffer principal, para ello lo haces moviendo bloques de lineas para entenderse, la RDRAM es efectiva moviendo grandes bloques continuos de memoria.

Otra posible idea sería definir zonas de pintado dentro del framebuffer, es decir si la pantalla es de 320x240, le dices vale, pero yo solo quiero pintar a partir del punto 32x16 y quiero que sea de 160 de ancho x 120 de alto, con ello ahorrarías tener que mover bloques de memoria.

Al fin y al cabo depende del tipo de efecto que estés buscando, podrá hacerse de una forma o otra.

Estupenda información.
La verdad es que pensaba por ejemplo en algún juego dividido en pantallas tipo Resident Evil donde hubiera un puzzle en cada una y cada vez que pasaras de una pantalla a otra, la cámara o grandes partes del escenario se movieran. La idea seria que todo fuese a 640x480 siendo la parte de los puzzles a buenos 30fps pero en los cambios de pantalla obviamente bajaría a 10-12 pero no importaría porque no serian momentos jugables.
Otro ejemplo sería el juego del virtual chess donde habría animaciones localizadas que se moverian a esos 30fps.
El motivo de esto es ofrecer algo de mucha resolución sin recurrir a fondos prerenderizados que poco o nada tengan que ver con los gráficos in-game y así engañar al jugador pareciendo que la consola tiene mucha más potencia de la que realmente tiene.

Dejo unas breves pruebas con el prototipo del Master quest

Así que me dirijo a Kakariko y oh no, el puto búho está en todas partes.


Tras darle esquinazo volamos hacia una montaña que no pueda alcanzarse normalmente y sí, podemos andar por ella, no todas las superficies tienen colisiones y tan pronto acaban de repente, ya que no está preparado para que vayas por ahí pisando.

El cielo como podemos ver son varios polígonos unidos que van girando y siempre están a mayor distancia que el resto del escenario, a partir de la mitad se invierte para crear el horizonte, por debajo no pinta nada, un movimiento inteligente para optimizar recursos.

Las montañas son eh papeles puestos a distinta distancia, es un truco muy empleado para crear más profundidad y detalle sin derrochar demasiado.

Si por alguna razón Link se sale del escenario cae al vacío, el cual tiene un limite (un poco amplio para permitir desniveles, como cuando nos tiramos por el río en Gerudo), en un barranco bien preparado tocaría con superficie o coordenada antes de llegar al suelo como en Shadow Temple, todas las salas tienen un punto de inicio para poder restaurar al personaje.


Mismo caso que el anterior, las entradas funcionan por posiciones en lugar de por eventos, quicir el acceso debería estar sellado hasta que toques la canción de Zelda, pero deja su funcionalidad en manos de las colisiones del escenario que previenen "entrar" en esas áreas, si sabes saltarte muros es un juego que va a dar resultados imprevisibles, como ya se ha visto en los speedruns con la botella y las puertas para pasarse el juego en varios minutos.

(yo lo que quería es que se diera con el techo al salir)

La catedral es otro caso interesante, en la transición entre la cámara de la espada y la sala con las gemas hay falsas habitaciones que se transforman según te acercas, es como un caso de LOD a lo bestia, aunque para ésto no hace falta jugar al prototipo.


Que no me dejas entrar a Gerudo, vas a ver tú, oh snap, ahora sal de ahí sin el gancho, espero que la verja fuera lo suficientemente alta para que nadie consiguiera saltarla por error.


Vamos a probar las distintas herramientas como la cámara libre, para ello necesito conectar un mando en el puerto 3, como solo tengo uno allé voy.. que si está la consola en la bandeja del teclado? Efectivamente, cuando quiero actualizar algo no solo tengo que sacar la SD, sino mover también la bandeja.


Y como lo hace éste buen hombre para escribir sin teclado? Más o menos así, en opciones, teclado virtual.


Visitamos al viejo del lago y nos confiesa que es un mirón, me reservo las dudas.


Pero si el cabronazo no estaba mirando.. era todo un farol, la cámara en modo manual no sigue al personaje, sería como la empleada en los escenarios prerrenderizados.


BUGCHU
Los bombchus deben ser uno de los objetos más peculiares y.. menos testeados, es muy fácil colgar el juego por usarlos en puntos determinados.

Sobretodo NO hay que usarlos con los dragones que se encuentran en la primera sección de la mazmorra Dodongo, yo quería probarlo con el Master quest pero cambiaron los dragones por... fantasmas, mi gozo en el pozo de Kakariko, así que pongo la copia del Zelda original.

Pues tal que así, llegas le lanzas uno en el momento en que aspira para lanzarte una llamarada y se acabó.


A partir de ese momento quedan inutilizados la mayoría de objetos que funcionen por cantidad, ni flechas, ni magias, ni bombas y si usas el gancho tu personaje quedará congelado, ya que el gancho tiene una actualización para largo alcance y no sabemos a qué se actualizó ésta vez.


Eso no es todo, la memoria temporal para objetos móviles de la mazmorra queda corrompida, podremos salir de la sala si previamente habíamos encendido todas las antorchas, no habrán enemigos ni las plataformas móviles, en algunos lugares faltaran paredes y podrás tirarte al barranco en plan gerónimo, pero si sales de la mazmorra obviamente se arregla el problema.


Esa es la versión buena del bug, la mala es un cuelgue total con la música sonando, se consigue fallando el primer tiro y que en lugar de tragarse el bombchu le explote, continuamos disparando sin parar hasta el cuelgue, cuando aparece la linea esa amarilla a la izquierda significa que hay información debug disponible.


Las capturas han salido un poco mierder, pero con más luz me veía reflejado y ESO si que hubiera sido horrible, una da error por intentar escribir donde no debe y otra por leer donde no da el sol.




Lo cierto es que para qué íbamos a querer volver a la mazmorra? Bueno en realidad si entramos por la puerta final a la derecha se puede volver de adulto y usar el gancho, además de recolectar alguna skulltula restante, un descuido en toda regla.

Detalle que no tiene nada que ver con lo anteriormente comentado: mientras el juego corre a 20fps, los menús lo hacen a 30, incluido el de pausa.

PD: Se agradece la info extra Flash-Original

@Conker64 Mas que una beta es un prototipo con las funciones debug, pero solo lo digo por ser pedante xD

La interfaz holográfica que usa en ese video J.J., el espia industrial de Sony España que se coló en la camara acorazada de Nintendo (que tiene ventanas con persianas y una puerta trasera con pomo), la proyecta la N64 desde el orificio frontal y era parte de las especificaciones del Project Reality. LLegaron a implementarlo y lo usaron en la grabacion de esa promo, pero, asesorado por Miyamoto, Yamauchi decidió que el mundo no estaba preparado para una tecnología tan avanzada y que sería un fracaso de ventas, así que pusieron una led normal en su lugar, y al espía de Sony, el unico testigo vivo de que la tecnología era real y no un efecto cinematografico, lo absorvieron con un portal de la 64ª dimension, cosa que tambien hicieron pasar por efectos especiales.
Todo es cierto y nos han estado engañando durante mas de veinte años, los muy cabrones.
Despues de lavarle el cerebro durante todo un año en la 64ª dimensión, lo soltaron para que fuera a comerle la cabeza al jefazo de Sony España, su secretaria cabezahueca, el pelota de su mano derecha con pelos de punta, y el tester culogordo flipao de los terminos tecnicos mal usados y mal pronunciados.

Y os creíais que era solo un video promocional... ¡almas candidas!

@radorn


No me vi veces esa cinta ni nada.

Pues espérate que también había llamado demo al master quest, he editado explicando un poco mejor algunas cosas y con un poco más de arte.

Ginxu explica lo de la lente de la verdad en los Zeldas de la N64.
Creo que hace ya un tiempo puse un enlace al blog donde lo explicaban, que es el mismo en que se basa Ginxu para la explicación.
Pero en video queda más claro que en leyendo el inglés castizo.