Hilo de detalles y curiosidades de N64

celgadis_84 escribió:Point lights en libdragon con el ucode tiny3D.
No se si este tipo de luces existieron en los juegos comerciales.

¿Te refieres a iluminación por vértice en tiempo real?, me suena que la N64 soporta hasta 8 luces dinámicas por escena, en personajes muchos , los Zeldas por ejemplo cuándo saca a Navi es muy notorio, pero cuando se acerca a una fuente de luz como una antorcha tan bien le afecta a él y los enemigos, en escenarios, lo primero que me viene a la mente y que se note mucho el Forsaken, en el vídeo esa escena es todo geometría muy densa , sólo la rejilla es una textura y da sensación de iluminación de la posterior generación, pero vamos es buena noticia que los ucodes de la scene mejoren y superen los ucodes comerciales de su época.

Salud.

SuperPadLand escribió:Para la propia época N64 tuvo un buen aprovechamiento por parte de Nintendo y sus asociados, yo en este aspecto no tengo queja, el problema fue no compartir más info y herramientas con los terceros para tener un mejor catálogo general. Que la scene ahora llegue a nuevos niveles está genial, pero no creo que en 1998 fuera posible llegar al nivel de Kaze y compañía, el propio Kaze ya lo dijo en algún video explicando sus optimizaciones, que en la propia época no era posible.

Lo único, quizás, que veo posible en la época es que se hubiera usado el expansion pak más como DK64, Quake II y Majoras y menos como el resto. Ahí sí que se perdió una oportunidad importante de tener mejores juegos en diseño o en rendimiento.

Tambien es una lastima que teniendo tanta ram y pudiendo usar resoluciones mas altas que 320x240 no contase con ports arcade 2D. Que estamos hablando de una burrada de 8MB. Si se hubieran puesto a ello podrian haber hecho hasta un port del street fighter iii creo yo.

@Freestate creo, que al usar cartuchos, la expansion de RAM da igual para juegos 2D. No estoy 100% seguro, pero creo que es más rápido leer directamente desde la ROM que no desde la RAM. En cualquier caso, aunque no lo fuera, sigue siendo suficientemente rápido para no depender de RAM extra como en máquinas CD. El problema de los ports 2D es que había que meter todos los contenidos en una ROM mucho más pequeña.

Lo único, que en la ROM metieran los datos comprimidos para poder meter más contenido y luego fueran descomprimiendo a la RAM con sus pequeños tiempos de carga como pasa con Quake por ejemplo.

Tampoco sé si al ser 2D le afectaría la subida de resolución al rendimiento. En lucha el rendimiento no es algo que puede bailar o ser inestable sea cual sea su valor debe ser estable, máximo oscilar 2frames arriba o abajo.

Para esto @emadeloc y @conker64 pueden aportar más.

@celgadis_84
Como ya te ha dicho @dirtymagic, hubo varios juegos que usaban 'point lights', sobre todo en personajes. Super Mario 64 usaba dos fuentes de luz (una blanca y otra roja) en la demo de la cabeza de Mario antes de empezar el juego. Creo que es el mismo efecto.
En gameplay Ocarina of Time es el primero que recuerdo, luego otros juegos de Rare como Jet Force Gemini o Donkey Kong 64).
Si además se le añadía algún truco para simular que la sombra cambiara de posición y tamaño según el origen de la luz, te quedaba un efecto gráfico muy inmersivo. Jet Force Gemini proyectaba varias sombras si había varias fuentes de luz cercanas (DK64 también, pero eran simples círculo y elipses). Creo que Conker BFD es del mismo estilo que JFG, y Banjo-Tooie tiene que ser similar, pero las sombras están hechas con geometría en lugar de una textura desde un buffer y no sé si se pueden desdoblar.
En escenarios el primero que me había venido a la mente era Rogue Squadron, donde los blasters del jugador principal y de algunos enemigos iluminan parte del escenario según avanzan. No recordaba Forsaken, que creo que es anterior y donde el efecto la verdad me parece más conseguido.
Factor 5 alardeaba de que su microcódigo para el Indiana Jones and the Infernal Machine era capaz de poner hasta 8 fuentes de luz en una misma escena.

Todos estos ejemplos son de iluminación por vértices. Es decir, que se le aplica un color a cada vértice calculado a partir de la intensidad, la distancia y la orientación del vértice respecto a la fuente de luz y después se interpolaba el color entre los vértices de los polígonos. Si la maya poligonal no era muy densa las zonas de luz no quedaban uniformes en su contorno.
Y por eso esta demo me parece tan impresionante, ya que no se nota ningún artefacto típico de la iluminación por vértices (incluso mezcla las luces con transiciones suaves de forma muy realista). La densidad de ese escenario debe de ser absurda, porque veo imposible que se trate de iluminación por píxel, que ya era algo muy raro de ver en las consolas de la siguiente generación por la cantidad de recursos que requería. No veo que lo aclare en ningún comentario. Por comparar, está este otro vídeo del microcódigo F3DEX3 que también muestra varias fuentes de luz en tiempo real, pero donde es claramente iluminación por vértices.

¿Hay alguna forma de probar estas demos? Creo que se pueden compilar las roms desde el repositorio, pero ni idea de como se hace. ¿Alguien puede compartirlas? ¿Hay algún impedimento legal?


@SuperPadLand
Siempre es más rápida la RAM que el acceso directo al cartucho. En algunas cosas ligeras te sirve leer directamente desde el cartucho, pero para texturas desde luego que no. Incluso las texturas tienen su propia memoria caché dedicada más rápida que la RAM.

@Sogun vale, pero para juegos de lucha 2D tipo Street Fighter realmente necesitas una expansión de RAM? Para qué? Cada pelea puedes cargar al nuevo rival y el fondo que toque. En los 4 megas de la máquina no caben dos luchadores y un fondo? Raro me parece cuando en PS1 se llegó a portear Alpha 3 o Capcom vs SNK decentemente con un CD lento y 2mb de VRAM.

