Hilo de detalles y curiosidades de N64

Diskover escribió:

Señor Ventura escribió: y a 640x480, que esa es otra.

¿No es posible poner menos resolución?

Hombre, con el anti aliasing, algo si, pero si hablamos de parecerse al arcade, aunque sea a 5fps...

Diskover escribió:

Señor Ventura escribió: y a 640x480, que esa es otra.

¿No es posible poner menos resolución?

Tan posible como que Model 2 saca 496x384 px de resolución.

Salud.

320x240 - > 496x384

Señor Ventura escribió:320x240 - > 496x384

Todos los juegos que utilizan expansion pak,para ofrecer modos de alta resolución,suelen ser resoluciones similares a model 2 ,que luego se rescalan a 640x480.
La definición que saca un monitor arcade,que emite en progresivo, no lo vas a sacar con la nintendo 64 ni aunque la pusieras a 480i.

Salud.

dirtymagic escribió:Todos los juegos que utilizan expansion pak,para ofrecer modos de alta resolución,suelen ser resoluciones similares a model 2 ,que luego se rescalan a 640x480.

Es custom?, porque realmente de cualquier lado solo parece leerse que su resolución tiene un mínimo y un máximo, pero como si no fuese un valor fijo.

Por ejemplo... ¿551x397?.

Si es así es todavía mejor porque puedes clavar la resolución original, que es mejor que 640x480 cropeados (o un poco me jor que eso, con un modo extra panorámico y bandas negras).

dirtymagic escribió:La definición que saca un monitor arcade,que emite en progresivo, no lo vas a sacar con la nintendo 64 ni aunque la pusieras a 480i.

¿A menos que la conectes a un monitor profesional? (¿tal vez?).

O instalándole el mod hd, y así un daytona usa a 291x225 tendrá un aspect ratio idéntico al del arcade con la menor resolución posible que admite el sistema, y la mejor nitidez posible.

¿No?.

@BMBX64
increible el avance que estas teniendo la n64 en verdad es una maquina potente, que genial lo que dices de Krom, yo pongo el demo de bad apple de nes con neon 64 en la consola y me da curiosidad como quedaría la versión de 64 se nota que traen muy buenos proyectos.

Por mientras esperare el emulador de snes, n64 forever!!

Señor Ventura escribió:

dirtymagic escribió:Todos los juegos que utilizan expansion pak,para ofrecer modos de alta resolución,suelen ser resoluciones similares a model 2 ,que luego se rescalan a 640x480.

Es custom?, porque realmente de cualquier lado solo parece leerse que su resolución tiene un mínimo y un máximo, pero como si no fuese un valor fijo.

Por ejemplo... ¿551x397?.

Si es así es todavía mejor porque puedes clavar la resolución original, que es mejor que 640x480 cropeados (o un poco me jor que eso, con un modo extra panorámico y bandas negras).

dirtymagic escribió:La definición que saca un monitor arcade,que emite en progresivo, no lo vas a sacar con la nintendo 64 ni aunque la pusieras a 480i.

¿A menos que la conectes a un monitor profesional? (¿tal vez?).

O instalándole el mod hd, y así un daytona usa a 291x225 tendrá un aspect ratio idéntico al del arcade con la menor resolución posible que admite el sistema, y la mejor nitidez posible.

¿No?.

Hay varios post de BMBx64 en este hilo,que dice la resolución del framebuffer de varios juegos en sus modos de normal y "alta resolución",luego la N64 rescala para ocupar toda la pantalla.
Turok 2, 3 y Shadowman : 480x360.
Goldeneye : 440x335 en los menus.
Castlevania Legacy of Darkness : 448x336
Hybrid Heaven : 576x448
NHL : 558x441
Battle of Naboo : 400x442
Perfect Dark : 640x240

Parece que sacar la resolución del Model2 no es problema.
Para conectarlo a un monitor profesional,creo que tendría que conectarse por RGB y que la consola emita 31 khz en vez de 15khz si quieres sacar mas de 240p,el mod hd ni idea.

Salud.

Me acabo de dar cuenta de que los reflejos del cristal de los coches son solo una única textura, sin mezclas.

dirtymagic escribió:Hay varios post de BMBx64 en este hilo,que dice la resolución del framebuffer de varios juegos en sus modos de normal y "alta resolución",luego la N64 rescala para ocupar toda la pantalla.

Vamos, 640x480 cropeados y reescalados.

He montado un debug del combiner, todas esas opciones acabadas en 0 no tienen efecto, pues parece que solo afectan si se activa 2cycle, así que en 1cycle nos centramos en las que tienen 1.


He visto bastantes cosas interesantes, sobretodo hay muchos modos de combinación:
- Se pueden crear máscaras, por ejemplo puedes hacer que una semitransparencia solo se visualice en las partes de color de otra superficie, imaginemos que proyecto una sombra en una pared y ahora paso por una ventana o una verja, la sombra solo se vería donde debe verse, no entre los huecos de la ventana o la verja.
- Se pueden crear máscaras de recorte, el típico radar que es redondo y hace scroll, pero da para mucho más.
- Se pueden crear negativos.
- Hay modos para crear falso sombreado, el RDP redondea los sprites poniendo pixeles oscuros alrededor, lo puede hacer por la izquierda, por la derecha, etc.
- Puede hacer tramados, en lugar de una semitransparencia, crearía huecos que se ven y no se ven, el patrón de ese tramado también es modificable.

