Hilo de detalles y curiosidades de N64

Responder
1…11, 12, 13, 14, 15…72
Gran test , de hecho en el gif del amenecer los tonos naranjas se ven muy bien logrados en el agua, no cabe duda que eres hábil para programar, yo me metí a un curso de programación con Unity de nivel basico xD y valla que programar es algo muy complejo y ese programa facilita muchas cosas, supongo que en el 64 es mucho mas complejo, si se me llega a dar esto de programar me gustaría hacer un port de ghouls and ghost del arcade ya que el n64 si tiene madera para 2d por lo que eh visto en tus test.

La version de snes "super ghouls and ghost" nunca me gusto el personaje va muy lento y ademas sufre de bastantes ralentizaciones al haber muchos elementos en pantalla y fue la versión que se porto a PSX y sega saturn y nuevamente está en la mini snes. Las version de genesis y pc engine están muchoo mejor.
john D9 escribió:La version de snes "super ghouls and ghost" nunca me gusto el personaje va muy lento y ademas sufre de bastantes ralentizaciones al haber muchos elementos en pantalla


¿Esto lo afirmas porque lo sabes?, o porque lo dice mas gente.

Lo digo porque sus ralentizaciones incluso suceden con pocos elementos en pantalla... bueno, y por otro detallito sin importancia xD
Lo digo por que lo he jugado, no por que lo digan los demás , y es bastante notorio si juegas a otra version como la de genesis o pc engine en cuanto a fluidez, solo es mi experiencia, desconozco las razones de sus ralentizaciones
john D9 escribió:Lo digo por que lo he jugado, no por que lo digan los demás , y es bastante notorio si juegas a otra version como la de genesis o pc engine en cuanto a fluidez, solo es mi experiencia, desconozco las razones de sus ralentizaciones


Pues a eso me refería, que si desconoces el motivo de sus ralentizaciones, no puedes saber el motivo xD

Se deben a un bug del programa, y si parcheas la rom, desaparecen.
Me alegra que vuelvas BMB siempre es un placer leerte
@Señor Ventura
Lo de las ralentizaciones eran siempre en sitios determinados, yo lo usaba para esquivar asi que pense que era parte del juego en momentos dificiles
Han encontrado modelos, texturas e incluso animaciones del Dinosaur Planet en una versión kiosk de Star Fox Adventures.

https://assemblergames.com/threads/new-dinosaur-planet-finds.67250/#post-953023

Dentro del hilo hay algunas imágenes y siguen investigando y desarrollando herramientas para porder ver el contenido con más claridad. Es muy interesante.
@Sogun Gracias por el aviso veo que hay modelados de dinosuar planet como dices

¿No rulaba una copia que tenia uno al 60% o asi?
Señor Ventura escribió:
john D9 escribió:Lo digo por que lo he jugado, no por que lo digan los demás , y es bastante notorio si juegas a otra version como la de genesis o pc engine en cuanto a fluidez, solo es mi experiencia, desconozco las razones de sus ralentizaciones


Pues a eso me refería, que si desconoces el motivo de sus ralentizaciones, no puedes saber el motivo xD

Se deben a un bug del programa, y si parcheas la rom, desaparecen.

info de ese parche, plis!

edit: es este parche? https://www.romhacking.net/hacks/3473/
hyrulen escribió:info de ese parche, plis!

edit: es este parche? https://www.romhacking.net/hacks/3473/


Si, parece que si :)
Curioso lo del Dinosaur Planet [toctoc]
Es triste lo de Dinosaur Planet en N64, yo lo estaba esperando como agua de mayo y recuerdo que me fastidió bastante que no apareciera, sobretodo después de estar tan avanzado...
Me dan la oportunidad de comprar por 90€ una n64 pal frances con rgb y lumasync ¿Lo veis buena oferta?
Flash-Original escribió:Me dan la oportunidad de comprar por 90€ una n64 pal frances con rgb y lumasync ¿Lo veis buena oferta?


