[HILO OFICIAL] Nintendo 64

Yo cometí el sacrilegio de no pasarme en N64 ni el Banjo-Tooie ni el Perfect Dark (ahora que habláis de él).

Por fortuna subsané el error y el Banjo lo acabé dos veces hace algunos años, y el Perfect Dark un año o así. Que no sé por qué no los pasé en su momento si tanto uno como otro (salvando las distancias) son la secuela del Banjo-Kazooie y del GoldenEye que me encantaron.

2 juegos 100% recomendables.
@SuperPadLand entiendo lo que dices, pero al menos podrían avisarlo, y de paso decir bajo qué condiciones han jugado/hecho las capturas.

No se qué juego de N64 mire review hace 2 semanas, era una página anglosajona, y las capturas se veían tan falsas, tan limpias y tan de monitor de ordenador, que no me creí ni la mitad de lo que leí.

Cada uno que juegue como le de la gana, para eso están los emuladores, pero si analizan un juego al menos que se esfuercen en decir cómo lo han jugado, porque si me van a hablar de gráficos y jugabilidad aumentando fps y aplicando filtros, a mí que no me tomen por tonto. Ese juego no es el mismo que yo barajo jugar.
@aranya me alegra muchísimo que te guste RR64, en su época pasó sin llamar la atención pero es uno de los tapados de la máquina. Totalmente recomendable. Yo lo juego con volante y pedales en la consola y me encanta XD
@Falkiño tiene que ser buena la experiencia con el volante. El juego es muy rápido, y algunos circuitos se disfrutan mucho yendo muy rápido.
@aranya no sé si has llevado algún blog alguna vez, pero a nada que intentes escribir y maquetar un poco tus post para que luzcan bien te verás con el problema de que capturas usar porque en una web del 2000 una captura a resolución original de PSX y N64 se veía bien, pero usar ese tipo de capturas en la actualidad con gente que usa monitores de 1080p a 4K te ves con el problema de que se ven fatal y al final le hacen todavía menos justicia al juego.

Entonces puedes decidir mejorar la imagen y aplicarle filtros CRT, pero tampoco quedan bien porque el filtro CRT emborrona el juego que muchas veces te interesa que se vea bien para que se entienda de lo que hablas sin tener que describirlo en cuatro parrafos (una imagen vale más que mil palabras).

Por último puedes subir la res y hacerla nítida a 720p para que se vean bien en monitores actuales, la mayoría optan por esto, yo en mi web saqué las capturas a resolución nativa y sin mejoras, se veían mal, bastante peor que en el CRT, pero me ocupan menos megas en el alojamiento y para las visitas que tenia me daba igual. Pero si tuviera pública buscaría que lucieran los mejor posibles.

Lo que sí, cuando no dicen nada es 99% seguro que emulan, cuando juegan en hardware suelen señalarlo siempre en el post o en la descripción de la propia web. Ya sabes la típica web que te dicen "aquí sólo jugamos en hardware original" o "todas los hacks de esta web han sido comprobados en consola real y flashcard" etc.
@SuperPadLand Ya veo, es todo un mundillo este de hacer reviews y publicar.
De todas formas, un par de notas aclarando como se ha jugado e incluso el emulador usado para las capturas, son siempre bien recibidas, y si la gente aporta feedback, siempre te van a ayudar a mejorar.

Seguramente me compre el mando de retrofighters(con cable). Solo tengo un mando, y aunque funciona bien, me gustaría tener un segundo para cuando venga mi hermano.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
Falkiño escribió:@aranya me alegra muchísimo que te guste RR64, en su época pasó sin llamar la atención pero es uno de los tapados de la máquina. Totalmente recomendable. Yo lo juego con volante y pedales en la consola y me encanta XD


Ridge Racer 64 es 1 título que calla bocas, porque demuestra que a base de microcódigo y sufrimiento se pueden sortear las limitaciones del malparido hardware de la Nintendo 64 sacando un producto con una calidad tan NOTABLE como en la mayoría de juegos de conducción de PlayStation: Frame-rate y sensación de velocidad muy altos, pop-up reducido al mínimo, poly-count relativamente alto, etc, sumado a las bondades exclusivas de la consola; filtro de texturas. AA, corrección de perspectiva etcétera, demostrando que cuando se quiere se puede. Una lástima que el formato cartucho le limitase tanto en contenido, aunque la música no estaba nada mal, si no recuerdo es una rom de 256 megabits + compresión ¿?

Como juego dentro de su propia franquicia es uno de los mejores RR del estilo clásico, sólo superado por el redondo Ridge Racer Type-4, y quizás por Rage Racer, dentro de su generación. Obviamente RRV se lo come, pero eso ya son 128 bits.

Junto a Mario Kart 64, F-Zero X, RR64 es el siguiente imprescindible en lo que se refiere a juegos de estilo "ARCADE" de conducción dentro del sistema, uno de los pocos subgéneros que no está nada mal resuelto en la N64 [oki]

Todo esto lo suscribe un fan de esta saga desde el PRINCIPIO; recuerdo que mis primeras partidas a la recreativa de Ridge Racer venían motivadas debido a que en los recreativos que yo iba en aquel entonces el mueble de Daytona U.S.A estaba ocupado siempre por los gitanos, liándola [+risas] Yéndome yo tranquilito al rincón donde estaba el ARCADE de NAMCO.