He cambiado sub_a_R_1 del 6 al 7 y ha salido este efecto de ruido, similar a una tv, creo que lo vi en el Duke Nukem 64, en el TWINE y en alguno más


Pero los valores que me interesan son los de las 3 últimas opciones, 4-5-4 activa semitransparencias estándar (que supongo que deberán controlarse con otro comando, aquí aparecen al 50% o así), el modo 5-2-3 activa el additive blending, creo que ya se comentó que N64 sí puede hacer este efecto (muy típico de PSX) pero los colores no tienen limite al hacer add y se voltean, pasa algo así:


Las zonas amarillas son las defectuosas, se ha ido de la cuenta los colores, sin embargo, hay zonas que han funcionado correctamente, por tanto en zonas controladas sí podría usarse additive blending tal cual de serie, pero es más, dado que se va de colores, podrían crearse 3 buffers, en cada uno se guardan los componentes R G B por separado y luego se mezclan, creo que hay juegos que usan algo parecido, Jet Force Gemini desde luego parece tener efectos de luz muy potentes, pero requiere más memoria.

El siguiente debug que voy a hacer es el set other modes, ese si que va a tener chicha porque son 36 opciones combinables, que además pueden alterar como funciona el combiner.

Hay que recordar que con el combiner y algunas opciones más se puede hacer esto, así que es algo muy complejo.


Por otro lado en el documento oficial hay información del modo Turbo3D, en resumen:
- Es menos preciso en las operaciones, por tanto más rápido y según en el documento puede crear algunos "artefactos".
- No tiene corrección de perspectiva.
- No tiene iluminación, vaya, esto no me lo esperaba, si es así no es demasiado útil, salvo que se implemente por separado.

Pero hay otro modo que no suele comentarse y es el Super3D, este modo es parecido al Fast3D pero a medio camino con el Turbo3D, es menos preciso y tiene algunas cosas desactivadas.

Para 2D, cuantas menos cositas tenga, mejor.

Sin corrección de perspectiva que va la psone, y en 2D no lo notas, así que el modo turbo3D pinta bien (y si ya de paso puede aprovecharse todo el hardware, mejor que mejor).

Y sobre el combiner, al parecer es una especie de mini-TEV, que ya es lo que le faltaba a la N64 para terminar de cerrar los paralelismos con la GC. Ahora veo al engendro de otra forma... la snes es a la nes lo que la GC es a la N64 (e incluso mas, ya que usan literalmente la misma arquitectura).

Estoy empezando a ver el monstruo que es el bichejo este, y solo me queda decir que es una lástima que los desarrolladores no se volcaran en aumentar su rendimiento.

@dirtymagic ¿Pero esos framebuffers son literales, entrelazados, o modos de 640x480i capados? Porque de ser lo primero la N64 sería 24khz compatible, y por extensión tri-frecuencia...

La Nintendo 64 es un nefasto diseño de hardware, que al igual que sistemas como Saturn, o Ps2, necesitan de programación a bajo nivel, con herramientas muy específicas para sortear todas sus taras, y desflorar su potencial en una perfomance ideal. La diferencia es que la última nombrada fue EL producto de masas por casi una década, y les tocó esforzarse por cojones, no porque les apeteciese, amén de que los SDKs del año 2000 los separa un abismo de los del 2006.

@Sexy MotherFucker

Off-topic: ¿Te habías dado cuenta alguna vez de que el sonic 1 usa 3 colores por tile?.

Modo 0 (4 planos a 3 colores + transparente), modo 5 (512x224), ejem xD


Perdón, prosigan

@Señor Ventura una cosa que nunca me terminas de aclarar: esos 512x224 son progresivos o entrelazados?

Sexy MotherFucker escribió:@Señor Ventura una cosa que nunca me terminas de aclarar: esos 512x224 son progresivos o entrelazados?

512x224 progresivo
512x448 entrelazado.

Y puedes hacer si quieres que los 512x448 entrelazados sean 512x224 entrelazados forzando 512x112 alternos a cada frame, desactivando un cerro de scanlines (bandas negras mas grandes). ¿Y para que?, pues para doblar el ancho de banda.

Pero si, 512x224 es progresivo.

Sexy MotherFucker escribió:@dirtymagic ¿Pero esos framebuffers son literales, entrelazados, o modos de 640x480i capados? Porque de ser lo primero la N64 sería 24khz compatible, y por extensión tri-frecuencia...

No lo sé a ciencia cierta pero yo creo que todo lo que saca a mas de 240p ,lo muestra en entrelazado,mas que nada por el "nivelazo" de salida de video que tiene ,y la "gran variedad" de conexiones para conectarla a la TV,me parecería muy raro que saque imagen a más de 15khz.

Salud.

Puedes colocar en modo NTSC una resolucion de 480 lineas sin problemas en modo no-entrelazado (30hz).

Urian escribió:Puedes colocar en modo NTSC una resolucion de 480 lineas sin problemas en modo no-entrelazado (30hz).

