Hilo de detalles y curiosidades de N64

jordigahan escribió:

cegador escribió:Soy diseñador gráfico y modelador 3D.

Si alguien se anima a hacer un juego para N64 me gustaría colaborar.

me apunto !!!
yo tengo diseñado todo el primer circuito en el unreal engine.

¿Cuántos polígonos?

.

@Calculinho Miyamoto dijo que en su opinión Super Mario 64 explota el 60% de la capacidad del sistema. Las mejoras que según él se podrían aplicar a ese motor sin sacrificar frame-rate ni filtros, serían una mejora en los efectos de luces, e IAs más sofitiscadas.

Miayamoto dixit.

.

@Calculinho lo dijo en esta entrevista durante la producción del juego:

http://shmuplations.com/mario64/

Pero vamos yo lo leí en la HobbyConsolas y Super Juegos de la época. Lo de los efectos de luces también lo saco de ahí.

Edit: En una entrevista posterior reitera lo del «60%», y dice que el Star Fox machaca aproximadamente el 70%:

http://www.dkvine.com/features/miyamoto.html

Que por cierto no tenía ni idea que existía una versión de SM 64 compatible con rumble pack, a la que ademàs incluyeron las mejoras de las versiones occidentales. Esa rom será mía.

Se soluciona fácilmente.

@BMBx64 ¿Que expectativas de rendimiento esperais, por ejemplo, si hablamos de un daytona usa?.

Señor Ventura escribió:Se soluciona fácilmente.

@BMBx64 ¿Que expectativas de rendimiento esperais, por ejemplo, si hablamos de un daytona usa?.

Vuelvo a colgar las cifras del Daytona U.S.A de ARCADE para establecer más visualmente la comparativa:

- 300.000 polígonos por segundo.
- Mapeado de texturas com mip mapping, correción de perspectiva, y 16 bit de profundidad de color.
- 60 fps inamovibles.
- 496x384p (24 khz).
- Hasta 39 ias en carrera.
- Sonido a 48 canales PCM y 44 Khz.

Que conste que yo me conformo con 50.000 polígonos, las mismas IAs que en Saturn, 60 fps constantes, y 0 pop up.

@Sexy MotherFucker esa rom que comentas la descubrí poco después de sacar las 120 estrellas sino recuerdo mal sólo salió en Japón y de lo que no estoy seguro al 100% es de si es el único caso o si hubo algún juego más que fue relanzado con soporte para el rumble.

Calculinho escribió:@Sexy MotherFucker esa rom que comentas la descubrí poco después de sacar las 120 estrellas sino recuerdo mal sólo salió en Japón y de lo que no estoy seguro al 100% es de si es el único caso o si hubo algún juego más que fue relanzado con soporte para el rumble.

Que yo sepa también salió el WaveRace64 con función de Rumble Pak, ambos los he jugado en emulador y van muy bien. Me hubiera encantado tenerlos en la época para mi N64.

Sexy MotherFucker escribió:Cifras del Daytona U.S.A de ARCADE para establecer más visualmente la comparativa:

- 300.000 polígonos por segundo.
- Mapeado de texturas com mip mapping, correción de perspectiva, y 16 bit de profundidad de color.
- 60 fps inamovibles.
- 496x384p (24 khz).
- Hasta 39 ias en carrera.
- Sonido a 48 canales PCM y 44 Khz.

Que conste que yo me conformo con 50.000 polígonos, las mismas IAs que en Saturn, 60 fps constantes, y 0 pop up.

Podemos comparar con F-Zero X que es lo más parecido
-50.000/60.000 polígonos por segundo
-Texturas con corrección de perspectiva, a 8 bits de color y sin mipmapping
-60 fps constantes
-Resolución 296x208p
-Hasta 29 IAs en carrera
-Sonido mono 16-bit PCM con un samplerate de 22,050 Hz
-Pop up/distancia de dibujo deficiente.

A ver, milagros no se pueden conseguir por mucho que falte potencial por exprimir de la consola o que se usaran herramientas y documentación deficiente. Se podrá recurrir a mil trucos y realizar un diseño soberbio para lograr resultados muy vistosos, pero si alguien se piensa que lo consiguieron profesionales durante 5 años trabajando a piñón (porque se hacían sus 14 horas diarias incluyendo fines de semana) lo van a dejar por los suelos cuatro aficionados en sus ratos libres (joder, suena muy duro, que no se me malinterprete) lo lleva claro.

No hablemos ya de hacer un juego completo. Goldfinger 64 nos ha llevado 6 años desde que se retomó el proyecto (9 años desde que comenzó Monkeyface) y ha tardado tanto porque la gente no profesional sólo puede dedicarle su tiempo libre y hay veces que no hay tiempo disponible o que necesitas/quieres dedicarlo a otra cosa. Yo modelé y texturicé los dos primeros niveles en unos seis meses consecutivos, acabarlos del todo me llevó varios días salteados durante dos años (pongamos dos meses más, la verdad es que no tengo forma de contarlo). Y eso que no hice la lógica del nivel, sólo me dediqué a colocar los objetos y los enemigos y decirle a SubDrag cómo quería que se jugaran las misiones para que él hiciera el trabajo. Luego estuve alrededor de un año con el nivel de Alps que al final no pude acabarlo, porque durante tres años apenas pude trabajar en el proyecto por motivos personales. Y me da mucha rabia no haberlo podido acabar después de tanto tiempo, porque el trabajo que hay en él es enorme (basta abrirlo con el Editor para comprobarlo) y todo iba a ir enfocado a hacer el cabra olvidándose de la misión.

Me parecería todo un logro que los esfuerzos de BMBx64 y la gente que programa en Nintendo 64 lograra sacar una demo jugable de lo que sea. Y si pudieran recrear cómo hubieran sido algunos juegos en N64 ya sea un circuito del mencionado Daytona USA aunque sólo estuviese el coche del jugador corriendo, o un Street Fighter/Tekken 3 con un escenario y dos personajes, o un combate del FFIX en el que se pudieran ver magias e invocaciones en acción... ya sería la leche.

