Hilo de detalles y curiosidades de N64

@EMaDeLoC
Me refiero a la capacidad de fillrate, obviamente el resto de las cosas sumarían tiempo para componer el Frame.
RA, es qué sólo suaviza los bordes del objeto, pero no en las uniones internas del objeto, AA suaviza todo el Frame, por lo que comentan, RA funciona bien en el escenario donde los polígonos son grandes, porque a no ser que 2 polígonos que compartan lados sean dos colores muy diferentes no se nota y usar AA, para objetos con muchos polígonos, como PNJ, objetos, el propio jugador,ect.

Salud.

EMaDeLoC escribió:@Señor Ventura Ten en cuenta que no todos los planos de fondos se pintan al completo en las consolas que mencionas, que son las pruebas que se han hecho en la N64, y que te he dado los datos más malos para saber el mínimo, pero no necesariamente para pintar fondos necesitas z-buffer ni 2-cycle. Con los datos mejores serían 10 fondos a 60fps. Así que de media se cumplen los 5 de Saturn, aunque los dos hardware funcionan de forma muy distinta.

@dirtymagic Yo creo que sí que habría diferencia con 3D, ya que habría que leer vertices, rasterizarlos, etc, y además añadir lectura de texturas que ocuparía algo de ancho de banda de memoria. Así que algo sí que se resintiría en los datos aportados.

Sobre las últimas pruebas, parece que activar el antialising al completo corta bastante el rendimiento.
¿Alguna información sobre ese "reduced aliasing"? No me suena que había otra opción entre tener o no tener antialiasing, y parece la mejor opción ya que mantiene buen rendimiento y la calidad de imagen es buena.

En N64 hablar de fondos no sería erroneo? Me refiero a que en SS supongo que sí se usan fondos completos unos sobre otros y si desactivas uno, el de atrás se verá completo porque siempre ha estado ahí. Pero en N64 no tendrías que pintar nada de lo que no se ve ¿no? Podrías simular 5 fondos que en realidad sean 2 y tres cuartos Lo cual todavía deja margen para hacer mucho más.

Kaze Emunar nos explica las ventajas y desventajas de usar en la N64 la función del inverso de la raiz cuadrada que se hizo famosa con Quake 3.
Aviso: basicamente es porno de mateticas y programación.

EMaDeLoC escribió:Kaze Emunar nos explica las ventajas y desventajas de usar en la N64 la función del inverso de la raiz cuadrada que se hizo famosa con Quake 3.
Aviso: basicamente es porno de mateticas y programación.

Si no he entendido mal:

-Sacrificar precisión (aunque no entiendo sobre que).
-Utilizar valores inversos para no repetir operaciones (esto es, ¿extrapolar?).
-Con esto consigues paquetes mas pequeños que puedes enviar mas rapido desde la caché.

Me recuerda un poco a la idea de utilizar las multiplicaciones del ppu1 de la snes para convertir los resultados en divisiones usando logaritmos neperianos, y así tenerlo todo.


P.D: ¿Con una memoria mas rapida seguiria habiendo un problema por el bus?.

@Señor Ventura Se trata de una forma de conseguir raices cuadradas mediante una formula optimizada de código para calcular inversos de raices cuadradas y de esta forma ahorrar ciclos de proceso. Es decir, más operaciones de cálculo en menos tiempo.

El caso es que el VR4300 ya tiene una operación expresa para raices cuadradas que tarda lo mismo que una división, así que no se ahorra mucho tiempo, o más bien no se ahorra nada.
Pero si sirve esta formula optimizada del inverso de la raiz cuadrada para calcular la normal de un polígono (el vector perpendicular). Lo cual es útil para calcular iluminaciones y cosas así. Si no es imprescindible la precisión, ahorra tiempo de procesado y el código va más rápido cuando se necesitan estos inversos de raices cuadradas.

Lo que comenta aparte es que aprovechando los 16kb de caché de la CPU se minimizan los accesos a la RAM, que tienen más prioridad que el RCP y además son de acceso más lento. Es decir, se eliminan tiempos muertos de la CPU esperando y el RCP no tiene que interrumpir su trabajo con cada acceso a la RAM.

