[HILO OFICIAL] Nintendo 64

Gracias!

Otra pregunta, estoy mirando como almacenar mis cartuchos. He visto algo así y me gustaría saber si conocéis de algo similar que se pueda comprar, pero sin que venga de Estados Unidos.

He visto varios sets en Etsy como este, pero todos vienen de Estados Unidos, por ver si alguien tiene algo similar.

Mi idea sería pegarlo en la funda pet de cartucho, no en el propio cartucho. ¿Qué os parece? Como el de este vídeo: https://www.youtube.com/watch?v=1BVNcb16c1E

Gracias!

Misscelan escribió:Lo que propongo principalmente es quitar el antialiasing y el zbuffer (y otros cambios menores) a cambio de más resolución, mejores texturas y mejor framerate. No sé porque iba a ser eso motivo de burla, si de hecho los principales detractores de n64 se "burlan" (injustificadamente en mi opinión) del antialiasing, de la resolución de las texturas o del framerate.

Lo de la CPU da igual porque la actual con cuellos de botella no estaría tan lejos de la que propongo sin ellos.

El problema es que la N64 apenas ofrecería mejoras respecto a la PS1 habiendo pasado un año o dos. Sería de hecho una PS1 maquillada. Sacar eso con cartucho y sin ninguna otra ventaja más... Yo no me burlaría, diria que es una puta mierda, pero otros sí lo harian.
El zbuffer no hace falta quitarlo, de siempre era opcional usarlo por el desarrollador. El problema es que Nintendo luego decía que de opcional nada, que no queria nada de z-fighting en sus juegos porque era dejar la consola a nivel de PS1 (o eso se supone, pero el caso es que era obligatorio). Es más, los de World Driver Championship quitaron el zbuffer e hicieron un trabajo increible para que no hubiera nada de z-fighting, y se la colaron a Nintendo.

La TMEM o caché de texturas es el doble de PS1, así que no hace falta tocar nada.

Misscelan escribió:No sería una ps1 con filtrado de texturas, si no una evolución sobre esta,

Pues como lo es actualmente.

Misscelan escribió:Sé como funciona el zbuffer, de hecho tienes por elotrolado mis experimentos activándolo y desactivandolo y los cambios en los fps que producía en mi hombrew. Los datos del zbuffer se almacenan en ram, me refieron a la parte del rdp que lo controla.

No hay nada en el RDP que lo controle, esa parte la ejecuta el RSP. El RSP incluye una variante de un procesador MIPS4000 controlado por microcódigos, y estos a su vez se implementan en las librerias del SDK. Si lo que quieres es que el RSP en vez de ser un procesador programable sea un procesador de funciones fijas como la GPU de PS1, eso es otra cosa, y no significa que fuese muy diferente en prestaciones o coste, pero sí que no sería tan versatil. Por ejemplo, se ha podido añadir funciones de partículas con textura ejecutadas directamente por RCP.

Y sobre los filtros como el antialiasing o el blur horizontal, aparte que no afectan al rendimiento y también se pueden desactivar al gusto, estan por las pantallas CRT de la época. Y digo esto con conocimiento de causa: he probado una misma consola conectada a pantalla plana de 32" con el mod UltraHDMI y deblur y a un CRT de 20" (casi de la misma altura los dos) en este último se ve muy bien la imagen, mientra en la pantalla plana si bien todo esta enfocadito y los pixeles afilados, se nota muchísimo la baja resolución y hace que la imagen envejezca mal. Todavía más: he probado en un CRT la salida RGB del N64Digital que es el RGB más nitido jamás conseguido en la consola, y la imagen se degrada y parece de peor resolución.

La imagen que dan los CRT es muy, muy específica. Cualquiera puede verlo no ya con una N64, con una PS1 o una Saturn. Tu ves un FMV en un CRT y es brutalísimo lo bien que se ve. Lo ves en una pantalla plana, y te sacas los ojos. Desafortunadamente aparte de filtros y scanlines no tenemos nada parecido a los CRTs más que los propios CRTs, y todas las consolas de la quinta generación envejecen muy mal en cuanto las sacas de ese tipo de pantallas.

Lo que quiero decir con esto es que todos esos filtros no se pusieron por capricho, era una forma de aumentar artificialmente la sensación de mayor resolución de la consola, evitando bordes serrados que eran un clásico en todos los juegos 3D de todas las plataformas. Pero los sacas de los CRTs y son un desastre. Son como los pingüinos, en el agua son unos cracks, en tierra muy torpes.

Señor Ventura escribió:Lo que está claro es que el bus es el principal escollo. Doble bus de 32 bits y dos módulos de 4MB, ¿cuanto hubiera costado adaptar el northbridge a eso?.

En la memoria actual son como mínimo 18 patillas del RCP más las que proporcionan energía, ya que aparte de 9 bits hay señales de control, reloj, etc. Hacer doble bus serian otras 18 patillas, más otras patillas de energía para el RCP (tiene más de 60 solo para eso). Si ya el RCP es un monstruo de 160 patillas, con doble bus nos vamos a 200. Una locura de aumento de coste de fabricación tanto del chip como de la placa.
Pero si Nintendo estaba presionando a SGi para quitarle patillas al RCP, como para poner más...

@EMaDeLoC ¿60 dólares adicionales, para un precio de venta de 259$?.

Pero el rendimiento habría sido una locura...

@EMaDeLoC
El TMEM no he dicho de tocarlo pero si es por ahorrar costes también se lo quitaría (si se implementase la VRAM), el problema no es el tamaño, es lo que pasa cuando la textura no está en la cache, en N64 bajas a la RAM bloqueando todo el sistema, en PS1 bajas a la VRAM, no molestas a nadie y tienes un retorno más rápido y predecible en un escenario real. De hecho la Saturn no tiene cache de texturas y surte a su GPU a la misma velocidad que la PS1 estando dentro de su cache.

Lo que hace el RSP es codificar el componente Z del vértice en un formato interpretable por el RDP, el RSP no descarta pixeles en base a su profundidad eso lo hace el RDP.
Aquí tienes un video posicionado donde te habla en que momento el RDP descarta un pixel o no basado en la profundidad:

Lo de los filtros, también sé que se la mayoría se puede desactivar, digo de quitar todo lo que los controla dentro del RDP (junto con lo que controla el Zbuffer) para hacer el RDP más simple y abaratar costes, yo sigo hablando del escenario planteado por Superpadland de intentar hacer algo mejor a un precio similar)

Con evolución, no me refería a que sea una cosa más nueva si no en tener una arquitectura más cercana, como me parece por ejemplo que la PS1 es una evolución de la arquitectura de la 3do pero tiene poco que ver con la de Jaguar.

No sé porque pensarías que es tan mala, no tendría píxeles, tendría precisión subpíxel del raster, multitextura y corrección de perspectiva (todo eso no lo tiene la PS1), tendría 5 mbs de ram (4mb normales + 1vram) y además lo que me parece más importante podrías conectar la VRAM directamente a la ROM sin necesidad de que estuviese conectada a la RAM, y por ejemplo cosas como la demo de la MegaTextura tendría bastante mejor framerate. Actualmente esa demo pasa sus texturas de la ROM a la RAM y de la RAM al TMEM, dejando en espera al RDP y la CPU en el proceso. Con la VRAM conectada a la ROM el RDP trabajaría más rápido y a su bola dejando a la CPU libre para AI, colisiones, etc.

A lo mejor aún así no daba para tener un juego tipo esa demo a gran escala, pero si creo que sería posible por ejemplo un OOT con texturas a 4 veces la resolución (aunque las texturas no entrasen en VRAM, las lejanas se podrían ir pasando de ROM a VRAM a tiempo) y mejor framerate, a cambio de perder antialiasing y que notases alguna vez la esquina de un polígono encima de otro?

Si se amplía la resolución y además con la precisión subpíxel del raster (que consigue un efecto parecido), no creo que mucha gente echase de menos el antialiasing. En la generación posterior muchos juegos de PS2 no tenían ningún tipo de antialiasing y fue la consola más vendida.

Pero bueno, que es una opinión personal, si al tu prefieres antialiasing y zbuffer a mejores resoluciones y framerate también es válido (y no lo digo por el hecho de activar o desactivar sino porque simplificarían el RDP, haciéndolo más barato y junto con una CPU más barata dejaría presupuesto para la VRAM)

@Misscelan pero la demo de la oclusión ambiental no sería posible...