@Falkiño ¿mejora mucho la experiencia con volante y pedal?
ale210 escribió:No sé si os ha pasado lo mismo, pero el joystick de la N64 tenía algo especial, no sabría decir qué, pero al jugar a goldeneye y pd con el joystick original tenía una precisión que jamás he tenido con otro mando.

Porque el joystick de N64 tiene un feedback único que jamás se ha repetido, lamentablemente.
En su construcción, lo que mantiene los dos ejes pegados a la cazoleta blanca es un muelle que está comprimido por toda la unidad del joystick. Además cuando uno de los ejes gira, su diseño hace que empuje el muelle. Es decir, el muelle es el que obliga a los ejes a estar centrados cuando no se toca el joystick.
Todo este sistema hace que la fuerza que tengas que hacer para inclinar el joystick sea mayor cuanto mayor inclinación tengas. Eso es un feedback muy intuitivo ya que no dependes tanto de saber la posición de tu dedo o la inclinación del joystick, sino de la fuerza que ejerces sobre él, que controlamos mucho mejor. En cambio en los joysticks modernos no hay tanta diferencia de fuerza según la inclinación, si es que la hay, y por tanto pierdes mucho feedback.
Además su sistema óptico previene lo que se conoce actualmente como drift. La putada es que los materiales hacen que se desgaste relativamente rápido, si comparamos con los joystcks modernos que también friccionan como el de la N64.
Por eso por muchos mandos nuevos que saquen, mientras tengan joysticks modernos no va a ser lo mismo que un mando de N64 nuevo o bien cuidado con su grasa de teflón.
@Sexy MotherFucker es que el RR Type 4 es demasiado XD Pero sí, RR64 es un buen juego, el tema es ese, que había que pelearse mucho con la consola para lograr esos resultados, y al parecer también Nintendo tampoco ayudaba, creo recordar que si tenías problemas para desarrollar algo tenías que llamarles por teléfono para pedirles la documentación de lo que querías hacer, y que no siempre te la enviaban. Había rumores de que Silicon Graphics había cerrado parte del hardware bajo una cláusula anti robo o de patente o algo así y eso impedía explotarlo al 100% al dejar a los desarrolladores fuera de ciertas funciones o capacidades, pero no lo puedo asegurar al 100% porque es algo que recuerdo haber leído y no sé donde, no puedo citar fuentes.

Un saludo!
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Falkiño precisamente RR64 no fue programado por NAMCO, sino por Nintendo Software Technology, es el segundo logo que sale en el juego (bueno tercero si contamos la N):

Imagen

Es evidente que gozaban de herramientas de primerísima mano a bajo nivel durante su desarrollo.

@X_Glacius Bueno de hecho Quake II tiene tiempos de carga en Nintendo 64, y en el Ocarina of Time cada vez que sales de por ejemplo Lake Hyllia o Kakariko Village a la campiña central de Hyrule Field, se produce un pequeño parón con un difuminado en blanco el cual genera 1 transición corta en la que N64 está descomprimiendo la siguiente zona...

Pero sí, Nintendo 64 ofrece una experiencia mucho más inmediata que Saturn o PlayStation gracias al formato cartucho, lo que a ciertas edades se agradece especialmente ;)
Sexy MotherFucker escribió: @X_Glacius Bueno de hecho Quake II tiene tiempos de carga en Nintendo 64,

Habría que echar un ojo al código o depurarlo vía emulador, porque pinta más a que esos tiempos de carga son mapas descomprimiendose o construyendose. El cartucho es bastante enano comparado con el contenido que hay.
Es como los circuitos de F-Zero X, que se generan por unas fórmulas matematicas y el grueso de lo ocupado en el cartucho es la música.
@EMaDeLoC bueno, pero al final es un tiempo de carga sea por el motivo que sea, a mi esperar para jugar me significa lo mismo sea por descompresión, lector lento o unos servidores online lentos a la hora de sincronizar. [+risas]

En N64 hay más tiempos de carga en otros juegos, lo que pasa es que comparado con PS1 y SS seguía siendo la más rápida en estos menesteres. De todas formas en 1996-2000 nunca vi a nadie siendo consciente de que PS1 cargaba más lenta y N64 más rápida, no creo realmente que nadie tuviera conciencia de que los tiempos de carga son malos o aburridos o algo así y anduviera mirando que consola era mejor en ese tema, de hecho diría que fue más a toro pasado cuando con internet empezaron los regresos a consolas retro y comparativas, etc. Que se empezó a hablar de muchos aspectos que ahora vemos como peores o malos: Tiempos de carga, paletas de colores, resoluciones, etc.
Hombre yo recuerdo en la época que N64 se valoraba por no tener casi tiempos de carga, mientras que en PSX tenías que comerte el típico "please loading..."

No creo que fuese algo "esencial" para lanzarte a por una u otra, pero es evidente que Mario 64 sin cargas era una maravilla, mientras en Tekken 3 o Castlevania había tiempos de carga (camuflados muchas veces, pero tiempos de carga)
@SuperPadLand Si es más por la curiosidad técnica que por justificar la carga. Esta claro que el paso de datos del cartucho a la RAM es muy rápido, incluso con datos comprimidos ya que la CPU era lo bastante rápida para demorarse muy poco en la descompresión. Por eso debe haber un motivo bastante importante para esas pantallas de carga que estaría bien saber por la curiosidad técnica.