Con una memoria más rápida se reducirian los tiempos de espera y mejoraría el ancho de banda, pero no se puede hacer a lo loco, habría que mejorar también el controlador de memoria del RCP y la capacidad de este y la CPU de transferir datos para que se aprovechase.

De todas formas ya comenté que la RAM de la N64 es muy rápida y con menor tiempo de acceso que, por ejemplo, las EDO de las 3Dfx Voodoo. El problema es que le supone un cuello de botella enorme los multiples accesos de memoria que exige rasterizar el 3D y que los 500MB/s de transferencia pico se quedaban en realidad en 200MB/s de media por el acceso a paquetes pequeños de datos.

Solo con que el RCP tuviera su propio framebuffer imbuido dentro del chip se habría conseguido un aumento significativo en el rendimiento. Pero claro, el chip habría costado el doble y Nintendo es muy rata con esos temas.

EMaDeLoC escribió:De todas formas ya comenté que la RAM de la N64 es muy rápida y con menor tiempo de acceso que, por ejemplo, las EDO de las 3Dfx Voodoo. El problema es que le supone un cuello de botella enorme los multiples accesos de memoria que exige rasterizar el 3D y que los 500MB/s de transferencia pico se quedaban en realidad en 200MB/s de media por el acceso a paquetes pequeños de datos.

De ahí que la demo de la mega textura rinda tan bien.

¿Mejor una caché para el rcp?, o mejor dividir la ram en varios chips, con varios buses... en términos de costes pienso que lo segundo sería mas viable económicamente, pero, ¿mas rendimiento?...

Lo de que su cpu rinde como un pentium es una barbaridad, pero, ¿que pentium?.

En general tengo la sensación de que una n64 mas equilibrada (al alza, claro), habría sido directamente next gen... y me pregunto cuanto se ahorró nintendo evitando eso, o cuanto mas costaría una n64 semejante...

Parece que han añadido soporte para videos en la dragoncillo (libdragon) aunque es inestable lo pongo en spoiler

Señor Ventura escribió:¿Mejor una caché para el rcp?, o mejor dividir la ram en varios chips, con varios buses... en términos de costes pienso que lo segundo sería mas viable económicamente, pero, ¿mas rendimiento?...

Posiblemente dos chips con dos buses independientes sería lo ideal, aunque quizá la mejor solución económica fuese una salida directa una VRAM para el frambuffer. Con solo 1MB de VRAM ya habría para doble framebuffer a 480i y se despejaría mucho ancho de banda a la RDRAM. El problema sería que no podría manipularse el framebuffer como lo hacen algunos juegos.
Siendo como es Nintendo, de haber ido por ahí serían 512KB de VRAM, que valdría para doble frambuffer a 240p o un solo frame a 480i, que no sería recomendable.

Señor Ventura escribió:Lo de que su cpu rinde como un pentium es una barbaridad, pero, ¿que pentium?.

Si comparas los MIPS de un R4000 a 100MHz con los de un Pentium a 90MHz, verás que son más o menos similares. No esta mal teniendo en cuenta que Intel era el rey en procesadores optimizados y que una instrucción por ciclo es un dato extremadamente bueno.

Señor Ventura escribió:En general tengo la sensación de que una n64 mas equilibrada (al alza, claro), habría sido directamente next gen... y me pregunto cuanto se ahorró nintendo evitando eso, o cuanto mas costaría una n64 semejante...

Teniendo en cuenta que Nintendo iba contando hasta las patillas del RCP, ya que cada patilla supone una soldadura con su coste en estaño... Seguramente se ahorró mucho dinero. Un solo centavo por placa ya supone 330.000$ si lo multiplicas por todas las consolas vendidas, dinero de 1996-2001. Imaginate si ahorraban 1$ en RGB, 10$ en 4MB de RAM o 75$ en un lector de CD.

Que de todos los posibles gastos que recortó yo habría dejado los 8MB de RAM de serie: más espacio para los desarrolladores y experimentar, y en especial para descomprimir datos del cartucho; gran emblema de marketing, "doble de RAM que la competencia"; y al ahorrarse el slot del jumper pak, dicho jumper, el agujero en la carcasa y la tapita, el coste no habría sido tan alto.

Pero en fin, es un gran "what if...".

Detalle curioso.

Como jugar en el sistema original no hay nada.