Sí, lo que yo pregunté es como mejorar y lanzar la consola a 1995 al mismo precio porque pedir pozos de memoria, vram, etc. Sin más es muy fácil, pero al final si N64 es como es, es porque había que recortar no por un mal diseño per se, si no hubiese que recortar tendríamos la Ultra64 directamente ya. Recortar no fue un capricho fue una obligación.

Evidentemente Podemos opinar que Yamauchi podía haberla lanzado a 250$ por ejemplo y mejorarla igual, pero eso sería otro escenario.

Pero también se puede teorizar sobre una n64 con unos buses en condiciones.

Señor Ventura escribió:Pero también se puede teorizar sobre una n64 con unos buses en condiciones.

Yo no he prohibido nada, he preguntado si esas teorizaciones eran posible lanzando la consola a 199$ o no. Porque para lanzar algo al doble de precio no me hace falta mucha teorización para saber que es posible mejorar cualquier hardware.

Misscelan escribió:El TMEM no he dicho de tocarlo pero si es por ahorrar costes también se lo quitaría (si se implementase la VRAM), el problema no es el tamaño, es lo que pasa cuando la textura no está en la cache, en N64 bajas a la RAM bloqueando todo el sistema, en PS1 bajas a la VRAM, no molestas a nadie y tienes un retorno más rápido y predecible en un escenario real. De hecho la Saturn no tiene cache de texturas y surte a su GPU a la misma velocidad que la PS1 estando dentro de su cache.

A ver, porque hay unas cuantas cosas mal.
La TMEM es imprescindible en la N64, igual que la cache de texturas de la PS1. En ambas se usa como almacenamiento de rápido acceso para ir copiando pixeles al framebuffer a medidad que se van dibujando polígonos. Si se hicieran desde VRAM (como puede hacer la PS1) el rendimiento se lastraría muchísimo. Pero encima la N64 requiere leer tres píxeles a la vez para hacer el filtrado, por lo que el acceso rápido es crucial. No esta puesto a capricho y no se puede quitar en ninguna de las máquinas.
Saturn es diferente. No dibuja polígonos como las otras, sino sprites deformados simulando polígonos. La forma de pintarlos en pantalla es distinta y no requerirá de cache porque no necesita leer los píxeles de forma individual.

Misscelan escribió:Lo que hace el RSP es codificar el componente Z del vértice en un formato interpretable por el RDP, el RSP no descarta pixeles en base a su profundidad eso lo hace el RDP.
Aquí tienes un video posicionado donde te habla en que momento el RDP descarta un pixel o no basado en la profundidad:

Lo de los filtros, también sé que se la mayoría se puede desactivar, digo de quitar todo lo que los controla dentro del RDP (junto con lo que controla el Zbuffer) para hacer el RDP más simple y abaratar costes, yo sigo hablando del escenario planteado por Superpadland de intentar hacer algo mejor a un precio similar)

Me remito a lo de antes: eso no significa que los costes fuese menores. Quizá en el desarrollo del chip, pero SGi ya iba con la parte principal hecha cuando visitó a Sega y a Nintendo, así que plantear modificaciones podía presentar más tiempo para desarrollarlo. Y de nuevo, ahorrar por un lado para dejar la consola más cerca de PS1 que de Dreamcast, en plena carrera por sacar los mejores gráficos 3D, no lo veo.

Misscelan escribió:Con evolución, no me refería a que sea una cosa más nueva si no en tener una arquitectura más cercana, como me parece por ejemplo que la PS1 es una evolución de la arquitectura de la 3do pero tiene poco que ver con la de Jaguar.

Si quieres una arquitectura más cercana, olvídate de meter mano al RCP: CPU con 2MB de RAM exclusivos, RCP con otros 2MB de RAM también en exclusiva, más 1MB de VRAM entre el RCP y el RAMDAC correspondiente para sacar señal de vídeo sin perjudicar rendimiento de cualquier RAM. Eso es una arquitectura más cercana y no modificar un chip. ¿Que así es más caro? ¡Sorpresa! Sony fabricaba ella misma en sus propias factorias no solo la placa sino también la mayoría de chips, por lo que cada consola le salía tiradísima de precio. Nintendo todo lo encargaba a terceros saliendole más caro.

Si quereis una consola más barata de producir, ya existe, es la actual. Si quereis mejorar el rendimiento, o se optimiza el código o las librerias, o se pone más dinero. La solución "después de decir que colaboramos con SGi vamos a recortarla y dejarla parecida a la compentencia" desde luego no estaba sobre la mesa.

Misscelan escribió:No sé porque pensarías que es tan mala, no tendría píxeles, tendría precisión subpíxel del raster, multitextura y corrección de perspectiva (todo eso no lo tiene la PS1),

La precisión subpixel evita que los polígonos tiemblen (no confundirse con las texturas). Los dientes de sierra seguirían ahí y solo se pueden evitar con antialiasing. El antialiasing requiere precisión subpixel entre otros datos, aunque depende del algoritmo, pero la precisión subpixel no da de por sí antialiasing.

Misscelan escribió:tendría 5 mbs de ram (4mb normales + 1vram) y además lo que me parece más importante podrías conectar la VRAM directamente a la ROM sin necesidad de que estuviese conectada a la RAM, y por ejemplo cosas como la demo de la MegaTextura tendría bastante mejor framerate. Actualmente esa demo pasa sus texturas de la ROM a la RAM y de la RAM al TMEM, dejando en espera al RDP y la CPU en el proceso. Con la VRAM conectada a la ROM el RDP trabajaría más rápido y a su bola dejando a la CPU libre para AI, colisiones, etc.

Por lo que he dicho antes, sin la TMEM el framerate estaría lastradísimo. Y más conectandolo a la ROM, que solo va a 5MB/s.

Misscelan escribió:A lo mejor aún así no daba para tener un juego tipo esa demo a gran escala, pero si creo que sería posible por ejemplo un OOT con texturas a 4 veces la resolución (aunque las texturas no entrasen en VRAM, las lejanas se podrían ir pasando de ROM a VRAM a tiempo) y mejor framerate, a cambio de perder antialiasing y que notases alguna vez la esquina de un polígono encima de otro?

La verdad es que yo pensaba más en usar la VRAM solo para el framebuffer, que es lo que más lastra el ancho de banda de la RDRAM de la consola sin cambiar la situación de esta. Sería la forma más barata de implementar dicha VRAM sin cambiar ni un apice las funciones que puede realizar el RCP, salvo la manipulación del framebuffer.

Misscelan escribió:Si se amplía la resolución y además con la precisión subpíxel del raster (que consigue un efecto parecido), no creo que mucha gente echase de menos el antialiasing. En la generación posterior muchos juegos de PS2 no tenían ningún tipo de antialiasing y fue la consola más vendida.

Pero es que aunque la RAM tenga cuello de botella, el RCP tampoco da mucho más de sí. Juegos con capacidad de sacar 480i con poca carga gráfica como Command & Conquer o Virtua Chess van bastante a pedales. 480i es el doble que 240p, es decir, se duplican todos los procesos que hace el RCP para pintar polígonos, superando lo que puede hacer por su frecuencia de reloj.

Misscelan escribió:Pero bueno, que es una opinión personal, si al tu prefieres antialiasing y zbuffer a mejores resoluciones y framerate también es válido (y no lo digo por el hecho de activar o desactivar sino porque simplificarían el RDP, haciéndolo más barato y junto con una CPU más barata dejaría presupuesto para la VRAM)

Si se puede prescindir del zbuffer, mejor, pero no es necesario quitarlo del RCP. Además hay métodos de optimización que usan el z-buffer, como pintar de alante a atrás para optimizar el fillrate.

Señor Ventura escribió:@EMaDeLoC ¿60 dólares adicionales, para un precio de venta de 259$?.

Pero el rendimiento habría sido una locura...

El Expansion Pak ya costaba 30€ tres años después de lanzarse la consola. Así iría por ahí, por los 60$ con todo acumulado. Pero hay que recordar que Nintendo ya pensaba lanzarla a 250$ originalmente y la bajó a 200$ debido a la competencia reduciendo el margen que tendrían pensado. A saber si esos 259$ habrían influido negativamente en el lanzamiento inicial, aunque los 8MB de serie le hubiesen venido bien tanto a los juegos como al marketing. Yo personalmente lo habría preferido, pero como el 64DD lo dejaron para más adelante y el EP es una parte bastante fundamental del mismo, también debió influir a la hora de incluirno o no de serie.

