Hilo de detalles y curiosidades de N64

@Señor Ventura no critico el hardware de las Ps360, sino al saco de rocas pesadas que se echaron encima en pos de los 720p. Tienen catalogazos, y fue la generación más igualada de la historia desde los 16 bits, no habiendo más hegemonía más allá de la japonesa. Incluso en tierras niponas la Ps3 fue un hardware menos popular que la Wii o la Nintendo DS a pesar de sus ventas. En el 2009 los Japos jugaban más a juegos de lucha online de la Ps2 que de su sucesora.

Lo que me pasa es que los juegos de esa gen me dan la sensación de "pantalla de teléfono móvil rota". Funcionar funcionan, pero tienen tearing galopante, bordes de Sierra notorios, frame-rates insuficientes, etc. A estas alturas el retrogaming de esas máquinas me interesa más hacerlo en STEAM o en las futuras Ps5XboxTwo, ya que habrán arreglado el "cristal" de sobra, y todos los hack'n slash (mi interés personal) de esas consolas irán como Dios manda.

¿Mentiendes xD?

Respecto a lo otro yo tampoco estoy de acuerdo. Y sé que dentro de tu fanboyismo eres un tío razonable xD. Pero es que personalmente me toca los cataplines el argumento genérico de que la resolución "da igual", sólo porque tu consola favorita se asfixia cuando la sacas fuera de un contexto Master System.

Sexy MotherFucker escribió:Lo que me pasa es que los juegos de esa gen me dan la sensación de "pantalla de teléfono móvil rota". Funcionar funcionan, pero tienen tearing galopante, bordes de Sierra notorios, frame-rates insuficientes, etc. A estas alturas el retrogaming de esas máquinas me interesa más hacerlo en STEAM o en las futuras Ps5XboxTwo, ya que habrán arreglado el "cristal" de sobra, y todos los hack'n slash (mi interés personal) de esas consolas irán como Dios manda.

¿Mentiendes xD?

Tiene sentido. Si te preocupa la diferencia entre un cable rgb y otro con cyan turquesa y luma marca acme de no se que, el tearing tiene hacerte llorar en la ducha xDD

Pero a mi me pueden poner el alan wake a 540p y el tearing ese a nada que algo se mueva, que no me voy a quejar.

El metar gear solid V es una gozada (aunque in game pasa una cosa rara, y es que no se si es que te acostumbras a los gráficos, pero no son tanto como en realidad son... es raro), pero creo que tiene tearing por un tubo.

Sexy MotherFucker escribió:Respecto a lo otro yo tampoco estoy de acuerdo. Y sé que dentro de tu fanboyismo eres un tío razonable xD. Pero es que personalmente me toca los cataplines el argumento genérico de que la resolución "da igual", sólo porque tu consola favorita se asfixia cuando la sacas fuera de un contexto Master System.

Es que no me refería a que la resolución de igual, si no a que no es un elemento rígido pase lo que pase. Dependerá del resto de circunstancias, y por eso lo que afirma el texto con eso de que la playstation puede con mas resolución que la N64 teniendo menos problemas, es una afirmación que no es para nada correcta, porque dependerá de la carga gráfica.

No lo digo a modo de comparación, sino a modo de que no vas a poder ejecutar un juego a 640x480 le metas lo que le metas, y es que encima la N64 es muchísimo mas escalable.

@Señor Ventura

Tiene sentido. Si te preocupa la diferencia entre un cable rgb y otro con cyan turquesa y luma marca acme de no se que, el tearing tiene hacerte llorar en la ducha xDD

xDDDDD

Depende del juego. Por ejemplo en un Uncharted me chirría mínimamente, porque a no ser que pongas la cámara en primera persona y pongas a Nathan tó pedo girando 360 grados no se nota demasiado.

Sin embargo en títulos como el primer Dead Rising es que es evidente hasta para el más cegato. En una pantalla digital 16:9 sus gráficos se parten LITERALMENTE en dos por más de 2 segundos en ocasiones. O Heavenly Sword (Ps3) durante sus escenas cinemáticas tres cuartas de lo mismo; hay un puto gordo que se vuelve una PUTA muñeca rusa en cierto momento xD.

Yo esa generación me la salté sin querer; estaba demasiado ocupado jugando a los Triple A japoneses de Ps2 que todavía salían para el sistema (¡EN EL PUTO 2009!), y con el inesperado catalogazo que encontré en la PUTA Wii , consola de la que fui estúpidamente hater (Internet, serious bussisnes) en sus inicios.

BTW en la 360 gran parte del catálogo rula opcionalmente a 640x480, lo que podría despertar mi interés de jugarla en CRT VGA. ¿Te consta si los juegos tienen mejor rendimiento a 480?

Si aumentas la resolución necesitas pintar más, eso depende del fillrate de la consola.

Hoy en día si hicieran un motor 3D podrían conseguir que el margen de error fuera más reducido, es decir las partes cubiertas por otras, si las pintas estás desperdiciando fillrate, creo que ya he enseñado como aumenta el rendimiento en un motor 2D, en 3D pasaría exactamente igual, pero el cálculo sería más complejo y por supuesto esto depende de cada engine, por eso los juegos de Factor 5 funcionan bien en ciertas resoluciones y otros juegos caen en picado, como el Castlevania.

Tengo por aquí un pdf de Nintendo donde explican todo el funcionamiento de la maquina, tener activado Atomic prim afecta al rendimiento, cuantos juegos usarán esta opción? Es más, sorpresa sorpresa, libdragon lo lleva activado , lo primero que hice es tratar de desactivarla, pero en algunos casos deja de pintar la última linea vertical y horizontal del sprite, tengo que investigar.


El Z-Buffer perjudica al fillrate, esto ya se ha comentado mucho, en algunos juegos usan partes sin z-buffer como barandillas o objetos 2D pegados en el escenario 3D.


Y lo bueno es que dentro de todas las combinaciones suelen usar goraud + zbuffer + texturizado, que es la opción más lenta, flat shade usa el comando prim color, que es el que estoy usando para hacer escalas RGB, manejar alpha, etc, obviamente en libultra ya te vienen todos los comandos programados en distintas funciones, para activar las cosas por mi parte tengo que ir mirando el chip en el pdf que puse hace varias páginas.