@Sogun ¿Pero el F-Zero emplea filtrado bilineal no?

A ver, propongo el siguiente contexto:

- A TOMAR X CULO el buffer Z, filtro alguno, ni corrección de perspectiva, así auméntamos el fill-rate al máximo, y aprovechamos todos los ciclos en darle mambo al dibujado.

- Expansion pak; 8,5 MB de ram totales.

- Expectativas modestas; 320x224 (quitamos 16 líneas horizontales para aligerar algo la C.P.U), 50k de poly count, después de todo la N64 trabaja mucho mejor las superficies con unos pocos polígonos que la Saturn

- Nueva librería usada con tino por los mejores sceners.

¿De verdad es mucho pedir 60 fps y unos pocos coches en carrera bajo ese contexto?

Edit: ¿La N64 tienes fast y lo roms como la SNES?

@Señor Ventura
La librería va a ser muy rápida, he podido ver código fuente de la libultra por internet (la librería es gigantesca) y tiene mucho código en C, ficheros que datan 1994.. bastante genéricos, otros más optimizados, también tiene hilos y usa el RSP para formar comandos para el RDP, pero no se para en detalles.

Libn64 está programada a nivel de chip casi entera, ya hemos acabado la librería del RDP y todos los comandos no solo están a nivel de maquina, usan variables de 64bits donde sea necesario y buscando un equilibrio entre floats y ints, la CPU de N64 tiene 32 registros para coma flotante que si se usan de forma equilibrada incrementan el rendimiento.

En libdragon los rectángulos se hacen a precisión de enteros, ahora se pueden hacer en coma flotante, imagina un scroll, el RDP de N64 trabaja en coma flotante y puede subdividir pixels, sabes los planos de fondo que se mueven muy lento y parece que parpadeen? Ese desplazamiento se vería mucho más suave ahora.

Libdragon es la librería más lenta de las 3, ya has visto cual es su rendimiento.

Ahora estoy haciendo las funciones "user friendly", pero lo primero que quería probar es si ya van las texturas de 64x64 en 4bit y claro que sí, a la primera, con la de horas que perdí en libdragon.. en libn64 no hay varias capas por encima, lo que escribes va directamente a memoria.

--

Me interesa lo de los modeladores 3D para hacer juegos en N64 , en su momento hablamos de hacer compatible el formato obj, es el que uso para las extracciones y tendría muchísimo material para trastear con la máquina, pero sería cosa de ponerse.

La idea es que cuando todas las funciones RDP estén 100% testeadas, se empiece a migrar código al RSP, ahí si que se va a ver el verdadero salto de rendimiento con esta librería.

Un juego de carreras también creo que es de lo más sencillo para empezar, a mi me gustaría un FPS

BMBx64 escribió:La idea es que cuando todas las funciones RDP estén 100% testeadas, se empiece a migrar código al RSP, ahí si que se va a ver el verdadero salto de rendimiento con esta librería.

Como te gusta hacernos sufrir xDD

¿cabe esperar mas rendimiento del que hemos visto ya en juegos comerciales de la consola?.

Sexy MotherFucker escribió:- Expectativas modestas; 320x224 (quitamos 16 líneas horizontales para aligerar algo la C.P.U), 50k de poly count, después de todo la N64 trabaja mucho mejor las superficies con unos pocos polígonos que la Saturn

Eso son casi cifras del F-zero X, y si encima le quitas z-bffering, corrección de perspectiva, etc... iría sobrada.

@Sexy MotherFucker

Filtrado bilineal sí que usa. No hay ningún juego en N64 que no lo emplee salvo alguna textura muy concreta. Perfect Dark no usa filtrado bilineal en los edificios del primer nivel y desconozco si hay algún ejemplo más en texturas aplicadas a un polígono de una escena 3D.
Bueno, hay juegos que con trucos lo puedes quitar, aunque creo que no tienen ninguna mejora real en el rendimiento.

La corrección de perspectiva yo no la quitaría por nada del mundo. Es lo que te permite usar polígonos gigantes sin que den el cante. Siempre se ha dicho (aunque creo que es más una leyenda urbana que datos reales) que PS1 mueve 300.000 polígonos por segundo y N64 100.000, pero esa diferencia se va por el retrete cuando tienes que emplear cientos de polígonos en el escenario para disimular la falta de corrección de perspectiva.
El Z-buffer parece que hay métodos para evitarlo y que no se note cuanto apenas. No sé si se puede hacer para todo tipo de juegos, pero se consigue una mejora en el rendimiento importante.
El mipmapping no se usa tanto como parece, sobre todo porque algunos juegos utilizan texturas tan grandes que no lo admiten. No sé cómo afecta al rendimiento utilizarlo o no. Por ejemplo, una textura de 64x64 a 16 colores no puede usar mipmapping, pero una de 32x32 a 256 colores sí ¿Hay realmente diferencia cuando las procesan? ¿Si a la textura de 32x32 a 256 colores le quitamos el mipmapping se gana rendimiento? La verdad es que no tengo ni idea, pero la lógica me dice que cuanto menos datos y cosas haya que calcular sí que hay una ganancia en velocidad. Lo importante es que esta ganancia sea apreciable.

Luego respecto a los 60 fps, es muy complicado mantenerlos constantes. No me sé la jerga técnica, pero la N64 tiene como una especie de v-sync que hace que cuando el framerate no puede llegar a 60 fps baje de golpe a 30, y cuando no puede a 30, baje de golpe a 20, y luego a 15, 12, 10.... No puedes apurar a 60 fps y que si no llega baje a 55-50. Los saltos son muy notorios. Por eso Super Mario 64 funciona a 30 fps y Ocarina of Time a 20 fps, porque podrían en algunos lugares mejorar la tasa, pero estarían dando saltos continuamente. Desconozco si esta cosa se puede desactivar.