@SuperPadLand
Dependerá de la cantidad de cuadros de animación de los personajes y del tamaño de sus 'sprites'. También de la complejidad de los fondos: si tienen varias capas, animaciones... 4 MB sería suficiente en muchos casos pero cuanta más espectacularidad gráfica quieras meter más memoria necesitas.

A la PS1 se le critica mucho, en comparación con Saturn, que sus juegos de lucha 2D tienen muy pocos cuadros de animación. Pero es que Saturn además de tener más RAM (aunque dividida) que PS1 y N64 de lanzamiento, también contaba con expansiones de 4 MB. Vamos, que la cantidad de memoria en los juegos de lucha 2D es muy importante.

Supongo que se podría hacer una estimación de la memoria necesaria para un caso concreto. Me refiero a coger todos los cuadros de animación de dos personajes, trocearlos en texturas de 64x32 píxeles, hacer lo mismo con un escenario y sumarlo todo sabiendo que cada trozo son 4 kB. Caben 1024 trozos en 4 MB. Seguramente habrá 'sprites' que se podrán reutilizar de un cuadro de animación a otro, pero es para tener un ejemplo a lo bruto.
EDIT: Si los personajes no tienen más de 16 colores (15 + transparencia) se podrían trocear en texturas de 64x64. En escenarios sería muy complicado hacer lo mismo.

@Sogun ¿Saturn más RAM que N64 de lanzamiento?

@Falkiño
Creo que entre todos sus chips de RAM suma 4.5 MB, pero no me hagas mucho caso.

Estaba equivocado, según Wikipedia tiene 4 MB -> 2 MB RAM, 1.5 MB VRAM, 512 KB sound RAM, expandable with Extended RAM Cartridge
Parece que la PS1 suma 3.5 MB de RAM y de ahí mi confusión. También de la wikipedia ->
2 MiB main EDO DRAM[5]
Additional RAM is integrated with the GPU (including a 1 MB framebuffer) and SPU (512 KB), see below for details.
Cache RAM for CPU core and CD-ROM. See the relevant sections for details.
Flash RAM support through the use of memory cards, see below.
BIOS stored on 512 KB ROM

@Sogun ah vale yo es que recordaba eso no me extraña que Saturn le costase tan cara a Sega.

Yo creo que en el caso de un fighter, lo mejor es seguir la senda KI Gold, que está hecho con el ucode más primitivo y lo hace funcionar a 60fps, escenarios 3D y luchadores 2D, permite lo mejor de 2 mundos, escenarios interactivos con mucho detalle y que ocupan poca memoria y luchadores con mucha animación.

Salud.

La Saturn tiene también los 512k del buffer del cdrom.

No estoy muy puesto en juegos 2d en n64, pero no me suena que el Yoshi o el Mischief tuvieran problemas de rendimiento.

Aunque necesitasen más animaciones de lo normal, siempre podrían comprimir y descomprimir en al aire (usando la cpu y el rsp que no estarían a tope), supiendo que entrasen en rom.

La única razón por lo que lo usuaría la expansión sería si necesito más rendimiento (aunque fuese con la misma resolución).
La memoría de N64 tiene una latencia de acceso inicial (unos 640ns) y otra latencia añadida si tienes que cambiar de fila dentro de un banco de memoria (unos 100 ns). La n64 tiene cuatro bancos de memoria y cada banco tiene algo parecido a una cache (tiene almacenada la fila de memoria abierta - 2k), si por ejemplo el buffer de color y el zbuffer estan asignados al mismo banco y necesitan acceder constantemente además del cuello de botella normal de monopolizar un recurso tienes el del cambio de fila de memoria. Si tienes la expansión tienes otros 4 bancos extra para poder colocar diferentes tareas en otros bancos.

Respecto a la velocidad ROM y RAM, la RAM es 100 veces más rápida (5mb/s vs 500), pero esa es la teoría, en la práctica con la latencia y la congestión del bus puede que para cosas puntuales y pequeñas te puede salir más a cuenta la ROM.

@sogun
Creo que el ejemplo lo puedes pillar de aquí, (te tienes que instalar libdragon antes).
https://github.com/HailToDodongo/tiny3d ... pointlight

A veces el tío trabaja con un fork de libdragon algo cambiado así que lo mismo tienes problemas al compilarlo.

La demo tiene en torno a 1k vértices. Aquí hablar sobre eso y sobre el coste (en tiemoo) de cada luz por 1k vertices

@Misscelan
El problema es que no sé compilar. ¿Es fácil de explicar o alguien me puede enlazar a algún vídeo donde explique el proceso? ¿Se puede hacer en Windows o es necesario Linux (otra cosa que habría que explicarme)?

Por eso preguntaba si alguien podía compartir las roms.

Sogun escribió:@Misscelan
El problema es que no sé compilar. ¿Es fácil de explicar o alguien me puede enlazar a algún vídeo donde explique el proceso? ¿Se puede hacer en Windows o es necesario Linux (otra cosa que habría que explicarme)?

Por eso preguntaba si alguien podía compartir las roms.

En el discord N64Brew, sección tiny3d tiene subido el rom

Hasta donde tengo entendido, quitando planos inclinados infinitos, la n64 es la mejor máquina para resultados 2D, y a mayor resolución.

@Sogun
Lo más facil es como ha dicho celgadis_84, es unirte al discord de n64brew, ahí te puedes descargar normalmente las roms de los ejemplos. Es una comunidad grande, nadie te va a preguntar nada, puedes estar de lurker sin más.

(No sé si EOL permite compartir roms de homebrew por aquí?)

Si no has compilado nunca nada el proceso puede ser un poco abrumador pero por si quieres darle un intento estos serían los pasos.