También hablan de cosas como el modo Turbo3D, una tasa de más de 5000 polígonos por frame a 60fps es bastante realista, daría >300K, esto es lo que vienen a ser datos de rendimiento real de algún test.

Es que no se puede comparar la resolución de los juegos de ps1 con la resolución de los juegos de N64 porque no mueven las mismas cosas.

N64 mueve mundos 3D reales con libertad de cámara, con polígonos mucho mas solidos y efectos como por ejemplo la iluminación en tiempo real, es lógico que a la maquina le costara mas trabajo mantener una resolución alta así como un framerate estable.

Podre no saber mucho de especificaciones técnicas pero lo que si se, es que no es lo mismo mover los mundos abiertos en 3D de Zelda, que mover los planos prerenderizados de Final Fantasy 7 o los Resident evil.

De todas formas yo no tengo quejas por la resolución de los juegos de N64, se veían bastante bien para las teles gordas esas de tubo de la época.

¿Qué métodos existen para poder mirar las resoluciones reales de los juegos? Entiendo que con emulador cuando los juegos permiten usar debug que es lo que haces tú @BMBx64 ¿no? Pero aparte de esto no se puede comprobar en hardware real de alguna forma ¿Una capturadora de vídeo lo haría o reescalaría? He estado mirando precios y como la mayoría de gente quiere capturar vídeo de sistemas actuales y no retro he visto que las capturadoras anteriores al HDMI son bastante asequibles y si vale sacar información real del hardware podría interesarme pillar una para mirar resoluciones desde NES hasta Wii.


Lo que dice de PSX sin aportar ningún dato de juegos no sirve de mucho, la propia N64 no tiene ningún problema en sacar 640x480. Sino digo nada más cierto es, ahora si añado: logos de compañías y menús estáticos de juegos; la cosa cambia.
Alguien ha dicho que Rival Schools va a 540x240 que siendo un gran juego de lucha supongo que no requiere procesar demasiados gráficos como la mayoría de los de lucha. Estaría bien saber más para saber realmente hasta que punto es cierto eso de que no le cuesta nada mover juegos a esa resolución.

@Sexy MotherFucker tú y yo tuvimos una evolución similar: PS2 hasta el 2010 y luego tras leer un par análisis de juegos de Wii en un blog pequeño que eran de todo menos nintenderos y pese a ello aquellos juegos recibían notazas me aventuré con una y que gran decisión. Los juegos por si tienes curiosidad eran: Super Mario Galaxy, Madworld y Little King's Story.

@Oystein Aarseth
N64 hace muchos más cálculos que PSX, si le amplias el área de trabajo (resolución) todavía tiene que hacer más, luego como ves hay muchas configuraciones en esta consola que afectan al rendimiento

@Calculinho
Tienes el plugin de angrylion, aunque no es perfecto y muchas veces no da la resolución correcta, en Resident Evil 2 precisamente falla, luego está que si lo quieres hacer funcionar con Project 64 puede que necesites versiones antiguas.

N64 creo* que reescala a 640x480 según que casos, no sé si sería válido lo que extraigas del hardware real.

Señor Ventura escribió:por eso lo que afirma el texto con eso de que la playstation puede con mas resolución que la N64 teniendo menos problemas, es una afirmación que no es para nada correcta, porque dependerá de la carga gráfica.

Antes no vi esto, pero no creo que decir que PSX mueve 500x240 sin tanto esfuerzo implique sea mejor resolución que las de N64. Recordemos que de N64 tenemos varios juegos increibles a 400x440 que creo que es mejor resolución ¿no? Lo que creo que trata de decir el usuario es que los juegos de PSX a esa resolución la máquina los procesa más rápido que N64. Yo lo he entendido en el sentido de que N64 es más puñetera de programar y optimizar y no en términos de potencia total.

Calculinho escribió:

Señor Ventura escribió:por eso lo que afirma el texto con eso de que la playstation puede con mas resolución que la N64 teniendo menos problemas, es una afirmación que no es para nada correcta, porque dependerá de la carga gráfica.

Antes no vi esto, pero no creo que decir que PSX mueve 500x240 sin tanto esfuerzo implique sea mejor resolución que las de N64. Recordemos que de N64 tenemos varios juegos increibles a 400x440 que creo que es mejor resolución ¿no? Lo que creo que trata de decir el usuario es que los juegos de PSX a esa resolución la máquina los procesa más rápido que N64. Yo lo he entendido en el sentido de que N64 es más puñetera de programar y optimizar y no en términos de potencia total.

Es que depende de lo que realmente el juego demande procesar. No es lo mismo el ridge racer 1 que el type 4, y por lo tanto no puedes contar con que puedan emplearse ciertas resoluciones, sin mas.

Es evidente que la playstation no tiene que tratar las texturas y los polígonos con filtros de ningún tipo, y puede dibujarlos antes, pero eso no significa que en cómputo global al final cada frame se acabe dibujando después. ¿Un ejemplo?: shadow man.

Así que después de todo el tamaño si importa ( el de la resolución) xD

Traigo algunas novedades

Ya he implementado las texturas de 4 y 8bits en la libdragon, solo hay un problema, de momento no puedo usar más de 1KB de cache y no sé el motivo, así que bueno, mi intención era probar cuanto aumentaría de rendimiento usando todo tiles de 64x64 4bits (2KB) y aún me tocará esperar

En cuanto a las texturas tienen funcionalidad completa, se pueden espejar, escalar, soportan alpha blending y toda la pesca, todo usando la misma interfaz de la libdragon y el mismo formato de fichero.

Vamos con algunos tests.

EDITOR DE PALETAS
Pues me aburría y quería probar no solo que la textura funcione, sino que se actualice cada color individual de la paleta.


De paso he puesto a prueba la rotación de colores dentro de una paleta, creo que algo similar hace el juego, esto se activa con L y se desactiva con R.


Con Start vuelven los colores por defecto, en caso de estropicio.

DESCARGA:
https://mega.nz/#!l4JFxIiB!jTS5TAQl8-0b5008yk7QQ392qOlYw0cbAK0QbAGOKSw

EL MAPA DE GOLDENAXE DE NUEVO
Pues si, me repito más que el ajo y lo he vuelto a utilizar para las pruebas, dado que el mapa entero solo utiliza 16 colores, se puede cargar una paleta al principio y usar la misma en todos los tiles sin tener que recargarla, eso aumenta algo el rendimiento.