A mí lo que verdaderamente me encantaría sería un juego que abusara del streaming desde el cartucho para lograr lo que se hizo con el Soul Reaver en PS1: un mundo contínuo sin cargas ni fundidos en negro, en el que se puede incluso viajar entre dimensiones sin ningún tipo de transición. Vamos, es que me imagino un cartucho de 512 MB y el Expansion Pak siendo alimentado constantemente y lo que podría salir de ahí... Metroid Prime 64.
Factor 5 hizo eso mismo con el Indiana Jones and the Infernal Machine pero el juego seguía estructurado en niveles. No sé si hay algún juego de N64 que sea un mundo contínuo sin cargas.

para los que dicen que daytona no es posible en N64, solo dire esto:
https://www.youtube.com/watch?v=H-S0BwVQ5Vo

jordigahan escribió:para los que dicen que daytona no es posible en N64, solo dire esto:
https://www.youtube.com/watch?v=H-S0BwVQ5Vo

Creo que nadie ha dicho que no sea posible, lo que yo he discutido era que veía difícil un port 1:1 del arcade. Ya dije que superior al de Saturn seguramente, en cualquier caso creo que el RR64 que es también un juegazo va a 320x240-30fps y tiene menos IA. Tiene el modo 640x480 con el expansion pak y ahora mismo no lo recuerdo, pero casi seguro que iba peor si se activaba el high-res. Aunque una cosa a tener en cuenta es lo que han comentado arriba: 8MB de RAM usados en mejorar la fluidez, IA o lo que sea en lugar de subir la resolución puede salir algo muy interesante.

@Señor Ventura
Sí, libn64 va a tener un microcódigo programado en ASM para el RSP, Factor 5 tenía parcialmente un ucode de este tipo, Boss Studios también, esos juegos tenían un rendimiento por encima del resto y eso que eran cosas reprogramadas parcialmente de libultra.

La libultra base maneja 2 triángulos a la vez, el ucode de Krom maneja 8, la unidad vectorial de N64 tiene un registro de 128bits, 8 elementos de 16bits.

Luego libultra igual fue compilada con GCC 2.XX, ha llovido mucho de eso, n64lib usa GCC 7.XX con todos los parches que han aparecido en los últimos 20 años para incrementar rendimiento en los MIPS, además la librería es óptima.

El mayor problema de N64 es el filltrate, en ese caso también has visto un progreso en mis demos de libdragon, como usaba recarga inteligente de texturas o el recorte de zonas tapadas para ir mejorando la velocidad del scroll, los motores 3D antiguos no recortan zonas tapadas, las 3D estaban en pañales en aquel entonces, se puede hacer mucho mejor.

Igual que los modelados 3D, los del Mario de DS usan menos polígonos que el de Mario 64 y se ven menos cuadradotes, ya solo por como ha avanzado los conocimientos en 3D y las herramientas los juegos deberían verse mejor, claro que hay que meterle trabajo a eso.

A mi me gustaría aspirar siempre a 60fps

En los próximos días a ver si ya empiezo a subir una demo de un cubo 3D rotando.

BMBx64 escribió:@Señor Ventura
Sí, libn64 va a tener un microcódigo programado en ASM para el RSP, Factor 5 tenía parcialmente un ucode de este tipo, Boss Studios también, esos juegos tenían un rendimiento por encima del resto y eso que eran cosas reprogramadas parcialmente de libultra.

La libultra base maneja 2 triángulos a la vez, el ucode de Krom maneja 8, la unidad vectorial de N64 tiene un registro de 128bits, 8 elementos de 16bits.

Luego libultra igual fue compilada con GCC 2.XX, ha llovido mucho de eso, n64lib usa GCC 7.XX con todos los parches que han aparecido en los últimos 20 años para incrementar rendimiento en los MIPS, además la librería es óptima.

El mayor problema de N64 es el filltrate, en ese caso también has visto un progreso en mis demos de libdragon, como usaba recarga inteligente de texturas o el recorte de zonas tapadas para ir mejorando la velocidad del scroll, los motores 3D antiguos no recortan zonas tapadas, las 3D estaban en pañales en aquel entonces, se puede hacer mucho mejor.

Igual que los modelados 3D, los del Mario de DS usan menos polígonos que el de Mario 64 y se ven menos cuadradotes, ya solo por como ha avanzado los conocimientos en 3D y las herramientas los juegos deberían verse mejor, claro que hay que meterle trabajo a eso.

A mi me gustaría aspirar siempre a 60fps

En los próximos días a ver si ya empiezo a subir una demo de un cubo 3D rotando.

Es que es una pasada. Si la progresión se cumple aritméticamente, y siempre y cuando el fill rate aguante, es como si la N64 pudiese aspirar a manejar entre 300.000 y 400.000 polígonos a 15 o 20fps, y eso sin contar los avances con el multihilo que has mencionado.

75.000 a 100.000 polígonos a 60fps sería muy interesante, la verdad, pero claro, el entorno tendría que ser bastante simplificado de texturas y otros efectos... un conker sería jodido que aprovechase tanto esos avances con el cálculo de polígonos.

Que hardware tan complicado, y lo que hay que saber para dominarlo tiene tela. Con la game cube no tuve tantos errores de concepto jamás, pero con la n64 aún me cuesta no perderme ^^u

Bueno, yo estaré encantado de desempolvar la N64 y flashcard para catar cualquier demo en el futuro

Señor Ventura escribió:Que hardware tan complicado, y lo que hay que saber para dominarlo tiene tela.

Es que está mal diseñado de cojones, me atrevería a decir que hasta un desastre como Saturn tiene un diseño más amable, después de todo en esa consola si te limitas a las 2D la vida florece para el programador; pero es que en Nintendo 64 hasta para hacer un puto Cadillac & Dinosaurs hay que pelear.