stormlord escribió:

Detalle curioso.

Como jugar en el sistema original no hay nada.

hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497_s3150#p1754373039
Ya se comentó.
Yo se lo expuse a un extremista del intento de imitación de funcionamiento por software de un dispositivo(emulación), y del intento de imitación de funcionamiento por puertas lógicas de un dispositivo(fpga), y se limitó a reirse.

@mcfly , cierto, no lo había visto.

Aprovecho para hacer un par de preguntas, ¿se distribuyó en España la Nintendo 64 con caja alemana pero con instrucciones en español o ver eso es debido a un transformer hecho por alguien?, ¿los mandos de color solo se vendían por separado o venían en algunos pack especiales?

No sé si llegaron a reutilizar cajas de otras regiones para el mercado español añadiéndole una fajita de cartón por fuera para crear packs de Super Mario o Maro Kart, incluso metiendo mandos de otro color.

@mcfly ahora que hablas de FPGA leí estos días en redes sociales que el core de N64 ya está sobre el 50% y que ya empieza a ejecutar juegos. Ponían un trozo de Goldeneye para ilustrar.

SuperPadLand escribió:@mcfly ahora que hablas de FPGA leí estos días en redes sociales que el core de N64 ya está sobre el 50% y que ya empieza a ejecutar juegos. Ponían un trozo de Goldeneye para ilustrar.

Pero........juegos ya ejecutaba,no?.
Mi duda,es si veremos el indiana jones o el wrc,funcionando sin glitches.

@mcfly pues ni idea, lo otro supongo que sí, a medida que avance la replicación debería ir todo. Otra cosa es que las FPGA actuales tengan suficientes celdas para replicar todo.

SuperPadLand escribió:@mcfly ahora que hablas de FPGA leí estos días en redes sociales que el core de N64 ya está sobre el 50% y que ya empieza a ejecutar juegos. Ponían un trozo de Goldeneye para ilustrar.

Esta bastante adelantado. El RCP esta casi completo, falta pulir detalles y cosas concretas de juegos concretos. Eso me hace pensar que no se emula el RCP al completo si no que se ha codificado un recopilatorio de parches a juegos concretos de algún emulador bueno, especialmente por la velocidad a la que se ha hecho. Pero no he mirado el código fuente así que no tengo prueba alguna aparte de mis sospechas.
De lo último que faltaba por incorporar al core era el TLB, una especie de gestor de memoria de la N64.

¿Alguien podria poner un indicie?
Estaba buscando información sobre cuando se probo el height map en goldeneye pero no lo encuentro

Flash-Original escribió:¿Alguien podria poner un indicie?
Estaba buscando información sobre cuando se probo el height map en goldeneye pero no lo encuentro

Usa la búsqueda del foro limitado a clásicas, y a contenido dentro de mensajes, no títulos.

@Señor Ventura Lo he buscado pero no me sale a lo mejor me estoy colando y @shogun no hizo eso

Kaze Emunar da una clase magistral de como superar los límites que creaba el estilo artístico característico de la N64:



Hay cosas interesantes como el conteo de polígonos, iluminación, texturas, uniones perfectas de articulaciones, etc.

Con un diseño pensado para la consola, se puede sacar cosas muy resultonas, pero claro tienes que diseñar con sus características en mente, que eran bastante diferente a como funcionaban, las 2 plataformas principales de esa época, que eran PSX y PC, que también afectaba a Saturn por sus características únicas.
Al final todos los juegos que usaban sus características únicas, sobresalían técnicamente sobre la competencia.

Salud.

No hay que olvidar el detalle importante del contexto de la época.

El 3D era algo muy novedoso, a pesar de estar introduciendose en las consolas desde años antes, y practicamente no había artistas 3D con notable experiencia, ni mucho menos buenas herramientas. Por ejemplo, en el vídeo sale la creación de gráficos 3D con un plugin de la comunidad de Blender que permite visualizar en modos de 1cycle, 2 cycle, jugar con el color combiner... Cualquier artista de la época habría matado por disponer de algo así, y mucho más gratis. Pero lo que había eran estaciones de trabajo de Silicon que costaban un pastizal y costoso equipo de desarrollo en el hardware original que no siempre estaría disponible de forma constante pues cada equipo tendría sus necesidades.