El rendimiento viene a ser el mismo que con una textura de 16bits, 5fps de diferencia a favor de la 4bit:

4bit
x= 0 - 166fps
x= 194 - 161fps
x= 974 - 143fps
x= 1552 - 169fps

16bit
x= 0 - 161fps
x= 194 - 156fps
x= 974 - 138fps
x= 1552 - 163fps

Donde realmente aumentaría es renderizando tiles de 64x64, volveré a taladrar con este mapa cuando eso ocurra.

Entonces para qué tanto rollo con implementar estas texturas? La RAM, esto ahora va a permitir añadir muchos más sprites en memoria, para hacer una comparación, el mapa de Goldenaxe ocupa en RAM lo siguiente:

4bit
213 tiles de 16x16 = 28,2KB

16bit
213 tiles de 16x16 = 108KB

DESCARGA
https://mega.nz/#!5x4zAYrT!6xAwSK76h8GaGyKfLo05vDUHjEU33MMmKpHDGAumUSc

MÁS EFECTOS
Trasteando con el combiner he dado con 2 nuevos efectos, me estoy fijando en los maestros de Treasure para ver qué comandos usaron y como puedo replicarlos.

void rdp_intensify( void ); con RGB de 0 (normal) a 255 (completamente blanco), permite efectos como este:


void rdp_color( void ); permite dibujar la silueta de un sprite en un único color (también se podría hacer con paletas, pero aquí es más rápido), ejemplo de su uso:


Hay muchos más efectos interesantes, como el morphing, este se consigue en modo 2cycle, quizás lo acabe implementando.

muy buen aporte el mapa del golden axe luce muy claro en consola y uso el cable compuesto y el efecto de mischief makers es parecido al que se ve en mortal kombat trilogy donde se ven sprites pero con transparencias, como cuando liu kang cuando hace las patadas de bicicleta, imagino que requiere gran trabajo conseguir estos efectos.

Pues he tenido que activar el antialias resample que emborrona la imagen, sino se vería en barras como la última vez, tengo que arreglar el seteo de vídeo que hace libdragon

MODO 32BIT
He arreglado el uso de texturas en modo 32bits, hasta ahora la consola se colgaba si se intentaba renderizar cualquier textura en modo 32bits, eso es porque este modo requiere que las texturas estén en 1cycle, así que he hecho unos pequeños ajustes en la librería y ya funciona.

MODO 32BIT soporta:
Texturas de 4,8,16, 32 bits, solas o simultáneamente.

MODO 16BIT soporta:
Texturas de 4,8,16 y sorpresa sorpresa 32 bits también, hace una conversión automática al vuelo, me ha sorprendido eso.

Para que quiero el modo 32bits? Bueno una de las ventajas es que podría proporcionar 255 niveles de alpha blending, en modo 16bit parecen ser 32, otra es el incremento de color, esto desde luego funcionaría mejor en 3D, en 2D creo que el modo 16bits va sobrado (y es mucho más rápido!), así que he probado un test.

He ido a buscar alguna imagen que tenga algún efecto gradual de luz, eso se nota mucho cuando pasas a 16bits.


Luego la he convertido en tiles y pasado por el motor de scroll, aquí no hay tile repetido ni nada que valga, incluso la imagen viene con compresión, pero no he podido esperar a encontrar una mejor.


El resultado fue tal y como sale en la imagen de arriba, sin embargo probando en modo 16bits el resultado fue este:


He subido el test, varias cosas:
- Hay un error global en todas las texturas que no sean de 16bits, que es la única que soportaba bien la libdragon, en todas las demás solo se puede usar la mitad de la cache, pero ya estoy cerca de saber donde está el problema, podría ser un fallo de alineado.

- Son 1200 tiles, tarda 47 segundos en arrancar, no me gusta nada como ésta librería gestiona la carga de ficheros, por revisar.

- El rendimiento no es el esperado, funciona a 50fps en modo PAL, pero no llega a 60fps en NTSC, inadmisible, el test se debería probar forzando el modo PAL.

Es de esperar que cuando se puedan usar texturas de 32x32 el rendimiento aumente, en este test no me queda más remedio que usar texturas de 16x16.

DESCARGA
https://mega.nz/#!RtxRCDob!MCUodWs-SP5lB7DMgZVeuXKMA3LkBRKMMSyg70ianRY

TEST 2
Este test es el scroll de mario que ya se ha puesto, aquí se compara el rendimiento en 3 modos distintos.

Scroll a 16bits, textura de 16x16 16bits en modo copy = 333fps
Scroll a 16bits, textura de 16x16 16bits en modo 1cycle = 266fps
Scroll a 32bits, textura de 16x16 16bits en modo 1cycle = 211fps

Conclusiones: el solo hecho de usar el modo 32bits de vídeo ya hace perder rendimiento, verse forzado a usar 1cycle para texturizar también.

Por lo visto existe un truco que permitiría usar texturas copy en modo 32bits, a ver si me comentan como funciona eso.

DESCARGA
https://mega.nz/#!5gIiAACS!V--UGTsV7FULDG0-E2OC_b2QO7HX02-ujwxZF7xzuDA

COSAS PENDIENTES:
- Arreglar seteo de vídeo, permitir desactivar AA en modo 60hz
- Arreglar uso de cache parcial en texturas de 4, 8 y 32bits
- Mejorar velocidad de carga en ficheros independientes, el problema no está en cuanto ocupan, sino en el número de archivos.

Pero como arreglar todo eso es un coñazo de momento lo voy a saltar para incluir rotación en sprites, para ello usaré 2 triángulos para formar un rectángulo en espacio 2D:

Entiendo los conceptos en general, aunque al entrar en detalle me lío. xD Aún así, sería de necios no reconocer todo éste trabajazo.

viper2 escribió:Entiendo los conceptos en general, aunque al entrar en detalle me lío. xD Aún así, sería de necios no reconocer todo éste trabajazo.

Yo también me choco, pero porque la N64 impone muchas condiciones en cada modo de trabajo, y ya no sabes con que te va a salir xD