Por eso la libn64 es una noticia fantástica.

@los sceners: Ni problemas de fillrate ni hostias; mandad al carajo de una vez el buffer Z y los filtros que hagan falta. Un bilinear, perspective correction, y a tirar palante como los de Alicante con la libn64.

Con la game cube no tuve tantos errores de concepto jamás, pero con la n64 aún me cuesta no perderme ^^u

Porque el cubito es una N64 sólo que bien diseñada xDD

Tanto hablar de Daytona y ha sido imposible no poner la Saturn un rato Sería la caña verlo en N64.

Una pregunta para los que domináis, ¿que tal hubiese movido la N64 esos juegos Arcade de lucha que tenían problemas en las consolas con soporte CD? ¿Flaquearía por otro lado?

Fue una pena no ver juegos de Capcom o SNK, uno se queda sin saber como hubieran sido éstas versiones.

https://www.youtube.com/watch?v=snK9TmKoTHY&t=222s

Sexy MotherFucker escribió:

Señor Ventura escribió:Que hardware tan complicado, y lo que hay que saber para dominarlo tiene tela.

Es que está mal diseñado de cojones, me atrevería a decir que hasta un desastre como Saturn tiene un diseño más amable, después de todo en esa consola si te limitas a las 2D la vida florece para el programador; pero es que en Nintendo 64 hasta para hacer un puto Cadillac & Dinosaurs hay que pelear.

Por eso la libn64 es una noticia fantástica.

@los sceners: Ni problemas de fillrate ni hostias; mandad al carajo de una vez el buffer Z y los filtros que hagan falta. Un bilinear, perspective correction, y a tirar palante como los de Alicante con la libn64.

Con la game cube no tuve tantos errores de concepto jamás, pero con la n64 aún me cuesta no perderme ^^u

Porque el cubito es una N64 sólo que bien diseñada xDD

Es que nunca en mi vida estuve interesado en la N64, y eso se nota ahora. Cuando te aprendes algo con gusto, resulta mas fácil.

Sin buffer z con el popping del arcade, y mas de 150.000 polígonos a 60fps, con corrección de perspectiva, suavizado de texturas, 20 coches...

Pero no se, viendo lo que se ha comentado del v-sync, a mi me llaman mas los 30fps, acercarme lo mas posible a los 300.000 polígonos del arcade, y así tener un juego que gráficamente luzca muy parecido a la recreativa. Creo que sería mas logro alcanzar ese nivel visual, que los 60fps con unos gráficos mas simplificados.

@BMBx64 se tiene que estar partiendo el culo de vernos opinar sin tener ni puta idea

En mi opinión creo que en este caso serían más sorprendentes los 60 fps que la fidelidad visual, por la naturaleza de la máquina básicamente.

@LINKr2 yo es que probé el Daytona del LIVE a 60 fps hace poco y la jugabilidad estaba a 1.000 jodidas millas del «Circuit Edition» a 25-30 fps de la Saturn, por lo que yo ya no quiero tocar un Daytona a menos de, como mucho, 50 frames. De hecho es que esta versión es incluso más rápida que la recreativa, ya que el ARCADE rula ade 57,XX hz, y el otro a 60.

Lista de prioridades en un racing game: VELOCIDAD »»» JUGABILIDAD »»» SONIDO »»» DETALLE GRÁFICO.

Sexy MotherFucker escribió:@LINKr2 yo es que probé el Daytona del LIVE a 60 fps hace poco y la jugabilidad estaba a 1.000 jodidas millas del «Circuit Edition» a 25-30 fps de la Saturn, por lo que yo ya no quiero tocar un Daytona a menos de, como mucho, 50 frames. De hecho es que esta versión es incluso más rápida que la recreativa, ya que el ARCADE rula ade 57,XX hz, y el otro a 60.

Lista de prioridades en un racing game: VELOCIDAD »»» JUGABILIDAD »»» SONIDO »»» DETALLE GRÁFICO.

La nintendo 64 no puede rular a 50fps en ntsc, por lo que dice el compañero pasa directamente a 30 si bajas 1 solo frame.

Daytona usa con 300.000 polígonos a 30fps, ¡aguafiestas! xD

Además, piensa que así si que puedes acumular tiempo de reloj en la cpu para manejar todavía mas coches... joder, y visualmente sería como el arcade, aunque con peores texturas.

60 fps sería ideal, pero también queremos ver algo gráficamente impactante y ahí es cuando notaríamos que nos faltan recursos por todos lados. Yo partiría de 30 fps a 320x240 que ya es más que el 99% del catálogo de la consola y luego buscaría meterle toda la traya posible con efectos de luz y de framebuffer por un tubo. También un uso inteligente de los mipmaps porque te permiten crear efectos gráficos como el agua del super mario sunshine.

Con imaginación se pueden hacer cosas muy chulas en N64. Un par de ejemplos de una demo que estaba haciendo. Esto corre en el GoldenEye:
-Fur shading: Cinco capas con cuatro texturas diferentes, aunque se podría conseguir el mismo efecto con la misma textura y diferentes grados de transparencia y pintado de vértices. En consola no funciona muy bien incluso con tan poca carga gráfica. Tengo que hacer más pruebas.


-Normal mapping: cinco capas con una textura de 64x32 a 4 bits de color. He hecho pruebas con mipmaps personalizados pero no se ve bien en consola cuando la textura se ve de canto. Lo más seguro es que haya que desactivar los mipmaps. No quedaría mal porque aunque se pixelice la textura a la distancia estaría simulando bordes de polígonos en cada ladrillo. También se podría probar con una textura de 32x32. El rendimiento no parece resentirse, lo trata como polígonos normales. Estamos multiplicando por 5 la carga poligonal en escenarios, por lo que habría que controlar dónde se usa.


