Hilo de detalles y curiosidades de N64

.

@BMBx64

Buff, sí. Meter un juego de 28 MB en un cartucho de 8 MB hubiera sido bestia. ¿cómo se sabe cuánto de una ROM está dedicado al sonido/música?

El de Super Nintendo ya ocupa 4 MB por lo que estoy viendo .

.

cegador escribió:Era lógico sacarlo en Super Nintendo: tenía 50 millones de potenciales clientes frente a N64 que estaba empezando.

Si pero posiblemente hubieran rascado mas ventas en N64 dado que no había mucha competencia 2D en la consola por lo que hubieran ido por la libre y la conversión no hubiera sido tan complicada, dudo que las ventas que tuvieron en supernes les haya compensando el trabajo e inversión que tuvieron que hacer para meterlo en un cartucho de supernes.

.

@Calculinho En eso tienes razón, N64 no se vislumbraba como una consola para juegos 2D por lo menos no en sus primeros años, cualquier apoyo hubiera fracaso.

@BMBx64 Si mal no recuerdo las roms pesaban tanto por el encriptado.

Señor Ventura escribió:@BMBx64 Si mal no recuerdo las roms pesaban tanto por el encriptado.

En castellano se dice cifrado, encriptado es un anglicismo.

Freestate escribió:

Señor Ventura escribió:@BMBx64 Si mal no recuerdo las roms pesaban tanto por el encriptado.

En castellano se dice cifrado, encriptado es un anglicismo.

La persona de LOPD me tiene loco con tanto encriptado...y mira que se lo he dicho, encriptar es meter en una cripta.

Perdón por el off-topic.

Y usar un anglicismo está mal, ¿por?.

http://dle.rae.es/srv/fetch?id=FABu3oz

.

Una cosa que me llamó la atención desde que lo vi en Super Mario 64 es lo raro que realiza las diagonales la N64 cuando se trata de sprites:

Miras esta foto del snowboard kids, las diagonales en un sentido están bien,pero las otras,son lineas rectas que hacen escalones más que diagonales xD.

Esto por qué pasa?siempre me ha intrigado, la verdad..

@hyrulen
Eso es por el filtrado bilinear que aplica la N64 a las texturas, que lo hace de forma "especial" para ahorrar recursos.
No sé cómo funciona técnicamente, pero el filtrado bilinear que se realiza normalmente lo que hace es coger un píxel y luego los 4 adyacentes (arriba, abajo, izquierda y derecha) y te suaviza la transición entre ellos.
La Nintendo 64 para ahorrar recursos lo que hace es coger 3 píxeles adyacentes (parece que son arriba, derecha, abajo) para calcular estas transiciones y por eso se generan esas transiciones diagonales en las texturas y sprites escalados.

No sé si la Nintendo 64 puede hacer un filtrado bilinear de 4 puntos, aunque supongo que se podría programar. De todas maneras este tipo de efecto le da un aire característico a los juegos corriendo en una Nintendo 64 y en ciertas ocasiones lo prefiero (sobre todo cuando la textura está muy estirada). Hay algunos plugins gráficos como el GlideN64 que te permiten usar este filtrado más simple.
También puede ayudar a evitar pixelización en ciertas textuas que contienen lineas diagonales si se saben alinear con el filtrado; pero en el sentido contrario te deja unos "escalones" de píxeles muy feos así que realmente acaba siendo mejor el filtrado bilinear de 4 puntos. En Perfect Dark había un punto en el que esto se veía a la perfección. A ver si saco una foto.

EDIT

Nintendo 64 real. Se trata de la misma textura espejada. En la derecha de la imagen la dirección de las diagonales de la textura y el sentido del filtro coinciden y se ven las lineas rectas. En la parte izquierda ocurre todo lo contrario y se ve un escalonado muy feo.


Emulador. Siempre se va a ver un escalonado cuando la textura tenga lineas diagonales, aunque no será tan evidente como en el caso anterior.


También existe una evolución del filtrado bilinear que tiene en cuenta los 8 píxeles que rodean al píxel en cuestión llamado filtrado bicúbico. Da mejores resultados en imágenes orgánicas, pero genera bordes borrosos cuando la textura de compone de líneas rectas ortogonales.