@BMBx64
El modo de 32 bits luce excelente probé el test de la palmera y la iluminación se ve con un suave degradado, corre a 40 fps en 60 hz, lastima que tarde en cargar, que buena noticia lo que dices sobre el truco de 32 bits en modo copy que mejoraría el rendimiento y la otra nueva buena que el modo de 16 bits soporta texturas de 32 bits , me pregunto por que krikzz no implementa este tipo de modos a su sistema operativo se verian mejor los fondos, en cambio marshall a puesto muchas mejoras a su OS que tiene una interfaz mucho mas bonita, personalmente veo superior al 64drive sobre el everdrive 64.

La diferencia de los fps es clara con los test de scroll de mario, no cabe duda de que eres un maestro en esto de la programación para que te la ingenies en como ir arreglando modos e implementando más cosas

Si tenéis dudas preguntad , la maquina es muy quisquillosa y la librería todavía lo es más, muchas cosas pienso que están bien, pero claro trabajo sobre una capa superior (que es la libdragon) que me desorienta.

Por ejemplo las implementaciones a nivel de chip que he ido añadiendo usan un comando ringbuffer de libdragon, que se encarga de preparar el DMA, de las interrupciones y de comunicarse con el RDP para subir datos, debo entender que ese comando es 100% correcto y que no está mandando mal las texturas de 4,8 y 32bits, sino que hay "otra cosa" de por medio, que puede ser la formación del comando en si, la carga del fichero, etc

Luego está la gestión manual de cache de la consola, la CPU tiene 16kb de instrucciones y 8kb de data, en el editor de paletas que hice tuve problemas con la coherencia de cache, que es esto?

La maquina usa la cache interna de su CPU para procesar toda la información posible y acelerar datos, esa gestión es parcialmente manual, esta estructura:



Tiene 2 copias, en la RAM y se ha hecho una copia en los 8kb de data de la CPU (por un casual se ha alineado esa información para ser optimizada, si añadieras variables nuevas podría ser otra información la que se alineara, así que existe cierta "fluctuación" con el rendimiento que puede tener un programa, sobretodo simple), cuando estoy actualizando un valor, no lo estoy actualizando en la RAM, sino en la cache de la CPU, pero para enviar esa información al RDP, no lee de la cache de la CPU sino de la RAM (donde estarán los datos antiguos y no los actualizados), así que hay que forzar a que la CPU actualice los datos de la RAM, eso se hace anulando esa cache.



Bueno por aquí ya hay triángulos rotando , he unido los vértices para acelerar rendimiento, ya que aunque sean 6 puntos, realmente solo hay 4 útiles, uno de los 2 triángulos solo tiene 1 punto diferente del otro, ahora faltaría texturizarlos para ver la rotación del sprite.


Esto usará el centro virtual del sprite, en este caso está rotando desde el centro, pero si está a los pies la rotación sería distinta.

@john D9
Ahora no recuerdo si el menú del Everdrive usa la libdragon, desde luego hay un menú alternativo que sí que la usa.

@BMBx64 Lo de los modo cycles que son que no lo encuentro

Con los menus alternativos tal vez te refieras al de saturnu alt64

@Flash-Original
Sería aconsejable que leyeras el pdf Nintendo_Ultra64_Programming_Manual_and_Addendums para entender como funciona la maquina, puedes encontrarlo fácilmente en google

--

Por otro lado ya tengo polígonos texturizados, pero aún no funcionan como espero, todas esas variables son coeficientes de textura, de los grados 0 a 45º parece que la cosa "anda bien" en el triángulo superior pero en realidad no va del todo sincronizado ni hace el giro adecuado y lo peor, en cada movimiento que hace el triángulo descentra la textura, los coeficientes cambian del triángulo superior al inferior.


Esto me lleva a pensar que ya no es necesario efectos de raster para desplazar lineas a distintas velocidad y darle volumen o profundidad a un plano de scroll (como te haría un Sonic en la parte del agua), se pueden usar triángulos y usar una combinación de coeficientes.

Con S / T podemos mover la textura hacia arriba o abajo dentro del triángulo en la perspectiva exacta que lo tengamos seteado, recordáis el agua o el cielo de los juegos que se mueven? Pues se desplazan de esta forma, además es a nivel de subpixel, la carga de la textura ya determina si es cíclica y se invierte al llegar al límite, etc

He corregido todos los color combiner que había hecho hasta ahora, existen combinaciones que solo se representan bien en rectángulos, pero no en triángulos, ahora mismo ambos usan una combinación compatible y soportan todos los efectos que he recreado hasta ahora, incluido el additive blending, así de pochos se veían los triángulos.


Por otro lado ya he probado la corrección de perspectiva, cruzando dedos para ver si la textura rotaba con el triángulo y va a ser que no , la corrección dados unos coeficientes entonces realiza los cálculos, pero necesita un input.

He corregido el modo blend color que era erróneo en la libdragon y he creado una función para seleccionar cualquier tipo de triángulo, esto es todo lo que soporta la consola:
0 - Flat
1 - Gourad
2 - Textura
3 - Textura + Goraud
4..7 - Todos los anteriores + Z-Buffer

Para 2D no nos interesan los Z-Buffer, aunque se podrían usar para proyectar 2D también, en los tests uso el 2.
--

En cuanto a desactivar atomic prim, esta teoría es correcta:


He realizado tests con y sin atomic prim con los siguientes resultados:

Scroll de Mario
Con - 333fps
Sin - 342fps

Goldenaxe
Con - 167fps
Sin - 172fps

Muy bien, incremento de framerate, pero esto va sujeto de muchas cosas, igual los tests van lastrados de CPU y no de fillrate, así que vamos a hacer un ejemplo específico.

Éste test (los números de rendimiento no son correctos en cen64)


Con - 1280 sprites a 50fps
Sin - 1320 sprites a 50fps

Lo que vienen a ser 40sprites más sin atomic prim o cerca de 1Mp/s de ganancia (40x16x32x50), aún así no todos los tipos de textura y tamaño son compatibles con desactivar atomic prim, así que lo he puesto como opción, tal como hace la libultra, para 3D si que será útil, en 2D se nota más si se pierde una línea.

--
Por otro lado cuando se inicia una transferencia de DMA, la CPU ya puede ir trabajando en otras cosas, sucede que libdragon al no tener hilos todo lo que hace es.. esperar a que acabe la transferencia DMA para seguir trabajando, así que no me queda claro como de lastrada va la maquina con esta librería, pero puede que bastante.