Los programadores tampoco estaban habituados a trabajar de esa forma, especialmente con un hardware con una arquitectura diferente a la habitual y unos gráficos sin un rendimiento fijo o estable como el sistema de sprites. Es decir, la capacidad de la SNES de dibujar sprites es fija y predecible, sabes cuantos puedes dibujar en pantalla, pero de un triángulo 3D no, depende de su tamaño, la textura, y de todos los calculos que añadas: corrección de perspectiva, iluminación, suavizado, 2cycle...

Las peleas constantes que debian haber entre los programadores y los artistas 3D para mejorar el rendimiento en una zona para mantener el diseño o cambiar todo un modelado a uno más óptimo, debian ser interesantes.
Y eso si se podían permitir dichas peleas, porque con unos plazos que cumplir, los productores lo zanjarian todo con un "¿funciona? pues pasa al siguiente que se nos va el presupuesto".

Ahora hay muchas herramientas y facilidades, pero entonces era todo bastante artesanal y caótico.
Nos vamos quejando del framerate del OoT, cuando seguramente alguien sudó sangre para conseguir que el bosque Kokiri se viera de lujo en la N64.

EMaDeLoC escribió:Kaze Emunar da una clase magistral de como superar los límites que creaba el estilo artístico característico de la N64:

Hay cosas interesantes como el conteo de polígonos, iluminación, texturas, uniones perfectas de articulaciones, etc.

Lo que demuestra que invertir en genios matemáticos y programadores dedicados e investigar y experimentar con tu hardware para sacar las mejores herramientas puede ser lo más importante y que menos visibilidad tiene.

Me ha encantado la parte del "sí, en ese entonces programé en 3D en editor hexadecimal ¿En que cojones estaba pensando?" Menudo crack por cierto.

Me encantaria entender todo lo que dice me parece muy interesante

Flash-Original escribió:Me encantaria entender todo lo que dice me parece muy interesante

Yo lo ví con subtítulos generados automáticamente y traducidos al español. Hay algún gazapo, pero lo vas entendiendo casi todo, excepto cuando se pone a hablar de matemáticas que ahí el problema no es el idioma sino que yo desde que terminé el bachillerato científico no volví a ver una integral, matriz, ni geometría, etc.

Yo soy de diversidad o sea los que no aprueban ni la eso asi que fijate como me quedo yo xD

Flash-Original escribió:Yo soy de diversidad o sea los que no aprueban ni la eso asi que fijate como me quedo yo xD

Jaja, bueno y aun así sabes programar o usar los kits para hacer mods cosa que yo no ¿Al final abandonaste el del Zelda?

Que va sigo poco a poco nunca lo deje
Tambien es lo que dije me gusta programar pero el idioma ingles soy un lerdo y estoy en base de ensayo y error para meter monstruos y jefes
Tengo monstruos diseñados,mapas, texturas,mapamundi pero me falta que no tengo ni idea de como es hacer que funcionen las misiones como escoltar a cremia hasta las montañas y hacer que te tiren del caballo los jinetes voladores porque el juego esta programado para que no te duela ni te echen del caballo entonces no tengo ni idea
Luego estoy optimizando y voy a hacer retopolgia, sigo perfeccionandolo en resumidas cuentas
AVISO FOTOSENSIBLES

Si nadie pide info yo no doy info xD de todas formas no se si me llamaran la atención si lo voy resucitando cada cierto tiempo lo del zelda
¿Alguien me lo confirma?

Si te da igual y tienes ganas de jugar a un zelda de los de antes hice un mod de ocarina a lo cerda de game boy por si os apetece probarlo esta echo toda la parte de link niño desde conversaciones que solo salen una vez hasta descripciones de monstruos

EMaDeLoC escribió:Kaze Emunar da una clase magistral de como superar los límites que creaba el estilo artístico característico de la N64:

Hay cosas interesantes como el conteo de polígonos, iluminación, texturas, uniones perfectas de articulaciones, etc.

Tiene traducción automática, al final lo he visto entero, muy interesante.

@Flash-Original cuando tengas vídeos y updates no te dicen nada por subirlos al hilo que creaste, además ni siquieras estás subiendo vídeos a tu canal de youtube ni nada