@EMaDeLoC ten en cuenta que los 30€ de RAM en el 98 ya son cuando el precio baja, pero en el 95 era más cara y las previsiones era que iban a subir más por falta de yacimientos de yoquesé (supongo que las tierras esas raras que ahora hablan de Ucrania).

Lo que no sabía era que primero barajaban 259$ de PVP de lanzamiento y lo recortaron al final a 199$. Que penam 259 tampoco era un precio tan alto para una máquina nueva, PS1 se lanzo a 400 un año antes, ya sé que el lector costaba 100 y pico y tal, pero eso como usuario al final te da igual. Lo que mirabas es cuanto cuesta el juguete nuevo.

@EMaDeLoC
La TMEM es imprescindible por la razón que he mencionado antes, si no tienes TMEM tienes que bajar a la RAM y lo mismo la RAM la está utilizando el audio o la está utilizando el procesador o lo mismo antes se había usado otro banco de memoria y tienes más latencia y si a eso le sumas a la latencia inicial de cualquier transferencia pues todo mal. La PSX tiene 2kb y la velocidad de acceso cuando no tienes la textura en cache baja a la mitad, pero como tienes que utilizar el algoritmo del pintor tienes poca probabilidad de agrupar los polígonos por textura (el SDK oficial de Nintendo intenta a toda costa que agrupes primero por material y así lo mandes RSP->RCP), así que la posibilidad de repetir textura en ps1 es bastante reducida, vamos que es bastante común perder la cache en PSX y como ves su GPU es bastante competente.

Lo de la Saturn no es así, ya lo he contado varias veces, funciona bastante similar a como renderiza PSX, son algoritmos de renderizado lineales (Forward vs Affine), lineales porque a la GPU no le llega información de la profundidad, Affine va recorriendo el polígono y mira que texel le corresponde y lo manda al buffer, Forward (al revés) recorre el texel y mira donde le corresponde al polígono y lo manda al buffer. Dos maneras diferentes de hacer la misma cosa.
Saturn podría renderizar usando Affine a la misma velocidad sin cache de textura si hubiese implementado ese algoritmo. Pero vamos que yo no había sacado el tema del TMEM, no sé porque lo sacaste tú, tampoco creo que el coste cambio mucho por 4kb de esa memoria.

El debate de que habría hecho SGI o Nintendo es otro debate desde mi punto de vista, especialmente argumentando más tiempo de desarrollo cuando posiblemente intentar meter todas esas cosas a un precio tan bajo fue lo que más tiempo llevó y dudo que lo que tenía SGI entre manos cuando lo enseño originalmente estaba dentro de los márgenes que las compañías se querían gastar. De hecho, en esta línea temporal inventada, lo que sugiero podría ser el supuesto que debería haber planteado SGI a Nintendo pero bueno, como te digo eso creo que es otro debate. Y lo de qué estaría más cerca de PS1 que de Dreamcast, es un comentario subjetivo. Ya veo que tú no, pero yo prefiero más resolución y mejores texturas que ciertos efectos.

Yo nunca he dicho que la precisión subpixel haga lo mismo que el antialiasing, pero ayuda. Lo que hace la precisión subpíxel es la oportunidad de que un pixel se componga de una mezcla de varios colores (en el caso de N64 -> 4) para así simular posiciones intermedias, en ps1 un pixel esta en X o en X+1 en n64 puede simular estar a mitad entre los dos, produciendo este efecto:


No es antialiasing, pero en determinadas aristas, las acaba suavizando.

Y por último, sí la ROM va lenta, más lenta que la RAM, pero aún así mira en la demo de MegaTextura y lo que tarda no es solo en transferir desde de ROM, sino de ROM a RAM a TMEM. Estoy hablando de un escenario el que tendrías que paulatinamente reemplazar las texturas del fondo, 5MB por segundo para traerlas a VRAM da para bastante. Crash Bandicoot está haciendo streaming continuamente de texturas a velocidades considerablemente más bajas. Y si el RCP actual da para usar texturas de 64x64 con todos los cuellos de botella en juegos como Banjo Kazooie entiendo que daría para bastante más sin ellos.

Edit: lo de los juegos a 480i, pues normal que se arrastren, imagínate la de micro accesos que tiene al buffer de color, al zbuffer o cambios de bancos, en una memoria a la que le viene mal ese tipo de accesos y que además puede ser constantemente interrumpida por otros procesos.


@SeñorVentura
Si te refieres a SSAO, no se podría hacer sin ese buffer. Pero esto no tendría mucho más recorrido que para una demo técnica en la consola actual.
Puedes implementar AO de la manera más básica con Gouraud, puedes implementarlo dentro del alpha de la textura, o en al caso de la supuesta “N64 teórica” al tener más fillrate puedes meterlo dentro del lightmap y renderizarlo al hacer multitexturing

@SuperPadLand Si, he tenido en cuenta que habian pasado tres años desde el lanzamiento. Los 60$ que decía señor Ventura es una cifra que creo que se aproxima bastante, pero a saber, igual podían ser más o menos.

A 400$ salió la Sega Saturn. La PS1 salió a 300$, y el verano antes de salir la N64, Sony la bajó a 200$. Creo que Saturn bajó también, pero no sé cuanto.

Misscelan escribió:La TMEM es imprescindible por la razón que he mencionado antes, si no tienes TMEM tienes que bajar a la RAM y lo mismo la RAM la está utilizando el audio o la está utilizando el procesador o lo mismo antes se había usado otro banco de memoria y tienes más latencia y si a eso le sumas a la latencia inicial de cualquier transferencia pues todo mal.

No, el problema es la velocidad de transferencia. Ni la latencia, ni que esté ocupada la RAM (la gestiona el propio RCP) ni que esté en otro banco (¡la N64 no tiene bancos de memoria!)... Es la velocidad de transferencia.
La TMEM al estar embebida dentro del RDP es de acceso muy bajo y transferencia muy alta.

Misscelan escribió:La PSX tiene 2kb y la velocidad de acceso cuando no tienes la textura en cache baja a la mitad, pero como tienes que utilizar el algoritmo del pintor tienes poca probabilidad de agrupar los polígonos por textura (el SDK oficial de Nintendo intenta a toda costa que agrupes primero por material y así lo mandes RSP->RCP), así que la posibilidad de repetir textura en ps1 es bastante reducida, vamos que es bastante común perder la cache en PSX y como ves su GPU es bastante competente.

El algoritmo del pintor se puede optimizar facilmente. Por ejemplo, se puede pintar los techos y suelos de una habitación primero, y a continuación las paredes. De esa forma mandas tres grupos de polígonos con la misma textura, reduciendo la necesidad de acceder a la VRAM y ganando velocidad de dibujado.
Los juegos de carreras pueden hacer eso mismo, pintar primero el suelo, luego los bordes de la carretera y después las decoraciones tipo árboles, público, etc.
Igualmente todas las texturas de PS1 se cargan en su cache, con la única excepción de que no quepan en dicha cache. La GPU puede entonces leer los pixeles directamente de la VRAM, cosa muy útil para fondos prerenderizados. A 132MB/s puede pintar 1700 pantallas a 240p por segundo. Y encima la VRAM permite lectura simultanea mientras se escribe, así que mientras esta pintando un frame manda el otro a la salida de vídeo sin ninguna penalización de velocidad. En la N64 eso no es así y por eso por ahí no se pueden comparar ambas consolas.

Misscelan escribió:Lo de la Saturn no es así, ya lo he contado varias veces, funciona bastante similar a como renderiza PSX, son algoritmos de renderizado lineales (Forward vs Affine),

Ni por asomo: https://youtu.be/FdD0GvVRSMc?si=uNzX_b_4_CnT37Jv&t=64
El mismo canal explica la diferencia entre los sprites de Saturn y los triángulos de consolas 3D: https://youtu.be/WDJgeuoaSvQ?t=116
Y el canal es de Jon Burton, antiguo desarrollador de Saturn, así que no se esta inventando nada.

Misscelan escribió:El debate de que habría hecho SGI o Nintendo es otro debate desde mi punto de vista, especialmente argumentando más tiempo de desarrollo cuando posiblemente intentar meter todas esas cosas a un precio tan bajo fue lo que más tiempo llevó y dudo que lo que tenía SGI entre manos cuando lo enseño originalmente estaba dentro de los márgenes que las compañías se querían gastar. De hecho, en esta línea temporal inventada, lo que sugiero podría ser el supuesto que debería haber planteado SGI a Nintendo pero bueno, como te digo eso creo que es otro debate. Y lo de qué estaría más cerca de PS1 que de Dreamcast, es un comentario subjetivo. Ya veo que tú no, pero yo prefiero más resolución y mejores texturas que ciertos efectos.