Primero tendrías que instalarte WSL2 (esto es para ejecutar cosas de linux en windows). De eso puedes encontrar bastantes tutoriales en google.

Después te tendrías que descargar la toolchain:

https://github.com/DragonMinded/libdrag ... x86_64.deb

E instalarla así desde WSL (tienes que moverte a la carpeta donde lo has descargado primero):
sudo dpkg -i gcc-toolchain-mips64-x86_64.deb
(Para moverte a la carpeta de windows desde WSL tienes que tratar la letra del disco como si fuese una carpeta y añadir mnt delante, si por ejemplo la carpeta está en "D:/Libdragon" para ir desde WSL tienes que poner "cd /mnt/d/Libdragon")

Después te creas una carpeta desde windows donde quieras y te descargas estos dos zip y los descomprimes (libdragon y tiny3d).
https://github.com/DragonMinded/libdrag ... review.zip

https://github.com/HailToDodongo/tiny3d ... s/main.zip

Los dos tienen dentro un archivo llamado build.sh que tienes que ejecutar desde WSL. primero el de preview (libdragon)y luego el de main (tiny3d). Tienes que moverte a la carpeta donde están (ambas) y ejecutar:
./build.sh

Esto debería compilar libdragon, tiny3d y los ejemplos que venían dentro de las carpetas.

Señor Ventura escribió:Hasta donde tengo entendido, quitando planos inclinados infinitos, la n64 es la mejor máquina para resultados 2D, y a mayor resolución.

Planos infinitos me suena que Conker ya puso un ejemplo de ello y los hacía sin problemas. Lo de la resolución no sé yo, salvo que por ser 2D sea diferente, subir la resolución en N64 siempre jode el rendimiento y además de una manera exageradamente desproporcional. Fijate que salvo menús, ningún juego va a 640x480 en N64, excepto Virtua Chess que es eso, un tablero de ajedrez que solo tiene que mover una pieza con calma cada rato. En juegos normales los modos hi-res petardean mucho subiendo la resolución 300-400p. El propio FZero va a 60fps estables, pero tiene la resolución más baja de todo el catálogo 296x208.

El Conkers también iba bajo 292x214.

Rayman en hi-res 400x300

Hubo juegos que lograron un equilibrio bueno entre rendimiento y subir la resolución algo (Factor 5 por ejemplo). Pero no existe juego en hi-res a 60fps y creo que tampoco a 30 estables.

Ya otra cosa es que por ser 2D se pudiera hacer que ni idea.

Misscelan escribió:La Saturn tiene también los 512k del buffer del cdrom.

No estoy muy puesto en juegos 2d en n64, pero no me suena que el Yoshi o el Mischief tuvieran problemas de rendimiento.

Aunque necesitasen más animaciones de lo normal, siempre podrían comprimir y descomprimir en al aire (usando la cpu y el rsp que no estarían a tope), supiendo que entrasen en rom.

La única razón por lo que lo usuaría la expansión sería si necesito más rendimiento (aunque fuese con la misma resolución).
La memoría de N64 tiene una latencia de acceso inicial (unos 640ns) y otra latencia añadida si tienes que cambiar de fila dentro de un banco de memoria (unos 100 ns). La n64 tiene cuatro bancos de memoria y cada banco tiene algo parecido a una cache (tiene almacenada la fila de memoria abierta - 2k), si por ejemplo el buffer de color y el zbuffer estan asignados al mismo banco y necesitan acceder constantemente además del cuello de botella normal de monopolizar un recurso tienes el del cambio de fila de memoria. Si tienes la expansión tienes otros 4 bancos extra para poder colocar diferentes tareas en otros bancos.

Respecto a la velocidad ROM y RAM, la RAM es 100 veces más rápida (5mb/s vs 500), pero esa es la teoría, en la práctica con la latencia y la congestión del bus puede que para cosas puntuales y pequeñas te puede salir más a cuenta la ROM.

@sogun
Creo que el ejemplo lo puedes pillar de aquí, (te tienes que instalar libdragon antes).
https://github.com/HailToDodongo/tiny3d ... pointlight

A veces el tío trabaja con un fork de libdragon algo cambiado así que lo mismo tienes problemas al compilarlo.

La demo tiene en torno a 1k vértices. Aquí hablar sobre eso y sobre el coste (en tiemoo) de cada luz por 1k vertices

Esta semana he jugado y completado el Mischief, sí tienen ralentizaciones, pero son anecdóticas en momentos de mucha acumulación de mierdas en pantalla rollo varios personajes, más explosiones y proyectiles. Pero el 99% del tiempo va estable.

Es un juego que parece sencillo por ser 2.5D, pero tiene momentos donde pone una docena o más de modelos pre-render de personajes con proyectiles, etc. Más los fondos que a veces tienen efectos o hacen efecto parallax, etc.

Edit: De hecho en SS no he visto nada 2D tan cargado, solo los combates de los Dragon Force que ponen muchas más unidades, pero no tienen todo el resto del decorado, efectos, etc.

Interesante.... ¿Nintendo 64 tiene capacidad para mayores resoluciones que Saturn y PS1? Desconocía ese dato. Si alguien pudiera aportar datos o una fuente....la información más completa que he encontrado es la siguiente:

Saturn

320×224, 320×240, 320×256, 352×224, 352×240, 352×256, 640×224, 640×240, 640×256, 704x224, 704×240, 704x256

320×448, 320×480, 320×512, 352×448, 320×480, 352×512, 640×448, 640×480, 640×512, 704×448, 704×480, 704×512

Play Station

256×224, 256x240, 320x224, 320×240, 368x224, 368x240, 512x224, 512×240, 640x224, 640x240, 704x224, 704x240

256x448, 256x480, 320x448, 320x480, 368x448, 368x480, 512x448, 512x480, 640x448, 640×480, 704x448, 704x480

Nintendo 64

320x200, 320x400, 320x240, 320x480, 640x200, 640×240, 640x400, 640×480