-Vegetación: Cinco capas con dos texturas diferentes (en realidad una de suelo y otra para la vegetación). Es un paso intermedio entre los otros dos, el rendimiento no se ve afectado porque no se usan semitransparencias. Aquí el uso de mipmapping queda bien, pero necesitas texturas cuadradas porque sino queda raro.


-El agua del mario Sushine a la derecha, también corriendo en el engine de GoldenEye. Estoy intentando mejorar el efecto añadiendo envmapping o más mipmaps para que dependiendo del ángulo de visión o la distancia se vea más azul o más verde.


-Celshading: este truco dobla la carga poligonal, aunque quizás se pueda optimizar un poco. La linea negra se consigue crean un modelo ligeramente más grande, texturizado en negro e invirtiendo los polígonos. El efecto de la textura se consigue con environmental mapping (el mario metálico del Mario 64) y dependiendo de la textura se podría hacer mejor el efecto.
https://files.catbox.moe/xgv36b.mp4
Este vídeo no es mío, pero era una idea que me rondaba en la cabeza de hace tiempo tras ver este vídeo y me alegro que alguien lo haya probado.

Creo que sacando partido a las texturas, el mipmapping y el env mapping se podrían hacer más efectos chulos. Sólo es cuestión de que alguien dé con la tecla.

Esos efectos molan

La corrección de perspectiva, el filtro bilinear y la mayoría del RDP se activa en 1CYCLE, si quieres pintar en 3D hay que ir a este modo, porque en COPY no tendrías ni iluminación, ahí ya viene el sacrificio que es pasar de pintar 4 pixels por ciclo a solo 1, activar o no algunos efectos tiene un impacto menor en el rendimiento, dar transparencia es inapreciable por lo que vi, ya se le ha dado tiempo al chip para su buen funcionamiento.

El mip mapping requiere irse a 2CYCLE (0.5 pixels por ciclo, la mitad que el otro modo), se interpolan 2 texturas de distinto tamaño y todo lo que sea trabajar con 2 texturas a la vez requiere este ciclo, como el morphing o renderizar una superficie con 2 texturas como el suelo de Zelda OOT o para otro tipo de efectos.

Lo ideal es renderizar la mayoría en 1CYCLE y dejar 2CYCLE para efectos especiales, como partes metálicas reflectantes, el agua, etc, claro que en un mundo 3D si coges y pones la cámara en frente de una superficie de estas ya le estas pidiendo a la consola que pinte a pantalla completa en ese ciclo.

Un juego salta de 60 a 30 con doble buffer, con triple buffer no existe ese problema

Sogun escribió:60 fps sería ideal, pero también queremos ver algo gráficamente impactante y ahí es cuando notaríamos que nos faltan recursos por todos lados. Yo partiría de 30 fps a 320x240 que ya es más que el 99% del catálogo de la consola y luego buscaría meterle toda la traya posible con efectos de luz y de framebuffer por un tubo. También un uso inteligente de los mipmaps porque te permiten crear efectos gráficos como el agua del super mario sunshine.

Con imaginación se pueden hacer cosas muy chulas en N64. Un par de ejemplos de una demo que estaba haciendo. Esto corre en el GoldenEye:
-Fur shading: Cinco capas con cuatro texturas diferentes, aunque se podría conseguir el mismo efecto con la misma textura y diferentes grados de transparencia y pintado de vértices. En consola no funciona muy bien incluso con tan poca carga gráfica. Tengo que hacer más pruebas.


-Normal mapping: cinco capas con una textura de 64x32 a 4 bits de color. He hecho pruebas con mipmaps personalizados pero no se ve bien en consola cuando la textura se ve de canto. Lo más seguro es que haya que desactivar los mipmaps. No quedaría mal porque aunque se pixelice la textura a la distancia estaría simulando bordes de polígonos en cada ladrillo. También se podría probar con una textura de 32x32. El rendimiento no parece resentirse, lo trata como polígonos normales. Estamos multiplicando por 5 la carga poligonal en escenarios, por lo que habría que controlar dónde se usa.


-Vegetación: Cinco capas con dos texturas diferentes (en realidad una de suelo y otra para la vegetación). Es un paso intermedio entre los otros dos, el rendimiento no se ve afectado porque no se usan semitransparencias. Aquí el uso de mipmapping queda bien, pero necesitas texturas cuadradas porque sino queda raro.


-El agua del mario Sushine a la derecha, también corriendo en el engine de GoldenEye. Estoy intentando mejorar el efecto añadiendo envmapping o más mipmaps para que dependiendo del ángulo de visión o la distancia se vea más azul o más verde.


-Celshading: este truco dobla la carga poligonal, aunque quizás se pueda optimizar un poco. La linea negra se consigue crean un modelo ligeramente más grande, texturizado en negro e invirtiendo los polígonos. El efecto de la textura se consigue con environmental mapping (el mario metálico del Mario 64) y dependiendo de la textura se podría hacer mejor el efecto.
https://files.catbox.moe/xgv36b.mp4
Este vídeo no es mío, pero era una idea que me rondaba en la cabeza de hace tiempo tras ver este vídeo y me alegro que alguien lo haya probado.

Creo que sacando partido a las texturas, el mipmapping y el env mapping se podrían hacer más efectos chulos. Sólo es cuestión de que alguien dé con la tecla.

Flipa... ¿y dices que eso funciona en una nintendo 64?, ¿que no son ejemplos de por ahí para ilustrar el concepto? O_O

BMBx64 escribió:La corrección de perspectiva, el filtro bilinear y la mayoría del RDP se activa en 1CYCLE, si quieres pintar en 3D hay que ir a este modo, porque en COPY no tendrías ni iluminación, ahí ya viene el sacrificio que es pasar de pintar 4 pixels por ciclo a solo 1, activar o no algunos efectos tiene un impacto menor en el rendimiento, dar transparencia es inapreciable por lo que vi, ya se le ha dado tiempo al chip para su buen funcionamiento.