Lo que sobre 1992 ofreció SGi a Sega y luego a Nintendo fue el concepto de un chip con capacidades gráficas similares las de una estación Indigo que salió en 1991, aunque para cuando comenzarón los contactos estaban a punto de sacar las estaciones de trabajo Indy, que en el futuro con una tarjeta extra se acabaron convirtiendo en los sistemas de desarrollo de la N64. La guerra por el 3D estaba ya empezada y como digo, ni de coña iba Nintendo o SGi a sacar una GPU peor de lo que ellos eran capaces de producir de salida.

Misscelan escribió:No es antialiasing, pero en determinadas aristas, las acaba suavizando.

Pues si no es antialiasing ya puedes ir corrigiendo el manual de programación de la N64:

https://ultra64.ca/files/documentation/online-manuals/man/pro-man/pro15/index15.2.html

@EMaDeLoC
Claro que tiene bancos, puedes leerlo en la documentación oficial, donde te recomienda poner por ejemplo el buffer de color en un banco y el zbuffer en otro (busca por “memory bank”):

https://ultra64.ca/files/documentation/online-manuals/man/pro-man/pro04/04-03.html

Cada banco (1mb) tiene una especie de cache asociada con el último acceso, si te vas a otra parte de la memoria no cacheada generas más latencia. Por eso uno de los beneficios de la expansión de memoria es que puedes compartimentar más el código poniendo cada cosa en un banco.

Y obviamente, como estos buffers están en la RAM no son de acceso exclusivo del RDP por lo que puede haber conflictos con cualquier otro recurso que la necesite.

Si la N64 tuviese mejor velocidad de transferencia pues mejor, con esa VRAM ficticia de la que he hablado pues esperaría mejores velocidades de transferencia, menos latencia y nada de congestión del bus. Pero yo ahora mismo no considero esa velocidad de transferencia como el principal talón de Aquiles. Te pongo el ejemplo que como tengo ahora mismo configurada mi proceso de renderizado para N64, las texturas son de 32x32x4bpp, primero tengo que subir la paleta 16 colores x16bits, ósea una trasferencia de 256 bytes de los cuales la mayoría se me van en latencia y espera, después subo la textura, aquí sí se lleva la tasa de transferencia el mayor tiempo pero en principio pensaba que no debería importar, porque la idea que tenía era activar el RDP y que fuese pintando esos polígonos y mientras subir otra textura de 32x32 a otra parte de TMEM y así sucesivamente, pero ni lo intentes porque el RDP va a tener monopolizado el bus mientras pinta. En una pipeline que no tuviese ningún tipo de bloqueo se podría camuflar esa tasa de transferencia con subidas asíncronas, pero no es el caso.

No sé qué quieres demostrar con los videos que has puesto sobre Saturn. Ya he comentado por aquí varias veces que cada compañía usaba un nomenclator diferente para referirse a un polígono (y mucha gente lo sigue usando) que no tenía sus ángulos rectos. La 3DO (que funciona exactamente igual que la Saturn con forward mapping y solo quads), los llama CEL, Saturn Distorted Sprites y la ps1 Textured Polygons.

Si yo te digo los árboles del Colin McRae de ps1 son sprites, tú entiendes a que me refiero. No creo que con eso supongas que la ps1 renderiza sprites como si fuese una consola de 16bits. Pero si quieres llamarlo de otra manera puedes decir que son polígonos texturizados con todos los ángulos rectos que simulan estar paralelos a la pantalla.
Con la Saturn te puedo decir que renderiza polígonos texturizados con las UV “Clamped to Edge” o puedo decir “Distorted Sprites”.

La principal diferencia es que la PS1 parte esos quads en dos triángulos y que acepta coordenadas UV (la saturn y la 3DO tienen fijas esas coordenadas “clamped to Edge”), si la PS1 no lo partiese, con un polígono con las UV ajustadas a la arista, el resultado de mapear una textura que cubrirse el quad por completo sería igual.

Los errores que se mencionan en el vídeo, son al tratar de renderizar un triángulo que obviamente no puede porque la GPU siempre espera un quad y por el tema de las transparencias (pero eso es un problema del algoritmo de Saturn que no pasa en 3DO, no es un problema de Forward mapping).

Y por cierto, el segundo vídeo es incorrecto, lo que pasa que Jon no lo sabía. La Saturn puede hacer UV mapping por hardware usando el VDP2 como descubrió XL2 hará hace unos 4 años. Pero bueno eso es otro tema porque el VDP2 sí que funciona de manera diferente.

Y esta información no es porque la haya visto en un vídeo es porque las he tenido que implementar en mi trabajo, y luego más tarde como hobby en el homebrew del cual tienes videos por aquí del raster por software en PC con Affine.
Pero si realmente no sabes cómo funcionan los puedes ver como una caja negra, al final los dos piden un texel de la textura para poner un pixel en algún lugar del frame buffer, un pixel de cada vez. Los dos se comportan como un texture mapper del montón. La textura y el framebuffer están en VRAM y en el caso de Saturn no hay ninguna cache.

Tampoco entiendo que me quieres decir con lo del antialiasing, primero me dices que yo he dicho que la precisión subpixel era lo mismo antialiasing y cuando te digo que no dije eso, vienes a decirme que según el manual son lo mismo?
Hay muchas maneras de implementar esos algoritmos y cada uno produce resultados ligeramente diferentes. Lo que busca el "subpixel del raster" es mezclar colores en el caso de que un pixel no caiga en el centro del mismo, si cae entonces no pasa nada. La foto es muy cutre y los colores están hechos una mierda, pero creo que se entiendo con la foto, los dos píxeles marcados supuestamente están en el centro y por eso no tienen nada de otro color encima.


Este no busca aristas simplemente intenta ser "justo" con la contribución de cada pixel.

El antialiasing intenta detectar aristas y cuando la encuentra intenta mezclarla con los pixel de su alrededor.

Los resultados pueden ser parecidos con variaciones dependiendo de la implementación, aunque normalmente el subpíxel:
-no asegura blending con píxeles colindantes
-tiene un trazo más fino.
Y el antialiasing lo contrario.

La parte de la historia no me interesa y lo del ejemplo que has puesto de ps1 para organizar la escena es un ejemplo muy restrictivo y hay un montón de casos donde esa aproximación puede fallar, no tengo ahora más tiempo, pero si sigues teniendo curiosidad de los pongo en el siguiente post.

Misscelan escribió:Claro que tiene bancos, puedes leerlo en la documentación oficial, donde te recomienda poner por ejemplo el buffer de color en un banco y el zbuffer en otro (busca por “memory bank”):

https://ultra64.ca/files/documentation/online-manuals/man/pro-man/pro04/04-03.html

No hombre, no esta relacionandolo con bancos de memoria reales. Los bancos de memoria son divisiones por bloques que se hacen cuando el bus de direcciones no es capaz de cubrir toda la memoria disponible. Por ejemplo, si se tiene 1MB de RAM pero solo se pueden direccionar 128KB, la memoria se separa en 8 bancos y la CPU va cambiando de banco conforme lo necesite.
La N64 tiene un bus de direcciones de 32bits, lo que le permite acceder a 4GB de datos. Por tanto no necesita bancos de memoria.
Lo que debía querer decir el manual es página de memoria, que es la división que se hace por software para ordenar la información.

Misscelan escribió:Cada banco (1mb) tiene una especie de cache asociada con el último acceso, si te vas a otra parte de la memoria no cacheada generas más latencia. Por eso uno de los beneficios de la expansión de memoria es que puedes compartimentar más el código poniendo cada cosa en un banco.

Ah, vale, te refieres a la RDRAM, que se separa en bloques de 1MB y si no cambias de bloque obtienes menos latencia, ya que la RDRAM no debe cambiar de bloque cada vez. No es exactamente "banco de memoria" al uso, pero podriamos decir que si.