Y ciertamente los tiempos de carga no influyeron en su momento. Solo lo harían para aquellos que tuvieran las dos consolas y aún así. En PSX ya se aseguraban de que las cargas no fueran mayores de 10 segundos, teóricamente llevaría 15 segundos cargar toda la memoria RAM de la consola a velocidad CD de 2x, que tampoco es un tiempo muy alto. Claro que un lector algo cascado y un CD guarro aumentaban el tiempo de carga bastante.
En los juegos de lucha 2D solían ser en los que más te cortaba el rollo los tiempos de carga de PS1. Gracias al lector de 2X no llegaban al nivel de Neo Geo CD, pero molestaban. Por desgracia ese tipo de juegos no se prodigaron demasiado en N64, que por el formato cartucho parecía una consola que podía haber dado mucho juego.



Mortal Kombat Trilogy en Saturn (y supongo que en PS1 también pero he encontrado este video) metía unos tiempos de carga (no muy grandes) que en N64 no había. A cambio, por ser en formato CD podían meter videos, diálogos y músicas en calidad CD a mansalva porque salía "gratis". Era algo que se tenía bastante asumido en la época. Lo uno por lo otro. Sin tiempos de carga pero espacio limitado o con tiempos de carga pero espacio casi ilimitado en un formato más económico.

Hola,

Hoy he ido a poner la nintendo 64 y no funcionaba con la fuente original y el problema lo tiene en un fusible.
¿De qué valores son los fusibles de una fuente de Nintendo 64 PAL?
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@txefoedu Joder es que has ido a poner el peor ejemplo posible, nada menos que The King of Fighters, una saga en la que no solamente hay que cargar escenario, personajes, y pantallas de equipo por combate, sino que además al ser un 3 vs 3 tiene cargar un luchador... ¡En cada ROUND! Y teniendo en cuenta que puede haber entre 3 y 5 rounds por combate (sin contar draw game) estos títulos se tornan totalmente infumables a partir del 96 en cualquier Neo Geo CD, y levemente menos desesperantes en Saturn/PlayStation. Afortunamente a partir de DREAMCAST ya la cosa mejoró bastante con esta franquícia; la música no se cortaba entre rounds, y el cambio de personaje apenas llevaba más de 3 segundos.

En cambio en Street Fighter Zero 3 en PS bien valía esperar una pantallita con ilustración entre combate y combate para disfrutar de 1 pedazo pelea sin interrupciones, por no hablar del incomensurable modo "World Tour" donde te creabas un luchador custom, por no hablar de que en Saturn las esperas se reducían a la mínima expresión gracias al cartucho de 4 MB de RAM.

Otra cosa:

txefoedu escribió:A cambio, por ser en formato CD podían meter videos, diálogos y músicas en calidad CD a mansalva porque salía "gratis".


Aparte de la ABISMAL diferencia en sonido entre las versiones 32 y 64 bits de MKT, también la había en cuanto a contenido, empezando por el ROSTER:

Imagen
Saturn y PlayStation.

VS

Imagen
N64.

Y siguiendo por el número de animaciones, combos, detalle en los escenarios, etc, por no hablar de la mayor nitidez y brillo gráfico a favor de las 32 bits.

Nintendo 64 lo único que tenía a su favor era la ausencia de tiempos de carga entre combates, y que podías emplear las transformaciones de Shang Tsung sin delay, pero que vamos si hay que recomendarle a alguien Mortal Kombat Trilogy desde luego la versión N64 no es ni siquiera la tercera opción, que es lo que pasa en el género de la lucha 2D en general de esta desafortunada consola.

¿Ves? En 0' ya estoy en modo HATER con la N64, puto asco de sistema bipolar que te da 1 de cal y otra de arena, me pasa igual con la SNES, pu**s Nintenfermos [+furioso]
No vamos a descubrir nada nuevo a estas alturas diciendo que usar cartuchos tiene los mismos problemas y ventajas que tuvo en 2600, NES, MS, MD o SNES. Si querías guardar grandes cantidades de datos tocaba gastar MUCHA pasta como eran los cartuchos de NeoGeo y como vender juegos a 20000-40000 pesetas la unidad no es que fuera el "negocio del siglo" todos sabemos que por lo que optaron por usar las memorias más baratas posibles que permitieran ofrecer juegos decentes para su momento. N64 no es diferente a sus hermanas cartucheras, joder si hasta la Switch con sus tarjetas de memoria que son el hijo tonto de los cartuchos tiene estos problemas.