Señor Ventura escribió:El fatal fury special de snes necesita hacer exactamente lo mismo que lo que causa las congelaciones en el sfa2, y sin embargo nadie se ha percatado nunca.

¿Qué?. Dónde has leído que el FFS de SNES emplea algoritmos de descompresiòn, ¿?. Porque no me suena nada, más teniendo en cuenta que a la rom PAL le recortaron alegremente 8 megabits por motivos de precio. Lógicamente no me estoy refiriendo al sonido.

@BMBx64 en una hipotética conversión de SFZ2 a N64 el único problema potencial a nivel gráfico sería solucionar el tema de la resolución horizontal, de 384 líneas en CPS2. ¿Cúal es el ratio progresivo qué más se le acerca en Nintendo 64?. ¿320?. En cualquier caso en 1996 eran tan obtusos en la gran N que hubiesen insistido en que el juego llevase un innecesario filtro bilineal de serie

Sogun escribió:@hyrulen
Eso es por el filtrado bilinear que aplica la N64 a las texturas, que lo hace de forma "especial" para ahorrar recursos.
No sé cómo funciona técnicamente, pero el filtrado bilinear que se realiza normalmente lo que hace es coger un píxel y luego los 4 adyacentes (arriba, abajo, izquierda y derecha) y te suaviza la transición entre ellos.
La Nintendo 64 para ahorrar recursos lo que hace es coger 3 píxeles adyacentes (parece que son arriba, derecha, abajo) para calcular estas transiciones y por eso se generan esas transiciones diagonales en las texturas y sprites escalados.

No sé si la Nintendo 64 puede hacer un filtrado bilinear de 4 puntos, aunque supongo que se podría programar. De todas maneras este tipo de efecto le da un aire característico a los juegos corriendo en una Nintendo 64 y en ciertas ocasiones lo prefiero (sobre todo cuando la textura está muy estirada). Hay algunos plugins gráficos como el GlideN64 que te permiten usar este filtrado más simple.
También puede ayudar a evitar pixelización en ciertas textuas que contienen lineas diagonales si se saben alinear con el filtrado; pero en el sentido contrario te deja unos "escalones" de píxeles muy feos así que realmente acaba siendo mejor el filtrado bilinear de 4 puntos. En Perfect Dark había un punto en el que esto se veía a la perfección. A ver si saco una foto.

EDIT

Nintendo 64 real. Se trata de la misma textura espejada. En la derecha de la imagen la dirección de las diagonales de la textura y el sentido del filtro coinciden y se ven las lineas rectas. En la parte izquierda ocurre todo lo contrario y se ve un escalonado muy feo.


Emulador. Siempre se va a ver un escalonado cuando la textura tenga lineas diagonales, aunque no será tan evidente como en el caso anterior.


También existe una evolución del filtrado bilinear que tiene en cuenta los 8 píxeles que rodean al píxel en cuestión llamado filtrado bicúbico. Da mejores resultados en imágenes orgánicas, pero genera bordes borrosos cuando la textura de compone de líneas rectas ortogonales.

¿Tal vez se pueda programar que tres puntos escoger para filtra la textura?

Salud.

Sexy MotherFucker escribió:

Señor Ventura escribió:El fatal fury special de snes necesita hacer exactamente lo mismo que lo que causa las congelaciones en el sfa2, y sin embargo nadie se ha percatado nunca.

¿Qué?. Dónde has leído que el FFS de SNES emplea algoritmos de descompresiòn, ¿?. Porque no me suena nada, más teniendo en cuenta que a la rom PAL le recortaron alegremente 8 megabits por motivos de precio. Lógicamente no me estoy refiriendo al sonido.

No te refieres al sonido, pero es lo que causa las congelaciones, que es lo que estoy comentando. La compresión de la rom no tiene nada que ver aquí.