Es su precio. Normalmente yo las he visto por 80€ sin envío así que si por 90€ la tienes puesta en casa no es más caro de lo que se ve por ahí. No es una oferta tampoco, pero está dentro de mercado.
Creo que no se llego a poner el análisis de DF de Duke Nukem 64
https://www.youtube.com/watch?v=__OQDj0YbAQ

Lo he estado revisando y mete un poco la gamba en algunas cosas:

- El cartucho ocupa 8MB, igual que Super Mario 64 así que hay bastantes sacrificios, en lugar de la ciudad de fondo hay un cielo azul que es un simple degradado, faltan texturas, hay explosiones 3D con tal de no meter animaciones de bastantes frames, en realidad ralentiza por culpa de estas explosiones que son de varías capas de semitransparencia a tamaño completo si te acercas demasiado.

- La ausencia de música in-game, intentan colarlo como que la consola "no tiene chip de sonido", pero viendo la geometría que mueve el juego, con armas en 2D, enemigos a base de sprites y cajas simples como escenarios el RSP debe estar bastante parado, quizás a este juego le hubiera venido mejor un cartucho de 96Mbits (12MB).

- Ausencia de iluminación en los disparos, en 1CYCLE la diferencia entre colorear o iluminar una superficie es 0, el cálculo de las superficies adyacentes no debería suponer ningún problema, como se vio en Forsaken 64.
Imagen

Sin embargo el vídeo está bien si queremos curiosear cual es el rendimiento de las 3 versiones del juego, N64, Saturn y PSX, siendo la de N64 la más estable (entre 25-30fps usando triple buffering).

- En PSX habla de que corre todo por software y eso tampoco es cierto, para que PSX pinte en el framebuffer tiene que acceder mediante comandos de GPU, pues es la GPU la que accede a la VRAM.

Creo que podría empezar a hacer demos en 3D prescindiendo de momento del RSP, haciendo el cálculo en la CPU y dándoselos al RDP, de esta forma no sé cuanto podría mover pero sería interesante para ir dándole forma a la librería [360º]

Edit: La resolución parece ser de 276x208.
Imagen

Los extractos de geometría no salen bien, se come algunos detalles, pero diría que mueve salas de 300-400 polígonos.
Imagen
No conocía el port de Sega Saturn del Duke3D, gran port!
SIN AND PUNISHMENT
Vamos a darle un vistazo rápido, el programador principal es Atsutomo Nakagawa que también ha trabajado en juegos como Radiant Silvergun, Ikaruga, Sonic Jam o Nights.

Por lo visto hubo toda una serie de complicaciones en el desarrollo del juego, el cual empezó con tan solo 2 programadores y 2 diseñadores, dado la complejidad del chip RCP (que es un infierno) en lugar de usar un esqueleto para los modelados prefirieron el método más arcaico de unir polígonos, de hecho los personajes se ven bastante cuadradotes, hubo otras limitaciones a tener en cuenta como el tamaño de las texturas y el número de polígonos.

Jugablemente me recuerda a las fases de boss del Jet Force Gemini, nos podemos mover lateralmente mientras apuntamos, pero aquí hay mayor set de movimientos, como esquivos, salto doble o movimientos cercanos a modo de contraataque.
Imagen

Éste mando aparece en pantalla para indicarnos los controles en medio de toda la acción, así que van con cuidado con los modelados y luego te meten un mando de 1100 polígonos, bien.
Imagen

La resolución es de 296x224, el marco negro redondea a 320x240, supongo que intentaban mantener una tasa estable al mover tal cantidad de semitransparencias en pantalla.
Imagen

Uno de los efectos destacables es el blur, bastante presente en las escenas.
Imagen

En cuanto a los niveles son todo un alarde técnico, empezando desde el primer nivel, donde tenemos toda esa mata de hierbas con semitransparencia, lo cierto es que es algo poco visto en esa generación de consolas.
Imagen