Si es cierto, N64 no tiene mucha versatilidad a la hora de manejar resoluciones.

Entiendo que todas las resoluciones que superan los 240-256 píxeles de resolución vertical son entrelazadas (segundo párrafo en Saturn y PS1).

En cuanto a los planos 2D infinitos y demás virguerías del VDP 2, desconozco las capacidades de N64 en este campo. En cuanto a catálogo 2D, lo poco que conozco de la consola, no me parece del otro jueves...y para mi gusto gráficamente Mischief Makers por ejemplo, no ha envejecido demasiado bien....

@SuperPadLand Creo recordar que Guardian Heroes mismamente tiene más carga en pantalla (si la memoria no me falla, en su momento llegué a contar unos 20 enemigos en pantalla más las réplicas animadas de la barra de vida). Dragon Force 1 y 2, en este sentido, son de otra galaxia.

Por si ha alguien le interesa se han encontrado con archivos beta de banjo kazooie de 6 meses antes del E3 y estan mirando que hay dentro

Se encontró el mapa E3 Treasure Trove Cove
- Se encontró una Caverna de Clanker beta, presumiblemente la iteración del Bosque de Fungi
- Texto de depuración utilizado para depurar fallas

Haced click en la iamgen para verlo aunque es solo wireframe

@SuperPadLand pero en un juego 2D puedes controlar mejor lo que aparece en escena, no vas a poner 3000 polígonos en pantalla, no vas a necesitar z-buffer porque no hay profundidad...

480p a 30fps en alguna clase de juego 2D, yo no lo descartaría mucho, pero por decir algo, claro, realmente ni idea.

Dos polígonos para un "sprite" de 64x32 (nótense las comillas), es mucha área para solo dos polígonos. A partir de ahí, la complejidad que tu quieras, pero un plano y un puñado de personajes...

Señor Ventura escribió:@SuperPadLand pero en un juego 2D puedes controlar mejor lo que aparece en escena, no vas a poner 3000 polígonos en pantalla, no vas a necesitar z-buffer porque no hay profundidad...

480p a 30fps en alguna clase de juego 2D, yo no lo descartaría mucho, pero por decir algo, claro, realmente ni idea.

Dos polígonos para un "sprite" de 64x32 (nótense las comillas), es mucha área para solo dos polígonos. A partir de ahí, la complejidad que tu quieras, pero un plano y un puñado de personajes...

Ni idea, pero me parece raro que de ser posible sin grandes complicaciones ya juegos como Mischielf Makers, Rakuga Kids, Wonder Project 2, Harvest Moon 64, Oggre Battle, Rampage, Clayfighter, Paper Mario entre otros que son juegos que tiran de pre-renders o poligonos planos 2D para todo o casi todo lo que ponen en pantalla. Y no hay ninguno que vaya a 640x480 ni tampoco a 60fps, el combo 640x480x60fps puede ser complicado vale, pero es que no hay ni 640x480x30fps ni 320x240x60fps tampoco. De hecho los pocos juegos a 60fps que hay en N64 poligonales. Y hablamos de llevar juegos de esos años: Street Fighter Alpha 3, Marvel vs Capcom, Street Fighter III, etc. No tengo dudas de que N64 podrá mover Street Fighter II, TMNT Tournament Fighters o Samurai Shodown cuando ya tuvieron buenas versiones en SNES y MD como para no tenerlas en N64 cuasi perfectas.

Creo que conker64 hizo una demo del castlevania sotn con 3 planos a 60fps, de la resolución no me acuerdo, pero, o era la nativa, o era algo parecido a 320x240.

A ver si alguien puede explicarnos bajo que diseños es contemplable un juego 2D a 480p y 60fps en n64.

Si me cuentan que un plano de 256 colores y 4 o 5 personajes es posible a 480p y 60fps, tampoco me parecería ciencia ficción.

Señor Ventura escribió:Creo que conker64 hizo una demo del castlevania sotn con 3 planos a 60fps, de la resolución no me acuerdo, pero, o era la nativa, o era algo parecido a 320x240.

A ver si alguien puede explicarnos bajo que diseños es contemplable un juego 2D a 480p y 60fps en n64.

Si me cuentan que un plano de 256 colores y 4 o 5 personajes es posible a 480p y 60fps, tampoco me parecería ciencia ficción.

Claro, pero un Street Fighter 3 usarla 256 colores? Y no recuerdo ahora la cosa más tocha de ese juego, pero que yo sepa no pone demasiados enemigos en pantalla de forma simultánea y ni alucard ni los enemigos son tampoco grandes y detallados. En el otro hilo ya nos han respondido en parte a esto.

Tal y como está la scene hoy no digo que sea posible, pero en los 90 con lo que había seguro que no. Nadie haría juegos a 400x300x20fps o a 200px60fps si pudiera hacerlos a 480px60fps sin grandes complicaciones.

Igual el problema era el tamaño de los cartuchos, ¿eh?.

Potencialmente un juego 2D va a necesitar mas texturas que un escenario 3D con chorrocientas texturas repetidas. Hace falta mas rom.

Y es que no se como va esto, en GC no necesitas comerte la cabeza porque la profundidad de color va en la textura, y esta va comprimida, siendo la tasa variable, por lo que te da igual que compresión elijas porque SIEMPRE te ocupa lo mismo, y tienes 1MB, en contraposición a los 4KB de n64, que por lo que leo carga las paletas aparte.

Ambas usan la misma arquitectura, pero es que son razonablemente diferentes, y no sabría decir como salir del paso, pero así a groso modo, con un juego estilo dibujos animados, una paleta pequeña para todo, un solo plano, texturas repetidas, número de personajes repetidos...

Formas tiene que haber de que se puedan alcanzar los 480p a 60fps, la pregunta es hasta donde se puede forzar... ¿tres planos con 15 texturas diferentes cada uno? (por decir algo).