Mola ese vídeo, está corriendo en hardware original? La instancia es enorme, supongo que el pasillo ayuda a ello.

Apúntate a clases de inglés no es tan difícil como crees, al menos de aprenderlo escrito (hablarlo y escucharlo ya es más jodido) y te va a abrir todas las puertas a la programación si realmente te gusta. Con un curso básico ya pegarías un buen salto a la hora de entender programación.

@SuperPadLand
Si, en consola original funciona

Se ingles pero enseguida se me quitan las ganas tanto en conversaciones como en temas tecnicos o tutoriales y cuando leo documentacion que no esta traducido enseguida se me va la cabeza

Por eso no me meto profesionalmente en programacion y prefiero para mi en propio

stormlord escribió:

Detalle curioso.

Como jugar en el sistema original no hay nada.

nunca pude jugarlo.
el rpg de snes(este lo tuve) y este de paper de n64 me parecen mejores que los posteriores.
si n64 hubiese tenido la versión mas cara o completa de sus integrados pudo tener mejor framerate, texturas y mejor imagen, pero la queja siempre fue el espacio y precio del cartucho,de parte de los desarrolladores, no del usuario me imagino, mucho mejor en mano, a la vista y sin tiempos de carga...

@cristus ni siquiera había que llegar a tanto, la imagen mejoraría una barbaridad sólo con una mejor salida de vídeo, usando el filtro de suavizado más inteligentemente (menos intensidad, desactivarlo donde no toca, etc) y aunque esto no lo ibamos a usar en la época casi ninguno: tener RGB de salida.

El resto de cosas que comentas podrían haber sido mucho mejores en general con mayor investigación del hardware (matemáticos y programadores) para pulir y sacar mejores herramientas ya en la propia época que aunque no iban a llegar a los niveles de la scene actual sí podían quedarse a medio camino. Y evidentemente compartir esto con las third porque Nintendo&Rare&Factor5 ya sacaban títulos en muchos casos que parecían de otro sistema en comparación el resto.

El otro factor que mejoraría mucho este sistema, pero no veo como solucionarlo sin encarecer el sistema o encarecer (más) los juegos es el tamaño de formato físico. Y aunque aceptemos encarecer la consola 100$ con un lector, hay que tener en cuenta que otras virtudes que permite el cartucho con sus tiempos de acceso rápido (gráficamente, no me refiero sólo a tiempos de carga) se perderían. No se venden duros a cuatro pesetas. Sólo se me ocurre que por lo dicho en el párrafo anterior, mejorasen pronto y mucho las herramientas de compresión de datos. A fuerza de CPU podría verse muy favorecida con estas herramientas.

Lo único que cambiaría de esta máquina y que no encarecería mucho más el sistema es aumentar la memoria RAM de salida a 8MB o al menos a 6MB.

@SuperPadLand tener cartucho como soporte conlleva mejoras graficas, eso debido a que se puede acceder a mas datos en la misma fase no? recuerdo los plataforma 3d de nintendo 64 tenían niveles muy grandes.
yo tengo el cable de s. video que uso en la super nes tambien y es verdad muchos juegos se ven muy borrosos en n64, si comparamos el yoshi is island y el yoshi story el de snes se ve mas limpio, tambien mencionar que tengo un modelo de super famicom de las primeras, dicen que son de mas calidad.
en su momento habían textos por internet que comentaban lo de factor5, con los juegos de star wars que usaban microcodigo, creo que de esa manera liberan ciertas restricciones para poder usar o aumentar algunas capacidades.
y bueno rare nose que hacia pero los resultados eran mejores que nintendo, ya viendo el banjo kazooi, las texturas, efectos de luz, lo enorme de los niveles y hasta donde se podía ver con la distancia de dibujado... desde el super nintendo demostró sacar mas rendimiento que los demás, vemos como para poder superar técnicamente a los donkey kong con el juego mario world 2, se tuvo que usar el chip super fx2´.

¿Para el formato fisico no se podia hacer varios bancos de datos? creo que tenia unos 2 o 3 segundos para cambiar el cartucho en caliente siempre que se le hiciera la llamada al sistema, se podia haber expandido ya que podia cargar 64mb y luego otros 64mb aunque tengo mucho desconocimiento de electronica
Tambien en caso de que se pudiera se tendria que hacer de manera organizada pero habria que decirle donde coger los bancos de que canal