Total que para hacer juegos lo más económicos posibles al usar cartucho o tarjeta de memoria toca reducir datos ya sea eliminando contenido del juego, ripeando música y calidades de sprites/texturas/gráficos pre-renderizados o comprimiendo datos y normalmente todo esto junto. La única diferencia es que en las anteriores generaciones todos los sistemas principales competían usando principalmente el mismo tipo de formato y estos recortes se padecían por igual así que era como "lo normal", muchos lo asociamos a la falta de potencia de las máquinas más que a un problema de no querer venderme el juego al triple de precio. Con N64 pasa que lo que habían sido addons y experimentos anteriores se convierte en un estandar con el CD ofreciendo ventajas y desventajas como formato, se empieza a comparar y se sacan conclusiones que todos conocemos, sólo que ahora podías escoger entre consolas principales empleando soportes físicos opuestos, pero lo que pasó con los juegos de N64 no es algo novedoso de ella es un lastre desde los años 70 y era de sobra conocido por las desarrolladoras que ya en la 2600 se ve el pedazo salto gráfico que experimenta esta máquina a medida que con los años se pudieron hacer cartuchos o usar mappers para aumentar el tamaño, en NES y N64 esto también se nota. La diferencia es que N64 no competía contra una consola con los mismos problemas de formato físico que ella como antaño sino con un CD, para cuando la máquina tenía memorias de 64mb ya llevabamos casi dos años en la siguiente generación y esperando la salida de PS2.

Lo curioso es que Nintendo no hiciera cualquier cosa para tener un mejor formato físico y no uno tan anticuado para aquellos tiempos cuando ellos mismos tuvieron que luchar con los altos precios de los cartuchos y sus pequeñas memorias con Famicom Disk, Nintendo Power, SNES CD y 64DD. Eran de sobra conscientes desde NES que los cartuchos limitan las posibilidades del software, pero con N64 no supieron adaptarse a un formato físico mejor que el cartucho ya fuera CD, disquetes zip u otra cosa. Pero bueno a toro pasado fue mejor así, si usaran disquetes zip es posible que hoy mitad de esos discos hubieran perdido sus datos y desde luego resisten mejor las caídas y cambios de temperatura que los CD. [beer]
@Sexy MotherFucker Relaja abuelo, tomate la pastilla. :P

el_ssbb_boy escribió:Hola,

Hoy he ido a poner la nintendo 64 y no funcionaba con la fuente original y el problema lo tiene en un fusible.
¿De qué valores son los fusibles de una fuente de Nintendo 64 PAL?

Yo no tengo ni idea, pero tienes una buena pista en los valores de operación del transformador. Si es para 3.3V, 2.7A o seguramente uno de 3A. Si es para 12V, 1A.

SuperPadLand escribió:Lo curioso es que Nintendo no hiciera cualquier cosa para tener un mejor formato físico y no uno tan anticuado para aquellos tiempos cuando ellos mismos tuvieron que luchar con los altos precios de los cartuchos y sus pequeñas memorias con Famicom Disk, Nintendo Power, SNES CD y 64DD. Eran de sobra conscientes desde NES que los cartuchos limitan las posibilidades del software, pero con N64 no supieron adaptarse a un formato físico mejor que el cartucho ya fuera CD, disquetes zip u otra cosa. Pero bueno a toro pasado fue mejor así, si usaran disquetes zip es posible que hoy mitad de esos discos hubieran perdido sus datos y desde luego resisten mejor las caídas y cambios de temperatura que los CD. [beer]

La decisión se tomó porque un lector de CD costaba 100$ o más y no querían que la consola pasara de los 200$ como fue con la NES y SNES. El coste de la consola ya se fue por las nubes como para gastarlo en un lector que aún era caro en ese momento.
Curiosamente en las líneas del cartucho hay dos dedicadas a audio L y audio R. No sé su finalidad o si se usan en algún juego, creo que como mucho en el cartucho de capturar para el Mario Artist Talent Studio para 64DD pero no estoy seguro. Cabe la posibilidad de que se incluyeran esas líneas para un add-on de lector de CD en el que meter juegos y reproducir las pistas a través de esas líneas. Pero ni idea, es una de mis cosas pendientes de investigar.
@EMaDeLoC sí claro, pero al final lanzaron la consola con el 64DD en marcha que costaba más que 100$. Es un poco un sinsentido a sabiendas de que habría problemas para almacenar juegos que explotasen todo el potencial del sistema.
@EMaDeLoC
Gracias.

Me equivoqué, no son los fusibles. luego comprobaré los valores que saca la fuente con un multímetro.
@SuperPadLand Es que con N64 se tomaron decisiones que fueron un desastre, y lo peor es que lo del 64DD recuerda a lo ocurrido con el Famicom Disk System en NES.
N64 y 64DD deberían haber salido a la vez, o mejor integrados. Contar desde el principio con 32 o 64MB aunque tuviera ligeros tiempos de carga (que seguirian siendo muy inferiores a PSX) habría hecho que salieran juegos espectaculares en contenido desde el mismo lanzamiento. Pero no, 64DD salió tarde y solo en Japón.
Otro error incomprensible es no haber metido los 8MB de RAM desde el principio. Sé que fue por costes, pero creo que ahorrarse el puerto del expansion pak y la apertura en la carcasa habría compensado bastante. Con esos 8MB desde el principio los juegos ya habrían tenido soporte hi-res de salida, aunque fuesen a pedales, o mejorado el framerate con el triple buffer o más cosas, ayudando a diferenciarse de la competencia y mejorar las ventas.