Lo que si intuyo es que es la que mas podría de las tres porque sin efectos gráficos sus 4KB de caché son una ventaja, su cpu superior para permitir mas tiempo de DMA que valide la superioridad del cartucho es una ventaja que da otra ventaja...

La única cuestión es si entran planos inclinados, ahí la saturn empieza a renderizar antes de empezar a agotar recursos, y podría salir ganando.

Me parece curioso.

Señor Ventura escribió:Igual el problema era el tamaño de los cartuchos, ¿eh?.

Potencialmente un juego 2D va a necesitar mas texturas que un escenario 3D con chorrocientas texturas repetidas. Hace falta mas rom.

Y es que no se como va esto, en GC no necesitas comerte la cabeza porque la profundidad de color va en la textura, y esta va comprimida, siendo la tasa variable, por lo que te da igual que compresión elijas porque SIEMPRE te ocupa lo mismo, y tienes 1MB, en contraposición a los 4KB de n64, que por lo que leo carga las paletas aparte.

Ambas usan la misma arquitectura, pero es que son razonablemente diferentes, y no sabría decir como salir del paso, pero así a groso modo, con un juego estilo dibujos animados, una paleta pequeña para todo, un solo plano, texturas repetidas, número de personajes repetidos...

Formas tiene que haber de que se puedan alcanzar los 480p a 60fps, la pregunta es hasta donde se puede forzar... ¿tres planos con 15 texturas diferentes cada uno? (por decir algo).

Lo que si intuyo es que es la que mas podría de las tres porque sin efectos gráficos sus 4KB de caché son una ventaja, su cpu superior para permitir mas tiempo de DMA que valide la superioridad del cartucho es una ventaja que da otra ventaja...

La única cuestión es si entran planos inclinados, ahí la saturn empieza a renderizar antes de empezar a agotar recursos, y podría salir ganando.

Me parece curioso.

No entiendo la relación del tamaño de la ROM con que vaya a 480p60fps. Evidentemente hace falta más ROM para meter todo el juego entero, pero para mover un combate de SF3 a 480p60fps sin más contenido jugable no veo que el tamaño de ROM influya, excepto que dichos datos estén ultra comprimidos y no puedas acceder a ellos a suficiente velocidad, pero incluso esto lo veo un problema de tiempos de carga con congelaciones en el combate no en el tema de rendimiento. Pero vamos aquí ya no vamos a como meter el juego entero sino a si podemos tener una demo de un combate completo de dos luchadores cualquiera con un escenario animado y todas las animaciones de los ataques a 480p60fps o no fiel al arcade o si toca recortar y hasta donde.

Con o sin el expansión pak.

Se está hablando de lo mismo en dos hilos de Nintendo 64... El usuario que reflotó este hilo tiene tela.

Creo que el tema de los juegos de lucha 2D para el sistema lo saqué yo en este mensaje del otro hilo.

Me alegro de haber generado un debate tan interesante. Yo por ejemplo me he enterado de que el Street Fighter 3 corría en una placa demasiado avanzada para la Saturn y la PSX por todos los colores, animaciones, etc. de los sprites y fondos. Una versión hubiera perdido colores y por lo tanto personalidad, pero también se comenta que no se hizo porque el juego no triunfó comercialmente.

En lo que sí creo que todos estamos de acuerdo es que la scene debería mirar más a la 5ª generación. En lugar de 5 juegos de 5 tíos diferentes para ZX Spectrum, se podían juntar 5 y hacer un juego de la Play.

@SuperPadLand no, no, relación del tamaño de la rom con el rendimiento no, con su viabilidad.

Si un SFIII no cabe en un cartucho de 32MB, ya apaga y vámonos, pero que un juego 2D de desarrollo consolero seguro que ocupa mas (los de n64 no, que ocupan justo eso), pero igual el yoshi epic yarn no es muy comparable con el silhouette mirage, o el guardian heroes, por eso mismo: capacidad de rom.


@PABEOL En este hilo se está hablando de la capacidad para juegos 2D, y en el otro se está hablando de la posibilidad de ampliar la n64 mas allá de los 8 megas, no es lo mismo.

Y si puede ser que se solapen algunas conversaciones, se corrije y ya está, no debería tener mas importancia.

El Veterano escribió:Nintendo 64

320x200, 320x400, 320x240, 320x480, 640x200, 640×240, 640x400, 640×480

Si es cierto, N64 no tiene mucha versatilidad a la hora de manejar resoluciones.

Eso son resoluciones de salida. El framebuffer podía personalizarse en tamaño dependiendo del desarrollador o el juego. Por ejemplo Factor 5 usaba 400x442 en su modo de alta resolución del Battle of Naboo.

Realmente solo hay 4 salidas de vídeo para todas las consolas: 240p, 288p, 480i y 576i, que corresponden a los formatos de NTSC y PAL. Luego cada una configura su framebuffer como quiera el desarrollador y dependiendo de las capacidades de la consola. Si este framebuffer supera los 240p o 288p, pues efectivamente se entra en modo entrelazado, 480i o 576i.

En teoría la N64 debería sacar resoluciones superiores, su circuito de vídeo podría. Otra cosa es que tenga sentido o que haya límites en las librerias o en otra parte del hardware. En los sistemas de vídeo analógico la autentica resolución real son las líneas horizontales, las 240 o 288. Los pixeles que hay en estas líneas (la resolución horizontal) ya son algo más difuso, depende muchísimo de la calidad y el tamaño del televisor, aunque hablar de pixeles sería incorrecto, ya que se trata más bien de variaciones de color y luminosidad a lo largo de la línea de barrido del TV. El mayor estandar es de 720 pixeles por línea, pero creo que eso supera con creces las capacidades del CRT medio, incluso 640 también. No hay que olvidar que los videos de la PS1 se ven increibles y solo van a 320x240.
También pasar de 640 pixeles horizontales es caer posiblemente en el overscan, ese margen de imagen que supera los bordes de la pantalla del CRT y que no se ve. Por lo que sería procesamiento que se desperdicia.