Misscelan escribió:Si la N64 tuviese mejor velocidad de transferencia pues mejor, con esa VRAM ficticia de la que he hablado pues esperaría mejores velocidades de transferencia, menos latencia y nada de congestión del bus. Pero yo ahora mismo no considero esa velocidad de transferencia como el principal talón de Aquiles. Te pongo el ejemplo que como tengo ahora mismo configurada mi proceso de renderizado para N64, las texturas son de 32x32x4bpp, primero tengo que subir la paleta 16 colores x16bits, ósea una trasferencia de 256 bytes de los cuales la mayoría se me van en latencia y espera, después subo la textura, aquí sí se lleva la tasa de transferencia el mayor tiempo pero en principio pensaba que no debería importar, porque la idea que tenía era activar el RDP y que fuese pintando esos polígonos y mientras subir otra textura de 32x32 a otra parte de TMEM y así sucesivamente, pero ni lo intentes porque el RDP va a tener monopolizado el bus mientras pinta. En una pipeline que no tuviese ningún tipo de bloqueo se podría camuflar esa tasa de transferencia con subidas asíncronas, pero no es el caso.

Ciertamente la RDRAM tiene una latencia bastante alta y solicitar paquetes de datos pequeños perjudica enormemente la velocidad de transferencia.
Hace ya bastante tiempo le eché un ojo al datasheet de la RDRAM y me salió este gráfico:


Con paquetes de más de 75 bytes se podian mantener transferencias de 400MB/s, pero por debajo de 50 la velocidad se desploma rapidamente.
No hagas mucho caso de la línea de escritura. Debe haber algún delay posterior en el datashhet que no vi o no tuve en cuenta.

Misscelan escribió:No sé qué quieres demostrar con los videos que has puesto sobre Saturn. Ya he comentado por aquí varias veces que cada compañía usaba un nomenclator diferente para referirse a un polígono (y mucha gente lo sigue usando) que no tenía sus ángulos rectos. La 3DO (que funciona exactamente igual que la Saturn con forward mapping y solo quads), los llama CEL, Saturn Distorted Sprites y la ps1 Textured Polygons.

Lo de Saturn muestra que no son polígonos sino sprites, y no es por una cuestión de nomenclatura. En un polígono la textura la puedes poner en cualquier coordenada (de ahí la demo de MegaTextures), en un sprite no. Con un polígono al pintar la textura solo pintas una vez cada pixel en el framebuffer, pero con un sprite muy deformado habría pixeles que se pintarían más de una vez en el framebuffer, lo que produciría problemas como el de pintar transparencias que sale en el vídeo.

Misscelan escribió:Y por cierto, el segundo vídeo es incorrecto, lo que pasa que Jon no lo sabía. La Saturn puede hacer UV mapping por hardware usando el VDP2 como descubrió XL2 hará hace unos 4 años. Pero bueno eso es otro tema porque el VDP2 sí que funciona de manera diferente.

Te refieres a esto: https://segaxtreme.net/threads/texture-coordinates-on-the-saturn.25017/
Lo que hace es convertir una textura en una paleta de colores, y aplicar sombreado gouraud a un quad sin textura de una forma específica, usando luego el sombreado como información de dirección de la paleta. Así cada pixel del quad corresponde un color específico de la paleta y este a un pixel de la textura. Eso permite que variando el sombreado se pueda colocar la textura en cualquier posición del quad y en cualquier tamaño.
Desde luego es una técnica ingeniosa, pero no esta en manual de desarrollo que Jon tendría en su momento, ni mucho menos tendría tiempo para meterse en tecnicas tan complejas. Me parece muy osado decir por eso que el vídeo es incorrecto, esa técnica no existia entonces y por tanto el vídeo era correcto. Es como decir que en 1998 desarrollaban los juegos de N64 mal porque ahora desde la comunidad hay técnicas de optimización y hasta de bump mapping mucho mejores que entonces.

Misscelan escribió:Tampoco entiendo que me quieres decir con lo del antialiasing, primero me dices que yo he dicho que la precisión subpixel era lo mismo antialiasing y cuando te digo que no dije eso, vienes a decirme que según el manual son lo mismo?

No quise decir eso, vuelve a leer los post.

Misscelan escribió:El antialiasing intenta detectar aristas y cuando la encuentra intenta mezclarla con los pixel de su alrededor.

Igual no manejamos el mismo concepto de antialiasing.
El antialiasing no se aplica solo a los bordes. Por ejemplo, se usa para evitar patrones muaré en las texturas que se alejan. El mipmapping es una técnica específica para evitar este tipo concreto de aliasing. Para los bordes hay otras técnicas, en el enlace del manual que puse antes especifíca la que usan para la N64 y situaciones en las que debe activarse o no (antialiasing entre polígonos con la misma textura es inutil o contraproducente).
En cualquier caso varias técnicas de antialiasing solo existen con cálculo subpixel.
Y defiendo que el antialiasing es necesario para la N64 a 240p.

Misscelan escribió:lo del ejemplo que has puesto de ps1 para organizar la escena es un ejemplo muy restrictivo y hay un montón de casos donde esa aproximación puede fallar,

Solo era un ejemplo de optimización que se puede aplicar. Si tienes un escenario con unas características controladas y conocidas, puedes aprovecharlo para optimizar el motor y así evitar latencias aquí y allá. Evidentemente no puedes aplicar de la misma manera una optimización para un circuito de carreras en un escenario de plataformas. Además según como restrinjas el funcionamiento del motor tendrás que diseñar el escenario de una forma muy específica o, como dices, pueden surgir fallos.

@EMaDeLoC

Mi último post al respecto, porque creo que no estamos repitiendo ya. Al final tú prefieres el sistema actual con sus virtudes y sus defectos y yo el otro con sus virtudes y sus defectos.

La foto la habías enseñado ya, creo que fue la primera vez que vi la transferencia de memoria de n64 representada en un gráfico y la verdad es que es una forma muy ilustrativa y rápida de entenderlo.

Lo de Sprite es una nomenclatura, el Sprite es un polígono. El hecho de no soportar coordenadas UV no es condición sine qua non un polígono se convierta en Sprite o no, porque realmente no existe una definición única de Sprite, pero si existe de polígono. De hecho, seguramente sepas que la primera tarjeta de NVIDIA (la Diamond Edge 3d) renderiza los polígonos de la misma manera que Saturn, solo quads y sin UVs y esto es lo que pone en la parte de atrás:


Se le un poco mal, pero dice “300.000 3d pixel textured mapped polygons/second”. Respecto a los problemas de transparencia, ya comenté el problema en el post anterior, es un bug en el algoritmo de Saturn, nada más. 3DO también usa forward mapping (sin UVs) y no tiene ese problema con las transparencias.

Lo de megatexture, cuando revisé el código hace tiempo, lo mismo recuerdo mal, al final convertía la n64 en una suerte de Saturn y en como hace la Saturn la subdivisión. Todas las texturas estaban pre-divididas en memoria para entrar en cache. Los polígonos usaban clamp to Edge (como si fuese un “Sprite” sin UVs). Pero bueno, cualquier juego de N64 usa UVs para texturizar y habría valido de ejemplo.

Lo de Jon, no quería sonar brusco, simplemente menciona todo el video gira sobre la imposibilidad de hacer lo que el hizo por hardware creando el raster en software y ahora mismo ese video está obsoleto en ese aspecto, nada más. Sigue siendo interesante y didáctico, en cualquier caso.

Lo de antialiasing sigo sin entender que decías, pero bueno, da igual. El aliasing al que me refería es al de los bordes de sierra, nunca habíamos mencionado ningún otro no? Yo mencioné quitar el “blending de los niveles” de mipmap por hardware como otra medida para ahorrar costes pero los mipmaps seguirían disponibles, y bueno aunque me cargase toda la circuitería referente a los mipmaps implementarlos por software es trivial.

Misscelan escribió:Mi último post al respecto, porque creo que no estamos repitiendo ya. Al final tú prefieres el sistema actual con sus virtudes y sus defectos y yo el otro con sus virtudes y sus defectos.

Sintentizando, yo estoy en contra de tu sistema porque no supone ninguna evolución destacable de una PS1, especialmente con todo lo que SGi era capaz de hacer en el momento que contacto con Nintendo y de lo que podía ofrecer.

Misscelan escribió:Lo de Sprite es una nomenclatura, el Sprite es un polígono.

Si, digo sprite por diferenciarlo del polígono o triángulo en un entorno 3D, aunque se usen sprites también en entornos 3D.

Misscelan escribió:De hecho, seguramente sepas que la primera tarjeta de NVIDIA (la Diamond Edge 3d) renderiza los polígonos de la misma manera que Saturn, solo quads y sin UVs y esto es lo que pone en la parte de atrás:

Lo conozco. Es más, se podía jugar a juegos porteados de Saturn con un mando de la consola.
Para mí si los vertices de un quad los maneja la GPU con solo dos coordenadas, en realidad es un sprite muy manipulable, pero no deja de ser 2D, o mejor dicho, la GPU no deja de ser 2D. Por eso considero que la Saturn de base es 2D, pero tan notablemente potente en ese aspecto que puede rendir en 3D sin problemas.
Pero bueno, eso es un tema aparte.