El efecto es más simple de lo que parece, 2 superficies grandes persiguen al jugador, el suelo y el cielo, mientras que las hierbas son paneles planos que van adentrándose en la cámara, en el extracto salen en fila, pero probablemente funcionen por separado haciendo uso de una Z manual que no detecte el plugin, a la distancia en la nada, algunos enemigos acechando.
Imagen

En la ciudad también hay efectos llamativos como superficies que mueven las coordenadas de textura de forma distinta a la del polígono, como el reflejo de los cristales de los edificios, la acción no resulta comprometida con todo un festival de explosiones y efectos.
Imagen

Aquí podemos ver un movimiento de esquivo que hace uso de una particularidad de la consola, además de unas olas para hacer surf.
Imagen

Viene a ser un efecto de ruido de TV que incorpora el RDP usando el color combiner, por lo que sale gratuito, como el aquí replicado, pero configurado para que los puntos negros sean transparentes.
Imagen

Da la impresión de que las ondas se dividen en cientos de partículas, como curiosidad, las interferencias en el reloj de Goldeneye mientras estamos en pausa usan ésta misma configuración, jugando en emulador es probable que cosas como estas nos las perdamos.
Imagen

Quizás una de las fases más sorprendentes del juego, por lo dinámica que es y la distancia de dibujado.
Imagen

Finalizamos con una canción de la secuela en Wii.
https://www.youtube.com/watch?v=oUs3DgW0ayI

Y por cierto hay un fandub en castellano [hallow]
https://www.youtube.com/watch?v=3Wx0WpIzOMg
Muy impresionante gráficamente hablando el sin and punisment
Juegazo el Sin & Punishment. Aún lo conservo en perfecto estado, es uno de los dos únicos juegos japoneses que me compré en su época para Nintendo64 (me costó 7000 ptas que tampoco era mucho) y que me obligó a pillarme un cartucho adaptador tipo Passport Plus.
No me arrepiento la verdad, lo disfruté cada segundo y hasta mi hermano se lo vició xD Lo recomiendo a los compañeros del foro.
Vaya! Conocía el juego pero no había jugado, y dese luego no me esperaba esos efectos tan impresionantes, sobretodo el último en el que se ven los barcos, espectacular es poco!
Muy interesantes detalles del Sin and Punishment, BMBx64.

Es un juego que pude jugar gracias a la Consola Virtual de Wii y ahí perdieron los efectos de ruido de las texturas. Vamos, no me suena de nada haberlos visto.
El Super Mario 64 de la consola virtual tampoco es capaz de emularlos.

Es un efecto que en GoldenEye está bastante presente. Como has dicho en las interferencias del reloj, pero creo que también hay algo en las semitransparencias del humo y la niebla. Al menos con el plugin GlideN64 que te permite activarlo, se ve un efecto granulado que le da bastante personalidad. Pero quizás sea un efecto diferente, porque GlideN64 te hace el efecto de ruido a resolución interna y la verdad es que queda fatal (mucho mejor el efecto de Mario invisible con Glide64) y tanto la niebla como el humo se ven de cine.

Cuando juegué a Sin and Punishment tras varios años de opiniones muy favorables me quedé un poco chof. Algo similar me pasó con el Conker, que me había creado unas expectativas tan altas que no se cumplieron. Star Fox 64 me parece un juego superior. Aún así tiene partes brillantísimas como esa fase de los barcos y el jefe final del juego y recomiendo muchísimo jugarlo.
A su favor he de decir que sólo terminé el nivel de dificultad más sencillo y que el juego cambia mucho si juegas los más difíciles, añadiendo nuevos enemigos y patrones. Seguramente al nivel más alto de dificultad parezca un juego totalmente diferente, más profundo y disfrutable.