Mejoras en el ucode tiny3D para hacer "culling" a la geometría de la escena, renderizando solo aquello visible por la camara.

celgadis_84 escribió:Mejoras en el ucode tiny3D para hacer "culling" a la geometría de la escena, renderizando solo aquello visible por la camara.

Una pasada lo que están avanzando con las librerias.

Se viene minecraft 64?

Pues yo quiero ver hasta donde llega con polígonos planos y sin ningún postproceso.

Y un daytona usa 64 xD

celgadis_84 escribió:Mejoras en el ucode tiny3D para hacer "culling" a la geometría de la escena, renderizando solo aquello visible por la camara.

Varias cosas a comentar de la demo porque lo que muestra es muy bueno.

- Al principio del vídeo muestra un conteo de 4072 triángulos ligeramente por debajo de 60 fps, por lo que está moviendo 240.000 triángulos por segundo que es como el doble de lo que se consiguió en los juegos más avanzados durante la vida comercial.
- Pero no está usando ningún filtro para las texturas (ni bilineal para los primeros planos, ni trilineal para los planos lejanos). Al menos tiene corrección de perspectiva. Ya sé que es porque la demo se basa en el Minecraft y tiene ese estilo gráfico, pero me gustaría ver cómo afecta al rendimiento aplicar esos filtros. Porque creo que no está tan claro que usar texturas 1 cycle (las de la demo si no me equivoco) realmente sea más ligero que usarlas 2 cycle.
- Sin embargo, parece que está usando antialiasing. Aunque por la calidad del vídeo es un poco difícil de juzgar. Parece que usa tanto el antialising tradicional de los bordes de los polígonos como el antialising "postprocesado" que emborrona toda la pantalla y hace que el dithering se convierta en un gradiente de color. En la demo no aprecio ni dientes de sierra muy severos ni artefactos provocados por el dithering.

-El Frustrum Culling del que hace gala el vídeo es impresionante. La forma perfecta de descartar polígonos para que no se dibujen y tener más detalle en lo que se muestra en pantalla. El proyecto de Portal 64 creo que ya lo usaba, pero había que delimitar los sectores manualmente. En esta demo se hace al vuelo y además parece que también descarta sectores que se encuentran tapados por otros aunque estén en el campo de visión de la cámara. Como idea llevada a la práctica es muy difícil de mejorar.
-Habría que ver si este sistema sólo es efectivo para mapas creados a partir de una retícula o si también serviría para escenarios más orgánicos con triángulos grandes.

Por comparar un poquito. Había un homebrew para PS1 basado en Minecraft que por los vídeos que he visto funcionaba bastante bien -> https://chenthread.asie.pl/fromage/
Lástima que venga con contador de FPS pero no contador de triángulos para poder hacer comparaciones más ajustadas. Cuando pone la distancia de dibujo a lo bestia también se llega a poner a 10 fps.
https://www.youtube.com/watch?v=6mR1ZQB ... l=AlfyGame

Muy interesante todo esto (y eso que odio el Minecraft). El Fromage ese de PSX tiene un vídeo en Youtube.

@Sogun cuando aleja el campo de visión cuenta 25 mil polígonos a 15fps.

Eso son 375 mil polígonos por segundo, pero con todos los post procesos desactivados, decías, ¿no?.

Edit: varía bastante, también baja hasta los 10fps.

Que pasada,nunca me habría imaginado que la n64 pudiese con algo asi como este port de minecraft, es una locura la potencia de esta maquina bien aprovechada!

Tiny3d es una bendición para el que quiera hacer homebrew y no se quiera complicar nada la vida.
No solo es fácil de usar sino que además tiene un desempeño estupendo.

Aunque los triángulos que salen en pantalla, no son los que se renderizan, si no los que mandan al ucode para procesar:
https://github.com/HailToDodongo/tiny3d ... ain.c#L220

Después ahí dentro se hará backface-culling y screen-clipping, por eso al principio del video aunque mueve ligeramente la cámara no cambia ese número. Y también recordar que a diferencia de otras consolas el fillrate puede variar notoriamente cuando se introducen elementos ajenos al renderizado como puede ser IA, colisiones, animaciones, etc...

Creo que a día de hoy el juego completo que mueve más polys por segundo sigue sigue World Driver Championship? Que por cierto he leído leyendas urbanas que mencionan hasta 300.000, pero me cuesta creerlo, en su momento intenté exportar la maya 3d de un frame para tener una idea pero no lo conseguí con los métodos que usé para otros juegos. Alguien ha podido extraer la maya que se manda al ucode en algún momento de la carrera?

Hasta donde yo sé el filtrado bilinear se hace por hardware y activarlo o no, no afecta al rendimiento.
Que tenga correción de texturas sí afecta al rendimiento y el filtrado AA también aunque mucho menos.
Si hay diferencia entre 1 cycle y 2 cycle, lo que pasa que si los efectos que necesita 2 cycle, son en diferente apartado de la mezcla, suele dar tiempo en el mismo ciclo, por ejemplo, tarda lo mismo poner 2 texturas mezcladas o activar el mipmap sólo, que si además le añades niebla, ya que una va por la combinación de Color y el otro por el Alfa.
La potencia de dibujado no es lineal, si dibuja x polígonos a 60 fps, a 30, dibuja más del doble y así sucesivamente.

Salud.

Una pregunta tonta.

Si los entornos de tipo Minecraft están formados por (aparentemente y siempre lo he considerado así) "unos pocos cubos"...

¿...cómo es posible que estéis diciendo que gastan todos esos miles de polígonos?

Espero no ser el único con esa sensación, yo es que lo miro y mi mente dice: "poca carga poligonal".

