Hilo de detalles y curiosidades de N64

@Sexy MotherFucker bueno, tiene sentido porque S&P a su vez bebe de Space Harrier. Pero pensé en el juego de N64 porque es en 3D

@BMBx64 Te haré una sugerencia; que tal un port del primer Starfox?, no es necesario que tenga una gran cantidad de polígonos ni grandes texturas, con que solo corra a 320x240 y tenga 60fps estable, sería más que suficiente .
Saludos.

@doblete miremos el primer Star Fox con overclock a 60 mhz para ambientarnos un poco:

https://youtu.be/sRm3gFikDBI

Aunque por seguir con los «what if» sobre juegos con polígonos planos desde placas ARCADE; ¿How about el STAR WARS de Model 1?

No soy nada amigo de los desbarres muy típicos de EOL de "¿Y si.....?", "¿Y si......?" especulaciones y demás conjeturas.
Siempre he defendido el dicho de "El movimiento se demuestra andando". Hablar las cosas, imaginar, etc. es muy sencillo, hacerlas, desarrollarlas, plasmarlas y más en una máquina antigua es enormemente complejo y tiene un gran mérito extra.
Por lo tanto las cosas que por ejemplo han hecho gente como @gasega68k y en este caso @BMBx64 me parecen sobresalientes y muy, muy meritorias. Soy programador y sé de lo que me hablo.
El pedirles ahora a esta buena gente que desarrollen un juego.... aunque sea el Virtua Racing, plano sin efectos o lo que quieras, sin aportar absolutamente nada por nuestra parte... me parece como poco descortés, vamos que gracias que no nos mandan a la porra.
Dejémosles tranquilos, que hagan sus avances y demos gracias a que los comparten con nosotros por aquí, para nuestro deleite.

Por otra parte en esa dinámica de suposiciones, ya he dicho que no soy amigo de ello, pero visto el nivel de especulación al que se ha llegado quiero decir que nunca he visto a una N64 alcanzar la carga poligonal de una PSX, el propio @BMBx64 ha destripado juegos, con wireframes, polycounts, etc. para más prueba. Me parece imposible que se llegue al nivel de carga del Gran Turismo 2 por ejemplo. Es más.... dudo que la N64 pudiera alcanzar el nivel de algunos juegos de Saturn, se me antoja muy complicado ver un Virtua Fighter 2, Last Bronx, Virtua Cop 2 o Sega Rally (p.ej.) (ojalá esté equivocado). Así que empezar a hablar de que si hacemos tal o cual cosa, ganamos un % de rendimiento y casi alcanzamos al model 2 y tal y cual pues.... lo estamos flipando chicos y más cuando el trabajo lo está haciendo otra persona.

Un saludo y dejemos trabajar a los que saben.


PD. El Virtua Racing de Saturn tiene muuchos menos polígonos que la recreativa, se ve a simple vista.

@sgonzalez nadie «pide» ni exige nada a nadie, simplemente divagamos y contrastamos con la opinión de esta «buena gente» porque precisamente sabe más que nosotros

Si los debates, o la propia vida ya puestos, tuvieran que ceñirse exclusivamente a lo demostrado y tangible, este mundo sería mucho más pobre. Sin soñadores no habría avance.

Así que perdónanos por tener curiosidad intelectual y conjeturar sobre tecnicismos en un hilo que se presta naturalmente a ello

.

Sexy MotherFucker escribió:@doblete miremos el primer Star Fox con overclock a 60 mhz para ambientarnos un poco:

https://youtu.be/sRm3gFikDBI

Ni a 60mhz es suave, ni lo sería a infinitos mhzs.

Lo que hacen es acelerar la velocidad de la acción, en lugar de aumentar la tasa de refresco.

Ahora, no se muy bien si realmente soportaría mas de 30 frames por segundo reales, porque todo eso tiene que pasar por el bus de datos, y no se si el DMA de la snes soportaría eso. Recordemos que estos juegos funcionan a base de pantallazo.

Que me corrija BMBx64, pero el sfx renderiza la escena en su ram (en el cartucho), y esa información luego es enviada troceada en tiles a la VRAM de la snes para conformar el line buffer con todo ya construidito.

Por ese motivo un SFX lo suficientemente rápido como para renderizar a 60 frames por segundo, sería inviable en la snes, porque los datos deberían ser enviados mas rápido.