El ucode de este tal krom, ¿funciona calculando 8 triángulos en el modo 1cycle?. Si es así, entonces estoy todavía mas impresionado.

BMBx64 escribió:El mip mapping requiere irse a 2CYCLE (0.5 pixels por ciclo, la mitad que el otro modo), se interpolan 2 texturas de distinto tamaño y todo lo que sea trabajar con 2 texturas a la vez requiere este ciclo, como el morphing o renderizar una superficie con 2 texturas como el suelo de Zelda OOT o para otro tipo de efectos.

Lo ideal es renderizar la mayoría en 1CYCLE y dejar 2CYCLE para efectos especiales, como partes metálicas reflectantes, el agua, etc, claro que en un mundo 3D si coges y pones la cámara en frente de una superficie de estas ya le estas pidiendo a la consola que pinte a pantalla completa en ese ciclo.

Si es para superficies pequeñas, del tipo luna trasera de un coche de la nascar... ejem... ¿no sería una solución animar la textura que superponer 2 texturas?.

.

@BMBx64 pues entonces a darlo TODO en 1 cycle; 50-60k polycount, 320x224p, A TOMAR X CULO el buffer Z, y a quemar la libn64 cuando estén a tope las partes para manejar ASM.

@Señor Ventura y ni reflejos, dobles texturas, ni mariconadas; esas pijadas pa los millenials, el 2 cycle ni tocarlo. A Daytona U.S.A se viene a correr a 60 fps y a fliparlo con la música.

Tendríamos una versión ++ del de Saturn con filtro bilineal, corrección de perspectiva, y a 60 fps.

¡VamonoosssSSSS!

@Sexy MotherFucker


@Señor Ventura
Sí, 1cycle activa todas las propiedades 3D de la maquina, los 2 sirven para 3D.

2cycle se puede usar, no dejan de ser efectos a nivel de hardware, el agua de las olas de Waverace es 2cycle.

Ahora me he encontrado algo curioso, en CEN64 me están yendo los ejemplos, en cuanto los he probado en N64, me han empezado a cascar y he visto defectos en pantalla.

Resulta que con libn64 el código va más rápido que el chip gráfico, termina antes las tareas y lo corta a medias, así que se quedan texturas a medio pintar y cosas raras, hay una función interna de sincronización en el RDP, para esperar a que se cargue un tile, esperar al pipeline, etc..

Ahora estoy editando las funciones para usarlo, allá donde casca, lo cual es un buen indicativo de velocidad, Marathon por su parte acaba de implementar los contadores internos, así que pronto podré empezar los benchmarks.

Sexy MotherFucker escribió:@BMBx64 pues entonces a darlo TODO en 1 cycle; 50-60k polycount, 320x224p, A TOMAR X CULO el buffer Z, y a quemar la libn64 cuando estén a tope las partes para manejar ASM.

@Señor Ventura y ni reflejos, dobles texturas, ni mariconadas; esas pijadas pa los millenials, el 2 cycle ni tocarlo. A Daytona U.S.A se viene a correr a 60 fps y a fliparlo con la música.

Tendríamos una versión ++ del de Saturn con filtro bilineal, corrección de perspectiva, y a 60 fps.

¡VamonoosssSSSS!

Con tanto a tomar por culo descartando cosas yo me estoy imaginando un Daytona USA 64 así, pero a 60fps constantes que es lo importante: https://www.youtube.com/watch?v=q7Ow3w2DIRc

Sexy MotherFucker escribió:@BMBx64 pues entonces a darlo TODO en 1 cycle; 50-60k polycount, 320x224p, A TOMAR X CULO el buffer Z, y a quemar la libn64 cuando estén a tope las partes para manejar ASM.

@Señor Ventura y ni reflejos, dobles texturas, ni mariconadas; esas pijadas pa los millenials, el 2 cycle ni tocarlo. A Daytona U.S.A se viene a correr a 60 fps y a fliparlo con la música.

Tendríamos una versión ++ del de Saturn con filtro bilineal, corrección de perspectiva, y a 60 fps.

¡VamonoosssSSSS!

Wow wow wow wow wow, para el carro...



Me temo que no tenemos la misma visión a la hora de valorar que son unos buenos gráficos.

300.000 polígonos para que se vea como el arcade, aunque sea a 15fps, y luego si se quiere en las opciones rebajas la carga gráfica para que fluya a 30fps.

Para mandangas a 50k polígonos y 60fps ya tenemos el f-zero x, y mira que tristes se ven los escenarios, joder. A mi una versión del de saturn a 60fps no me diría nada, para eso ya tenemos el ridge racer, y quitando que no tiene nada de popping visualmente a mi no me impacta como un daytona.

Lo dicho, 300.000 polígonos, suavizado de texturas, corrección de perspectivas, mip mapping simulado con desplazamiento/animación de una única textura, 20 coches en pantalla, y a tirar millas (literalmente).

¡¡Ya puedo oir la sintonía!!, ¿no lo sientes?... es el... ¡¡PODERRRRRRRR DE CIENTOS DE MILES DE TRIANGULOOOOS!!.


Ahora si:

BMBx64 escribió:@Sexy MotherFucker


@Señor Ventura
Sí, 1cycle activa todas las propiedades 3D de la maquina, los 2 sirven para 3D.

2cycle se puede usar, no dejan de ser efectos a nivel de hardware, el agua de las olas de Waverace es 2cycle.

Ahora me he encontrado algo curioso, en CEN64 me están yendo los ejemplos, en cuanto los he probado en N64, me han empezado a cascar y he visto defectos en pantalla.

Resulta que con libn64 el código va más rápido que el chip gráfico, termina antes las tareas y lo corta a medias, así que se quedan texturas a medio pintar y cosas raras, hay una función interna de sincronización en el RDP, para esperar a que se cargue un tile, esperar al pipeline, etc..