@Misscelan
El WDC unos 100-120K+ reales, creo que es en beyond3D donde uno de los desarrolladores daba esas cifras, con zsort, en teoría sin Z-Buffer, o uso de este al mínimo.

Son 8 coches simultáneos así que esos picos solo los alcanzas a principio de carrera con los 8 coches visibles, el número de polys en la carretera como en los escenarios (Las Vegas en especial) en base a los wireframes que vi también parece mucho más elevado que la media de N64.

Llegué a contar a mano un coche de WDC, pero ya no recuerdo a cuanto salía, en Rush 2048 los coches rondan los 600 poly, así que debe estar algo por encima, pero no muy lejos.

Vamos a imaginar que son 800, se dibujarían como la mitad de las caras, 400 * 8 (3200), pero es bastante improbable de que los 8 coches queden delante de la pantalla a modelado completo, es de suponer que habrá diferentes niveles de LOD (El Rush descuenta unos 200 por cada nivel), sumamos escenario, supongo que 1000 es una cifra muy alta, (he llegado a ver juegos que solo ponen 100 en escena, así que escalar de 1000 para abajo no parece mala idea), OSD y demás, y suenan cifras creíbles, pero solo en picos, si fuera un juego de pelea sería más fácil.

Los plugin que usé solo mostraban las caras visibles en los wireframe (a saber como de preciso es el dibujado, o si es simplemente como lo manda a la gráfica de PC), pero vamos, por rizar el rizo se podrían extraer imágenes en alta resolución sin comprimir y con un pequeño programa recorrerla, rellenando zonas y sumando caras, para deducir un número de escena.

¿Alguna vez hemos hablado de un virtua racing en n64 a 480p?.

@Conker64 Gracias por la info!

800 por coche es un montón, no digo que no sea eh, solo que me sorprende porque por ejemplo por referencia el chasis de los modelos de Gran Turismo 2 suele estar en 200 (eso sí muchos son quads) y con tres nivels de LOD.

En algún sitio leí lo de los 120k también, pero no encuentro ahora donde leí algo mucho más alto. Siempre que queda la curiosidad porque por lo general cuando encuentro algún comentario de un desarrollador de esa época hablando de números las cosas no suelen cuadrar con la realidad (y no lo digo por la n64, siempre recuerdo de la burrada de polígonos que se mencionaban en el Vagrant Story y salvo que sea en algún pico que no pillé en el emulador, la mayoría del tiempo está por debajo de 40.000 polys por segundo).

Y siempre que he intentado exportar la escena del WDC cuando la intento importar en blender me dice que solo tiene un vértice y no muestra nada. Tú conoces alguna combinación de emulador/plugin/blender que funcione con WDC?

@Misscelan
200 el coche entero o solo caras visibles?

En Rush 2049, suelen ser unos 600 en el modelado completo y más complejo.


Incluso el Ridge Racer 64 no anda muy lejos


Creo que las extracciones y el count son correctas vaya, he contrastado alguna vez con models-resource cuando estaban disponibles y todo parecía correcto, a veces parece como que engañan a la vista y no son tantos como parecen, o por falta de experiencia los equipos usan más con peores resultados, los coches del WDC a nivel de wireframe, se veían más complejos y redondos que estos.

Pero vamos, si puedes extraer el de estos 2 juegos me gustaría saber que te dan, igual las herramientas de ahora son más fiables, ej. en su día cuando empecé a extraer de PS2 me salía geometría duplicada, pero no vi aquí el caso al usar el mismo método con Mario, que es contrastado que tiene 752.

El Excite Bike 64 (piloto + moto) por ejemplo ya está más cerca de los 1000, sin salirnos de cifras razonables.


En su momento usaba 3D Ripper pero requería de un DirectX antiguo y limitaba la compatibilidad de los juegos, o algunos plugin que directamente sacaban la geometría, ahora no sé que tal andará la cosa, del WDC se podía usar el Jabo pero para ver wireframes solo, fallaba con los 2 anteriores.

@Señor Ventura
No creo que le suponga mucho problema al sistema pintar en flat o goraud sin apenas texturizar a esa resolución y cantidad de detalle, por lo menos de lo que recuerdo de la versión 32X.

@PABEOL
Puede que los cubos estén subdivididos, pero es una apreciación curiosa la verdad, y que tiene que ver con lo de arriba, como puede ser que un coche que se ve tan plano con flat tenga tal cantidad de polígonos. (que luego el goraud hace maravillas a la hora de redondear cosas simples)

Mi mente ultrapotente acaba de calcular que cada cubo son seis polígonos.

No tengo ni idea de cuántos cubos hay en la demo "de Minecraft" de Tiny3D, pero yo no le echaría más de 1000 en lo que se ve.

¿No serían eso 6000 polígonos? A ver si alguien puede explicar dónde está la magia.

@Conker64

200 el chasis, pero como son muchos quads, pues a lo mejor ponle 350 triángulos, más otros 100 de las ruedas. Osea unos 450 triángulos.

Por ejemplo este son 152 polígonos.


Las herramientas no sé si han cambiado mucho, he usado estas:
https://github.com/scurest/blender-impo ... i/Tutorial

Aunque sí que parece que en el tuyo te estaba reportando algún duplicado.
Esto es lo que me da a mi por ejemplo en Rush 2049:
-433 tris en el que coche que maneja el jugador.

-3 coches más delante en la salida ya baja a 242 (se nota sobre todo en las ruedas)


Luego en el RR64:
-362 para el coche que maneja el jugador


-126 el coche que está tres posiciones delante en la salida:


Pero de todos estos el que me interesaba era el del WDC. Supongo que como hace cosas raras con el ucode, la exportación da problemas

@Misscelan
Ah pues parece que la cosa cambia bastante en algunos casos... igual habría que actualizar esos extractos que puse que ya tienen como 10 años, con estas herramientas nuevas más fiables.