La nueva librería (libn64 o n64chain) con el core mucho más eficiente se puede encontrar aquí (muy incompleta de momento), es brutal ver la cantidad de partes que están escritas en ASM.
https://github.com/tj90241/n64chain

Comprender los detalles es algo difícil, esto es muy complejo para un mortal como yo xD aun así el procedimiento es interesante hasta para los detalles como el efecto del cielo o del agua de juegos en 2d que mencionas tienen bastante ciencia.

PROTOTIPOS DE DIE HARD VENDETTA
Acabo de ver el hilo en Assemblergames, han liberado 3 roms, las estoy probando ahora mismo

excelente !! también voy a probarlo, en el gameplay que se habia publicado no se hace mucho se veia que corria suave, veamos que tal

@Flash-original
ya probe el menu de satururnu y se ve bien pero creo que me quedo con el original. eso si puede usar fondos de 32 bits con resolución de 320 x 220

Yo ya lo he probado un buen rato y hay un poco de todo.

Está bastante inacabado, funciona suave hasta que te encuentras con 1 o varios enemigos a la vez entonces se vuelve unas diapositivas, a lo bestia xD

Pero es normal teniendo en cuenta que está inacabado.

El Die Hard Vendetta de Gamecube me lo conozco bien porque lo tuve en su día y apenas he visto zonas iguales, tienes el mismo tipo de niveles, las alcantarillas, la comisaría, el museo, etc pero parece que rehicieron gran parte de los escenarios (incluso de Gamecube a PS2 hay bastantes diferencias, hora del día, detalles del escenario como pósters distintos, etc), solo me ha parecido ver una parte similar de la pescadería (y se cuelga al abrir cierta puerta).

Algo que me ha llamado la atención es que gráficamente es más solido que el de Gamecube, para éste último ampliaron la resolución de texturas, parecían sacadas de un set gratuito de internet, muchas veces ponían texturas que no quedaban bien cíclicamente, veías una pared y todo eran recuadros intentando encajar, sin embargo en el de N64 no pasa eso.

Cuando revientas los cristales lo hace como en Gamecube cayendo a cachos con física, eso me pareció muy bueno.

Y en ese sentido he visto geometrías bastante complejas para la consola y para el estado de estas betas, que si un cuarto de baño y todos los grifos con su geometría y hasta el chorro del agua o detalles más minuciosos como ver el soporte del papel de váter.

También parece que a ésta gente les gusta colgar posters en alta resolución o algo por el escenario, he visto algunas texturas bastante buenas y poco comunes en N64.

En la tercera rom hay unas salas de test que son un puntazo, sobretodo si vienes de programar en la consola sabes que están intentando, hay salas con distintas texturas a distinta resolución y tipo de formato, hay tests de animaciones, texturas invertidas, efectos de semitransparencia, focos, test de voces 3D, plataformas flotantes y móviles en distintos ángulos para probar las colisiones, todo esto pasando por diferentes salas como si de un parque temático se tratara, me encanta ver ese tipo de cosas.

En cuanto al juego es bastante inestable, IA nula, los enemigos no persiguen ni hacen nada más que disparar una vez te han localizado, no es el que de Gamecube fuera muy brillante en esto tampoco.

Si te acercas demasiado a ciertas paredes puedes quedarte enganchado y girando sin parar, por alguna razón no puedes entrar al menú para reiniciar nivel, así que toca reset.

Si disparas a un enemigo con la escopeta casi congelas al juego, parece que le cuesta la vida analizar disparos únicos y la escopeta lanza unos cuantos a la vez.

En opciones podemos desactivar cosas como la iluminación dinámica para mejorar el rendimiento o la de apuntar automáticamente, para hacerlo más jugable.

--
Por cierto ya tengo corregidas las texturas de 32bits, ahora se pueden usar de 32x32 (4KB), por tanto el test que lancé el otro día ya alcanza los 60fps.

https://mega.nz/#!w1IFWD4A!k4F3BoVzp1vQ-69SQ4Tfti1E5MTEotgGTYDrw-acxPM

yo buscando encontre(aunque de mala calidad el eternal darkness)
https://www.youtube.com/watch?v=7WIDWoefpAc
y gameplay
https://www.youtube.com/watch?v=LWeXnBH8Ohs

del prototipo a mi impresiono los efectos de luz como cuando caminas por los pasillos y no recuerdo si en el rom 1 o 2 llege a una parte donde hay unos monitores en los cuales ves lo que graban unas camaras de seguridad y vi a una mujer golpeando a un tipo xD (torturandolo) y la pantalla se ve con efecto de grabación distorsionado me parecio muy bien hecho el efecto, lo que no pude encontrar fue como invertir la mira para apuntar con las armas, como el juego de james bond the world is not enough que te da la opción para invertir el eje "Y" así que opte por matar enemigos tirando box .

Lamentable que cancelaron muchos juegos para Nintendo 64 que estaban en desarrollo, creo que tanto la consola como los jugadores merecían que esos juegos se terminaran y se publicaran pero en fin.

Que buena noticia que corrigieras las texturas de 32 bits, si tienes más novedades no dudes en publicarlas

Del Eternal Darkness estaría genial ver la beta y del RE0 que en este vídeo se ve muy bien:
https://www.youtube.com/watch?v=_dcKEHt9htA

EFECTOS DE FRAMEBUFFER
Si recordáis algunos juegos tienen efectos de framebuffer como Mario Kart 64 en la pantalla del fondo:


La tasa de refresco de ese efecto no es muy alta, resulta que la he replicado en N64, no sé como lo haría Nintendo pero puedo explicar un poco como lo hice.

En este caso se puede volcar el fondo a una textura única de 32x32 o a 2 texturas de 64x24 de 16bits, en lugar de recoger todos los pixeles de la imagen y luego reducirla se saltea, si tengo una pantalla de 320 y la voy a poner en una textura de 32 se pueden hacer saltos de lectura en el buffer de 10 en 10 horizontalmente, así queda un bucle más corto.

El resultado queda así, en este ejemplo se crean y se destruyen las texturas al vuelo, a cada frame se le solicita una actualización (esto podría cambiarlo para mejorar rendimiento, pero guardando las texturas temporalmente en memoria).


Otra de las funciones nuevas permite hacer una copia exacta del fondo para luego manipularla, invertimos toda una fila, le cambiamos el color y la movemos para simular reflejos en el agua o hielo de todo lo que exista arriba.