Tal vez si el star fox funcionase exclusivamente a base de tiles de 3 colores, y sin ser a pantalla completa del todo (igual que ahora, vamos, aunque si que admitiría mayor superficie de pantalla), si podría alcanzarse esa tasa.

@Calculinho

Si bien, tengo pendiente meterme el fullset de PSX entre pecho y espalda como hice con el de N64

Ufff, buena suerte con esa librería de más de 2500 roms, aproximadamente el octuple que la de Nintendo 64

La cantidad de juegazos que hallarás será inversamente proporcional a la cantidad de juegos basura rollo «Barbie Cabalga Contigo» que también habrá xD

120K a 60 fps y a 512x480 ¡QUE PASADA!

Que yo recuerde el primer Tobal no emplea texture mapping en los luchadores, e imagino que esa resolución es un entrelazado.

@Señor Ventura deja de rayarte con tus parafilias con la SNES, ¡FANBOY DE LOS COJONES!

Contexto N64 chacho, céntrate xDD

Sexy MotherFucker escribió:@Señor Ventura deja de rayarte con tus parafilias con la SNES, ¡FANBOY DE LOS COJONES!

Contexto N64 chacho, céntrate xDD

Ahaaaaaa offtopic!!!!!

Yoqse tio, si hablas de star fox, pues vuelta y vuelta, no hay mas.

xDD

@Señor Ventura yo estoy esperando a que BMBx64 te conteste a lo de cúanto desahoga en rendimiento a la N64 el pasar de texturizar los polígonos.

A la Saturn una barbaridad en fillrate.

.

yo no se, teneis en cuenta el mapping los poligonos y tal y poneis el tope

La cosa es como lo programas para que haga tal cosa desde ¿2001? ha cambiado el algoritmo de hacer 3d ahora deberia ser con menor carga a la cpu, se puede comprimir las texturas mejores y casi sin perdida( mejor caso conker con sus 128x64) ahora mismo se podria meter hasta videos gracias a la codificacion MPEG el resident evil no se que usa

Ahora se podria hacer cosas mas brutales

Tened mas cosas en cuenta y no lo que veais en pantalla

En mi opinion claro

Yo por mi parte estoy trastocando con el zelda, la comunidad ha puesto mejoras (hack obviamente) lo pongo por si alguien le interesa

Mejoras/cambios:

-Ahora te puedes poner las botas de hierro sin dar al start dando al d-pad
-el inventario es infinito (BOOOOOOTELLLLLLLLLLLLLAS CON HAAAAAAAAAAAAAAAAADAS)
-El link Adulto puede tener todas las espadas (kokiri,maestra y biggoron)
-Editor in-gamae( mientras ejecutas el juego puedes hacer cambios desde el editor)
- El efecto cell-shading funciona en zelda
-El motor no tiene limite de poligonos (o al menos no he llegado)
-Se ha desbloqueado el fps (limitado a 20)

A lo mejor me olvido de algo pero por ahora eso

link del editor ?

.

@jordigahan
http://www.mediafire.com/file/1xryy24v7i0jyae/ZLE2.rar No he encontrado mas reciente,yo prefiero usar sharpocarina
ya que permite manejo de la IA,path-ID(jefe zora),iluminacion,etc (la semana que viene sale la 0.90 con mejoras)
https://www.youtube.com/watch?v=znjt6nQlnZc

@Calculinho tu estas hablando de poligonos, yo del algoritmo eso es mas cosa del modelador el propio ejemplo del mario como dices

N64 puede reproducir videos perfectamente en juegos
En juegos se puede la comprensionmpeg modificandola especificamente para el chip (r4300 era ¿no?) lo usa el conker aunque solo para los audios que lo pone en el inicio del juego (quizas aqui me estoy columpiando)

Lo de 64MB(512Mb) creo que es lo máximo(el unico mayor a 64 es el mario con 128mb y el editor es una M con la consola),ya que se queda dentro de la consola y el cartucho lo unico que hace es contacto
En tema de compresion es cierto puede ser un arma de doble filo pero por ejemplo esta el DDS que permite texturas muy buenas y comprimidas bien sin perder nada de calidad aunque use directx al final todo depende de como lo hagas
Tambien se podria hacer que el video no fuera un video sino programado lo cual ocuparia mucho menos