Me habría gustado que una de las dos cosas se hubiesen hecho, mejor lo de la RAM, porque a su vez el precio de venta del 64DD habría bajado (venía con un expansion pak para reducir tiempos de carga). Pero en fin, a toro pasado... Y la máquina logró grandes cosas sin esos añadidos de serie.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@EMaDeLoC yo hubiese preferido que aun teniendo 8'5 MB de serie desde el principio hubiesen dejado el puerto de expansión, y con el tiempo que hubiesen implementado otros 8 MB opcionales haciendo un total de 16'5 MB para aguantar el tipo en su recta final frente a portentos como Dreamcast. [360º]

Eso sí siempre y cuando no hubiese sido necesario modificar el "chasis" y/o tamaño de la consola, supuesto en el cual prefiero dejar la N64 tal cual está; con su ergonomía y elegancia curvilínea intrínsecas.
@Sexy MotherFucker pues yo casi preferiría 4mb de RAM, pero más rápida. [+risas]
@SuperPadLand La RDRAM de la N64 era de las más rápidas del mercado en su momento. Es rapidísima comparada con la VRAM de PS1. El problema es que era la única y se usaba para todo, lo que provoca serios problemas de cuello de botella, pero su mayor debilidad es que las velocidades bajaban mucho con paquetes pequeños de pocos bytes.
Lo comenté un poco en detalle en el hilo de curiosidades de N64, e incluso hice un gráfico:
Imagen
Si no entendí mal a Conker64, las comparaciones de Z-buffer las hace pixel a pixel, lo que significa que se mueven paquetes de apenas 2 o 4 bytes, que son tasas de 100MB/s, bastante lejos de los más de 450MB/s que puede alcanzar la RDRAM.
Con que el RCP hubiese tenido 80KB dedicados a z-buffer la consola se quita un cuello de botella de rendimiento muy gordo. Vease la velocidad de polígonos que alcanza World Driver Championship ahorrandose el z-buffer. Pero claro, a saber si luego hubiesemos podido ver los efectos de lupa tan guapos de los Zeldas.

La VRAM de PS1 es más lenta, pero a cambio tiene un puerto de lectura/escritura y otro de lectura, lo que significa que se puede leer el framebuffer mientras se escribe en otra región de memoria, eliminando cuellos de botella.
@EMaDeLoC pues prefiero 4MB de RAM sin cuello de botella a 16 [sonrisa]
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
La memoria en estos cacharros es como el dinero entre gente de clase media; siempre es poca, y un poquito más nunca sobra.

Sony tardó 4 generaciones de consolas en aprenderlo :-|
@Sexy MotherFucker si estoy de acuerdo que las consolas al final se quedan cortas de RAM, pero en el caso de N64 creo que sale ganando más arreglando el cuello de botella que no metiéndole 16MB de RAM con ese mismo cuello de botella.
@SuperPadLand yo aquí estoy de acuerdo contigo. Creo que esos 8MB salen más a cuenta sin cuello de botella que salir con 8 y meterle otros 4 por expansión (en plan 12MB) pero seguir con la penalización al rendimiento. También creo que el aumento de RAM debió usarse de maneras más creativas que solo subir resolución como hacen la mayoría.
No sufrais, los fallos de diseño se corrigieron casi todos en la game cube.

Es que realmente no se pudo hacer mucho con una máquina que sobre el papel era un monstruo, pero que los fallos de fabricación, y otras decisiones, la nerfearon brutalmente. Nintendo tuvo toda la culpa de emperrarse en el cartucho, pero no de que sus componentes no se fabricaban de forma eficiente, y ello obligase a funcionar por debajo de sus especificaciones.

Una caché de texturas hubiese mejorado la cosa, pero debía ser caro... y la ram... ¿serviría de algo haber estado dividida en dos o mas memorias siendo un único bus?.
Pues el otro día probé Parallel con Retro Arch y vamos, la emulación va genial, me sorprendió mucho que todo se veía bien, no como en los emuladores anteriores que el texto dejaba mucho que desear...pero me falta encontrar algo que filtre los textos se ven muy pixelados.

¿Alguna idea?

Grcias:

Ese RR64 me hice completo, la verdad que me gustó, frenético y te obligaba a jugar de forma perfecta.
ale210 escribió:Pues el otro día probé Parallel con Retro Arch y vamos, la emulación va genial, me sorprendió mucho que todo se veía bien, no como en los emuladores anteriores que el texto dejaba mucho que desear...pero me falta encontrar algo que filtre los textos se ven muy pixelados.

¿Alguna idea?

Grcias:

Ese RR64 me hice completo, la verdad que me gustó, frenético y te obligaba a jugar de forma perfecta.

El parallel es el que uso yo para el mod del OoT, porque es el que más se acerca a como se ve en N64, yo lo uso junto a un shader de scalines.

Salud.
Señor Ventura escribió:No sufrais, los fallos de diseño se corrigieron casi todos en la game cube.

Exacto. Tiene memorias dedicadas para framebuffer, z-buffer y la caché de texturas es inmensa.
Aunque las quejas por los 4KB de caché de texturas de la N64 son bastante artificiales, tiene el doble que PS1.

Señor Ventura escribió:Es que realmente no se pudo hacer mucho con una máquina que sobre el papel era un monstruo, pero que los fallos de fabricación, y otras decisiones, la nerfearon brutalmente. Nintendo tuvo toda la culpa de emperrarse en el cartucho, pero no de que sus componentes no se fabricaban de forma eficiente, y ello obligase a funcionar por debajo de sus especificaciones.