Los tests son bastante malos y apenas le sacan partido a estos efectos, pero pueden dar mucho de sí, ya iré mostrando mejoras.

Después de haber visto este Die Hard 64 moverse en la consola tan bien, me da la sensación de que se pudo haber hecho un Half Life bastante decente para Nintendo 64.

Pues muchas gracias por los datos, parece ser que N64 no fue exprimida al 100% y es una verdadera lastima, la de juegazos increíbles que pudimos ver en ella, además de los que ya tiene

@BMBx64 voy a intentar probar los parches que existen para modificar las roms y eliminar el filtro AA y me estaba preguntando si existirán parches similares para otras modificaciones que sí se pueden con Gameshark (30fps, 60fps y widescreen por ejemplo). Mi everdrive no permite usar códigos de GS y creo que pocos juegos van bien con los 60fps desbloqueados, pero si hay alguno bienvenido sea.

@Calculinho
Como que no tiene soporte para gamesharks, no es el oficial?

Probé algunos juegos y creo que ninguno te va a ir bien a 60fps, el Mario o el Waverace van demasiado acelerados, casi injugables, aunque habrá zonas que solo tiren a 30fps y luego a 60fps, pero es bastante incontrolable.

La herramienta para modificar roms no sé si ha evolucionado más, lo que sí estaría bien es forzar todos los juegos a usar expansion pak y mover allí el buffer de pantalla para hacerlo triple, ganarían suavidad los juegos que oscilan entre 20 y 30, pero eso es complejo.

@BMBx64 desactivando el Z-Buffer aumentamos la tasa de relleno y ahorramos espacio en memoria, pero; ¿el sobredibujado se va mucho de las manos?

@BMBx64 no, es el chino y puedo instalar el https://krikzz.com/forum/index.php?topic=816.0 con ese sí puedo usar Gameshark, pero es demasiado lentorro la navegación por menús.

De todas formas lo de parchear las roms no me ha funcionado ninguna así que a saber que hago mal, así que voy a probar eso del enlace y armarme de paciencia

@Calculinho
El alt64 está programado con la libdragon y algunas librerías más, he mirado el código y usa funciones de pintado por software:
graphics_draw_box_trans(disp, s_x, (((p+3)*8)+24), 272, 8, selection_color); //(p+3) diff

Modo 32bits, supongo que puso el modo triple buffer pensando que funcionaría, pero eso hace que vaya a la máxima velocidad que pueda la consola, así que habrán problemas de tearing además.

display_init( res, DEPTH_32_BPP, 3, GAMMA_NONE, ANTIALIAS_RESAMPLE );

Debe ser muy lento.

En cuanto empiece a crear 3D en la consola no me importaría hacer un menú acelerado por hardware con las caratulas 3D de los juegos.

@Sexy MotherFucker
Desactivar el Z-buffer en un juego que lo use? Eso debe provocar un enorme estropicio.

El culling back face creo que requiere de z-buffer para funcionar y así descartar las caras tapadas de un cubo y con ello superficies que no se van a renderizar, además de que la prioridad de pintado y de triángulos cruzados es cosa del z-buffer.

Por lo que me dijo Krom, consiguió programar directamente en la VU y calcular 8 vértices por ciclo, con capacidad de descartar de dentro hacia afuera en el mismo cálculo, creo que se pueden hacer avances enormes programando a tan bajo nivel.

También por lo que entendí incluso con el z-buffer se dibuja bastante de más en los juegos comerciales, en algunos más que en otros, así que hay un enorme margen de mejora en eso.

BMBx64 escribió:@Calculinho
El alt64 está programado con la libdragon y algunas librerías más, he mirado el código y usa funciones de pintado por software:
graphics_draw_box_trans(disp, s_x, (((p+3)*8)+24), 272, 8, selection_color); //(p+3) diff

Modo 32bits, supongo que puso el modo triple buffer pensando que funcionaría, pero eso hace que vaya a la máxima velocidad que pueda la consola, así que habrán problemas de tearing además.

display_init( res, DEPTH_32_BPP, 3, GAMMA_NONE, ANTIALIAS_RESAMPLE );

Debe ser muy lento.

En cuanto empiece a crear 3D en la consola no me importaría hacer un menú acelerado por hardware con las caratulas 3D de los juegos.

@Sexy MotherFucker
Desactivar el Z-buffer en un juego que lo use? Eso debe provocar un enorme estropicio.

El culling back face creo que requiere de z-buffer para funcionar y así descartar las caras tapadas de un cubo y con ello superficies que no se van a renderizar, además de que la prioridad de pintado y de triángulos cruzados es cosa del z-buffer.

Por lo que me dijo Krom, consiguió programar directamente en la VU y calcular 8 vértices por ciclo, con capacidad de descartar de dentro hacia afuera en el mismo cálculo, creo que se pueden hacer avances enormes programando a tan bajo nivel.

También por lo que entendí incluso con el z-buffer se dibuja bastante de más en los juegos comerciales, en algunos más que en otros, así que hay un enorme margen de mejora en eso.

Pues si algún día lo haces estaré encantado de probarlo!

BMBx64 escribió:
Por lo que me dijo Krom, consiguió programar directamente en la VU y calcular 8 vértices por ciclo, con capacidad de descartar de dentro hacia afuera en el mismo cálculo, creo que se pueden hacer avances enormes programando a tan bajo nivel.

También por lo que entendí incluso con el z-buffer se dibuja bastante de más en los juegos comerciales, en algunos más que en otros, así que hay un enorme margen de mejora en eso.

¿No es mucho 8 vértices por ciclo?,estamos hablado de 8*62.5 Mhz = 500 M de vértices segundo,con que calculara 1 por ciclo ya me parecerían muchos.

Salud.

Estaré esperando ese menú con caratulas... Y ojala que funcione en los ed chinos!

@dirtymagic
Supongo que se refería por operación, luego tienes un tiempo muy limitado de trabajo en la VU, no creo que el cálculo sea así, porque de ahí no sacas la geometría lista para ser renderizada, hay otros pasos más, de todas formas da igual cuantos polígonos puedas calcular, el lastre está en que no le da tiempo a renderizarlos, pero si se los das mucho antes mejor.

@bluedark
Eso creo que es cosa de la librería que maneja la interfaz de la SD, hay que compilar el menú con la librería correspondiente de cada flash