Una cosa que quería preguntarte hace tiempo, a ver si eres capaz de saber como funciona.
Hay un efecto de Ocarina of Time que resulta muy llamativo y no recuerdo haberlo visto en otros juegos (si hay más ejemplos me gustaría conocerlos). Por ejemplo, cuando muere Gohma o Ganondorf destruye las vidrieras del escenario donde te enfrentas a él, las texturas se "deshacen" píxel a píxel.

¿Cómo lo hacen? ¿Son varias texturas a modo de animación? ¿Una misma textura a la que editan la paleta para hacer los píxeles transparente?
Si se pudiese editar la paleta al vuelo y usar la misma textura (como los tiles y sprites de las consolas 2D) se podría ahorra espacio en el cartucho, la RAM y seguramente tiempo de proceso. También sería posible hacer animaciones en las texturas como estas con una sola imagen:
http://www.effectgames.com/demos/canvascycle/?sound=0
@Sogun
[beer]

Las texturas independientemente del formato que utilices se le tienen que pasar al chip gráfico como array de 1 dimensión, configuras el chip y le dices que es una textura de 16bits, ese array tendrá valores de 0 a 65535, donde cada uno será el color de una posición.

Ej. el chip entiende esto como una textura de 16bits (24x32):
uint16_t buffer_texture[768]={0}; // 24*32

Entonces a partir de aquí sabes que esta textura tiene 768 posiciones, es 24 de ancho, así que cada línea vertical suma 24, si ahora mediante código voy y digo:
0 , 1, 2, 3
24,25,26,27
48,49,50,51
72,73,74,75

Os escribo el número 3000 (supongamos que sale amarillo), pues obtendrás este resultado, a la textura le habrás pintado un cacho que coincide con esos números:
Imagen

Imagina que en lugar de poner el número 3000 pones el 0 que para el chip significa transparente, entonces allá donde modifiques el valor le estarás haciendo "huecos" a la textura.

Luego esto es en memoria RAM, tienes la copia original en el cartucho para restaurarla cuando quieras, el proceso es rápido, tan rápido que cabe en la cache de la CPU sin tener que hacer lecturas en la RAM, salvo cuando ya quieras mostrarla o tengas que recoger la de origen, si la textura se reutiliza los cambios se aplican en todas las superficies.

En cuanto a como las hacen desaparecer, bien podría ser una tabla que siempre elimina de la misma forma, podría ser una función aleatoria que se pone a borrar bloques, etc
Sogun escribió:Una cosa que quería preguntarte hace tiempo, a ver si eres capaz de saber como funciona.
Hay un efecto de Ocarina of Time que resulta muy llamativo y no recuerdo haberlo visto en otros juegos (si hay más ejemplos me gustaría conocerlos). Por ejemplo, cuando muere Gohma o Ganondorf destruye las vidrieras del escenario donde te enfrentas a él, las texturas se "deshacen" píxel a píxel.


No se deshacen pixel a pixel. De hecho cambian las texturas violentamente y luego caen al suelo. No le veo mayor truco.
@Diskover
Fíjate en el vídeo de la muerte de Ganondorf a partir del 1:59:33. Sobre todo cuando hace la transición en blanco se puede ver como los píxeles de las texturas van desapareciendo. No lo hacen de uno a uno o de forma aleatoria, sino que parece que lo hacen por grupos de colores, por eso preguntaba si se podía cambiar las paletas al vuelo y hacer que un color pasara a transparente para lograr este efecto.
Sogun escribió:@Diskover
Fíjate en el vídeo de la muerte de Ganondorf a partir del 1:59:33. Sobre todo cuando hace la transición en blanco se puede ver como los píxeles de las texturas van desapareciendo. No lo hacen de uno a uno o de forma aleatoria, sino que parece que lo hacen por grupos de colores, por eso preguntaba si se podía cambiar las paletas al vuelo y hacer que un color pasara a transparente para lograr este efecto.