Ahora estoy editando las funciones para usarlo, allá donde casca, lo cual es un buen indicativo de velocidad, Marathon por su parte acaba de implementar los contadores internos, así que pronto podré empezar los benchmarks.

¿Que teneis pensado hacer para la máquina una vez tengais pulido todo?.

P.D: Ya me he dado cuenta de que no quieres entrar al trapo con las especulaciones de un datytona usa para la n64. Si messi regateara como tu sería el mejor del mundo

@Señor Ventura un Daytona U.S.A a 15 fps es como un Mortal Kombat sin Fatalitys o un Mario Kart sin multijugador. ¿Para qué quieres tantos gráficos si falla lo PRINCIPAL? Porque entonces lo que buscas es una demo técnica, no un juego xD.

Es como el Star Fox funcionando al mismo framerate que el de la Megadrive xDD

Y F-Zero es un ejemplo de pésima útilización de la geometría para incluir la hostia de pilotos.

Esto es el segundo Daytona U.S.A de la Saturn:



60-70 k a 30 fps. Ahora imaginátelo a 60, menor pop-up, y las texturas filtradas; ¿Tan mal lo ves?

P.D: Y sin el Hi-res mode en entrelazado que usa la Saturn claro

Sexy MotherFucker escribió:60-70 k a 30 fps. Ahora imaginátelo a 60, menor pop-up, y las texturas filtradas; ¿Tan mal lo ves?

Lo veo mal incluso a la resolución del arcade original. Mira esos coches, necesitan mas carga poligonal.

Por lo menos los escenarios en movimiento se deja apreciar menos el descenso en la poligonización, pero el coche que manejas, y en segunda instancia los coches rivales, están a un mundo de la versión arcade.

Piensa que para que no se note una excesiva difuminación de las texturas, hacen falta muchos polígonos. La diferencia entre la texturización a 50k polígonos, y entre a 300k polígonos, puede ser incluso mas notoria que en la diferencia de geometría.

Prefiero un daytona usa con texturas mas parecidas a las del arcade, que no un daytona usa con borrones en lugar de texturas. Cuando hablamos de una model 2, y esa diferencia de memoria para texturas entre esta y la N64, esta última tiene que compensarlo con muchos polígonos para poner muchas texturas pequeñitas que permitan no emborronar demasiado.

Y con eso de paso consigues una poligonización como la del arcade. A 15fps lo vas a jugar mucho mas a gusto que un ridge racer 64 a 60fps.

Si me hablases de otro juego, pues vale, pero en el caso de un daytona usa, lo que tu expones sería un port (en el sentido de estra muy rebajado), y lo que yo expongo sería el mismo juego que el arcade pero con peor rendimiento.

Yo tengo claro con que me quedo.

@Señor Ventura ¿Pero tú has jugado al Daytona U.S.A alguna vez xD? Porque eso del tercer gif no es Daytona U.S.A; el éxito de su jugabilidad se basa en un alto frame-rate.

En serio, te hace falta el documental de DF.

Sexy MotherFucker escribió:@Señor Ventura ¿Pero tú has jugado al Daytona U.S.A alguna vez xD? Porque eso del tercer gif no es Daytona U.S.A; el éxito de su jugabilidad se basa en un alto frame-rate.

En serio, te hace falta el documental de DF.

Para mi es mas daytona usa el tercer gif, que el segundo gif.

Arcade:


Saturn:


Posible versión flipada, hypeada, y hoy por hoy imposible en N64 :

La verdad que lo que sea que decidan hacer las personas que están trabajando en libn64 seria genial , no importa si es un juego en 2d ya sea un run and gun , metroidvania ,mata marcianos o algo en 3d estaria muy chingon o como ustedes dicen, seria la leche!

Model 2 utiliza flat-shaded para iluminar los polígonos,y la N64 creo que puede usar gouraud,que da un aspecto más suavizado con menos polígonos,sin perdida de rendimiento,luego se puede usar LoD a varios niveles en los coches y en partes del escenario,que el escenario sea en la parte más lejana polígonos sin texturizar y con gouraud y texturizado en la más cercana a la cámara como hace Spyro de PSX o Vigilante 8, de todas manera me parece poquísimo hacerlo con 60.000-70.000 Pol/seg a 60 Fps da 1100 polígonos por frame cuándo el Daytona original pone 5.000 por frame ,la mitad con los truquillos de antes podría dar una imagen muy similar pero claro, a ver como haces que la N64 renderice 150.000 Pol/seg a 60 Fps, cuándo lo máximo que se a conseguido comercialmente es 120.000 Pol/Seg a 30 Fps.


Salud.

dirtymagic escribió:cuándo lo máximo que se a conseguido comercialmente es 120.000 Pol/Seg a 30 Fps.

Hola, ¿En qué título se llega a esa cifra?

Ya me han pasado un test de cubos, ahora es en flat sin iluminación, luego se irá probando con goraud, con z-buffer, texturizado, etc, se usan tablas precalculadas para ahorrar ciclos, la FP de la CPU para los cálculos, el RDP para pintar, cuando esté lista todo el cálculo de vectores se hará en el RSP.


Por lo visto el toolchain de windows está buggeado y da problemas, pondría la descarga de la demo 3D pero se cuelga en consola, el de linux va mejor, aplica muchas más optimizaciones y seguramente no se cuelga, mal porque yo uso windows.

No hay math.h de momento así que no puedo implementar algunas cosas, por otro lado ya tengo el contador de fps que marca un 3C lo que viene a ser 60fps, pero con el bug de windows igual no tiene mucho sentido hacer benchmarks de momento, pero más que contador de fps, lo que nos interesa es analizar en milésimas lo que tardan algunas funciones para poder optimizarlas.

@Señor Ventura
No puedo darte expectativas ni decirte como funcionará el Daytona si no sé todavía ni como va a ir la librería

Yo me encargo de la librería 2D, Krom de la 3D.