@BMBx64 no, me refería a juegos diseñados desde 0 sin Z-Buffer, como World Driver Championship, el cual es uno de los títulos comerciales con más alto polycount, y que encima corre a algo más de 30 fps constantes.

Realmente más allá del Buffer z, tengo curiosidad de hasta dónde puede llegar la N64 en juegos de lucha o carreras prescindiendo de CUALQUIER filtro que le reste memoria o capacidad de proceso.

A mí un Virtua Fighter 2 de model 2 me parece aspirar muy alto; son más de 300.000 polígonos texturados por segundo a 60 fps, un filtro, y 496x384p. (24 Khz).

En cambio un Tekken 3 de System 12... ¿es realista esperar algo así de N64? Yo creo que sí.

@Sexy MotherFucker
El Z-Buffer, el AA, el dither, el filtro bilinear, el mip map y la corrección de perspectiva se hacen todos en el RDP, restarías tiempo al rasterizador con cualquiera de esas cosas.

El mip map requiere poner el RDP en 2cycle, si quieres iluminación goraud o corrección de perspectiva necesitas 1cycle, usar triángulos flat podría ser más rápido porque no hay que rellenar la información de iluminación de los ejes al enviar el comando, Tobal 1 usa mucho flat en los personajes por ejemplo, porque ahí están concentrados casi todos los polígonos, para fondos 2D podrías usar COPY y para los marcadores de pantalla, siempre que no sean semitransparentes.

El modo COPY hace bypass a la mayoría del pipeline y por eso es tan rápido, no tiene operaciones de blender ni del color combiner, ni lee el buffer de pantalla, por tanto lo mucho que puede hacer como su nombre indica es "copiar" una textura de TMEM al buffer y nada más, con la suerte que al menos tiene alpha compare para deducir que partes de una textura son invisibles (transparentes).

Los juegos de lucha son 4 polígonos contados para el escenario y muchos polígonos para los personajes, yo creo que programando bien no habría problemas de fillrate, porque la superficie de los triangulos a renderizar de los personajes va a ser pequeña.

Teniendo en cuenta que Mortal Kombat 4 ya va a 60fps con muchas cosas activadas, yo creo que habría bastante cambio programando al estilo de WDC.

@BMBx64 gracias

Hablando de juegos de coches; ¿qué puedes decirme de Ridge Racer 64?

Joder si es que en este vídeo parece que la consola lleva overclock o algo de lo zumbadísimo que va en algunos circuitos, atento al tramo que enlazo:

https://youtu.be/x-47fWFNUI4

Lo comparo con WRC y el juego de NAMCO me parece MUCHO más rápido con los coches avanzados, no tiene problemas de pop-up partiendo de una distancia de dibujado similar, se marca efectos de... ¿frame-Buffer? En las estelas de luz que dejan los coches en las repeticiones de los circuitos nocturnos, y eso; que el juego va CICLADÍSIMO cuando desbloqueas buenos coches.

Te pregunto porque tú tienes emulador a mano.

P. D: La N64 también usa Tri-lineal filtering en algún juego No?

@Sexy MotherFucker @BMBx64 ya sabéis que yo no soy experto en mirar detalles técnicos de juegos, pero juegos de velocidad de la consola que van bien y a mi como jugador no técnico me parece que lucen muy bien diría todos estos (sí, voy a aprovechar cualquier hilo que pueda para hablar del fullset que para algo estuve 2 meses intensivos con N64 ):

1º- Top Gear Rally 2
2º- F1 World Grand Prix II
3º- Top Gear Overdrive
4º- Monaco Gran Prix (creo que usa mucho decorado 2D para engañar)
5º- Roadsters
6º- Indy Racing 2000
7º- San Francisco Rush 2049

Evidentemente RR64 y WRC que mencionaste antes también.

Otros de velocidad por si interesan, pero creo que a nivel explotar polígonos no lo hacen aunque tengo dudas con el primero:
1º- Diddy Kong Racing
2º- MK64
3º- Extreme-G (la segunda parte luce mejor, pero va peor)
4º- F-Zero X
5º- Re-Volt
6º- Beetle Adventure Racing
7º- Automobili Lamborghini
8º- Wipeout 64
9º- Penny Racers (en Japón tiene secuela)
10º- Mickey's Speedway
11º- S.C.A.R.S.
12º- Star Wars Racer

Otros de carreras, pero distintos:
1º-Hydro Thunder
2º-Wave Race 64
3º- Micro Machines 64
4º- 1080º Snowboarding
5º- Snowboard Kids 1&2
6º- Road Rash 64

@Calculinho ¿no te sorprendió lo A TODA HOSTIA que zumba Ridge Racer 64 con la cámara en primera persona, y que dibuje los fondos sin rastro de pop-up con tanta distancia de dibujado? Joder mira el vídeo de la página anterior, más rápido que eso el F-Zero X.

Se lo alquiló mi hermana en la época para su N64, pero no me lo tomé muy en serio más allá de un par de vueltas quizás por el formato PAL, pero tengo la apremiante sensación de que cometí un tremendo error ignorándolo...

¡Joder pero si es que es más rápido y con escenarios más sólidos que el RR-Type 4 en PlayStation, el cual fué el pináculo de la saga en la generación! Estoy flipando, si es que hasta la música es decente.

Soy fan de la saga hasta el V, y me he perdido este por mis prejuicios madre mía.

Sólo me mosquea el número de coches competidores, que parecen incluso menos que en PS...

Sexy MotherFucker escribió:@Calculinho ¿no te sorprendió lo A TODA HOSTIA que zumba Ridge Racer 64 con la cámara en primera persona, y que dibuje los fondos sin rastro de pop-up con tanta distancia de dibujado? Joder mira el vídeo de la página anterior, más rápido que eso el F-Zero X.

Se lo alquiló mi hermana en la época para su N64, pero no me lo tomé muy en serio más allá de un par de vueltas quizás por el formato PAL, pero tengo la apremiante sensación de que cometí un tremendo error ignorándolo...

¡Joder pero si es que es más rápido y con escenarios más sólidos que el RR-Type 4 en PlayStation, el cual fué el pináculo de la saga en la generación! Estoy flipando, si es que hasta la música es decente.

Soy fan de la saga hasta el V, y me he perdido este por mis prejuicios madre mía.