Cambiar la paleta al vuelo se hace desde las 8bits, con que imagínate.
@Sogun
En el caso de N64 cada textura de 4 o 8bits requiere de una paleta cuando la cargas en TMEM, así que siempre van actualizadas a como estén sus tablas.

Quizás si que sean cambios de paleta en el caso del Zelda, es mucho más sencillo que lo que he puesto arriba, eso serviría por ejemplo para el editor del Top Gear Rally.
@Sogun lo que ves no son texturas esta programado asi,puedes verlo en la beta de ocarina of time en la habitacion
116 que se uso originalmente para ponerla encima de texturas animadas( que al final no se usaron para eso),
El Sin&Punishment lo jugué yo traducido hace poco y es genial ese juego, lo malo es que me petaron los joysticks en el boss del gif del efecto partículas en el agua y ya no pude avanzar más. Mis mandos van bien para juegos más tranquilos o con menos precisión, pero en el S&P se nota mucho el no tener un joystick preciso [+risas]
Ese efecto como de "punteado" de texturas es relativamente común en juegos de N64 y o bien es un efecto soportado por su Hardware o bien es relativamente fácil de programar.

[bye] [bye]
Sin and punishment fue un juego que disfrute de principio a fin, me impresiono visualmente hace uso de buenos efectos de luz no tan potentes como los de jet force gemini pero también se ven muy bien, el juego viene por defecto en la dificultad fácil , y aun así es desafiante, yo batalle para pasar el juego en normal y nunca pude pasar el juego en difícil, seguiré intentando que es un juegazo [risita] .

Sobre el efecto que mencionan del ocarina of time, se me viene a la mente el Castlevania como al momento de romper antorchas tiene un efecto similar.
Comentar que ya he dado el salto de libdragon a libn64.

Me topé con bugs imposibles de corregir, por la forma en que libdragon gestiona las cosas, como no conseguir de ninguna manera cargar 2KB de texturas en 4bits (64x64), creo que estaba perdiendo el tiempo.

Qué tiene de bueno libn64?

- Es muy rápida, CEN64 en mi portátil con ejemplos compilados en libdragon a duras penas alcanza los 30-40fps, los tests compilados con libn64 llegan a correr a 80fps, gran parte de la librería está escrita en ASM y hace exactamente lo que pide la consola.

- Multi hilo, en libdragon si tienes 10 enemigos hay que gestionarlos con 1 solo bucle, en libn64 puedes crear hilos independientes y de distinta prioridad, como darle prioridad a la música por encima de otras cosas para que no se entrecorte, sabéis de esos juegos que se cuelgan pero sigue la música? Algo así

- Soporta RSP, gestión transparente de cache, etc.

- N64 tool chain, no hace falta montar un entorno de trabajo, bajas los binarios de mips64, la librería, usas el cmd de windows mismamente, make en la carpeta de libn64, luego en los ejemplos, profit.

- Soporte, el autor de ésta librería es el autor de CEN64, ayer mismo hablé con él, más gente de la scene está interesada en ésta librería y no demasiado en libdragon.

Así que de momento estoy traduciendo todo lo que he hecho en el RDP para dárselo a libn64, la cual no tiene funciones de RDP.

Una de las primeras cosas que he creado es un controlador de comandos, el RDP empieza a leer en la dirección de memoria 0xA0100000 de la DRAM, el chip es lo suficientemente inteligente para concatenar comandos, así que no hay que indicarle cuando empiezan y cuando acaban.

Veréis que hay un salto de 4 en 4, esto es porque estamos formando comandos de 32bits, la memoria de N64 es de 9bits (1 reservado), así que la lectura es 32 / 8, hay que tener cuidado porque en la dirección 0xA0200000 empieza el framebuffer y no queremos pisar memoria, para ello habría que enviar 131K comandos por frame, cosa bastante improbable, esa última parte del código de igual forma es una chapuza, pero lo que vamos a hacer es NO usar la DRAM de la consola, se usará el RSP y la DMEM cuando esté todo traducido.