Al tuntun;
Imagen 640x480 1mb para video seria mucho mas dependiendo la duracion
Preprogramado 50kb idem ejemplo

Lo del codigo seria el sistema de colores de la n64 es mas largo,tedioso pero puede dar mejor resultado dejarias espacio para audios y otras cosas, o usarlo como si fuera un loading para despues de la escena

Todo depende de la perspectiva del que lo hagas

Lo de afectar al chip grafico, yo crei que afectaria a otras partes la descomprension quizas gpu(en modernos) en antiguos ni idea

Con cargas te refieres a cuando sales en el zelda el circulo negro, o a cual?

Me he leido todo este tema que hasta miro todos los dias por alguna info asi que no se si se me escapara algo

.

Me pierdo con los quotes

- El z-buffer se usa para algunas cosas, evitar un display list manual que debe ser manejado por el programador y que sea la consola la que controle la proyección con una serie de "sencillos" pasos, además se usa para evitar el "z-fighting", para entenderse si tienes un personaje y miras la unión de la cabeza y el cuello, sin z-buffer se va a liar a pintarse uno sobre el otro de forma continua, con el z-Buffer la maquina siempre los pinta de la misma manera y en el mismo orden, porque tiene información exacta de la escena 3D.

- Si la maquina es más rápida pintando en flat que en goraud o texturizado? Claro, solo generando los comandos para triángulos el goraud requiere 16 coeficientes más, otros 16 si lo quieres texturizado, 4 más para el z-buffer, todo ello para cada una de las superficies que existan en ese frame, a nivel de cálculo es más pesado, sin contar que si van texturizados necesitas ir cargando texturas de la ram a la cache, restando fillrate, quizás hay más diferencia entre texturizado a goraud que de goraud a flat.

El rendimiento, mirando el manual oficial unos 300K para el ucode Turbo, no especifica si son superficies pintadas o polígonos calculados, se entiende texturizados, ésta imagen ya se puso hace meses.


En flat deberían ser más, usa el modo blend para pintar colores en triángulos, no sé cual es la tasa de relleno de ese modo, tendría que mirar los manuales.
--

Lo de hacer juegos me gustaría primero empezar por 2D, por suerte he conseguido arreglar las texturas de 4bit en libdragon, así que ya puedo ir trabajando con sprites, montando las animaciones, etc mientras por otra parte avanza la libn64.

kusfo79 escribió: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...

¿Se puede conseguir de alguna fuente fiable?

viper2 escribió:

kusfo79 escribió: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...

¿Se puede conseguir de alguna fuente fiable?

Aquí está el tutorial para configurarlo:
http://www.psxdev.net/help/psyq_install.html

Si te fijas hay un link que te lleva a la pagina donde descargar la imagen de xp con este sistema:
http://www.psxdev.net/help/virtual_machine.html

@BMBx64

Respecto a lo de hacer un juego 2D ¿qué tenías pensado? Colaborar en la creación de un juego para N64 sería un sueño para mí

Mare mía el editor del Zelda... ¡¡ Cosa más rica para enredar!! @Flash-Original ¡Gracias por los links!

Señor Ventura escribió: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

El WDC ,sólo lo he visto en video de Youtube y tiene pinta de que no usa Mip-maping,pero seguro que usa 2 Cycle para los reflejos del coche.

Salud.

@Naitguolf De nada, si tienes alguna duda o algo dimelo

Por cierto la parte de creacion de videos es mas complicado se necesitan 4 mandos segun recuerdo y hacerlo en nemu
(edito 2 mandos)
El editor de videos esta dentro del juego

Te dejo esto porque no es algo que sea simple:
https://tcrf.net/Proto:The_Legend_of_Ze ... era_Editor

Algunas cosas tienes que meterle gameshark como pruebas de efectos de sonido,ambiental y demas. Aunque la mayoria lo que hace era enviar informacion por el puerto serie al ordenador

Paso una demo del e3 1998 del zelda
¿Veis alguna diferencia?
https://www.youtube.com/watch?v=jq5OoSlpu-w

kusfo79 escribió:

viper2 escribió:

kusfo79 escribió: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...

¿Se puede conseguir de alguna fuente fiable?

Aquí está el tutorial para configurarlo:
http://www.psxdev.net/help/psyq_install.html