Claro,tienes razón,yo es que siempre pienso en 60/50hz.

Salud.

CURIOSIDAD
Una de las mazmorras más místicas de Zelda en vista de 360 grados, usad el ratón para mover la cámara mientras se desplaza.
https://www.youtube.com/watch?v=E4_YgCL7O_0

DEMO ALPHA BLENDING
He montado una pequeña demo donde se enseñan semitransparencias usando el RDP, hasta 32 niveles de transparencia en modo 16bits, supongo que es correcto, los 8 bits enteros de alpha igual se usan en modo 32bits.


También trae additive blending, al final tanto rollo con usar 3 buffers separados o por software y se puede controlar manualmente mediante el rango RGB directamente, eso sí, he tenido que dedicar un buen rato en el combiner para dar en el clavo, pongo esta imagen porque en el emulador no va demasiado bien el add.


CONTROLES
A - Espejar Sprite horizontalmente
Z - Activar / Desactivar additive
L / R - Controlar alpha
Joy - Mover scroll
C - Controlar escala X/Y

DESCARGA
https://mega.nz/#!YtwGUbJC!y1zx0efruI_ezXkJQnm4csosFxDDxP5qo7v9bKtu5J4

Así que estas son todas las funciones nuevas que he ido añadiendo en la libdragon para el RDP:

Crear y enviar comandos directamente al RDP (generalmente para debug o para crear nuevas funciones internas):


Control de centros virtuales de imágen:


Modo 1cycle para activar compatibilidad con X_scale y RGB scale, no soporta alpha este set de combiner.


Mismo modo que el anterior pero filtra la textura en cuanto hace zoom para que no se vea pixelada:


Como el modo 1cycle pero activa compatibilidad con alpha, sin embargo si alpha es 255 sigue siendo algo transparente, por eso he creado esta otra función, se llama a 1cycle cuando no se use transparencia.


Es como alpha pero además añade additive, si se va de colores se puede controlar con rgba_scale.


Ya puse un ejemplo en páginas anteriores, permite tintar un rectángulo a una escala de colores, el color puede ser gradual en componente RGB, además añade alpha a la mezcla.


Con ésta función se puede hacer un fundido a negro, pero no a blanco, tengo que crear otro combiner que me permita intensificar la imagen, siendo RGB 255,255,255 blanco total, o 255 0 0 rojo total.

Ninguna penalización en rendimiento por usar cualquiera de estas funciones, más allá de hacer funcionar al chip en modo 1 pixel por ciclo.

En cuanto al tamaño del rectángulo existe un limite, pueden ser de 4096x4096, esto no viene bloqueado de serie en la libdragon, así que si nos pasamos con el zoom podrían verse cosas muy feas en pantalla, lo he parcheado con un límite, como curiosidad el tamaño máximo de un rectángulo en PSX es de 1024x512.

Nunca he respondido en este hilo y voy a dar mi opinión en cuanto al diseño de la consola.

¿Que sentido tiene el RSP cuando puedes colocar algo como el GTE de la PlayStatio como coprocesador en el R4300 ahorrandote unos costes excesivamente altos? ¿Que sentido tiene el RSP cuando puedes colocar la función del rasterizador en una serie de máquinas de estado ocupando una porción minúscula y dandote espacio para colocar un DSP de sonido?

Claro esta que incluso la propia Silicon Graphics reconocía por otro lado que el RSP era un tordo para el 3D. ¿Como? Fuera de Nintendo era llamado Multimedia Engine y estaba pensado para los set-top boxes inicialmente aunque termino en el SGI O2 como el ICE, que por cierto en esos ordenadores el ICE/RSP nunca se uso para el calculo de la geometría 3D porque sabían que era una puta mierda para ello.

A mi lo que me resulta revelador de SGI es lo que los fundadores de la mítica 3Dfx dijeron en el panel sobre la compañía, donde Gary Tarolli comentaba como su demostración de su simulador de vuelo iba la mar de suave en un Pentium de los primeros con una Voodoo Graphics prototipo y en la sala de al lado una estacion de trabajo SGI con cien veces el coste ranqueaba con la misma demostración.

Dicho de otra manera... A Silicon Graphics no le importaron jamás los fotogramas por segundo, es por ello que cuando Nintendo propuso la RAMBUS les pareció bien en el diseño, porque al fin y al cabo cuadraba con lo que ellos consideraban que era bueno para un sisteme doméstico.

El templo del bosque del ocarina es uno de los mejores para mi es el más místico, tal vez solo sea mi imaginación pero la música del templo tiene una voz que me recuerda a yoshi, pero en fin cada una de las mazmorras del ocarina son únicas y especiales, no por nada está considerado como una obra maestra.

Forest Temple es mi mazmorra favorita del OOT , la música me encanta y todo el nivel tiene una iluminación que le da un sombreado brutal a los objetos.

El RSP es todo un desconocido de momento, sirve como coprocesador, puede correr código general al no dejar de ser otro MIPS 4000, sumas, restas y multiplicaciones van como un tiro, no se le deben pasar divisiones ni funciones que usen sqrt (lo que uso para ordenar display lists), ya que eso lo hará emulado, mucho más lento que la CPU, así que esas operaciones se las damos ya hechas, la CPU y el RSP funcionan en paralelo.