@Señor Ventura pero es que ten en cuenta que a nivel de foro estás hablando de un juego que emplea el chip SDD1, que se dedica sobre todo a descomprimir informaciòn gráfica. Lo digo porque metidos en contexto pareces un fanboy que está diciendo que;«;¡Já! ¡La SNES a pelo hace lo mismo que el SDD1 y sin congelamientos!», poniendo como ejemplo el Fatal Fury Special, cuando en realidad podrías haber puesto el ejemplo de casi cualquier juego de SNES ya que el spc700 opera igual con los samples para todos.

Y es que encima añades un; «y nadie se percató nunca, ¿Eh?». Dando como más misterio y rimbombancia al asunto, aunque esa no fuese tu intención.

Yo desde luego te he malinterpretado (ya te conozco y sé de qué vas para bien), pero creo que das motivos a veces a que se te tache de tal o cual.

@Sexy MotherFucker Si, van a ser culpa mia las licencias que se tomen los demás

Sucede que en la fase de krauser la música cambia en caliente de canción (primero la intro, y luego el tema), y como no se está haciendo streaming, no basta solo con un par samples durante ese frame, sino que hay que precargar TOOODOS los instrumentos que la partitura va a usar durante los próximos minutos, así que hablamos de llenar la ram en la medida que se necesite (luego puedes cargar y borrar al vuelo ciertos pcm's, o lo que sea, pero a groso modo es así).

Y es que ocurre que en la fase de krauser, cuando cambia la música hay un leve parón. Sucede lo mismo que en el SFA2, pero sin estar tan horriblemente mal depurado como en este.


P.D: En el DKC también pasa en los bonus, pero también no pasa de un leve tirón.

@hyrulen
Es lo que comenta Sogun, se trata de la textura pos. 61ED265B que es de 64x16 (4bit), en este caso no es un sprite (copia exacta de info pintada sobre el FB), sino una textura procesada por el TE, en el caso de los sprites solo se aplica filtro bilinear si van escalados por encima de su tamaño (con lo cual necesitas 1cycle).


Me ha costado encontrar de dónde salía esa textura con tan poca información


Pero si a ese tamaño de pantalla aplicas un patrón de este tipo se verían escalones por el lado derecho, ya que falta un negro.


La OST está muy maja por cierto, me gusta más que la del 2, los segmentos de pianillo (0:30)
https://www.youtube.com/watch?v=2YTPOm2fOYU

Otra canción.
https://www.youtube.com/watch?v=wCsm00Tr2zg

@Sexy MotherFucker
Filtro bilinear solo se aplica a sprites escalados, por mucho que lo actives el chip lo ignora si trabajas con sprites de tamaño 100%, el AA resample igual sí que lo hubieran activado

Puedes trabajar con un FB de cualquier tamaño y luego agrandarlo a la salida de vídeo final, sobre resoluciones finales del chip tendría que preguntarle a Marshall.

--

Por cierto he leído en otro hilo que en N64 no se suele trabajar con datos de 64bits, pero lo cierto es que sí se hace, otra cosa es si tiene sentido usarlo para la lógica de un juego, en ese caso depende del uso que se le vaya a dar, de hecho no es ni necesario usar variables de 32bits para muchas cosas, recordemos que las coordenadas de textura son de 16bits (0-65535).


Por no hablar que los datos orientados a save suelen ser 8bit (0-255) como el máximo número de balas de un slot de Resident Evil 2.

Pero volviendo a los 64bit, con las optimizaciones de compilador actuales no he notado diferencia usando float o double, a veces hasta el segundo ha resultado ser más rápido o lo que es mejor, no hay ningún problema de rendimiento por usar variables de 64bit cuando sea necesario, otra cosa es usar variables de 64bit para todo, sería absurdo.

En este caso se construye un comando de 64bits (ya que el RDP solo trabaja con comandos de 64bit) y se divide en 2 para el ringbuffer (que envía en 2 tiempos)


Ese código simplifica el tener que trabajar con 2 bloques distintos y además nos permite la flexibilidad de añadir cualquier cambio a ese comando, no se está usando para lógica de juego, pero sí para un posible engine gráfico, pues esto configura el RDP por cada superficie distinta que quiera renderizarse.

que bien explicáis, y cuanto aprende uno en este hilo

@wwwendigo lo de los 64 bits juraría que lo dicen por ti:

Por cierto he leído en otro hilo que en N64 no se suele trabajar con datos de 64bits, pero lo cierto es que sí se hace

Te quoteo por si quieres apuntarte el dato de cómo se trabaja actualmente en la scene del R4300i.

@BMBx64

sobre resoluciones finales del chip tendría que preguntarle a Marshall.

Sería información muy interesante, ya que de resoluciones progresivas en el sistema conocemos 320x240, los potenciales pero poco realistas 640x480, ¿Más?. ¿256x240?.

No recuerdo donde lo leí pero no iba hacia nadie en particular, era más por comentar , Marshall seguro que sabe todo el tema de resoluciones (el hizo el mod HDMI), en cuanto a progresivo sin mod hdmi solo saca entrelazado

Tenía curiosidad con el tema del filtro bilineal y he pillado esa textura para montarla ésta vez en un sprite con escala 5x y el resultado en CEN64 es exactamente el mismo que en consola.


Si invertimos, la orientación del filtro sigue siendo la misma, ahora es la otra parte de la flecha la que parece una escalera.


Sprite a 0.5x (y luego aumentado a mano), no aplica filtrado en ese caso al igual que en escala 1:1.

BMBx64 escribió:en cuanto a progresivo sin mod hdmi solo saca entrelazado

¿Te refieres a los hipotéticos 480i no?. Porque entiendo que juegos como Super Mario 64 o los Zelda funcionan a 240p (320x240).

Pues nada sin prisa, pero será un excelente aporte cuando lo traigas

Sexy MotherFucker escribió:@wwwendigo lo de los 64 bits juraría que lo dicen por ti:

Por cierto he leído en otro hilo que en N64 no se suele trabajar con datos de 64bits, pero lo cierto es que sí se hace

Te quoteo por si quieres apuntarte el dato de cómo se trabaja actualmente en la scene del R4300i.

@BMBx64

sobre resoluciones finales del chip tendría que preguntarle a Marshall.

Sería información muy interesante, ya que de resoluciones progresivas en el sistema conocemos 320x240, los potenciales pero poco realistas 640x480, ¿Más?. ¿256x240?.

Yo lo que he dicho alguna vez al respecto es que no sirve de nada trabajar con datos de 64 bits en ese caso, que una cosa es que el tamaño de registro sea así y otra que signifique alguna ventaja real, que va siendo que no. De hecho si tal he mencionado potenciales desventajas de usar ese tipo de datos (mayor consumo de ancho de banda de la cpu a memoria al cargar datos, etc), pero no sé si se usaban los registros en modo de 64 bits o en modo de 32 bits, aunque sería hasta lógico usarlos como registros de 32 bits aunque parezca un "desperdicio".

Es posible que alguien al comentar el tema sí mencionara que sí se usaban los registros en modo de 32 bits, pero es algo que no sé sobre cómo se programaba la N64.

Tampoco es que sea muy relevante a nivel de potenciales a explotar, la verdad. Es totalmente irrelevante a nivel de resultados finales, un tipo de dato entero de 64 bits es una bestiada que no marca ninguna diferencia en esa máquina y para mover juegos. Es una herencia de una arquitectura pensada para estaciones de trabajo (los R4000 originales) y no para juegos.

wwwendigo escribió:Es totalmente irrelevante a nivel de resultados finales, un tipo de dato entero de 64 bits es una bestiada que no marca ninguna diferencia en esa máquina y para mover juegos.

Pero esto siempre hablando de las consolas de la época, ¿No?. O sea; en las CPUs de Ps4 y Xbox ONE imagino que se usarán más datos enteros de 64 bits que de 32 ¿?.

Recuerdo que en la Ps2 scene comentaban que para X rutinas en juegos usaban 64 bits en el R5900 custom que calza la consola, no recuerdo si porque no había otra opción para ese menester (que no me acuerdo cual era, algo relacionado con las unidades vectoriales), o si bien era por atajar de esa manera.

Sexy MotherFucker escribió:

wwwendigo escribió:Es totalmente irrelevante a nivel de resultados finales, un tipo de dato entero de 64 bits es una bestiada que no marca ninguna diferencia en esa máquina y para mover juegos.

Pero esto siempre hablando de las consolas de la época, ¿No?. O sea; en las CPUs de Ps4 y Xbox ONE imagino que se usarán más datos enteros de 64 bits que de 32 ¿?.

Recuerdo que en la Ps2 scene comentaban que para X rutinas en juegos usaban 64 bits en el R5900 custom que calza la consola, no recuerdo si porque no había otra opción para ese menester (que no me acuerdo cual era, algo relacionado con las unidades vectoriales), o si bien era por atajar de esa manera.

No lo creo, poder pueden usar enteros de 64 bits, pero... ¿para qué? Mientras que internamente no hay problemas porque tanto los registros como los buses internos están ya diseñados para eso (y las unidades de ejecución, etc), implica usar un mayor ancho de banda para procesar un mismo grupo de datos, que al cargar una línea de caché de datos habrá menos datos contenidos en ella, y por tanto un perjuicio al rendimiento aunque no sea grande.

Es más, diría que un buen programador incluso no usará datos de 32 bits para enteros sistemáticamente, que irá ajustando según necesidades a enteros de 16 bits o incluso a carácteres de 8 bits. Claro, ahí con estos tipos de datos podría ser ya interesante plantearse el uso de unidades vectoriales, y ahí cambia el cuento un poco de cómo hacer las cosas (si se puede, que no siempre es posible).

Si estás hablando de las unidades vectoriales de la PS2 entonces el tipo de dato debería ser de 128 bits, o mejor dicho, el tamaño del registro o vector usado. En principio no procesa datos de 64 bits de ninguna forma (sólo fp32 e "int16", y entre comillas porque sólo se menciona que son datos de punto fijo, no enteros), sí la cpu en sí pero no veo ni la necesidad ni el porqué de usar esos datos en la cpu en sí por mucho que se usen las unidades vectoriales.

Tiene que haber algo mal en lo que has dicho, algo lo has entendido mal o estaba ya mal en lo que decían porque no cuadra mucho. Que de todas formas, aunque estuvieras "obligado" a usar datos en entero con 64 bits, no iba a suponer ninguna ventaja ni entonces ni ahora en juegos.

Saludos.

@wwwendigo una última cosa ya que estamos; ¿Y fuera del àmbito dede los juegos, para qué es útil?. Copón, el registro estará a ese tamaño para ALGO en la vida xDD

Gracias de antemano y un saludete.

Es como las multiplicaciones de 24 bits del ppu1, mas allá del modo 7, que por poder puedes usarlas, pero es un desperdicio en comparación con las de 16 bits.

@Señor Ventura o sea, extrapolando más como las de las FPU/VU potentes de 128 bits, que para calcular GFLOPS vale, pero fuera de ahí es como matar mosquitos a cañonazos, ¿No?. Y lo mismo hasta asfixiando recursos para otras cosas (buses, etc, lo que ha comentado wwwendigo).

Sexy MotherFucker escribió:@Señor Ventura o sea, extrapolando más como las de las FPU/VU potentes de 128 bits, que para calcular GFLOPS vale, pero fuera de ahí es como matar mosquitos a cañonazos, ¿No?. Y lo mismo hasta asfixiando recursos para otras cosas (buses, etc, lo que ha comentado wwwendigo).

A ver, las unidades vectoriales no procesan realmente datos de 128 bits, lo que procesan son datos de fp32 (coma flotante de precisión simple) y int16 (enteros de 16 bits), por ejemplo. Ahí son útiles.

Pero los registros del R5900 de 64 bits, los genéricos, NO sirven para nada en juegos por la simple razón de que están ahí para tareas que NO tienen que ver con juegos. La cpu es un diseño que se usó en más tipos de tareas, y el tamaño de registro está pensado para casos que no tienen que ver con la consola, que es algo muy posterior.

De la misma forma que, excepto por el tema de poder usar más RAM, x64 no sirve para nada en juegos en sí (el tamaño de registros, me refiero), otro asunto es que en este caso y porque los PCs/consolas actuales ya tienen una cantidad de RAM importante sí existan beneficios de usar x64 para manejar toda esa RAM sin problemas. También existen otras ventajas como tener más registros arquitectónicos o novedades en el set de instrucciones, pero en sí el usar enteros de 64 bits para los registros generales no beneficia ni al PC, ni a la PS4, ni a la XONE.

@Señor Ventura

Ya, pero es que la multiplicación del PPU1 está ahí para temas del modo 7 (no sabía que fuera de 24 bits), que se pueda usar indirectamente por la cpu es circunstancial, la precisión que tiene es la que "necesita" para la tarea para la que se diseñó el PPU1, no para lo que "necesita" el Ricoh 5A22. De hecho aunque se pueda usar para eso, dudo que haya juegos que usen esa capacidad de hacer multiplicaciones "rápidas" en la SNES, dado que se deben evitar como la peste este tipo de operaciones al programar en sistemas además como éstos (con un claro coste alto de hacer mul/div, etc).

@Sexy MotherFucker
Para qué necesitas saber posibles datos teóricos?

Ya hemos testeado a nivel de rendimiento las variables de 64bits en N64 y para algunos usos como el que comenté en la página anterior producen un rendimiento superior, ej. una única variable de 64bit para montar un comando vs varias variables de 8bit por parametro.

El rendimiento por otro lado varía según como queden alineados los datos (con las opciones de optimización del compilador), cuando edité la libdragon eran casi todo variables de 32bits, según iba reemplazando el resultado iba fluctuando, el caso es que el tipo de variable no debería preocupar y se tendría que usar el que fuera más óptimo.

Sexy MotherFucker escribió:

BMBx64 escribió:en cuanto a progresivo sin mod hdmi solo saca entrelazado

¿Te refieres a los hipotéticos 480i no?. Porque entiendo que juegos como Super Mario 64 o los Zelda funcionan a 240p (320x240).

Pues nada sin prisa, pero será un excelente aporte cuando lo traigas

Marshall me acaba de dar una respuesta a esto

- Output horizontal: N64 siempre redimensiona a 640, sea lo que sea la resolución / framebuffer horizontal.
- Output vertical: Pueden ser 240p, 288p, 480i, 576i

BMBx64 escribió:- Output horizontal: N64 siempre redimensiona a 640, sea lo que sea la resolución / framebuffer horizontal.

O sea; ¿Cómo cuando los juegos de Pc iban a 320x200 y el monitor de 31 khz te los adaptaba a 640x400, sólo que en la horizontal nada más?. Qué raro, no entiendo por qué necesita hacer eso la N64, aunque ello explicaría porqué cuesta tanto visualizar scanlines en la consola.

Para qué necesitas saber posibles datos teóricos?

Porque me flipa entender cómo funcionan estas consolas viejunas internamente, para mí eso les da tanta personalidad como su estética, catálogo, o lo que muestren en pantalla. Y este «patito feo» que siempre ha sido la N64 quizá pueda convertirse en un cisne algún día gracias a vosotros, y yo quiero estarque cerquita para verlo

Según has comentado con las nuevas librerías los objetivos a corto-medio plazo son:

- Incrementar el polycount con todos o casi todos los efectos activados, manteniendo una tasa muy estable en rangos de 20-35 fps.

- Explorar las capacidades 2D del sistema.

Genial, pero yo vuelvo a sugerir una dirección que en teoría no debería costar mucho esfuerzo seguir aunque sea por curiosidad.

- Ver hasta donde llega la N64 liberando el fill-rate, ciclos de reloj, y memorias de TODO; filtro bilineal, AA, Enviroment Mapping, TLFMMI, corrección de perspectiva, etc, OFF. La consola A PELO en el mismo terreno que la PlayStation, a ver por cúanto la rebasa.

¿En tales condiciones cabría esperar un rendimiento dede 200.000 polígonos a 60 fps?. Me encantaría ver un Tekken 3 como el de System 12 rulando en la 64.

Y bueno luego movidillas intermedias rollos de desactivar el Z-Buffer cuando no hiciese falta como en World Driver Championship, esas cosillas.

Sexy MotherFucker escribió:O sea; ¿Cómo cuando los juegos de Pc iban a 320x200 y el monitor de 31 khz te los adaptaba a 640x400, sólo que en la horizontal nada más?. Qué raro, no entiendo por qué necesita hacer eso la N64, aunque ello explicaría porqué cuesta tanto visualizar scanlines en la consola.

Puede que de la forma en que funciona el AA tenga que ver, tendría que hacer pruebas o consultar para salir de dudas, si se utiliza 640x240 de resolución se evita el reescalado.

Sexy MotherFucker escribió:Porque me flipa entender cómo funcionan estas consolas viejunas internamente, para mí eso les da tanta personalidad como su estética, catálogo, o lo que muestren en pantalla. Y este «patito feo» que siempre ha sido la N64 quizá pueda convertirse en un cisne algún día gracias a vosotros, y yo quiero estarque cerquita para verlo

Según has comentado con las nuevas librerías los objetivos a corto-medio plazo son:

- Incrementar el polycount con todos o casi todos los efectos activados, manteniendo una tasa muy estable en rangos de 20-35 fps.

- Explorar las capacidades 2D del sistema.

Genial, pero yo vuelvo a sugerir una dirección que en teoría no debería costar mucho esfuerzo seguir aunque sea por curiosidad.

- Ver hasta donde llega la N64 liberando el fill-rate, ciclos de reloj, y memorias de TODO; filtro bilineal, AA, Enviroment Mapping, TLFMMI, corrección de perspectiva, etc, OFF. La consola A PELO en el mismo terreno que la PlayStation, a ver por cúanto la rebasa.

¿En tales condiciones cabría esperar un rendimiento dede 200.000 polígonos a 60 fps?. Me encantaría ver un Tekken 3 como el de System 12 rulando en la 64.

Y bueno luego movidillas intermedias rollos de desactivar el Z-Buffer cuando no hiciese falta como en World Driver Championship, esas cosillas.

- En N64 no hay un termino medio, si pasas de copy a 1cycle a la consola le da tiempo de hacer muchos de los efectos que quieres liberar a un coste mínimo o nulo, por eso pasas a pintar 1 pixel por ciclo, teníamos la teoría de que el RDP hacía cuello de botella, pero en los últimos tests se siguen consiguiendo más fps, dando a entender que son otras cosas, la memoria unificada juega un papel importante.

- El AA no gasta apenas, no lo usaría en 2D, en 3D sería más cuestión de ver si emborrona la imagen o consigue buenos resultados según la resolución a la que corra el juego, pero no lo vería desde el punto de vista de que pueda perjudicar mucho al rendimiento.

- Se puede montar un engine 3D que funcione todo con copy (lo que dices, con todos los efectos desactivados), pero es un esfuerzo que no sé si valdría la pena, por lo menos la idea que tiene la gente en la scene es hacer rendir la maquina con todo (porque puede), pero al rendimiento que sería el esperable.

---
Por otro lado llevo tiempo queriendo volver a los origines del post, hablar de curiosidades, gifs, etc a ver si saco tiempo

BMBx64 escribió:Por otro lado llevo tiempo queriendo volver a los origines del post, hablar de curiosidades, gifs, etc a ver si saco tiempo

Yo me suscribí por eso

@Sexy MotherFucker sin texturizar no eran 600k polígonos?

@Calculinho ¿Hablas de N64 o PlayStation?.

@Sexy MotherFucker N64 había leído que el modo ese de programación que Nintendo no permitía usar porque era muy inestable movía 600k. De PSX ahora ya no recuerdo, pero puede ser que leyese 380K?

javierator1981 escribió:[oki] Yo me suscribí por eso

Genial , ya estoy mirando una lista de juegos "oscuros" de N64 a ver por donde puedo atacar, también me gustaría comentar cosas de los Castlevania, había pendiente comparar OOT con Majoras y mirar los Goemon.

---
Nintendo dijo del turbo3D que son 5000+ frame / 60fps (suelen usar hz para referirse a fps en muchos casos, debugs de juego incluidos).


El manual fue actualizado por última vez el 21 de octubre de 1996, las mejoras a nivel de compilación y librería de hoy en día deberían ser enormes, tal como comentan era la primera versión del micro código, luego les fueron mejorando el rendimiento, tampoco se indica cual es el uso de la unidad vectorial para esta configuración.

En cuanto a PSX habría que ver dónde está el techo de la CPU, creo que sería el componente más afectado en una escena compleja que además tenga que cargar con todo el código del juego, de igual forma puedo pasarme por la scene de PSX a ver que se cuentan.

@BMBx64 ok gracias, no sé porque doble los datos. Imagino que PSX andará en 200K entonces.

@BMBx64 sik buscas juegos "oscuros" terecomiendo hybrid heaven un juego unico en su gameplay y con una muy buena trama donde nada es lo que parece

Hace un par de años un fan empezó a hacer un remake de Ocarina of Time en Unreal... y aún sigue con ello:

Comienzo del juego:
https://www.youtube.com/watch?v=r_AO0IjHNaY

Lucha que recuerda a la tech demo de lo que sería Zelda en Wii U:
https://www.youtube.com/watch?v=wwWPgUjADL0

Zora Domain:
https://www.youtube.com/watch?v=Owbnvee4JLc

cegador escribió:Hace un par de años un fan empezó a hacer un remake de Ocarina of Time en Unreal... y aún sigue con ello:

Comienzo del juego:
https://www.youtube.com/watch?v=r_AO0IjHNaY

Lucha que recuerda a la tech demo de lo que sería Zelda en Wii U:
https://www.youtube.com/watch?v=wwWPgUjADL0

Zora Domain:
https://www.youtube.com/watch?v=Owbnvee4JLc

Pues mola un montón, han implementado incluso las animaciones de Link en Majora's Mask, como las volteretas en salto. Las físicas del UE4 le sientan bien a las piedras, hojas, etc; así como las fuentes de luz dinámicas, y la música arreglada.

Yo me lo pillaría sin pensarlo.

Lo sorprendente de ese proyecto es que lleve años sin que Nintendo lo haya tirado abajo ¿Habrán contactado con el usuario para re-re-remakearlos de nuevo a Switch?

Calculinho escribió:Lo sorprendente de ese proyecto es que lleve años sin que Nintendo lo haya tirado abajo ¿Habrán contactado con el usuario para re-re-remakearlos de nuevo a Switch?

El usuario comenta en uno de los vídeos que Nintendo se lo había tirado por usar una canción de OOT y tuvo que volver a subirlo pero con otra canción. Igual le van dejando hacer, pero no mucho.

Con lo fácil que sería dejar a ese tenia hacer el juego completo y después comercializarlo Nintendo, ganarían muchísimo tanto Nintendo como el creador

Calculinho escribió:Lo sorprendente de ese proyecto es que lleve años sin que Nintendo lo haya tirado abajo ¿Habrán contactado con el usuario para re-re-remakearlos de nuevo a Switch?

mientras no este terminado y no lo "lanze al mercado" nintendo no va a mover un dedo

si lo termina le pasara lo mismo que al que hizo el AM2R (juegrraco por cierto )

Kitizarpaszuaves escribió:Con lo fácil que sería dejar a ese tenia hacer el juego completo y después comercializarlo Nintendo, ganarían muchísimo tanto Nintendo como el creador

Las cosas no son tan sencillas.

Ese juego lo está haciendo un aficionado. Tendrá mil bugs, tendrá código "robado" de otros programadores, tendrá texturas "robadas", tendrá sonidos "robados", tendrá modelados "robados", tendrá animaciones "robadas"...

En los videos ya se ve que fallan muchas cosas. Nintendo no se puede arriesgar a pillar algo hecho por un aficionado y venderlo como si fuera algo profesional... tienen mucho que perder y nada que ganar.

Optimizacion de espacio en super mario 64 en este caso audio

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

Acabo de empezar este hilo y lo voy a leer enterito, cuanta información interesante!!

@Flash-Original hostia qué ingenioso, eso sí es reciclar xD