Si te fijas hay un link que te lleva a la pagina donde descargar la imagen de xp con este sistema:
http://www.psxdev.net/help/virtual_machine.html

¡Muchas gracias!

cegador escribió:Respecto a lo de hacer un juego 2D ¿qué tenías pensado? Colaborar en la creación de un juego para N64 sería un sueño para mí

Pues en 2D de momento solo he estado haciendo pruebas, ahora que tengo arregladas las texturas 4bit (y la selección de paletas entre 16) ya puedo plantearme empezar algo en serio.

Creo que hacer una recreación de Castlevania SOTN me tomaría años, pero una del primer Metal Slug sería más llevadero y serviría como lanzadera de lo que se puede hacer en la consola o con las librerías, incluso en su estado más básico.

En 2D no creo que haga un proyecto original porque toma mucho tiempo hacer el pixelart y una cosa sencilla apenas animaría a la gente a probarla.

En 3D comentabas que también tenías experiencia no? Ahí si que me encantaría hacer algo nuevo y creo que sería la mayor diversión.

Flash-Original escribió:@Naitguolf De nada, si tienes alguna duda o algo dimelo

Por cierto la parte de creacion de videos es mas complicado se necesitan 4 mandos segun recuerdo y hacerlo en nemu
(edito 2 mandos)
El editor de videos esta dentro del juego

Te dejo esto porque no es algo que sea simple:
https://tcrf.net/Proto:The_Legend_of_Ze ... era_Editor

Algunas cosas tienes que meterle gameshark como pruebas de efectos de sonido,ambiental y demas. Aunque la mayoria lo que hace era enviar informacion por el puerto serie al ordenador

Paso una demo del e3 1998 del zelda
¿Veis alguna diferencia?
https://www.youtube.com/watch?v=jq5OoSlpu-w

Whoa whoa whoa... Interesantísimo. De nuevo mil gracias. Me encantará meter mano a ver qué puede sacarse

Yo si necesitais algo 2d o alguna cosa 3d puedo ayudar (paint tool sai,gimp,blender,sketchup)

Una cosa que necesito saber es el tema de la iluminación no se si tu sabras de esto @BMBx64 la que usa cada juego

https://youtu.be/RRKEU-oPBho no se si se notara ya que este video era para ver como funcionaba el cell shading con texturas lo digo porque le toco la iluminacion pero siempre me lo hace en las mismas partes de la textura y ademas los sitios con transparencia en vez de quedarse lo de detras sale el skybox(que a lo mejor es cosa mia de hacerlo mal)

BMBx64 escribió:El rendimiento, mirando el manual oficial unos 300K para el ucode Turbo, no especifica si son superficies pintadas o polígonos calculados, se entiende texturizados, ésta imagen ya se puso hace meses.

Entiendo, 300.000 polígonos con polígonos de "calidad playstation", y bastantes mas si son sin textura.

Vamos, que se come a la model 1 con patatas, aunque la falta de corrección de perspectiva sería una lacra importante, pero al carecer de texturas también pasaría mas desapercibido.

La corrección de perspectiva ,hasta donde yo sé sólo es necesaria cuando le pones una textura a un polígono,en flat y Gouraud no hace falta.

Salud.

Flash-Original escribió:Una cosa que necesito saber es el tema de la iluminación no se si tu sabras de esto @BMBx64 la que usa cada juego

No sabría decirte en el caso concreto del Zelda, deja que investigue un poco (aún tengo una comparación pendiente con el Majoras mask pero aún no me lo he pasado en 3DS )

Señor Ventura escribió:Entiendo, 300.000 polígonos con polígonos de "calidad playstation", y bastantes mas si son sin textura.

300K pero sin iluminación dinámica, me confirman por aquí que un 99,9% de los triángulos se pueden pintar con fill color, el 0,1% restante debe dividirse en 2, pero se puede evitar la representación de esa posición en concreto.

Eso haría que los triángulos en flat se pintaran a 4 pixels por ciclo, que es la velocidad de limpieza de buffer.


En copy también se puede texturizar, en libdragon puse un ejemplo hace poco de un triangulo texturizado, sin iluminación, sin corrección y sin efectos, ya que casi todo el pipeline está desactivado, muy similar a lo que comentan del Turbo3D, pero desconozco qué usa éste último.