Sólo me mosquea el número de coches competidores, que parecen incluso menos que en PS...

Recuerdo lo que me flipó el RRT4 de PSX en su momento y este sí lo jugué con cámara en primera persona. Pero todos los juegos que he citado antes los he jugado en tercera persona y sobre RR64 no me flipó, pero tampoco me decepcionó de hecho ya indico que está en la lista de los que me llamaron la atención. Los que más me llamaron la atención fueron los dos Top Gear que he mencionado, me decepcionó bastante V-Rally 99 que no lo he puesto en el listado porque me olvidé. Pese a ello, este género no es mi fuerte y de hecho mis favoritos de velocidad de la consola serían del segundo listado: DDKR, MK64 y FZero.

Evidentemente el hecho de que RRT4 me flipara y RR64 no, se debe a que el primero lo jugué en su lanzamiento y el otro lo jugué en 2017 y no juega con el factor "gráficos a la última" que sí tuvo el otro. Seguramente ambas versiones sean parecidas con las típicas diferencias entre ambos sistemas: musicote, voces y efectos de sonido en PSX, filtros AA en N64 y sin tiempos de carga.

@Calculinho joder entonces será cosa del vídeo, a lo mejor es una partida grabada con overclock a 125 Mhz, porque madre mía...

Y sí, Ridge Racer Type-4 es el pináculo de elegancia en la franquicia.

@Sexy MotherFucker @Calculinho

Me pasé todos los circuitos y desbloqueé todos los coches. Menudo vicio le pillé al puto juego...

Y sí, cuando pillas coches que van a partir de cierta velocidad, como el Lizard Nightmare o el Screaming Eagle (por no hablar del cheto Ultra64), el juego vuela en velocidad. El problema es que, para mi gusto, va demasiado rápido. De hecho, va rápido hasta el punto de que el último circuito me lo pasaba de memoria porque, casi literalmente, no veía la pista de lo rápido que iban éstos coches.

Por ejemplo, en F-Zero X, que va a full speed (a mi ojo va a 60FPS) pues bueno, lo puedo seguir. Pero RR64, que va a 30FPS (lo digo a ojo), pues me pierdo bastante a según qué velocidad vaya.

@viper2 o sea que entonces la velocidad es real.

Gracias.

Cuando tenga tiempo lo fundo en mi Everdrive64.

Sexy MotherFucker escribió:@viper2 o sea que entonces la velocidad es real.

Gracias.

Cuando tenga tiempo lo fundo en mi Everdrive64.

Al menos el vídeo que has puesto es como lo recuerdo, muy rápido. Los últimos circuitos, con los coches que te digo, es más práctica la vista desde fuera. Con la vista subjetiva ya te digo que me los pasaba de memoria porque no veía ná, y la tele que tenía tampoco ayudaba mucho.

También me pasé el V-Rally 99 en su momento. Para mí, bonito y algo lentorrete... pero ponte la cámara subjetiva y consigue ir a todo trapo... de pequeño pillé muchos mareos porque me gustaba más ésa vista que la exterior.

Quizás por éso me volví muy nazi con los juegos de coches, y no considero igual de bueno uno a 30FPS que uno a 60FPS.

@viper2 pues para see el único juego "serio" que hizo NAMCO para el sistema lo programó acojonantemente bien; o sea el juego va FOLLADO en primera persona cuando pillas X coches, tiene una distancia de dibujado considerable en escenarios trabajados, y ni rastro de popping.

Aunque ahora que me acuerdo no fué Nintendo Software Tecnologic la que programó RR64 ¿¿?? Eso explicaría muchas cosas.

Flipante el juego para ser la plataforma que es.

Sexy MotherFucker escribió:@viper2 pues para see el único juego "serio" que hizo NAMCO para el sistema lo programó acojonantemente bien; o sea el juego va FOLLADO en primera persona cuando pillas X coches, tiene una distancia de dibujado considerable en escenarios trabajados, y ni rastro de popping.

Aunque ahora que me acuerdo no fué Nintendo Software Tecnologic la que programó RR64 ¿¿?? Eso explicaría muchas cosas.

Flipante el juego para ser la plataforma que es.

Alguien comentó hace tiempo, creo que en éste mismo hilo, que NAMCO no tocaba la N64 ni con un palo, así que apostaría a que fué Nintendo quien lo hizo. Tendría sentido, y a Nintendo le venía bien traer un peso pesado de PSX a N64... que, las cosas como son, a la N64 le hacían falta juegos de carreras. (Y lo digo como nintendero, tiene juegos buenos, pero pocos)

viper2 escribió:

Sexy MotherFucker escribió:@viper2 pues para see el único juego "serio" que hizo NAMCO para el sistema lo programó acojonantemente bien; o sea el juego va FOLLADO en primera persona cuando pillas X coches, tiene una distancia de dibujado considerable en escenarios trabajados, y ni rastro de popping.

Aunque ahora que me acuerdo no fué Nintendo Software Tecnologic la que programó RR64 ¿¿?? Eso explicaría muchas cosas.

Flipante el juego para ser la plataforma que es.

Alguien comentó hace tiempo, creo que en éste mismo hilo, que NAMCO no tocaba la N64 ni con un palo, así que apostaría a que fué Nintendo quien lo hizo. Tendría sentido, y a Nintendo le venía bien traer un peso pesado de PSX a N64... que, las cosas como son, a la N64 le hacían falta juegos de carreras. (Y lo digo como nintendero, tiene juegos buenos, pero pocos)

Juegos tiene bastantes creo yo, fijate la lista que he puesto que son los que yo he considerado buenos dentro del catálogo. Había más que para mi son malos y he decidido no meterlos en mi top: V-Rally, Lego Racers, GT64, etc.

El problema es que PSX tiene no uno, sino dos Gran Turismo y sólo con estos la mayoría de amantes de la conducción se decantan por la consola de Sony. N64 tenía complicado competir contra un Gran Turimos aunque Nintendo quisiera hacer uno porque a ver como metes en un cartucho toda esa base de datos de circuitos y coches. No puedo hablar de cuantos juegos de velocidad buenos tendrá PSX porque no me he puesto con su fullset (me da miedo ) y seguramente tenga un gran catálogo también y más amplio, pero el de N64 en este género está bien cubierto creo yo a diferencia de juegos de lucha, rpg, terror, etc.