Menos mal que muchos modelados que puse después estaban extraídos de otra forma.

De que otros juegos no consigues extraer geometría, solo del WDC? Prueba con el Stunt Racer 64 del mismo equipo, que también usa Z-Sort, supongo que ambos al no usar Z-Buffer darán problemas, aún así creo que los modelados de WDC son más complejos que los de Stunt Racer.

Luego están los de Factor 5, pero creo que estos si usaban Z-Buffer, modificaban el ucode para otras cosas.

@Conker64 muy guapas las capturas, solo una cosilla, en el rush2049 los coches en el aire despliegan alas, que no creo que sean muchos polígonos pero ahí están, para mí el rush 2049 es el mejor juego de coches de la 64, buenos vicios me pegué a esa saga en su día.

@Conker64
El Stunt no tira. El Indy...

Cogi esta escena:


Pero al importar...


A todo los objectos del juego se les elimina la rotación y traslación, todos vuelven al origen.
Eso que está marcado en la foto de arriba es la cara de Indy.
La escena tiene algo menos de 2000 polis antes del backface culling y screen clipping.

Intenté poner a Indy junto:


Por alguna razón que no entiendo han gastado polígonos extendiendo la parte de dentro del cuello hasta la barriga:


Esto es el nivel. Tiene más o menos los mismos polys que Indy (aunque casi todas las paredes de este nivel miran al exterior=Menos backface-culling):


El skybox ya se manda recortado en función de donde miras:


Y por último, solo hay dos objectos de trozos de hierba en memoria, pero como veis hay más en la imagen final. Irán moviendo y rotando los dos que tienen, mucho más eficiente que tener todos como parte del nivel.


Indy es otro de esos juegos que me gustaría cacharrear más para ver como han hecho algunas cosas pero así como se exporta es mucho curro para poca información.

¿Soy el único que no le impresiona nada el Indiana Jones?, no me parece ni artísticamente ni técnicamente muy reseñable y menos para el año que salió y sobretodo en comparación con los 2 juegos anteriores que hizo Factor 5.

Salud.

@Misscelan
Gracias por las capturas

@Segastopol
El Rush 2049 también es de mis favoritos de carreras del sistema, junto al Top Gear Rally, Wave Race 64 y el F-Zero X.

@dirtymagic
A mi tampoco me entusiasma demasiado, ni gráficamente, ni jugablemente, pero tampoco lo he jugado demasiado.

--
Dejo una curiosidad que me encontré el otro día cuando probé el ISS 2000.

Resulta que para algunos letreros el ISS usa el modo COPY (4 pixel por ciclo), esto es raro de ver comercialmente, y me encanta porque intentaron arañar el máximo de rendimiento posible, y de hecho estos juegos son estables como rocas, yo creo que es más herencia desde el primero y lo han ido conservando sin tocar, hasta el punto que se olvida.

Pero veamos que pasa al cambiar de resolución:

Modo normal:


Hi-res:


Ahora si prestamos atención a los letreros 2D, como el contador en la versión en alta resolución tiene como un efecto "acordeón".


Al aumentar la resolución agrandaron también los letreros para que no se vieran demasiado pequeños, pero se olvidaron de cambiar el modo de dibujado, es exactamente lo que me pasaba a mi cuando estaba añadiendo zoom a los sprites, con COPY solo se puede estirar a lo largo, pero a lo ancho sale ese efecto peculiar:


Otro motivo podría ser una mala entrada de coordenadas, por ejemplo el dibujo del mini campo de fútbol está corrupto, con líneas extrañas, al ser semitransparente no se estaría usando COPY.

Por suerte solo aparece en la parte in-game.


Yo me inclino a pensar que lo añadieron a última hora, con tal de poner el logo en la caja.

Conker64 escribió:@Misscelan
Gracias por las capturas

@Segastopol
El Rush 2049 también es de mis favoritos de carreras del sistema, junto al Top Gear Rally, Wave Race 64 y el F-Zero X.

@dirtymagic
A mi tampoco me entusiasma demasiado, ni gráficamente, ni jugablemente, pero tampoco lo he jugado demasiado.

--
Dejo una curiosidad que me encontré el otro día cuando probé el ISS 2000.

Resulta que para algunos letreros el ISS usa el modo COPY (4 pixel por ciclo), esto es raro de ver comercialmente, y me encanta porque intentaron arañar el máximo de rendimiento posible, y de hecho estos juegos son estables como rocas, yo creo que es más herencia desde el primero y lo han ido conservando sin tocar, hasta el punto que se olvida.

Pero veamos que pasa al cambiar de resolución:

Modo normal:


Hi-res:


Ahora si prestamos atención a los letreros 2D, como el contador en la versión en alta resolución tiene como un efecto "acordeón".


Al aumentar la resolución agrandaron también los letreros para que no se vieran demasiado pequeños, pero se olvidaron de cambiar el modo de dibujado, es exactamente lo que me pasaba a mi cuando estaba añadiendo zoom a los sprites, con COPY solo se puede estirar a lo largo, pero a lo ancho sale ese efecto peculiar:


Otro motivo podría ser una mala entrada de coordenadas, por ejemplo el dibujo del mini campo de fútbol está corrupto, con líneas extrañas, al ser semitransparente no se estaría usando COPY.

Por suerte solo aparece en la parte in-game.


Yo me inclino a pensar que lo añadieron a última hora, con tal de poner el logo en la caja.

El ISS 2000 es para mi el mejor juego de fútbol de siempre, más completo, que peca un poco en dificultad de marcar gol. Una lástima que el modo HI-Res esté tan mal hecho, no tiene pinta ni que lo probasen. No se si en NTSC de comporta algo mejor... Por cierto, la versión USA pierde el modo carrera pero le metieron narradores en español (de España) un poco raro porque lo normal sería que fuese en latino. Supongo que su idea era hacer una versión para la zona PAL de España e Italia