Una caché de texturas hubiese mejorado la cosa, pero debía ser caro... y la ram... ¿serviría de algo haber estado dividida en dos o mas memorias siendo un único bus?.

Tener la RAM en paralelo en vez de en serie no significaría una mejora sustancial de velocidad en los paquetes pequeños, pero si en los grandes.
Pero lo interesante habría sido que tuviese dos buses independientes para cada chip de RAM, de forma que el RCP pudiese leer en uno y escribir en otro. De esta forma mientras dibuja los polígonos podría leer y escribir el z-buffer por un lado y escribir el framebuffer por el otro, sin necesidad de turnar las operaciones. Habría eliminado uno de los cuellos de botella más importantes de la máquina como es el uso del z-buffer.

Aún así yo creo que habría sido mejor los 8MB directamente de salida. El coste de fabricación sería mayor, pero se habrían ahorrado el conector, el jumper pak (que debía costar su aquel), la complejidad de la carcasa con el acceso del jumper pak y la tapita, aparte de diseñar un expansion pak.

Si las desarrrolladoras en vez de estar experimentando con los 8MB y el triple buffer desde el año 98-99 lo hubiesen hecho desde el 96 y sabiendo que todas la consolas lo tendrían, para el año 99 habrían podido salir algunas maravillas muy interesantes.

Y bueno, si Nintendo no hubiese sido tan cabezona en que por huevos había que usar el z-buffer, los juegos tendrían mejor rendimiento.

De todas formas hablamos de la era de inicio del 3D, ni los más expertos programadores sabian manejar algunas cosas.
@EMaDeLoC Claramente mejorar el acceso a la RAM hubiese sido primordial para mejorar el rendimiento, lo de prescindir del Z-buffering, en algunos juegos ( conducción y lucha) al ser juegos donde es "fácil " predecir el orden de los triángulos, y se usan muchos medianos y pequeños, pero en los juegos de aventura, plataformas 3D ...etc, yo creo que les hubiese sido más cómodo usar el Z-Buffering.
Salud.
EMaDeLoC escribió:De todas formas hablamos de la era de inicio del 3D, ni los más expertos programadores sabian manejar algunas cosas.


Pues sí, me recuerda por ejemplo al Mario 64 VS Mario 64 DS, donde los personajes de DS (Mario, Bowser y tal) tienen menos polígonos que los de N64 y sin embargo, lucen mucho mejor, debido a la experiencia ganada en modelado 3D desde el 95 al 2005.

Un saludo!
EMaDeLoC escribió:Exacto. Tiene memorias dedicadas para framebuffer, z-buffer y la caché de texturas es inmensa.
Aunque las quejas por los 4KB de caché de texturas de la N64 son bastante artificiales, tiene el doble que PS1.


También tiene sus miserias, y de verdad que son muy miserables. Principalmente (para mi), son dos:

1) Una textura de 8 bits pesará siempre lo mismo que una textura de 24 bits... y no puedes hacer que todas las texturas de un juego sean de 24 bits porque no cabrían en aquellos mini discos.

¿Que significa esto?, que resident evil 4 podría haber tenido todavía mejores texturas, GRATIS en términos de rendimiento. Eso nos lo hemos perdido por no ver el juego dividido en 4 mini dvd's.


2) La siguiente pega que le veo es la enorme diferencia entre los polígonos que es capaz de calcular, y los que el rasterizador es capaz de dibujar. Para ser un hardware tan equilibrado y eficiente, esa parte de su pipeline es un descuído inaceptable.



Esto es a groso modo lo mas gordo que se le puede achacar a la máquina. Luego hubiese estado muy bien que incluyese las instrucciones altivec, o que se potenciase el uso de la caché de la cpu para emplear "custom shaders" en lugar de esas "fixed shaders"... que es algo que se puede hacer ya de por si (por ejemplo los famosos pixel shaders), pero me refiero a mayor escala, y sin lags.

Ya puestos, 32MB de RAM en lugar de 24MB hubiese estado genial, pero bueno.



EMaDeLoC escribió:Tener la RAM en paralelo en vez de en serie no significaría una mejora sustancial de velocidad en los paquetes pequeños, pero si en los grandes.
Pero lo interesante habría sido que tuviese dos buses independientes para cada chip de RAM, de forma que el RCP pudiese leer en uno y escribir en otro. De esta forma mientras dibuja los polígonos podría leer y escribir el z-buffer por un lado y escribir el framebuffer por el otro, sin necesidad de turnar las operaciones. Habría eliminado uno de los cuellos de botella más importantes de la máquina como es el uso del z-buffer.

Aún así yo creo que habría sido mejor los 8MB directamente de salida. El coste de fabricación sería mayor, pero se habrían ahorrado el conector, el jumper pak (que debía costar su aquel), la complejidad de la carcasa con el acceso del jumper pak y la tapita, aparte de diseñar un expansion pak.

Si las desarrrolladoras en vez de estar experimentando con los 8MB y el triple buffer desde el año 98-99 lo hubiesen hecho desde el 96 y sabiendo que todas la consolas lo tendrían, para el año 99 habrían podido salir algunas maravillas muy interesantes.

Y bueno, si Nintendo no hubiese sido tan cabezona en que por huevos había que usar el z-buffer, los juegos tendrían mejor rendimiento.