Misscelan escribió:Lo de antialiasing sigo sin entender que decías, pero bueno, da igual. El aliasing al que me refería es al de los bordes de sierra, nunca habíamos mencionado ningún otro no? Yo mencioné quitar el “blending de los niveles” de mipmap por hardware como otra medida para ahorrar costes pero los mipmaps seguirían disponibles, y bueno aunque me cargase toda la circuitería referente a los mipmaps implementarlos por software es trivial.

El caso es que entendía que el antialiasing era uno de los sacrificios de tu versión de N64. Lo cual me parece un error porque precisamente una de las varias características que distinguen la N64 de la PS1 es el antialiasing. Que haya o no zbuffer casi nunca se va a notar, pero si falta antialiasing si.

¿Cual sería mas el impacto de ese doble bus de 32 bits + 8MB?, ¿rendimiento?, o resolución de texturas.

Porque igual semejante ancho de banda excede el rendimiento de la cpu+gpu, pero dentro de su rango puede texturizar a tiempo cada polígono, lo que permitiría unas multitexturas muy definidas.

¿Que se podría esperar de un hardware así si hubiese costado de salida lo mismo que su competencia, justo cuando salieron?.

@Señor Ventura Te voy a matizar que sería un bus de 18 bits, ya que la RDRAM solo lleva 9 bits de datos.

Así en teórico y si mantiene el reloj de 250MHz, el doble de velocidad de transferencia, 1GB/s.
Igualmente sufriría de bajada drástica de velocidad de transferencia con paquetes pequeños. Es decir, comparaciones pixel a pixel con el frambuffer seguirian siendo lentas. Todavía no tengo claro si el RCP tiene alguna clase de caché que le permita comparar dos o más píxeles a la vez, si no es así, la mejora de rendimiento no sería muy notable.

Sin embargo habría una reducción notable a la hora de cargar texturas a la TMEM. Actualmente una textura completa de 4KB tarda 8'8 microsegundos en cargarse en la TMEM desde la RDRAM, con el doble de bus sería la mitad de tiempo, 4'4 microsegundos. Pintar el framebuffer es más o menos aleatorio, no es un paquete completo y grande sino varios de distintos tamaños, así que no habría un porcentaje fijo de mejora, pero la habría. Podría rondar un 20 o 30% de mejora.

Al final todo suma, el cuello de botella se haría más ancho, por lo que el RCP empezaría o terminaría algunas tareas un poco antes, haciendo que el framerate fuese más rápido. Todo depende de cuanto es capaz de rendir el RCP sin límite de ancho de banda de memoria. Algunos vídeos de kaze emunar señalan que su optimización es tan alta que la mayor parte del tiempo de un frame se pierde en transferir datos desde y hacia la RDRAM. Es decir, que ha llegado a su límite. Por cuello de botella.

Así a bote pronto, los Zeldas a 30fps tal cual están sería posible.

La resolución de texturas sería la misma, ya que eso va limitado por los 4KB de la TMEM. Sin embargo al poder cargarlas más rápido, se podrían añadir más texturas a una superficie dividiendola en más polígonos. Obviamente eso requiere más espacio en cartucho, pero lo que digo a veces, con 4MB guardas 1.000 texturas, el almacenamiento de texturas no es tan problematico como un audio de calidad decente. 1 segundo de audio WAV en mono, 8bits de resolución y 22'1KHz de muestreo es como más de 5 texturas, y eso que la caliad del audio no es precisamente para tirar cohetes. Ahí es donde tenemos problemas de espacio.

La CPU va muy sobrada. Las pruebas de Kaze sale que está como al 70% en idle en cada frame. Pero yo mantendría la CPU como esta, la potencia es ideal para la descompresión. Para los FMV de RE2 vino de lujo junto al RCP.

@EMaDeLoC Entonces es culpa de la memoria que las transferencias fragmentadas afecten a la tasa de datos por segundo... pero no había nada mucho mejor por aquel entonces que no se pasase de precio.

Si no entiendo mal, lo que demanda una n64 para lo bueno que si tiene, es no andarse con medias tintas: memoria ram en 4 módulos de 1MB cada uno con su bus de 9 bits, deduzco que sería mejor que un bus de 32 bits y un módulo de 8MB.


Lo que voy a decir... en fin, no me lo tengas en cuenta... ya que la cpu siempre anda ociosa en el grado que sea, ¿no sería significativo para el rendimiento enviar todas las transferencias pequeñas en un solo paquete grande comprimido, y luego usar la cpu para descomprimir y hacer uso de cada pequeño dato donde corresponda, aprovechando que tiene tiempo de cpu sin usar, y que daría igual si lo emplea solo para eso porque no lo necesita para nada mas?.

Señor Ventura escribió:Entonces es culpa de la memoria que las transferencias fragmentadas afecten a la tasa de datos por segundo... pero no había nada mucho mejor por aquel entonces que no se pasase de precio.

Hay que ser justos, es un problema de todas las memorias. Cuando el tiempo de transferencia de datos es cercano a la latencia de la memoria, la velocidad media cae mucho.
Y la RDRAM, esa "gran megaculpable" del cuello de botella de la consola. era la memoria más rápida y cara del momento. Podía transmitir el doble de datos por ciclo de reloj que cualquier otra memoria. No sé de quien sería la idea, de si Nintendo o SGi, pero su velocidad permitía ocuparse de todos los procesos. Seguramente vendría de SGi, ya que fueron los que diseñaron el controlador de memoria del RCP, y a Nintendo la idea de usar una memoria cara pero que le permitía ahorrarse mucho dinero en varios chips de RAM y buses le pareció bien.

Señor Ventura escribió:Si no entiendo mal, lo que demanda una n64 para lo bueno que si tiene, es no andarse con medias tintas: memoria ram en 4 módulos de 1MB cada uno con su bus de 9 bits, deduzco que sería mejor que un bus de 32 bits y un módulo de 8MB.

4 buses de 9 bits sería demasiado, ocuparía demasiado en la placa y en el chip. 2 ya sería una mejora considerable, cada uno con 4MB para dejarse de expansiones.

Señor Ventura escribió:Lo que voy a decir... en fin, no me lo tengas en cuenta... ya que la cpu siempre anda ociosa en el grado que sea, ¿no sería significativo para el rendimiento enviar todas las transferencias pequeñas en un solo paquete grande comprimido, y luego usar la cpu para descomprimir y hacer uso de cada pequeño dato donde corresponda, aprovechando que tiene tiempo de cpu sin usar, y que daría igual si lo emplea solo para eso porque no lo necesita para nada mas?.

Los paquetes más grandes son de 256 bytes. Apenas da para meter más datos con compresión. No creo que valiese la pena complicar el sistema de esa manera.
Sin embargo la CPU tiene 8KB de memoria caché. Podría programarse para trabajar en paralelo al RCP con datos que cupiesen en 4KB y guardase los datos en los otros 4KB, y en cuanto estuvise disponible guardarlos en la RAM.
Creo que Top Gear Rally tiene un tracker para componer música y liberar carga de trabajo al RCP.

@EMaDeLoC los dos buses más dos memorias de 4megas cabrían en una N64 de 259$?

@SuperPadLand Por tema de espacio, esta muy limitado. Seguramente Nintendo tiraría por chips de 2MB por tema de precio, lo que serían 4 chips. Aún quitando el slot del expansion pak, no cabrían en la placa, pero por suerte dentro de la consola hay espacio para una placa más grande.

Pero luego el RCP tendría que ser más grande, de 200 pines, poner los buses, asegurarse de que los buses tienen la impedancia adecuada y esten intercalados con la masa (porque la RDRAM es muy puñetera), soldar los chips, hacer la placa más grande seguramente...

Creo que por política de Nintendo se habría ido a los 300$ para llevarse algo de margen, que no es mal precio comparado con el lanzamiento de las otras consolas y el coste. Luego pudiendo pasar de 4 a 2 chips se podría reducir costes y bajar el precio a 200$.
De todas formas no veo a Nintendo pasando de los 250$, ni tampoco vendiendo la consola a perdidas por 250$ o menos. Así que el diseño actual de la consola quizá fuese la mejor decisión, ya que al ser más barato permitió a Nintendo bajar aún más el precio en el momento de salida. Ese precio competitivo ayudó bastante a no llevarse un batacazo, además de los juegos, soporte 4 jugadores, etc.