dirtymagic escribió:La corrección de perspectiva ,hasta donde yo sé sólo es necesaria cuando le pones una textura a un polígono,en flat y Gouraud no hace falta.

Eso es, se puede usar a partir de 1cycle, pero llegados a ese modo la puedes desactivar si no hay texturas, ej. las superficies en flat o goraud para ser semitransparentes necesitarán 1cycle porque requieren del blender.

BMBx64 escribió:300K pero sin iluminación dinámica, me confirman por aquí que un 99,9% de los triángulos se pueden pintar con fill color, el 0,1% restante debe dividirse en 2, pero se puede evitar la representación de esa posición en concreto.

Que putada, sin iluminación dinámica... ¿adios gouraud?.

BMBx64 escribió:Eso haría que los triángulos en flat se pintaran a 4 pixels por ciclo, que es la velocidad de limpieza de buffer.

300.000 x 4= 1.200.000 ciclos.

¿Entonces si un polígono ocupa la mitad de la pantalla, significa que a 640x480 se lleva el solito 38.400 ciclos para ser dibujado?.

Sería un problema si algunos polígonos empiezan a requerir mas ciclos para ser pintados cuando el número total sigue siendo el mismo (300k polígonos), ¿como se soluciona ese problema?, porque bajaría el frame rate si no se hace.

BMBx64 escribió:En copy también se puede texturizar, en libdragon puse un ejemplo hace poco de un triangulo texturizado, sin iluminación, sin corrección y sin efectos, ya que casi todo el pipeline está desactivado, muy similar a lo que comentan del Turbo3D, pero desconozco qué usa éste último.

Cierto, parece que en COPY y en FILL a 16 bits se pueden dibujar 300k polígonos, ¿alguna diferencia mas entre ambos modos a parte del texturizado?.

@BMBx64 En 2D tengo experiencia profesional en Photoshop y podría aprender a usar cualquier programa necesario más especializado en pixel art.

En 3D también tengo experiencia profesional usando 3D Studio y MODO. Sobretodo entornos y arquitectura, modelado orgánico no he hecho.

No sé si te acuerdas de mí, pero hiciste un concurso en Vandal (en un hilo hermano de este) en el que premiabas con un cable s-video de N64 y yo lo gané

Cuanto más leo, más nervioso se pone mi flashcard

cegador escribió:En 2D tengo experiencia profesional en Photoshop y podría aprender a usar cualquier programa necesario más especializado en pixel art.

En 3D también tengo experiencia profesional usando 3D Studio y MODO. Sobretodo entornos y arquitectura, modelado orgánico no he hecho.

No sé si te acuerdas de mí, pero hiciste un concurso en Vandal (en un hilo hermano de este) en el que premiabas con un cable s-video de N64 y yo lo gané

Pues estaría genial tener alguien que se encargue de hacer modelados a medida de las especificaciones de la consola

Claro que me acuerdo, qué tal te fue el cable? notaste mejora?

Señor Ventura escribió:¿Entonces si un polígono ocupa la mitad de la pantalla, significa que a 640x480 se lleva el solito 38.400 ciclos para ser dibujado?.

Sería un problema si algunos polígonos empiezan a requerir mas ciclos para ser pintados cuando el número total sigue siendo el mismo (300k polígonos), ¿como se soluciona ese problema?, porque bajaría el frame rate si no se hace.

He portado la demo de los cubos a la libdragon para tener un poco más de control y poder probarla en hardware, hay que tener en cuenta que en libdragon se parte de un rendimiento de 500fps de una pantalla en negro, así que estos se pueden considerar buenos resultados para lo que es la librería.

Cubos en chiquitín, se usa blend, no fill color:


Más grandes.. vaya 1fps de diferencia, esto es porque aún con este tamaño todavía hace a tiempo lo que se le solicita y claro el RDP va en paralelo a la CPU.


Mec.. problemas, el cubo empieza a ser demasiado grande y el RDP empieza a tardar más que el código, hace esperar a la CPU para el siguiente paso, bajan los fps, esto es a grandes rasgos lo que pasa con el 3D en estas maquinas, por eso el número de polígonos en frío no importa tanto, sino más bien lo que está pasando en pantalla, que podías poner por un decir 500K triángulos de 8x8? Bueno pero en un juego 3D vas a estar dentro de un cubo o de varios del tamaño de la pantalla, así que las cifras bajan.