Flash-Original escribió:¿Para el formato fisico no se podia hacer varios bancos de datos? creo que tenia unos 2 o 3 segundos para cambiar el cartucho en caliente siempre que se le hiciera la llamada al sistema, se podia haber expandido ya que podia cargar 64mb y luego otros 64mb aunque tengo mucho desconocimiento de electronica
Tambien en caso de que se pudiera se tendria que hacer de manera organizada pero habria que decirle donde coger los bancos de que canal

Ni idea, pero supongamos que sí y que es posible. No solucionaríamos nada, dos cartuchos significaría los juegos al doble de precio. 24 mil pelas 🤣 Existe el 64DD, pero tampoco cumple con lo de no encarecer el sistema.

Lo único viable que se me ocurre que no encarece es currarse herramientas de compresión de datos que permitiesen almacenar más en cada cartucho y cuya descompresión no tardase mucho claro. Es complicado.

@SuperPadLand
Pero a estas alturas para que, usas un tocho cartucho y usas los megas que necesites.
Que sentido tiene dispararte una pierna para correr una maraton?

@blade133bo porque partimos de aquí

cristus escribió:

stormlord escribió:

Detalle curioso.

Como jugar en el sistema original no hay nada.

nunca pude jugarlo.
el rpg de snes(este lo tuve) y este de paper de n64 me parecen mejores que los posteriores.
si n64 hubiese tenido la versión mas cara o completa de sus integrados pudo tener mejor framerate, texturas y mejor imagen, pero la queja siempre fue el espacio y precio del cartucho,de parte de los desarrolladores, no del usuario me imagino, mucho mejor en mano, a la vista y sin tiempos de carga...

No hablamos de usar lo actual sino de cambiar el pasado.

@SuperPadLand No porque precisamente te ahorrarias lo de otro cartucho
En super nintendo en dkc la electronica que tiene son varios bancos de datos

Flash-Original escribió:@SuperPadLand No porque precisamente te ahorrarias lo de otro cartucho
En super nintendo en dkc la electronica que tiene son varios bancos de datos

Entiendo que te refieres a lo que hicieron con RE2 de meter dos ROM de 32 y un mapper. Eso sí, ya se hizo en el 99 y el precio también subió. Si metes más pues más sube y en N64 el precio de salida más barato de un cartucho enano ya era caro. Hice la actualización al IPC no hace mucho y un RE2 de N64 de lanzamiento equivalía a unos 170 y pico € actuales. Sin encarecer no hay muchas soluciones y Nintendo no estaba por la labor si sacrificó el RGB por ganar 5 centimos/no subir 5 centimos el PVP de la consola.

No veas, yo recuerdo que en su día me costó pasta el resident, unas 12.000 mínimo, salía en la época casi a lo que valía una psx no? Como mínimo media play y un cacho más xD.
Para ser cartucho molaba y tal pero no era muy eficiente.

Segastopol escribió:No veas, yo recuerdo que en su día me costó pasta el resident, unas 12.000 mínimo, salía en la época casi a lo que valía una psx no? Como mínimo media play y un cacho más xD.
Para ser cartucho molaba y tal pero no era muy eficiente.

Playmania de Diciembre del 99 en Centro Mail: 19990 pesetas. Y si querías el adaptador RF mil pelas más (esto lo digo porque todavía hay gente que se cree que lo normal ya era como mínimo RCA y muchos RGB, pero la realidad es que muchos tuvimos que pillar el RF aparte porque teníamos teles de los 80 con RF y ya).

Faltaba poco para el lanzamiento de PSOne y esta creo que andaba con 10 o 12 mil pelas. Este modelo lo vi mucho en crios como alternativa paterna lowcost a regalarles una Play2 a 70-80mil, de hecho Harry Potter se vendió en bundle con este modelo y es uno de los juegos más vendidos del sistema por eso. Esto lo digo para entender el panorama general de que no es como ahora que los críos tienen de todo. Pasaba lo mismo con los PC, yo vi a varios pedir uno y recibir uno de juguete o un Spectrum en tiempos de Tekken 3, Fifa 99, etc.