De todas formas hablamos de la era de inicio del 3D, ni los más expertos programadores sabian manejar algunas cosas.


Lo del doble bus y dos memorias para la ram pensaba que vendría bien para que la cpu y el rcp pudiesen trabajar en paralelo de forma real, no pensaba que solo el rcp podría trabajar sobre ambas memorias al mismo tiempo... o igual he entendido mal.

Pero vamos, que la lacra de trabajar peor con paquetes pequeños hubiera tenido un impacto menor si al mismo tiempo estás haciendo otras tareas en la otra memoria, porque la lentitud de la otra tarea no te obliga a esperar para lo que YA estás haciendo.

Pero es lo de siempre... doble bus y dos memorias... ¿bajo que coste?.


En la snes al menos hubiese tenido un sentido. El spc700 solo puede usar el bus para leer samples de la rom durante un breve espacio de tiempo, y si hubiese tenido su propio bus (ya que el spc700 sustituye al DMA), para leer de la rom, lo podría hacer durante todo el frame, en lugar de durante solo una breve parte de el, y así no habría forma de exceder el ancho de banda incluso aunque transfieras 8 samples con la máxima calidad, y la mínima compresión.

Pero no lo hicieron así. Conectaron físicamente dos patillas de la ROM directamente al DSP (gracias a lo cual inventos como el MSU1 son posibles), pero no al SPC700, cosa que habría permitido tener las dos opciones:
-Leer de la rom solo durante un mínimo espacio de tiempo reservado, o en su defecto durante mas tiempo siempre y cuando el DMA no esté accediendo a la ROM.
-O dividir la ROM en dos memorias (gráficos y programa en una, y sonido en otra), y tener todo el tiempo que dura cada frame para leer de la misma independientemente de lo que haga el DMA.
Señor Ventura escribió:Lo del doble bus y dos memorias para la ram pensaba que vendría bien para que la cpu y el rcp pudiesen trabajar en paralelo de forma real, no pensaba que solo el rcp podría trabajar sobre ambas memorias al mismo tiempo... o igual he entendido mal.

Es una especulación de haberse diseñado así desde el principio. Cuando el RCP calcula un pixel de un triángulo, en ese momento calcula también la distancia z y la compara con lo que hay en el z-buffer. Si z es menor que el valor del z-buffer, lo sustituye y pinta el pixel en el framebuffer, en caso contrario no hace nada.
Con RAM unificada haría:
-leer el z-buffer y comparar
-escribir el z-buffer (si es el caso)
-escribir en el framebuffer

En paralelo podría:
-leer el z-buffer
-escribir el z-buffer Y escribir el framebuffer

Además de, por ejemplo, leer el framebuffer mientras el RCP o la CPU acceden a la otra memoria.

Vamos, varios cosas que se pueden ver en PS1 al tener cada parte su propia memoria.

Señor Ventura escribió:Pero es lo de siempre... doble bus y dos memorias... ¿bajo que coste?.

Pues un RCP aún más gigante. [burla2]
No sé el coste de la RDRAM en la época, pero a las malas 50$ más. Que es pasta, pero conseguir algo más de rendimiento más facilmente habría facilitado a las desarrolladoras. Pero bueno, también la historia podría ser la misma que conocemos.

Ciertamente para lo "simple" que es la máquina y lo barata que fue de fabricar sin sacrificar calidad, el diseño es impecable.
Pero siempre se le puede sacar punta al lápiz.
¿Una N64 con CD que mejora hubiese tenido en gráficos?

¿Texturas y ya?
(mensaje borrado)
@ale210 las tasaciones están prohibidas en el foro.
@ale210 las tasaciones están prohibidas, pero no es un juego caro de conseguir. Cuando veas variedad de precios, pilla el más bajo el resto es gente que lo pone caro porque no quiere venderlo al precio real, pero si pillan a un incauto al que sablar pues lo venden mientras sacrifican un cordero a "es la ley de la oferta y la demanda amigo".
@SuperPadLand el que compre un juego X, como Earthworm Jim, a un precio más alto habiendo otros disponibles más baratos, no es porque es un incauto al que sablan, es porque le da igual pagar más pudiendo pagar menos.
Si le da igual pagar más, que lo pague. Pero problema del vendedor no es. Ni tampoco tiene nada que ver con la oferta y la demanda, ya que habiendo más baratos disponibles en oferta, demandas el más caro.

Todo esto suponiendo que los juegos estén exactamente todos en el mismo estado y con precios dispares.
PHANTASIA escribió:¿Una N64 con CD que mejora hubiese tenido en gráficos?

¿Texturas y ya?


Principalmente las FMV, en los juegos de PSX eran lo que más memoria ocupaba.

Eso y la posibilidad de usar varios CD, en un sistema de cartuchos no es posible cambiar de cartucho con la consola encendida y seguir jugando.
@SuperPadLand @Falkiño

No quería un precio, si no mas bien una "valoración no económica" tendría que haberlo expresado mejor. [beer]