El test viene con cull back de serie, así que la cara que no se ve del cubo no se pinta, pero eso no es lo importante, imagina que cojo los 6 cubos y los pongo uno encima del otro, rotando de la misma forma, un engine óptimo solo pintaría 1 cubo, un engine antiguo de la época seguiría pintando los 6, pero sin la cara de atrás de cada uno, daría lo mismo que estuvieran juntos que separados.

Fill y copy no usan la mayoría del pipeline, por eso son tan rápidos.

.

@Calculinho Si era yo xD

Por poder se puede pero necesitas expandir la rom (depende en que mario party lo quieras meter) extraer los minijuegos de los otros y meterlos (a excepcion del menu antes del minijuego son scripts) ya que son pocas las diferencias de motor de uno a otro

Si sabes programar hay un programa que injecta asm a los juegos( hay un tutorial por ahi para mario 64 con el hello world)

En resumen por poder se puede, pero no me suena haberlo visto

¿Lo dices por el mario party top 100 de 3ds?

La verdad es que para eso habría que reprogramar bastante el juego.

Una comparativa de velocidad:


Libn64: 418-422fps (1A2-1A5)
Libdragon: 337fps

Los tests no son exactamente los mismos, en libdragon hay controles, pero bueno, si se quitan las esperas libn64 puede alcanzar los 975fps, pero no se asegura que lo que pinte sea el display list para ese frame, sin embargo creo que hay margen de mejora desde esos 418fps, el test muestra tearing, eso es porque no usa doble buffer, usa un único buffer.

Ya se está mirando sistema de archivos eficiente, con soporte transparente de gzip, libdragon tarda hasta 47 segundos en cargar 1400 archivos de 4KB, según una charla de ayer, programando bien para la maquina esa espera se reduciría a 1 segundo.

Para no saturar más el hilo sobre esto, ya iré poniendo noticias cuando la cosa esté más avanzada.

BMBx64 escribió:Mec.. problemas, el cubo empieza a ser demasiado grande y el RDP empieza a tardar más que el código, hace esperar a la CPU para el siguiente paso, bajan los fps, esto es a grandes rasgos lo que pasa con el 3D en estas maquinas, por eso el número de polígonos en frío no importa tanto, sino más bien lo que está pasando en pantalla, que podías poner por un decir 500K triángulos de 8x8? Bueno pero en un juego 3D vas a estar dentro de un cubo o de varios del tamaño de la pantalla, así que las cifras bajan.


El test viene con cull back de serie, así que la cara que no se ve del cubo no se pinta, pero eso no es lo importante, imagina que cojo los 6 cubos y los pongo uno encima del otro, rotando de la misma forma, un engine óptimo solo pintaría 1 cubo, un engine antiguo de la época seguiría pintando los 6, pero sin la cara de atrás de cada uno, daría lo mismo que estuvieran juntos que separados.

Fill y copy no usan la mayoría del pipeline, por eso son tan rápidos.

Es como si la nintendo 64 estuviese diseñada con cpu y gpu equivalentes, pero el downgradeo que sufrió durante su desarrollo se cargara ese equilibrio.

La cpu va a 93mhz, y el rdp/rsp a 62mhz. Por lo que cuentas, a la misma velocidad que la cpu pocos cuellos de botella debería sufrir (si hablamos de pintado).

93mhz para ambas, y una caché de texturas de 8kb, y esta máquina hubiera sido otra.

BMBx64 escribió:La verdad es que para eso habría que reprogramar bastante el juego.

Una comparativa de velocidad:


Libn64: 418-422fps (1A2-1A5)
Libdragon: 337fps

Los tests no son exactamente los mismos, en libdragon hay controles, pero bueno, si se quitan las esperas libn64 puede alcanzar los 975fps, pero no se asegura que lo que pinte sea el display list para ese frame, sin embargo creo que hay margen de mejora desde esos 418fps, el test muestra tearing, eso es porque no usa doble buffer, usa un único buffer.

Ya se está mirando sistema de archivos eficiente, con soporte transparente de gzip, libdragon tarda hasta 47 segundos en cargar 1400 archivos de 4KB, según una charla de ayer, programando bien para la maquina esa espera se reduciría a 1 segundo.

Para no saturar más el hilo sobre esto, ya iré poniendo noticias cuando la cosa esté más avanzada.