void rdp_command( uint32_t data )
{   
    uint32_t mem_address = 0xA0100000 | memory_pos;
    *(uintptr_t *)mem_address = data;
    memory_pos += 4; // 32 bit / 8
    memory_pos = memory_pos % 131072; // TOP LIMIT
}


En libdragon hay muchos más pasos para enviarle comandos a la consola:
static void __rdp_ringbuffer_send( void )
{
    /* Don't send nothingness */
    if( __rdp_ringbuffer_size() == 0 ) { return; }

    /* Ensure the cache is fixed up */
    data_cache_hit_writeback(&rdp_ringbuffer[rdp_start >> 2], __rdp_ringbuffer_size());
   
    /* Best effort to be sure we can write once we disable interrupts */
    while( (((volatile uint32_t *)0xA4100000)[3] & 0x600) ) ;

    /* Make sure another thread doesn't attempt to render */
    disable_interrupts();

    /* Clear XBUS/Flush/Freeze */
    ((uint32_t *)0xA4100000)[3] = 0x15;
    MEMORY_BARRIER();

    /* Don't saturate the RDP command buffer.  Another command could have been written
     * since we checked before disabling interrupts, but it is unlikely, so we probably
     * won't stall in this critical section long. */
    while( (((volatile uint32_t *)0xA4100000)[3] & 0x600) ) ;

    /* Send start and end of buffer location to kick off the command transfer */
    MEMORY_BARRIER();
    ((volatile uint32_t *)0xA4100000)[0] = ((uint32_t)rdp_ringbuffer | 0xA0000000) + rdp_start;
    MEMORY_BARRIER();
    ((volatile uint32_t *)0xA4100000)[1] = ((uint32_t)rdp_ringbuffer | 0xA0000000) + rdp_end;
    MEMORY_BARRIER();

    /* We are good now */
    enable_interrupts();

    /* Commands themselves can't wrap around */
    if( rdp_end > (RINGBUFFER_SIZE - RINGBUFFER_SLACK) )
    {
        /* Wrap around before a command can be split */
        rdp_start = 0;
        rdp_end = 0;
    }
    else
    {
        /* Advance the start to not allow clobbering current command */
        rdp_start = rdp_end;
    }
}


Otro detalle interesante que se preguntó en el hilo es si el programa se cargaba en memoria o se leía directamente del cartucho, el programa entero se carga en memoria, el SO de N64 reserva automáticamente el primer MB de RAM, en otras palabras, sería recomendable que un programa de N64 no ocupara más de 1MB en código, pues tras esa cifra la gestión se vuelve manual.

Un test donde cada rectángulo tiene su propio bucle y hilo.
Imagen
@Sogun @MyoCid

https://www.elotrolado.net/hilo_crees-que-half-life-puede-correr-en-nintendo-64_1901022#p1732581001
@BMBx64 Brutales noticias.

Con la libndragon ya hablábamos de pisarle los talones al daytona usa, ¿no?. No quiero ni pensar que clase de bicho es la N64 en realidad, pero teniendo en cuenta que es la arquitectura de la que desciende GC, no me extrañaría que todos estos años no hayamos visto mas que una fracción de su potencia.

¿Expectativas?.

Que me he perdido? [+risas]
@Señor Ventura
La libdragon lastraba mucho el rendimiento de la consola, demasiadas comprobaciones y esperas, en 3D creo que no habría sido muy buena.

La libn64 funciona como un reloj suizo, está llena de código ASM en las partes importantes para no desperdiciar ciclos, utiliza hilos para no dejar a la CPU quieta, luego el soporte de RSP permite escribir los comandos del RDP en la DMEM, si los escribes en RAM es más lento, haces más accesos y le quitas ancho al RDP.

Ayer conseguí portar un 80% del código RDP que tengo a la librería, pero aún queda trabajo, no tiene un sistema de archivos, ni input para controles ni otras cosas básicas, ni siquiera contadores internos para sacar un cálculo de fps.