De todas formas, aún creo que 8MB de serie en un solo bus, la actual pero con expansion pak integrado, compensando el coste de los chips ahorrando jumper pak, slot y diseño de carcasa, habría sido posible dentro de los márgenes de Nintendo. Pero bueno, a toro pasado...

¿Dónde sería más barato comprar el Everdrive de Krikzz? En la web de Krikzz la última versión pone 159$, pero por ejemplo el distribuidor en España que es retrocables lo venden a 250 eurazos. Si alguien sabe, os agradezco la ayuda. Gracias.

puro_nervio escribió:¿Dónde sería más barato comprar el Everdrive de Krikzz? En la web de Krikzz la última versión pone 159$, pero por ejemplo el distribuidor en España que es retrocables lo venden a 250 eurazos. Si alguien sabe, os agradezco la ayuda. Gracias.

Más o menos te va a costar lo mismo en cualquier lado salvo ofertas puntuales porqué al de krikzz le tienes que sumar gastos de envío más IVA del 21%.

Sale más rentable pillarse summercart 64, tiene todas las características del x7 por la mitad de precio.


Salud.

dirtymagic escribió:Sale más rentable pillarse summercart 64, tiene todas las características del x7 por la mitad de precio.


Salud.

Estoy algo desconectado, que tiene el X7 (importante claro) que no se pueda apañar con el chinorro de aliexpress?

puro_nervio escribió:¿Dónde sería más barato comprar el Everdrive de Krikzz? En la web de Krikzz la última versión pone 159$, pero por ejemplo el distribuidor en España que es retrocables lo venden a 250 eurazos. Si alguien sabe, os agradezco la ayuda. Gracias.

En la web de krikzz, en black Friday suele hacer descuento.
Entre impuestos y envío y aduanas sale por unos 150 dólares con el descuento.

SuperPadLand escribió:

dirtymagic escribió:Sale más rentable pillarse summercart 64, tiene todas las características del x7 por la mitad de precio.


Salud.

Estoy algo desconectado, que tiene el X7 (importante claro) que no se pueda apañar con el chinorro de aliexpress?

Del X7 creo que destaca el reloj, el guardado automático y el emulador.

El Summercart 64 sale mejor: ejecuta roms de cartuchos e imagenes del 64DD sin tener que parchearlas, y hasta se puede ejecutar la expansion del F-Zero X (ROM japonesa más imagen 64DD). Lo mismo con los de Aleck64. Y tiene RTC, guarda partidas, emuladores, etc.

Aún así el X7 puede guardar y cargar copias de los controller pak y meter códigos game shark, aunque me imagino que el summercart64 hará lo mismo en algún momento.

Summercart, echaré un ojo a ver donde se compra. Ese es nuevo, gracias por la información. Si no el Everdrive pero en black Friday, no hay prisa. Gracias!

Teniendo el ED64 Chinorro, creéis que vale la pena el Summercart?

@X_Glacius Por la diferencia de precio, que no es mucha, el SC64 es bastante mejor.

EMaDeLoC escribió:

SuperPadLand escribió:

dirtymagic escribió:Sale más rentable pillarse summercart 64, tiene todas las características del x7 por la mitad de precio.


Salud.

Estoy algo desconectado, que tiene el X7 (importante claro) que no se pueda apañar con el chinorro de aliexpress?

Del X7 creo que destaca el reloj, el guardado automático y el emulador.

El Summercart 64 sale mejor: ejecuta roms de cartuchos e imagenes del 64DD sin tener que parchearlas, y hasta se puede ejecutar la expansion del F-Zero X (ROM japonesa más imagen 64DD). Lo mismo con los de Aleck64. Y tiene RTC, guarda partidas, emuladores, etc.

Aún así el X7 puede guardar y cargar copias de los controller pak y meter códigos game shark, aunque me imagino que el summercart64 hará lo mismo en algún momento.

Emuladores, Aleck y 64DD va en el chinorro. Lo de guardar partidas también, excepto los juegos que requieren un memory pak para ello que no sé si el X7 emula las tarjetas de memoria y te refieres a esto. O si te refieres a que no hay que resetear para generar los guardados de los juegos que grababan en el cartucho.

RTC no tiene, pero que yo sepa solo lo usa el Animal Crossing que está en español en Gamecube ya.

La expansión del FZero creo recordar que no me iba.


Lo de parchear no sé bien a que te refieres, pero no me suena que el chino haga nada de parchear cosas.

X_Glacius escribió:Teniendo el ED64 Chinorro, creéis que vale la pena el Summercart?

Yo diría que no, con el chino ya puedes jugar a todo el fullset en cartucho, incluso el Animal Crossing funciona si tienes curiosidad. Puede que falle alguna cosa del 64DD, el Aleck iba.

Si acaso esa expansión de FZero sería lo más importante. Lo del gestor de saves no sé si se puede apañar de alguna forma, lo cierto es que es raro que no haya un homebrew que permita gestionar saves o un juego que permitiese copiar&pegar saves entre dos mandos con dos memorias.

SuperPadLand escribió:

EMaDeLoC escribió:Del X7 creo que destaca el reloj, el guardado automático y el emulador.

El Summercart 64 sale mejor: ejecuta roms de cartuchos e imagenes del 64DD sin tener que parchearlas, y hasta se puede ejecutar la expansion del F-Zero X (ROM japonesa más imagen 64DD). Lo mismo con los de Aleck64. Y tiene RTC, guarda partidas, emuladores, etc.

Aún así el X7 puede guardar y cargar copias de los controller pak y meter códigos game shark, aunque me imagino que el summercart64 hará lo mismo en algún momento.

Emuladores, Aleck y 64DD va en el chinorro. Lo de guardar partidas también, excepto los juegos que requieren un memory pak para ello que no sé si el X7 emula las tarjetas de memoria y te refieres a esto. O si te refieres a que no hay que resetear para generar los guardados de los juegos que grababan en el cartucho.

RTC no tiene, pero que yo sepa solo lo usa el Animal Crossing que está en español en Gamecube ya.

La expansión del FZero creo recordar que no me iba.


Lo de parchear no sé bien a que te refieres, pero no me suena que el chino haga nada de parchear cosas.

X_Glacius escribió:Teniendo el ED64 Chinorro, creéis que vale la pena el Summercart?

Yo diría que no, con el chino ya puedes jugar a todo el fullset en cartucho, incluso el Animal Crossing funciona si tienes curiosidad. Puede que falle alguna cosa del 64DD, el Aleck iba.

Si acaso esa expansión de FZero sería lo más importante. Lo del gestor de saves no sé si se puede apañar de alguna forma, lo cierto es que es raro que no haya un homebrew que permita gestionar saves o un juego que permitiese copiar&pegar saves entre dos mandos con dos memorias.

Los juegos que usan memory pack suelen tener un gestor al que se accede manteniendo start al encender la consola. Me parece que eso no funciona con el flashcart porque he visto mucha gente que lleva un juego barato para usar el gestor de partida así, pero igual eso es una limitación del everdrive x5 o anterior, no estoy seguro no lo he probado.

@SuperPadLand sí que hay gestor de saves. Yo lo uso y lo comparti en este hilo hace tiempo

X_Glacius escribió:@SuperPadLand sí que hay gestor de saves. Yo lo uso y lo comparti en este hilo hace tiempo

Pues una cosa menos del listado. La verdad que no veo mucha necesidad en N64 de irse a uno caro como con NES y SNES o el MD con MCD.

Es que irónicamente, el más completo que es el summercart 64, es también el más barato,😅

Salud.

dirtymagic escribió:Es que irónicamente, el más completo que es el summercart 64, es también el más barato,😅

Salud.

El chino cuesta menos de la mitad (53€) salvo que me esté equivocando buscando precios del summer (95$ más aduanas y gastos de envío). No me he matado mucho buscando y puede que haya mejores precios de ambos. En todo caso, XGlacius y yo ya tenemos el chino, él preguntó si merece la pena comprarse el Summer teniendo ya el chino. Yo hasta que rompa el mío no gastaría en otro, no veo ningún extra importante que justifique volver a gastar, cuando rompa pues ya se miraría.

@SuperPadLand