Luego tiene una unidad vectorial que va como un tiro, en las transformaciones 3D puede trabajar con 8 vectores simultáneamente, muy poca gente ha tocado ese chip a bajo nivel, en la scene de hecho solo hay unos pocos que saben realmente que puede hacer el chip y más vale que me empape rápido antes de que marchen

Tengo planeado empezar a usarlo en cuanto acabe todo lo del RDP, primero me interesaría usarlo para audio, luego dándole el trabajo que hace ahora mismo la CPU, crear rectángulos y comandos para el RDP, ya iré escribiendo que me encuentro, aunque cada vez veo que interesa menos esto y que se prefieren los análisis, igual tendría que crear otro hilo.

Por otro lado el framebuffer tendría que haber llevado su propio pozo, el que afloja demasiado es el RDP cuando hay muchas operaciones de pintado y no por el chip en sí, que es rápido cuando hace operaciones internas, parece que aprendieron de este detalle en GC.

Ahora ya estoy trabajando en las texturas de 4 y 8 bits, las paletas se almacenan en los 2KB superiores de la TMEM, de nuevo esto tendría que haber llevado memoria extra en el chip para almacenar paletas y dejar los 4KB libres para la textura en si.

Las texturas de 8bits serían del mismo tamaño máximo: 64x32
Las texturas de 4bits si reciben mejora, ya que 2 pixels ocupan un byte, se puede llegar a 64x64.

El sistema permite guardar 1 paleta de 256 colores o 16 paletas de 16 colores, se pueden actualizar en cualquier momento, tantas veces como sea necesario, los colores de las paletas se almacenan como 16bits, aunque estemos en modo 32bits, historias raras.

De todas formas usar paletas implica que las texturas ocupen menos espacio en el cartucho, menos espacio en RAM y dejar un poco más de ancho de banda para otras transferencias.

Pero hay que hacer llamadas extra si se van cargando paletas de forma continua, creo que habría que hacer un sistema donde vayan compartidas, para tomar ventaja y acelerar cálculo.

Tras acabar texturas con paletas solo me queda empezar a usar triángulos, para hacer las rotaciones de sprite, aquí además se podría aplicar sombreado y otro tipo de transparencias, ej. las graduales que defines desde un punto solido a transparente.

yo por mi puedes seguir con los analisis tecnicos de la consola que me encantan a la vez que aprendo sobre cuan desaprovechada estaba la pobre

La cosa es ¿le habria añadido algo extra la 64dd? porque no es que sea pequeño el modulo

BMBx64 escribió:El RSP es todo un desconocido de momento, sirve como coprocesador, puede correr código general al no dejar de ser otro MIPS 4000, sumas, restas y multiplicaciones van como un tiro, no se le deben pasar divisiones ni funciones que usen sqrt (lo que uso para ordenar display lists), ya que eso lo hará emulado, mucho más lento que la CPU, así que esas operaciones se las damos ya hechas, la CPU y el RSP funcionan en paralelo.

¿Esto significa que comercialmente el RSP se usó poco?. No llego a imaginar hasta donde puede sacarse petróleo de ahí, pero hasta donde llevo leyéndote, empiezo a creerme eso de que queda un 60% de potencia extra aún por sacar.

Si eso significa algo así como 300.000 polígonos por segundo con todos los efectos a 30fps, o 600.000 polígonos pelados, oficialmente tengo que decir que la N64 merece un reconocimiento especial.

BMBx64 escribió:Luego tiene una unidad vectorial que va como un tiro, en las transformaciones 3D puede trabajar con 8 vectores simultáneamente, muy poca gente ha tocado ese chip a bajo nivel, en la scene de hecho solo hay unos pocos que saben realmente que puede hacer el chip y más vale que me empape rápido antes de que marchen

No te olvides de informarnos, que algunos te leemos atentamente...

BMBx64 escribió:Tengo planeado empezar a usarlo en cuanto acabe todo lo del RDP, primero me interesaría usarlo para audio, luego dándole el trabajo que hace ahora mismo la CPU, crear rectángulos y comandos para el RDP, ya iré escribiendo que me encuentro, aunque cada vez veo que interesa menos esto y que se prefieren los análisis, igual tendría que crear otro hilo.

39.000 visitas al hilo a mi me dicen que si hay interés

Que no decaiga, que está esto en la parte mas interesante

BMBx64 escribió:Por otro lado el framebuffer tendría que haber llevado su propio pozo, el que afloja demasiado es el RDP cuando hay muchas operaciones de pintado y no por el chip en sí, que es rápido cuando hace operaciones internas, parece que aprendieron de este detalle en GC.

Ahora ya estoy trabajando en las texturas de 4 y 8 bits, las paletas se almacenan en los 2KB superiores de la TMEM, de nuevo esto tendría que haber llevado memoria extra en el chip para almacenar paletas y dejar los 4KB libres para la textura en si.

Las texturas de 8bits serían del mismo tamaño máximo: 64x32
Las texturas de 4bits si reciben mejora, ya que 2 pixels ocupan un byte, se puede llegar a 64x64.