De todas formas tienes el ejemplo comercial de World Driver Championship:
- +120K~
- 320x240 (30fps, estables)
- Sin Z-buffer
- Cartucho de 16MB

BMBx64 escribió:No puedo darte expectativas ni decirte como funcionará el Daytona si no sé todavía ni como va a ir la librería

En la vida hay que pegarse ciertos lujos de vez en cuando, hombre... lo hago yo, que no tengo ni puta idea de nada, ¿y no lo vas a hacer tu, que eres un crack?


Gracias por la info... por cierto, ¿que tal incide en el fill rate si no texturizas los polígonos?. Me estaba fijando en ciertos detalles del virtua racing, y en como aplica un sombreado muy chulo sobre los polígonos según gire el coche hacia donde incide la iluminación.

Creo haberte leído decir que ese tipo de efectos lo podría hacer la n64 sin casi coste en el rendimiento.

BMBx64 escribió:De todas formas tienes el ejemplo comercial de World Driver Championship:
- +120K~
- 320x240 (30fps, estables)
- Sin Z-buffer
- Cartucho de 16MB

30 fps estables, que en idioma de la n64 a lo mejor significa que tiene un margen para añadir mas polígonos, porque no puede renderizar a 45 fps (por ejemplo).

¿Que opinas?, ¿un virtua racing con 100.000 polígonos planos a 60fps hubiera podido ser posible durante su etapa comercial?.

@BMBx64 según tu opinión; ¿En qué tipo de juegos crees que se hace imprescindible el buffer Z, en cúales no, y en qué otros depende de la habilidad del programador para reducir el sobredibujado?

Contexto N64 por supuesto.

P.D: World Driver Championship tiene algunos escrenarios que con varios coches a la vez marca distancia con sus homónimos en la consola. Aunque a mí Ridge Racer 64 me parece el gran tapado de los racing games dentro del sistema.

@Sexy MotherFucker BTW recordemos las cifras del Virtual Racing original

- 180.000 polígonos por segundo.
- 57 fps.
- 496x384p.
- Efectos de partículas y sombras.

Putas placas de SEGA en los 90, hasta la más débil representa un reto para las consolas de la época xDD

Por cierto, el world driver championship tiene algún efecto sutíl de mip mapping por ahí. Así que si mip mapping implica que todo se renderice a 2CYCLE, ahí hay una puerta abierta del tamaño de un puto arco iris... ¿no? xD

@Sexy MotherFucker El buffer Z es imprescindible si quieres reducir el popping todo lo posible, ese es el contexto en cualquier juego, pero en mi opinión, salvo que la escena no esté precalculada, no interesa tanto, porque te puedes encontrar con que usas una función que reduce enormemente el rendimiento para que luego a lo mejor no se le saque tanto provecho, y te encuentres con un popping brutal igualmente (o casi).

Seguramente se haya dicho ya, pero no lo recuerdo, ¿en cuanto reduce el rendimiento emplear el buffer z?.


Virtua racing a 60fps
https://youtu.be/XPhGKlPc-kQ?t=97

Señor Ventura escribió:¿Que opinas?, ¿un virtua racing con 100.000 polígonos planos a 60fps hubiera podido ser posible durante su etapa comercial?.

BTW en Saturn se hizo eso más o menos:

https://youtu.be/R3tdQVawMF8

A 320x240.

Edit:

por cierto, ¿que tal incide en el fill rate si no texturizas los polígonos?.

En Saturn hace subir el rendimiento una barbaridad, porque es el propio VDP1 el que renderiza y aplica texturas a los quads. Y en VR le va de perlas porque así se dedica a parir frames junto a la cpu subiendo el polycount, mientras que el VDP 2 pinta los marcadores y poco más.

Y a ver, en una hipotética conversión de Virtua Racing la Nintendo 64 no tendría que dibujar ningún tipo de texturas aparte de la de los marcadores, por lo tanto no tendría necesidad de aplicar NI UN PUTO EFECTO a nada, y en ese contexto con 62,5 Mhz de procesador gráfico da tiempo a pintar los fondos sin rastro de pop-up, y sin necesidad de Z-Buffer.

¿Ahí tampoco podemos aspirar a 180.000 polígonos PLANOS a 60 fps, aunque sea en 320x240? Joder vale que Daytona U.S.A es una utopía, pero esto lo veo más que razonable

@BMBx64 me vas hacer ir a acosar al Krom como acoso a exdevelopers en Beyond 3D, y no quiero

@Sexy MotherFucker Pues oye, un virtua racing con 90k polígonos a 60fps, pero a 640x480, si me parecería bastante impresionante.

Mejor 90k polígonos a 640x480 que 180k a 320x240.

.

Señor Ventura escribió:Mejor 90k polígonos a 640x480 que 180k a 320x240.

Cierto, el de Saturn impresiona pero peca en exceso de bordes de sierra.

No nos olvidemos del Expansion pak, un recurso muy práctico y asequible para todos.

@Calculinho gracias por el link. Ya lo daba por hecho de cualquier forma tras la anterior contestación de BMBx64.

Y sí, yo me quedé flipado con que el Conker's tirase a pelo sin expansión de ram en la consola.

Por cierto, el otro día decía que apenas conocía juegos 3D de la scene para consolas retro y ayer he visto el Xenocider para Dreamcast que por lo que veo es una especie de heredero del Sin&Punishment: https://www.youtube.com/watch?v=YMQzfE3dR3E

No es evidentemente un Shenmue, pero me alegra ver que se hacen cosas en 3D también.

@Calculinho a Chui, uno de los programadores de Xenocider, le hicieron una entrevista junto al resto del equipo en la hora retrona; y al ser a su vez Chui forero de Segasaturno, tuve el privilegio de «acosarle» a él y algún otro en persona en este hilo, acerca del apartado técnico del juego:

http://www.segasaturno.com/portal/chui- ... t9097.html



Según ellos está inspirado en Space Harrier.