Entiendo pues que es un juego poco valorado, pero también me parece raro que hayan pocos a la venta, supongo que al ser un juego tan poco conocido, poca gente lo compró en su día.
Con un cartucho puedes tener mas contenido en la misma escena, con un cd puedes tener mas escenas con contenido diferente.
@PHANTASIA Un CD a nivel de mejoras gráficas no habría supuesto ninguna.
Habría dado más facilidades a los desarrolladores a la hora de diseñar escenarios. Si tienes 16MB de espacio para, por poner un ejempo, una docena de escenarios, a la fuerza no te queda otro remedio que aprovechar el espacio para los modelos 3D y que compartan la mayoría de texturas reusandolas con trucos (la misma textura teñida de verde es hierba y teñida de rojo es lava, por ejemplo). En cambio si tienes espacio de sobra con un CD, cada escenario puede tener su propia colección de texturas y no hay que romperse la cabeza, siendo el diseño más rápido y simple.
Si acaso las texturas podrían ser de más calidad, de 32bits en vez de 16 u 8, pero entonces habría límitación de la memoria RAM, así que no se habría notado excesiva mejora al no poderse mejorar el color de las texturas. Aparte que a más bits de color, más pequeñas y menos detalladas son las texturas, lo cual empeora el resultado final.
coyote-san escribió:
PHANTASIA escribió:¿Una N64 con CD que mejora hubiese tenido en gráficos?

¿Texturas y ya?


Principalmente las FMV, en los juegos de PSX eran lo que más memoria ocupaba.

Eso y la posibilidad de usar varios CD, en un sistema de cartuchos no es posible cambiar de cartucho con la consola encendida y seguir jugando.


Todos el catálogo 2D, con fondos pre-renderizados o con bases de datos grandes también se basa en la mayor capacidad del formato físico. Esto afecta directamente a buena parte de los géneros cojos del sistema que usaron estos recursos en PSX y Saturn, imagina una N64 con RE1, FFVII, SFA, Myst, Broken Sword, Sim City, Civilization II, Manager de Liga, etc. En pleno 2021 casi todos tienen por seguro que prefieren jugarse un Mario 64 en N64 a un Theme Hospital en PSX porque pueden jugar el original de PC, pero en 1998 estas carencias del catálogo de N64 fueron su peor baza para convencer a indecisos y sobre todo generaron una desconfianza de cara a las futuras consolas de Nintendo y los juegos third del momento que desde entonces ya no se esperan en sus máquinas y cuando salen, aunque sean 5-10 años más tarde se celebran como si fuera un triple AAA exclusivo tipo GTAVI.

Por otro lado está la pura comodidad que le das a una desarrolladora a la hora de organizarse y planificar proyectos si le quitas de delante el tener que estar pendiente de no pasarse de cierto tamaño de datos. Que como jugadores no nos damos cuenta, pero tener 700mb para hacer un programa frente a 16 (presionando la mayoría de thirds por usar las de 8) en 1996-1997 era una facilidad enorme. Hasta Nintendo sabía esto anunciando el 64DD en 1995, esta consola usa cartuchos por pura cabezonería de no ceder ante el CD tras el fiasco del SNES CD. [carcajad]
@EMaDeLoC
@Señor Ventura
@SuperPadLand
@coyote-san

La pregunta venía un poco viendo la comparativa N64/PS1 de Quake 2 (tuve el de 64 en la época, el de ps1 nunca lo vi)



Esa riqueza en texturas e iluminación de la versión ps1 hubiese sido igual en 64 de haber llevado CD?
En n64 eran un manchurrón estirado hasta el infinito...
PHANTASIA escribió:La pregunta venía un poco viendo la comparativa N64/PS1 de Quake 2 (tuve el de 64 en la época, el de ps1 nunca lo vi)



Esa riqueza en texturas e iluminación de la versión ps1 hubiese sido igual en 64 de haber llevado CD?
En n64 eran un manchurrón estirado hasta el infinito...

Hombre, el vídeo es bastante borroso de por sí como para ver bien las diferencias.

Este trata más las diferencias y es más claro: https://www.youtube.com/watch?v=ZH0T8_NhD-A

Este es de un clásico canal de comparativas, pero es bastante superficial: https://www.youtube.com/watch?v=akBSeXy5Ehc

Cada port es distinto en cada sistema. En N64 hay efectos que en PS1 no hay y viceversa, aprovechando más las peculiaridades del hardware.
Las texturas de PS1 no serán, mayormente, de más resolución que las de N64, más que nada porque la de Nintendo tenía el doble de caché de texturas y por tanto podían tener más resolución aunque había serias limitaciones.
Lo que ocurre es que el filtrado es bastante pernicioso con texturas de tan baja resolución, da igual si es N64 o PC. El ojo humano va a preferir una textura de 64x64 en PS1 que en N64 porque en esta última estará más borrosa, aunque a nivel de detalle sean lo mismo.

No es que el Quake II sea un ejemplo de múltiples texturas, practicamente todas las paredes, suelos, techos, etc son iguales en todos los niveles. Pero sí que en N64 el cartucho es de 12MB así que por las limitaciones de espacio las texturas se habrán visto perjudicadas. Solo con 16MB el tamaño de las texturas no habría sido un problema.

No sé si habrá algún ripeo de las texturas de cada versión para comporbar empíricamente si tienen diferencias de resolución, pero no creo que las haya o sean importantes.
A ver si alguien puede arrojar más luz al tema.
5573 respuestas