El sistema permite guardar 1 paleta de 256 colores o 16 paletas de 16 colores, se pueden actualizar en cualquier momento, tantas veces como sea necesario, los colores de las paletas se almacenan como 16bits, aunque estemos en modo 32bits, historias raras.

A mi lo que no me queda claro, es que cosa obliga a la N64 a usar solamente 4KB de la RAM unificada para conformar las texturas. ¿Se establece durante el arranque y es inamovible?, menudo fallo no poder ser programable... se supone que lo genial de disponer de memoria unificada es que tu eliges que cantidad le dedicas a cada cosa.

Señor Ventura escribió:¿Esto significa que comercialmente el RSP se usó poco?. No llego a imaginar hasta donde puede sacarse petróleo de ahí, pero hasta donde llevo leyéndote, empiezo a creerme eso de que queda un 60% de potencia extra aún por sacar.

Si eso significa algo así como 300.000 polígonos por segundo con todos los efectos a 30fps, o 600.000 polígonos pelados, oficialmente tengo que decir que la N64 merece un reconocimiento especial.

Usaban las macros creadas en la libultra y los "micro códigos", pero en ese chip puedes programar directamente, lo único pues eso no es un procesador completo porque le han quitado partes para hacer hueco a la unidad vectorial, trabajas con la DMEM que es más corta que la cache de la CPU, etc.

En el test de copos ya ponía 350K rectángulos por segundo, los triángulos serían más lentos, pero para hacerse una idea, todo tira de CPU y sin demasiadas optimizaciones, ese test estaba limitado por la CPU no por el RDP, que ponía copos de 4x4 o 16x16 sin bajar el rendimiento.

Metes el RSP que es el chip dedicado para esas tareas y el test volaría, es decir, no hay que entender o un chip o el otro, pueden trabajar los 2 a la vez y en lo mismo, que el RSP a partir de X afloja? Reparte la faena con la CPU.

Lo mismo sirve a la inversa, puedes usar la unidad de coma flotante de la CPU para ayudar al RSP con las transformaciones 3D, de hecho la mayoría de homebrew 3D que hay en N64 no usa el RSP, todo en la CPU, yo creo que la consola puede procesar más polígonos de los que puede pintar, eso mismo me comentó Krom que ha hecho todos esos ejemplos en ASM y también ha tocado PSX a bajo nivel, según él lo que más echa en falta en N64 es la SPU de PSX, el chip de sonido, de la VU del RSP está muy contento.

En los juegos comerciales tenemos el ejemplo del Top Gear Rally, para ese juego creían que el sonido perjudicaba al RSP en el rendimiento, así que lo pasaron a la CPU, para World Driver Championship programaron su código y entendieron que eso no era el problema, lo volvieron a cargar en el RSP y sin embargo, aún con sonido a cuestas, ese juego es de los que más polígonos pone de la consola.

Señor Ventura escribió:A mi lo que no me queda claro, es que cosa obliga a la N64 a usar solamente 4KB de la RAM unificada para conformar las texturas. ¿Se establece durante el arranque y es inamovible?, menudo fallo no poder ser programable... se supone que lo genial de disponer de memoria unificada es que tu eliges que cantidad le dedicas a cada cosa.

Bueno no son 4KB de la RAM unificada, son 4KB de TMEM, una memoria dentro del RDP mucho más rápida, la respuesta sencilla es que solo "trabaja de ahí", tienes comandos que leen de la RAM y cargan en TMEM, pero a partir de ahí se trabaja solo con esa memoria, salvo que exista algún truco o modo especial.

Flash-Original escribió:yo por mi puedes seguir con los analisis tecnicos de la consola que me encantan a la vez que aprendo sobre cuan desaprovechada estaba la pobre

La cosa es ¿le habria añadido algo extra la 64dd? porque no es que sea pequeño el modulo

Pues no sé, igual se podría haber hecho algo con el módem, los saves también podían ocupar más, quizás daría para guardar cosas más complejas (como los circuitos editados del F-Zero), que tal llevas los tests en N64?

@Señor Ventura
@BMBx64

300.000 polígonos a 30 fps con todos los efectos activados equipararía a la Nintendo 64 con un Model 2....

@BMBx64 No lo he toqueteado ya que estoy aprendiendo del libro de programacion en c lo intente transportar y no supe porque tengo entender todas las cosas que vas diciendo (windows= auto, n64=manual) y segun lei tenia que entender los de framebuffer y demas asi que no he tocado mucho la libdragon por que no consigo entenderlo.

Lo maximo que he llegado es a seguir editando niveles de zelda como funcionamiento de salas, intento de usar la multitextura,uv map, iluminacion global y direccional (que se usa poco)

Si llego a hacer algo lo subire por aqui

Aun asi la 64dd creo que lei que daba un poco mas de potencia por la lectura de los discos magneticos, ademas de las nuevas funciones como el reloj a tiempo de real del ura y otras cosas.

Hay una pagina francesa que ha analizado bastante este apartado llego a dumpear el S.O,pruebas con multiples juegos simulando carga por 64dd y demas (que se puede usar en everdrive)

Si la encuentro la paso

No se si es verdad pero hay juegos curiosos como spin-off de perfect dark
https://www.unseen64.net/category/nin/nintendo64-64dd/