No, por favor, tu pon todo lo que puedas, que siempre es mas que bien recibido

¿Cuanto aumento de rendimiento sueles obtener con doble buffering?.

@BMBx64
Pasar de 47 segundos a 1 segundo es una mejora impresionante. A ver si lo conseguís.
De todas formas 1400 archivos de 4 KB son unos 5.5 MB ¿Estáis planteando todo con el Expansion Pak en mente?

No me imaginaba que el sistema de archivos pudiera ser tan determinante. Supongo que la forma de comprimir los datos también lo es.
Por ejemplo el juego Soul Reaver de PS1 que mencionaba antes, que en principio en N64 debería de ser la consola ideal para desarrollarlo por la cantidad de RAM y la velocidad de acceso al cartucho. En PS1 el CD está lleno de datos redundantes para hacer su acceso más rápido y supongo que estarán descomprimidos para evitar cualquier tipo de de procesamiento extra y hacer el streaming más fluido. ¿En N64 se podría seguir usando este streaming mientras se descomprimen los datos o es necesario hacer pausas hasta que se descomprime todo?
En GoldenEye me parece que en RAM no se carga todo el escenario al principio (porque no hay memoria suficiente) y va cogiendo los datos del cartucho según los necesita. Al cargar nuevos trozos de mapa se producen micropausas imperceptibles en consola, pero si hay mucho nuevo que cargar entonces ya se nota más y a veces se puede ver cómo aparece el escenario de la nada (esto más en hacks, pues los niveles originales están bien diseñados para que no ocurra). En Perfect Dark ya cargaban todo el nivel de una tacada en la RAM (de ahí el uso obligatorio del Expansion Pak) para evitar estos microcortes. Por eso los niveles tardaban tanto en cargar.

Me gustaría saber cómo de factible sería un juego que fuera haciendo streaming constantemente en pequeños trozos para que lo que se muestre en pantalla esté sacando el mayor provecho de los 8 MB de RAM (nada de texturas pre-cargadas de zonas del escenario que no se ven, o modelos de enemigos y sonidos que no aparecen en pantalla). No sería necesario que fuera un juego de mundo continuo como Soul Reaver (aunque sería donde más luciría), si no que te serviría para cualquier juego donde el escenario abarcara más de lo que se muestra en pantalla.

.

@Calculinho Seria mas rapido que se lo pidieras a alguien de la comunidad de mod el mario party, alguno se lo coge como un reto

es posible que te refieras al mismo que estan haciendo el editor de paper mario y mario kart?

@Flash-Original los que digo yo son mario party legacy, pero vamos que tampoco es plan ir pidiendo que trabajen para mi. Lo preguntaba porque como vi el editor del Zelda, a lo mejor ya existía algo como lo que yo busco.

@Calculinho empieza toquetando un poco esto es lo mas parecido que hay aunque no puedes cambiar los minijuegos en el futuro puede que se pueda:

https://github.com/PartyPlanner64/PartyPlanner64

https://www.youtube.com/watch?v=_PyhmEdD7oc

Dejo aqui un video que encontre de juegos cancelados:

https://www.youtube.com/watch?v=mLlhhmedGaE

@Flash-Original gracias por el editor, no parece excesivamente complicado así que igual intento hacer un tablero que todas las casillas sean un minijuego que a mis amigos lo que les cansa de los tableros es que a veces hay muchas tiradas sin "jugar" a nada.

Sobre el vídeo, hay muchos que no me llaman nada la atención, pero el catálogo de N64 hubiera sido redondo si hubiese recibido antes del 2000 sólo Metroid 64, Mother 3, esa expansión del Mario 64 y el Dinosaur Planet.

Y añado el Animal Crossing que salió en Japón por el 2001 (muy tarde evidentemente) y que en occidente nos llegó vitaminado para GameCube. El de N64 tiene traducción al inglés y le he estado un buen rato, ese juego creo que hubiera triunfado si saliese aquí en el 98 o 99 porque lo del ciclo día/noche con calendario y eventos según la época del año era algo muy novedoso al coincidir con las festividades de la vida real.

BMBx64 escribió:

cegador escribió:En 2D tengo experiencia profesional en Photoshop y podría aprender a usar cualquier programa necesario más especializado en pixel art.