La buena noticia es que ayer mismo marathon se puso con la librería y sacó un nuevo ejemplo, Krom está supervisando mi código RDP y añadirá su código RSP, el cual incluye el uso completo de la unidad vectorial y supongo que más gente se animará.
BMBx64 escribió:@Señor Ventura
La libdragon lastraba mucho el rendimiento de la consola, demasiadas comprobaciones y esperas, en 3D creo que no habría sido muy buena.

La libn64 funciona como un reloj suizo, está llena de código ASM en las partes importantes para no desperdiciar ciclos, utiliza hilos para no dejar a la CPU quieta, luego el soporte de RSP permite escribir los comandos del RDP en la DMEM, si los escribes en RAM es más lento, haces más accesos y le quitas ancho al RDP.

Ayer conseguí portar un 80% del código RDP que tengo a la librería, pero aún queda trabajo, no tiene un sistema de archivos, ni input para controles ni otras cosas básicas, ni siquiera contadores internos para sacar un cálculo de fps.

La buena noticia es que ayer mismo marathon se puso con la librería y sacó un nuevo ejemplo, Krom está supervisando mi código RDP y añadirá su código RSP, el cual incluye el uso completo de la unidad vectorial y supongo que más gente se animará.


Dios, quiero carnaza, ¿cuales son las expectativas?, ¿cual es el listón esperable en términos de rendimiento, hablando de juegos en concreto?.

Es que por lo que te leo, da la impresión de que existe un potencial que nunca se ha descubierto en ningún juego comercial de la consola, pero además dando la impresión de que realmente la diferencia puede ser mucha, y me pica la curiosidad sobre que cosas estais pensando los implicados en vuestros sueños mas húmedos XD
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
Conviene recordar que Daytona U.S.A son más de 300.000 polígonos por segundo, texturas con mip mapping, corrección de perspectiva, a 60 fps inamovibles, 496x384p, y 39 coches pilotados por la C.P.U...

Poca broma.
.
Que va, se a quedar corta para un daytona usa segurísimo, pero en algún punto se quedará XD
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
La verdad es que estaría chulísimo, yo me haría una repro:

Imagen

A 320x240, la misma cantidad de coches en carrera que en Saturn, 60 fps, y sin muchos filtros emborronando a mí ya me valdría.
Sexy MotherFucker escribió:A 320x240, la misma cantidad de coches en carrera que en Saturn, 60 fps, y sin muchos filtros emborronando a mí ya me valdría.


La gracia está en que precisamente con el multi hilo podría manejar bastantes coches, pero gráficamente no te vayas tan lejos.

320x240, y algo mas de 200.000 polígonos por segundo a 30fps ya sería una proeza, y lo que al menos si mejorarías es el popping. No creo que sea esperable pedirle mas a una nintendo 64 (que son mínimo 7000 polígonos por frame, tu, bastantes mas que los del arcade).
no digo que llegase a la calidad de la version arcade, pero creo que seria muy similar a la version de saturn, o tal vez, incluso mejor.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Señor Ventura Bff, pero es que los 60 fps deberían ser innegociables a estas alturas:

https://youtu.be/Tv_GQNh9D68?list=PLY9cZ8nX4xmlpd1RE8_toocbU9cND7U-A

Aunque sea a 50-70k poligon count, que son las cifras que maneja Saturn.
Sexy MotherFucker escribió:Aunque sea a 50-70k poligon count, que son las cifras que maneja Saturn.


Bueno, es que en su época un juego de N64 con 100.000 polígonos rondaba los 15 a 20 fps, y por momentos a veces menos.

Si realmente consiguen meterle mano a la consola sacando el doble de potencia de lo que dió en su día, que ya es ser optimista (el doble, nada menos), hablaríamos de poder rular un cruis'n usa a un frame rate como el de la versión arcade, y este a su vez da la impresión de necesitar el doble de potencia para alcanzar el refresco de un daytona usa, y no se si el juego encima tiene menos polígonos que el de el arcade de sega.