BMBx64 escribió:Tengo planeado empezar a usarlo en cuanto acabe todo lo del RDP, primero me interesaría usarlo para audio, luego dándole el trabajo que hace ahora mismo la CPU, crear rectángulos y comandos para el RDP, ya iré escribiendo que me encuentro, aunque cada vez veo que interesa menos esto y que se prefieren los análisis, igual tendría que crear otro hilo.

Todas tus pruebas de programación en Nintendo 64 me parecen una pasada. Si no comento es porque no tengo ni la más remota idea de programación y no puedo aportar nada.
Si creas un nuevo hilo es posible que llames la atención de algún despistado, pero creo que todos los interesados en Nintendo 64 de este foro ya están al loro de lo que estás haciendo.
Lo que sí sería interesante es que crearas un índice en el primer mensaje con links a los mensajes como hiciste en el hilo del otro foro.

BMBx64 escribió:Ahora ya estoy trabajando en las texturas de 4 y 8 bits, las paletas se almacenan en los 2KB superiores de la TMEM, de nuevo esto tendría que haber llevado memoria extra en el chip para almacenar paletas y dejar los 4KB libres para la textura en si.

Las texturas de 8bits serían del mismo tamaño máximo: 64x32
Las texturas de 4bits si reciben mejora, ya que 2 pixels ocupan un byte, se puede llegar a 64x64.

Esto no lo termino de entender. ¿Estás hablando de cómo mejorarían las texturas si las paletas se cargasen a parte de los 4KB de la caché? En ese caso te daría lo mismo que las texturas fueran a color que en escala de grises, por lo que las texturas podrían ser de 64x64 con 8 bits de profundidad y 128x64 con 4 bits. Claro que serían texturas sin mipmapping, que quizás es a lo que te refieres y entonces sí podrían alcanzar el tamaño que mencionas. Básicamente guardar las paletas en los 4KB de la caché está limitando la resolución de las texturas a la mitad.

Flash-Original escribió:La cosa es ¿le habria añadido algo extra la 64dd? porque no es que sea pequeño el modulo

Potencia no creo que le añada. Lo que sí incluía el 64DD era una amplia librería de samples para la música para poder ahorrarte espacio en el cartucho. Claro que si ibas a usar samples propios no podías aprovechar esa "ventaja". A parte, el 64 DD obligaba al uso del Expansion Pak.

Más que potencia yo le veía muchas posibilidades para los juegos porque los discos magnéticos podían actuar como gigantescas tarjetas de memoria. Esto se aprovecha muy bien en juegos como Simcity 64 y los Doshin the Giant donde la cantidad de datos que hay que manejar para modificar esos mundos no podían guardarse en las típicas tarjetas de memoria (aunque quizás se podrían crear chips especiales de memoria en los cartuchos...).
Poder combinar cartuchos y discos de 64 MB (512 Mb) cada uno, con acceso a internet y reloj interno daría para cosas impensables en ese momento.

Sogun escribió:Lo que sí sería interesante es que crearas un índice en el primer mensaje con links a los mensajes como hiciste en el hilo del otro foro.

Sería mas interesante que alguien se lo deje hecho, y ya si eso que lo copie&pegue en el primer mensaje del hilo... vaya a ser que le quememos, y nos quedemos sin primicias en exclusiva

@BMBx64

BMBx64 escribió: ya iré escribiendo que me encuentro, aunque cada vez veo que interesa menos esto y que se prefieren los análisis, igual tendría que crear otro hilo.

yo te recomiendo que continúes en este hilo, soy uno de los que te lee atentamente y me parece genial leer los datos técnicos sobre lo que vas encontrando así como las curiosidades como el limite de tamaño de rectángulos en n64 comparado con el de psx, y eso que los conocimientos de programación que tengo son de 0.

Ademas pruebo los test que haces en el hardware real, por cierto en el demo alpha blending nunca pude ver el srpite de Mario como se muestra en la imagen, me aparecía el mapa dividido en 3 (supongo que son los 3 buffers separados)

@john D9
Comor, tienes imágenes de eso? Ya sabía que libdragon estaba zumbada, pero no a esos niveles, aquí tanto en consola como en emulador va bien, el resto de ejemplos te van bien?

@Flash-Original
Llegaste a compilar el entorno no?

@Sogun
Bueno lo comento porque tampoco me gustaría descarrilar demasiado el hilo, lo que es comentar curiosidades, analizar los juegos, etc, en cuanto a la falta de actividad es por los 5 días entre replica

Sogun escribió:Esto no lo termino de entender. ¿Estás hablando de cómo mejorarían las texturas si las paletas se cargasen a parte de los 4KB de la caché? En ese caso te daría lo mismo que las texturas fueran a color que en escala de grises, por lo que las texturas podrían ser de 64x64 con 8 bits de profundidad y 128x64 con 4 bits. Claro que serían texturas sin mipmapping, que quizás es a lo que te refieres y entonces sí podrían alcanzar el tamaño que mencionas. Básicamente guardar las paletas en los 4KB de la caché está limitando la resolución de las texturas a la mitad.

Cuando activas TLUT divides la memoria de TMEM en 2, los 2KB bajos para información del tile, los 2KB superiores la paleta (dirección 0x100).