En 3D también tengo experiencia profesional usando 3D Studio y MODO. Sobretodo entornos y arquitectura, modelado orgánico no he hecho.

No sé si te acuerdas de mí, pero hiciste un concurso en Vandal (en un hilo hermano de este) en el que premiabas con un cable s-video de N64 y yo lo gané

Pues estaría genial tener alguien que se encargue de hacer modelados a medida de las especificaciones de la consola

Claro que me acuerdo, qué tal te fue el cable? notaste mejora?

Sí noté mejora con el cable, claro... lo que pasa es que le he sacado poco provecho . Ahora me viene de camino un everdrive y voy a quemar la N64

Respecto a lo de modelar a medida de N64 me encantaría

@cegador
Guay , con el Everdrive si, la mejor inversión

Sogun escribió: ¿Estáis planteando todo con el Expansion Pak en mente?

Esa es una buena pregunta, por comodidad sería mejor hacer los proyectos en 8MB y creo que hoy en día quién sigue dándole a una N64 muy seguramente se ha pillado algún Expansion pak, por ejemplo el Metal Slug, mucho más sencillo a 8MB que pensando en 4.

Sogun escribió:¿En N64 se podría seguir usando este streaming mientras se descomprimen los datos o es necesario hacer pausas hasta que se descomprime todo?

Ayer hablé con Marathon y ya está trabajando en un sistema de archivos, streaming en segundo plano es posible usando hilos, en libdragon cualquier lectura paraliza todo el programa, ahora imagina lo que pasa cuando reproduces archivos en streaming como el ogg.

El gzip lo ha descartado porque es demasiado pesado para la consola, supongo que por la descompresión en tiempo real, en una pantalla en negro no habría problema de esperar 1 o 5 segundos.

La velocidad de lectura se espera de al menos 4mb/s, que es lo que suelen alcanzar los juegos comerciales, libdragon eran unos... ¿100-150kbs? algo mejor en carga secuencial imagino.

Señor Ventura escribió:¿Cuanto aumento de rendimiento sueles obtener con doble buffering?.

Solo he usado doble buffer, en libn64 aún no he probado, pero no es por cuestión de rendimiento, sino para evitar tearing y otros defectos.

@BMBx64 seguramente ya te lo preguntaron, pero lo máximo que detecta o maneja la N64 de RAM son los 8 megas finales que nos vendieron o hoy en día sería posible fabricar un expansion pack de mayor capacidad y que lo reconociese la máquina? Ya sé que nadie se va a poner a fabricarlo, pero es por saber los límites de la máquina.

@Calculinho Recuerda que parte de la RAM esta reservado para el sistema o sea no hablamos de 8mb reales

Por cierto ya salio nueva version del editor de zelda por si alguien quiere probar:

https://mega.nz/#!aJQlzJzT!61Ib1EkMPd97 ... JzA4VthXR8 incluye el codigo fuente por si alguien quiere probar a modificar o ver un poco como funciona el tema del motor del zelda

Esto es todo los cambios que han habido a lo largo del editor


La version original del editor esta echo por xdaniel y a parte de la 0.71 esta a cargo de Nokaubure

@Flash-Original creía que en consolas (descartando las actuales claro) una vez lanzado un juego todo el hardware se empleaba en dicho juego, de ahí las diferencias en especificaciones de hardware para PC para un mismo juego.

En cualquier caso siguen siendo 8mb totales los que tiene la máquina, independientemente de para que los use. Mi pregunta es si la placa está preparada para reconocer expansiones mayores.

Calculinho escribió:seguramente ya te lo preguntaron, pero lo máximo que detecta o maneja la N64 de RAM son los 8 megas finales que nos vendieron o hoy en día sería posible fabricar un expansion pack de mayor capacidad y que lo reconociese la máquina? Ya sé que nadie se va a poner a fabricarlo, pero es por saber los límites de la máquina.

Según tengo entendido podría manejar un total de 16MB de RDRAM., pero como comercialmente solo llegaron a 8MB pasa como con los 64MB de la rom.

En cuanto a la memoria disponible, el SO de N64 busca el boot al arrancar, el kernel de la libn64 son 16KB si no estoy equivocado, más el programa entero que se carga junto a las librerías en el primer 1MB de la consola.

Framebuffer aparte, que pueden ser 300KB si la pantalla es de 320x240 con doble buffer.