50,99€ vale el summercart 64 en Aliexpress, mirando por encima, al ser abierto lo puede fabricar quién quiera, supongo que el tuyo lo habrás mirado en la página del proyecto original, si se quiere comprar ahí para apoyar a los que lo crearon, pues bien, pero vamos fabricado en china es más barato el SC64 que el ED64Plus copia.Y con más prestaciones.
Yo también tengo el ED64 plus, si ya lo tienes, pues no es mucha diferencia, excepto si programas para N64, que es más cómodo lanzar las ROMs desde el USB. Yo hago romhacks de Zelda y la verdad es que me sería más cómodo así, pero vamos lo que es jugar a ROMs de cartucho vale cualquiera, de 64DD y Aleck64 necesitan conversión para que funcione en ED64Plus cosa que no pasa con SC64.

Salud.

@dirtymagic sí, miré en la web del proyecto. No sabía que era open source, en ese caso es como dices. Más barato y mejor, cuando rompa el chino pillaré ese.

SuperPadLand escribió:Lo de guardar partidas también, excepto los juegos que requieren un memory pak para ello que no sé si el X7 emula las tarjetas de memoria y te refieres a esto. O si te refieres a que no hay que resetear para generar los guardados de los juegos que grababan en el cartucho.

Me refiero a que no hay que resetear la consola antes de apagar para que se guarden las partidas en aquellas ROMs de cartuchos con memoria flash.
Respecto al Memory Pak, ningún cartucho crea MP virtuales, y creo que técnicamente no se podría. Pero en el X7 se puede volcar el contenido completo de un MP en un archivo de la SD. De esta forma te puedes crear varios archivos de cada juego y tener siempre copias de seguridad de los MP dedicados a cada juego.
Al menos en el Everdrive v3 tienes esa opción, supongo que el OS del X7 la habrá heredado.

SuperPadLand escribió:La expansión del FZero creo recordar que no me iba.

Porque el disco de expansion requiere tener el juego original insertado en la consola. No sé como se las apaña el SC64 tecnicamente, pero puedes seleccionar la ROM del cartucho y luego la imagen del disco, te carga ambas y se ejecuta el juego con la expansión añadida. Funciona también con el Dezaemon.

SuperPadLand escribió:Lo de parchear no sé bien a que te refieres, pero no me suena que el chino haga nada de parchear cosas.

Con los parches me refería a que para jugar a juegos de 64DD y Aleck64 había que buscar unos parches o encontrarlos ya parcheados (tampoco es que sea dificil encontrarlos) porque buscaban un CIC específico y no servía el UltraCIC 2 del Everdrive v3. No sé si más adelante ya no hizo falta por alguna mejora.
Pero ya que mencionas los parches, el v3 puede aplicar parches IPS al vuelo.

Pero vamos, si no te importan las dos expansiones en 64DD y los juegos te corren, no es necesario cambiar el flash chino.

Hay algún cable convertidor HDMI para N64 que realmente valga la pena? Creo que ya hice la pregunta hace años.

Pero llevaba un tiempo sin mirar y veo que han ido saliendo nuevos modelos, lo que pasa lo de siempre, la mayoría son composite/s-video, estaría bien alguno que tomara del RGB.

Las PAL FR con el mod luego no te sacan S-Video y la calidad va a ser calamitosa... sobretodo teniendo un OSSC y un buen cable RGB de N64, aunque de tanto mover la consola, el cable hace un ruido insoportable dependiendo de los colores en la pantalla.

Marcas hay bastantes, Kaico, Mayflash, McBazel, genéricas...

De cara a volver a desarrollar me estoy planteando una actualización, tener la consola y el OSCC encendido durante horas no me parece buena solución, de ahí algo que conecte a la tele y listo.

El Summer Cart 64 también parece que me vendría genial, por el USB y porque el ED2.5 ya tiene mucha tralla, si es capaz de acceder en caliente a la SD desde el mismo explorador de Windows sería gloría, ahora si hay que usar línea de comando o programas de gestión no tanto.

Veo que están en Amazon, 50€ en Ali es teniendo en cuenta aduanas y transporte? Porque quizás sale a cuenta pagar algo más, saber que tienes garantía y lo puedes devolver durante un tiempo, del Kaico aunque caro dicen que lleva una buena placa, supongo que habrá diferentes variantes o versiones.

Conker64 escribió:Hay algún cable convertidor HDMI para N64 que realmente valga la pena? Creo que ya hice la pregunta hace años.

Si buscas cables a HDMI para N64, la mayoría seran por compuesto o S-video, simplemente porque no todo el mundo tendrá el mod RGB y el vendedor no querrá pillarse los dedos con quejas de cables que no funcionan.

Mira de buscar cables para SNES o Super Famicom. Como si tienen RGB, serán RGB seguro.

Conker64 escribió:Las PAL FR con el mod luego no te sacan S-Video y la calidad va a ser calamitosa... sobretodo teniendo un OSSC y un buen cable RGB de N64, aunque de tanto mover la consola, el cable hace un ruido insoportable dependiendo de los colores en la pantalla.

Es posible habilitar el s-video en las francesas, aunque yo solo he habilitado la parte de luma, no el croma, por tema de sincronismo limpio.
El cable que compres debe ser para SNES PAL, si has hecho el mod de RGB original a la francesa.

No te puedo recomendar ningún cable concreto a HDMI, pero el de Retrogamingcables dicen que va de lujo para todas las de Nintendo, aunque cuesta un riñon y medio más aduanas.

Yo pillé un SC64 en AliExpres con el IVA ya pagado y sin problema de aduanas. La placa interna es de buena calidad de fabricación, no han rateado ahí. Por AE tienes hasta 15 días para solicitar devoluciones.

@EMaDeLoC
Y cuanto te costó el SC64 en total?

Probaste la interfaz USB? Me estoy leyendo el github pero voy poco a poco, la cosa es que es muy buena noticia que todo sea open source y esté en github, hasta el mismo menú, el cual si no se puede poner fondo, porque he visto unos cuantos vídeos en negro sería genial de implementar.

En los ED64 eso era más complicado.

--
Lo del cable supongo que acabaré pillando otro igual al mismo vendedor... pero tener que cargar con el OSSC es bastante pesado, mod HDMI y consola Analogue un poco fuera de presupuesto... creo que como mucho pillaré el mando cuando salga, pero del dongle que tendrán que sacar para la consola original no he visto nada aún.

@Conker64 El SC64 me costó 59€, IVA y envío incluidos.

Con el USB solo he actualizado el firmware. No sé si has visto que hay una aplicación que se conecta directamente y permite cargar las ROMs por USB y cargar o guardar los archivos flash de guardado y también hacer debug: https://github.com/Polprzewodnikowy/SummerCart64/blob/main/docs/00_quick_startup_guide.md#developer-mode-uploading-roms-from-the-pc-and-more

La interfaz USB supongo que será útil para casos específicos o control a más bajo nivel.

Pero con el Summercart se puede guardar partida con el Fzero Expansion Kit? Porque con el chino y la rom parcheada no lo he conseguido

Ayer me pillé este libro que llevaba tiempo agotado en la web:

@X_Glacius He hecho una prueba rápida y he podido crear un circuito, guardarlo y cargarlo después de apagar la consola.
Así que si, puede guardar.
Como apunte, los juegos de 64DD que guardan lo hacen dentro del disco, es decir, dentro de la imagen.

Piro25 escribió:Ayer me pillé este libro que llevaba tiempo agotado en la web:

Buenísimo!

@EMaDeLoC gracias!!

X_Glacius escribió:

Piro25 escribió:Ayer me pillé este libro que llevaba tiempo agotado en la web:

Buenísimo!

@EMaDeLoC gracias!!

Mira que no lo tengas en solo lectura, o si por estar comprimido no puede escribir datos.

Conker64 escribió:Hay algún cable convertidor HDMI para N64 que realmente valga la pena? Creo que ya hice la pregunta hace años.

Pero llevaba un tiempo sin mirar y veo que han ido saliendo nuevos modelos, lo que pasa lo de siempre, la mayoría son composite/s-video, estaría bien alguno que tomara del RGB.

Las PAL FR con el mod luego no te sacan S-Video y la calidad va a ser calamitosa... sobretodo teniendo un OSSC y un buen cable RGB de N64, aunque de tanto mover la consola, el cable hace un ruido insoportable dependiendo de los colores en la pantalla.

Marcas hay bastantes, Kaico, Mayflash, McBazel, genéricas...

Yo no buscaba nada pro, así que me pillé el Kaico Line Doubler y se ve bastante mejor que con la entrada composite de mi tele plana y el cable original de la N64. Tiene filtros guarriperos, pero son opcionales (yo sólo uso el escalado 2X). Además, yo por lo menos no noto nada de lag al navegar por el menú del EverDrive.