Cuando usamos texturas de 16 o 32bits la información es directamente el color del pixel, el primer pixel de una imagen de 16bits? Color entre 0..65535, luego el segundo, etc, eso ocupa más espacio, porque indistintamente de que un color sea 0 o 65535 se reserva un espacio de 16bit por pixel.

En las texturas con paleta de 4 y 8 bits no funciona así, lo que guardas en la textura es una posición dentro de la tabla (índice de 0..255) y en TLUT lo que se guarda es el color en sí con referencia a esa posición, posición 0 de la paleta, color ej. 65535 (blanco).

Cuando tenemos una textura de 64x64 en 4bits es usando los 2KB al máximo, los otros 2KB están siendo usados por la paleta, si el mip mapping usa el espacio de la textura (2KB), no sería posible tener 64x64.

Las texturas que permiten 128x64 en 4bits es porque no usan TLUT, el valor que tienen en lugar de para posicionar una tabla lo usan para crear una escala de grises (intensidad), por tanto pueden usar los 4KB de cache enteros, coloreas el vértice y tienes una textura diferente a la gris, muy al estilo de Goldeneye.

Para entenderlo de otra forma, esto es una textura de 4bits, 2 pixels por byte, un byte es un valor de 0..255, las texturas de 4bits solo usan un valor de 0 a 15 (16 colores), he señalado un valor para que se vea el "dibujo" por dentro.


En este ejemplo se usan valores hexadecimales, la posición marcada es 0x11, que serían 2 veces 1, 0xFF serían 2 veces 15, por ej.

Y esto es la tabla de colores, esto es lo que se envía a los 2KB superiores de TMEM, solo esto, verás que desperdicio.


En la posición 1 de la tabla hay el color 4095, pues 2 veces color 4095, la tabla solo tiene 3 colores rellanados, azul = 4095, negro = 1, rojo = 61441, el 0 debería ser transparente.

El resultado:


Ahora que ya he conseguido mostrar texturas con paleta tengo que actualizar aquella herramienta que hice para generar texturas y ya podré empezar a trabajar con texturas de 4 y 8bits, a sacar tests, etc.

@BMBx64
Si que logre compilar el entorno de por ahi antes de que desactivaras la limpieza por software o algo asi que no recuerdo para que funcionara finalmente a 60fps

https://ibb.co/knEeEk

Y tenia esta configuracion

@BMBx64

esto es lo que se ve en pantalla cuando abro el demo

mi consola es ntsc, solo ese ejemplo se ve así desconozco si es normal, los demás funcionan y se ven perfectamente

@Flash-Original
Cuando termine el tema de las paletas volveré a subir la libdragon actualizada, podrías compilarla de nuevo para sacar partido a todas las cosas nuevas

@john D9
Gracias por la captura, es la libdragon que no setea bien el vídeo en formato NTSC cuando el antialias está desactivado, prueba con esta nueva versión a ver si fuera bien :
https://mega.nz/#!g4ZlELCY!1Wbgx4wzpJalM798Ck0zXLHRK2Q6qNmYzyY9zFcOHvY

@BMBx64 Vale, gracias

BMBx64 ya lo probé y va perfecto con la nueva versión, gracias por resubirlo

Sobre detalles y curiosidades... ¿Alguno sabe si hay diferencias entre las N64 grises y negras de lanzamiento y las de colores transparentes del final?
Hay una pequeña investigación en un foro que concluyó que en PAL, las de colores transparentes sacan mejor calidad de vídeo que las primeras grises y negras, pero nadie habla de ello nunca xD

Salu2!

Me he encontrado algo curioso del funcionamiento del n64

When using the Nintendo 64 development system, the developer needs to run the game loader gload() program to download his prepared ROM image into the cartridge memory on the development board. After the memory image is loaded, gload can optionally read back the memory and verify the contents. It then generates a reset signal to the development board, causing the R4300 to jump to the reset vector where it begins executing the boot code from the PIF ROM.

Some of the important tasks performed by the boot code include:

Initialize N64 CPU CP0 registers

Initialize the RCP (such as halt RSP, reset PI, blank video, stop audio)

Initialize RDRAM and CPU caches

Load 1 MB of game from ROM to RDRAM at physical address 0x00000400

Clear RCP status

Jump to game code

Si no recuerdo mal cuando se analizo los primeros 8mb eran el motor del juego del zelda ocarina con esto quiero decir que se hacen saltos de memoria programables (aunque a lo mejor se dijo anteriormente y ni me di cuenta)

Hey! Aquí otro muy interesado en este hilo y tus avances @BMBx64!!
Soy uno de los que entra cada día en el hilo buscando nuevos posts con información y tus avances, a ver si alguien con conocimientos se anima y empieza a crear cosillas jugables ya!!

Falkiño escribió:Sobre detalles y curiosidades... ¿Alguno sabe si hay diferencias entre las N64 grises y negras de lanzamiento y las de colores transparentes del final?
Hay una pequeña investigación en un foro que concluyó que en PAL, las de colores transparentes sacan mejor calidad de vídeo que las primeras grises y negras, pero nadie habla de ello nunca xD

Salu2!