@SuperPadLand ya ves, te daba para una ps1 de segunda zarpa y la bobina princo de regalo, es que es muy importante contextualizar las cosas, hoy en día puedes meter muchos megas pero en esa época había lo que había.

No hay que olvidar un par de cosas más:

Más contenido se crea, más costoso es el desarrollo. Añadir un nivel de 10-15 minutos puede suponer varias semanas más de desarrollo, entre que se diseña el nivel, se modela, texturiza, etc y se testea que no tenga bugs. Un cartucho de 32MB en la época costaba un pastizal, y tenía que estar super justificado ese salto de 24MB a 32MB. De hecho tenía que estar muy justificado cualquier salto: 8 -> 12MB, 12 -> 16MB, etc. Una solución que encontraron con SM64 es crear pocos mundos que hubiera que recorrer varias veces, y aún así es increible que quepa todo en 8MB.

De facto la N64 tiene 4'5MB. Mucho expansion pak y tal, pero si querias llegar a cierta cantidad de público, había que restringirlo a esa memoria. Con un cartucho de 32MB tienes para llenar 8 veces la RAM, más o menos. Es decir, 8 niveles enteros bastante grandes y completos. A poco que se use compresión, se reutilicen modelos (los personajes por ejemplo) y texturas entre niveles, música, etc. Con 32MB hay muchísimo espacio para meter contenido jugable.

Ojo, contenido jugable. Videos, narraciones de voz y cinemáticas no son contenido jugable, son extras para contar la historia. Si de 10 horas de juego te pasas 8 en cinemáticas, no estás jugando, estás viendo un DVD dándoles muchas veces al botón play del mando. Vamos, que es un pelijuego. ¿Que Metal Gear Solid no sería lo mismo sin las voces, o FFVII sin los vídeos? Seguro que si, pero lo que es jugabilidad, apenas se vería afectada. De nuevo el SM64 de ejemplo: al principio la Princesa nos invita a su castillo, nos enteramos de que el castillo lo ha tomado Bowser, toca rescatar la princesa. Punto. Ni giros de guión ni leches, no hace falta más historia, a jugar al plataformas.

Por eso antes de preguntar si se pueden expandir los cartuchos a más de 64MB, habría que preguntarse primero para qué y si es necesario.

Que por cierto, yo ya comenté por el otro hilo que sí que se puede expandir a más de 64MB la capacidad del cartucho. De hecho, como añadido, el 64Drive HW2 admite ROMs de 200MB, si no recuerdo mal, ya que en principio con las direcciones físicas de la consola es posible hasta 4GB de datos. En realidad no es tanto ya que hay muchas direcciones reservadas, pero en principio no hace falta ningún truco especial ni modificar la consola, tiene capacidad de sobra por sí misma de acceder a muchos datos.

Pero lo dicho, primero hay que ver si hacen falta, y si valía la pena, porque las MaskROM de N64 eran carísimas.

Los gráficos 3d de esa época eran más livianos que los 2d, muchos juegos de n64 eran grandes con pocas megas, la música y los diálogos eran los que se sacrificaban.
Los juegos 2d en esta consola usaban cartuchos grandes pero la mayoría se ven borrosos

Wonder Project J2 es un RPG de la primera hornada para la N64 y ocupa una ROM de 8MB, la misma capacidad que el SM64.

Los gráficos 3D son livianos si no se usan texturas y/o se usan algoritmos procedurales para generar los mapas, pero son casos bastante excepcionales. Un sprite normal requiere de dos coordenadas para dibujarlo en pantalla, más en el caso de Saturn donde se transformaba con distorsiones, rotación, etc. En el caso de un triángulo, cada vértice tiene 3 coordenadas más un valor de color para tintarlo, además de coordenadas y ángulo para la textura. Es decir, no resulta más liviano que el 2D, pero tampoco significa que sea más pesado. Depende del modelo, las texturas y el estilo artístico que se quiera conseguir.

EMaDeLoC escribió:No hay que olvidar un par de cosas más:

Más contenido se crea, más costoso es el desarrollo. Añadir un nivel de 10-15 minutos puede suponer varias semanas más de desarrollo, entre que se diseña el nivel, se modela, texturiza, etc y se testea que no tenga bugs. Un cartucho de 32MB en la época costaba un pastizal, y tenía que estar super justificado ese salto de 24MB a 32MB. De hecho tenía que estar muy justificado cualquier salto: 8 -> 12MB, 12 -> 16MB, etc. Una solución que encontraron con SM64 es crear pocos mundos que hubiera que recorrer varias veces, y aún así es increible que quepa todo en 8MB.

De facto la N64 tiene 4'5MB. Mucho expansion pak y tal, pero si querias llegar a cierta cantidad de público, había que restringirlo a esa memoria. Con un cartucho de 32MB tienes para llenar 8 veces la RAM, más o menos. Es decir, 8 niveles enteros bastante grandes y completos. A poco que se use compresión, se reutilicen modelos (los personajes por ejemplo) y texturas entre niveles, música, etc. Con 32MB hay muchísimo espacio para meter contenido jugable.

Ojo, contenido jugable. Videos, narraciones de voz y cinemáticas no son contenido jugable, son extras para contar la historia. Si de 10 horas de juego te pasas 8 en cinemáticas, no estás jugando, estás viendo un DVD dándoles muchas veces al botón play del mando. Vamos, que es un pelijuego. ¿Que Metal Gear Solid no sería lo mismo sin las voces, o FFVII sin los vídeos? Seguro que si, pero lo que es jugabilidad, apenas se vería afectada. De nuevo el SM64 de ejemplo: al principio la Princesa nos invita a su castillo, nos enteramos de que el castillo lo ha tomado Bowser, toca rescatar la princesa. Punto. Ni giros de guión ni leches, no hace falta más historia, a jugar al plataformas.

Por eso antes de preguntar si se pueden expandir los cartuchos a más de 64MB, habría que preguntarse primero para qué y si es necesario.

Que por cierto, yo ya comenté por el otro hilo que sí que se puede expandir a más de 64MB la capacidad del cartucho. De hecho, como añadido, el 64Drive HW2 admite ROMs de 200MB, si no recuerdo mal, ya que en principio con las direcciones físicas de la consola es posible hasta 4GB de datos. En realidad no es tanto ya que hay muchas direcciones reservadas, pero en principio no hace falta ningún truco especial ni modificar la consola, tiene capacidad de sobra por sí misma de acceder a muchos datos.

Pero lo dicho, primero hay que ver si hacen falta, y si valía la pena, porque las MaskROM de N64 eran carísimas.

Falta hacían, en los multiplataformas se recortaban cosas que ya estaban desarrolladas, pero a ¿Qué precio le vendes un cartucho de 200MB a alguien en 1997? Otro tema son los exclusivos del sistema que ya mirarían eso más, pero sigue siendo otra limitación en lugar de ponerte a desarrollar y crear sin más, tienes que empezar a calcular todo para que quepa en el menor espacio posible, ya estás condicionando todo el desarrollo desde el principio. En PS1 se descartaba contenido por falta de tiempo en los desarrollos, pero en N64 se hacía por falta de tiempo y por falta de espacio. Que hoy en día ojalá saquen un flashcard de 512MB y la scene nos haga babear con lo que se podría hacer así, pero en los 90 era jodido.

Información para los que aún usa Project 64 1.6.

@doblete yo uso hardware, pero cual es la alternativa a Project64? Fue el que usé hace unos 8 años para hacer la capturas de los juegos de N64

SuperPadLand escribió:@doblete yo uso hardware, pero cual es la alternativa a Project64? Fue el que usé hace unos 8 años para hacer la capturas de los juegos de N64

Mupen64 con los plugin's de Parallel y Angrylion.
Son los que uso yo porqué gráficamente son fieles al hardware original, pero estable en FPS.
Salud.

dirtymagic escribió:

SuperPadLand escribió:@doblete yo uso hardware, pero cual es la alternativa a Project64? Fue el que usé hace unos 8 años para hacer la capturas de los juegos de N64

Mupen64 con los plugin's de Parallel y Angrylion.
Son los que uso yo porqué gráficamente son fieles al hardware original, pero estable en FPS.
Salud.

Ese lo tuve también hace años, pero en Android. No sabía que lo había para PC. Tomo nota por si necesito hacer capturas algún día.