La verdad es que tengo ganas de saber cuales son las expectativas con la potencia que podrían sacar de esta máquina. Algo pensarán, digo yo...
Soy diseñador gráfico y modelador 3D.

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

[beer]
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
Señor Ventura escribió:y no se si el juego encima tiene menos polígonos que el de el arcade de sega.


Ni lo dudes:

Imagen

Cruis'n U.S.A abusa de elementos 2D para rellenar huecos en los escenarios (lo jugué tanto en casa como en ARCADE), mientras que Daytona U.S.A escupe 300.000 polígonos por segundo a 60 fps, con mip mapping y perspectiva corregida para las texturas:

Imagen

Madre mía es que la Model 2 era un bicho muy serio para la época incluso en su versión más low.

Y la Nintendo 64 salió con un hardware de 1993 en el 1996/97, castrado, mal diseñado y escasamente documentado.
cegador escribió:Soy diseñador gráfico y modelador 3D.

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

[beer]

me apunto !!!
yo tengo diseñado todo el primer circuito en el unreal engine.
Calculinho escribió:Yo no me estoy enterando demasiado del tema porque soy profano, pero mi experiencia es que desde ¿1993? Que existen consolas con capacidad de hacer juegos 3D ha habido mucho juego homebrew 2D para montones de sistemas, pero al menos yo cuando busco juegos 3D de la scene no he encontrado nada minimamente potable, lo digo porque mola un montón lo que se está comentando aquí, pero @Señor Ventura ya está salivando imaginando un port 1:1 del arcade Daytona USA [sonrisa]


Y no lo digo por crear desánimo, es mi experiencia de no encontrar nunca demasiada cosa. Si conocéis algún juego potente homebrew 3D para cualquier sistema pasármelo por privado porque me interesa mucho estas cosas, pero yo sólo encontré este potable: https://www.youtube.com/watch?v=__AlmfOWjUo


Normalmente ponerte a hacer 3d en maquinas viejunas es un poco infierno, entre que las apps actuales no estan pensadas para modelar en tan pocos poligonos, y además son mucho más complicados de debugar....

Yo tengo por casa la imagen virtualbox del systema de Psygnosis para PSX, y claro, está preparada para usar modelos hechos con el lightwave de 1995...
@Sexy MotherFucker Chacho, no se ve la imagen.

Si, por eso lo decía. La N64 necesita ser varias veces mas potente para poder acercarse siquiera a todo un daytona usa arcade.

Vería mas realista que consigan sacar la potencia escondida de la máquina para un cruis'n usa a 40/50fps, que otra cosa.

Lo que pasa es que si le sumas lo del multi hilo, puede ser el empujón final para algo ya un poquito más gordo.

¿El daytona usa de la saturn a 60fps, con corrección de perspectiva, suavizado de texturas, mas coches, y puede que algún polígono mas por ahí?... pues no me suena tan imposible si las expectativas se cumplen.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Señor Ventura qué dices xDDDD

El primer Daytona de la Saturn son 50.000 polígonos a 20 fps, 320x224, y pop-up salvaje. Aunque eso sí; dicen que es divertídisimo. Su continuación en la consola mejora el motor. Mírate el análisis de Digital Foundry joder, que para eso te lo colgué.

Las imágenes yo las veo.
Sexy MotherFucker escribió:@Señor Ventura qué dices xDDDD

El primer Daytona de la Saturn son 50.000 polígonos a 20 fps, 320x224, y pop-up salvaje. Aunque eso sí; dicen que es divertídisimo. Su continuación en la consola mejora el motor. Mírate el análisis de Digital Foundry joder, que para eso te lo colgué.

Las imágenes yo las veo.


Mucha tralla, o poca...
3586 respuestas
Responder
1…11, 12, 13, 14, 15…72
Volver a Consolas clásicas