Eso te lo confirmo, yo. El año pasado me hice con una N64 pikachu (con olor a fumador) y después con otra normal (que se veía vieja y rayada de cojones, pero la compré por los juegos que incluía el vendedor). La pikachu me parecía tan hortera que mi primera intención al verme con dos N64 fue venderla y quedarme con la normal. Pero haciendo pruebas vi que la normal daba una señal de video con unos colores "muertos". Por el contrario la pikachu daba unos colores vivos, más saturados. Todo esto comprobado manteniendo el mismo cable (composite), el mismo juego (Banjo Kazooie) y la misma TV.

Al final acabé vendiendo la normal y quedándome la pikachu.

Yo eh leído y visto algunos vídeos demostrativos en donde se comparan las consolas de colores transparentes con las normales y el tono de los colores si es un poco más vivo pero la resolución continua siendo la misma, para mejor calidad está el cable ultra HDMI que tampoco aumenta la resolución pero si limpia la imagen, mejora el color y se ven con claridad los pixeles sobre todo en los juegos de 2d, eh leído que también hace posible jugar pal y ntsc , como me gustaría tener el ultra hdmi lastima que sea muy caro, no he podido jugar varios juegos que están en castellano por problemas de la región como operation winback o shadowman se ven en blanco y negro.

He visto otros vídeos en donde convierten la señal de salida usando el cable s-video a hdmi con convertidores y tienen muy buenos resultados como se ven en este vídeo(minuto 3:39):
https://www.youtube.com/watch?v=Sqv-_VydgXU&t=239s

También está el antialiasing que ya todos conocen, ayuda bastante a algunos juegos.

@bainomamueles yo he visto sobretodo en un foro, que salía que las N64 transparentes de colores sacan mejor vídeo compuesto que las grises, hasta el punto de ser prácticamente igual de buena que un S-Video en una gris clásica. Pero que si pones el S-Video en la gris lo ves igual de bien, pero el compuesto se ve bastante peor.

7 páginas de hilo sobre ello:

http://s9.zetaboards.com/Nintendo_64_Fo ... 7363768/1/

En GameFAQS :

https://www.gamefaqs.com/boards/916387- ... 4/71892139

Donde se lee lo que digo:

The consensus is this:

This whole thread was about the fact that certain coloured (Funtastic) consoles improved the COMPOSITE sharpness...meaning that if you have that certain coloured type console your composite signal will essentially be AS SHARP AS s-video...

...if you have a grey n64 then you will be seeing a blurry image if you are using composite (especially if PAL console), but upgrade to s-video with a grey pal or ntsc console and it will be as good as having a composite or s-video coloured console.

Unas imágenes de prueba, a la izquierda la N64 PAL gris/negra clásica por compuesto, a la derecha, una PAL de colores transparentes (Funtastic) también por compuesto, podréis notas mejorías en la definición si miráis atentamente las letras, y sobretodo en la última foto y demás:

En cuanto a nitidez, no noté ninguna variación, ahora, como digo, la imagen en la N64 normal se veía "blanquecina" mientras que en la pikachu tenía unos colores mucho más vivos. Era bastante notable la diferencia.

@BMBx64 Que te parece el Ready 2 Rumble 1&2, debe ser de los juegos de lucha de Nintendo 64 que mejor se ven,¿es posible que sea el que más polígonos mueva?.

Salud.

¿Novedades?, me voy a quedar en los muñones de morderme las uñas.

@Señor Ventura
jaja yo también pero hay que ser pacientes que las buenas cosas requieren algo de tiempo, ya nos mostrara algo BMBx64

dirtymagic escribió:@BMBx64 Que te parece el Ready 2 Rumble 1&2, debe ser de los juegos de lucha de Nintendo 64 que mejor se ven,¿es posible que sea el que más polígonos mueva?.

Salud.

Si no me falla la memoria ya comentó que el juego que más polígonos mueve es el Perfect Dark; pero igual lo soñé.

@Calculinho y World Driver Championship, gracias a que desactivaron el Z-Buffer aumentando así la tasa de relleno. El primer Ridge Racer de la PlayStation creo que mueve menos.

Sexy MotherFucker escribió:@Calculinho y World Driver Championship, gracias a que desactivaron el Z-Buffer aumentando así la tasa de relleno. El primer Ridge Racer de la PlayStation creo que mueve menos.

No sabía lo del WDC y además sino me falla la memoria va bastante fluido para los tiempos que corren, el Perfect Dark me está costando bastante rejugarlo porque se nota lento para 2017.

@Calculinho es que Perfect Dark ha envejecido fatal; no se puede ir con 11 fps por la vida después de haberte acostumbrado a un mínimo de 25-30 en el género. Y si no pegase trompicones vale; pero es que madre mía en niveles semiabiertos como el complejo al lado de la playa.

En mi opinión, Nintendo se hubiera evitado muchos problemas de haber incluido el RAM extra que da el expansión pack, pero de base en el hardware de la consola en lugar de ponerlo como accesorio aparte.

Es que jugar con este aditamento puesto(aunque los juegos no lo requieran) mejoraba muchísimos la experiencia(mayor resolución y mejor rendimiento), que jugar sin el, desde que me "regalaron" el expansión pack con el Donkey Kong 64, ya nunca mas lo quite y vaya que se notaban mejoras en todos los juegos.