Hilo de detalles y curiosidades de N64

Sogun escribió:

dirtymagic escribió:Ahh,ok, supongo que tarde o temprano lo harán compatible con GYSEditor, no parece que sea muy diferente a JFG, a nivel de motor, vamos tiene pinta de ser una evolución de este.

Salud.

Yo no contaría con ello. SubDrag, el creador del editor, cedió el desarrollo y ahora sólo se dedica a corregir bugs e introducir algunas funciones nuevas sencillas sobre lo que ya existe. Carnivorus, que fue quien cogió el testigo cuando SubDrag se retiró un tiempo, también tuvo que abandonar el desarrollo. Ahora el Editor se podría considerar en fase de mantenimiento y no de crecimiento.

Desconozco hasta qué punto se pueden modificar Diddy Kong Racing y Jet Force Gemini con el Editor actual, pero desde luego deben de estar muy lejos de lo que se puede conseguir en GoldenEye y Perfect Dark. De DKR sí que hay varios mods, pero de JFG creo que sólo hay una pequeña demo (del Mickey's Speedway USA no se acueda nadie, jeje).

Si vemos algo parecido a un editor para Dinosaur Planet seguramente será por otro lado. La comunidad que está hackeando la rom para hacerla más jugable sí que es posible que necesite crear herramientas que podrían evolucionar en un editor.

Pues vaya, pensaba que se seguía trabajando en el, sobretodo en dar más soporte a los juegos que no son GY/PD.
De todas maneras lo que estaría bien es un motor que fuera más general y no uno dedicado a modificar un juego existente, aún que estuviese basado en los de Rare o Nintendo en su funcionamiento, pero que se pudiera hacer de cero no modificando partes de un juego ya existente.

Salud.

Sogun escribió:-El desarrollo de la aventura no me estaba gustando nada. Le veo poco sentido a cómo ocurren las cosas o cómo llegas a los lugares. Tampoco le veo la gracia a tener dos personajes si pueden hacer las mismas cosas y no pueden recorrer las zonas del otro.

Eso se llama variabilidad, a mi el desarrollo me parece muy bueno al igual que la jugabilidad, considerando que es un prototipo, no estoy muy seguro pero creo haber leído un post tuyo de que no te había gustado Conker's Bad Fur Day . extraño que tampoco te agrade el desarrollo de DP, en fin para gustos colores.

@john D9
Hola.

Lo que me ocurre a mí con Conker es que no lo considero una obra maestra como parece que es el consenso general. Sí que me gustó, pero la primera mitad del juego me parece bastante aburrida y que sólo se salva por la factura técnica, la genialidad de la ópera de Great Mighty Poo y alguna referencia a películas famosas como Terminator o Tiburón. El juego realmente empieza a despegar cuando Conker llega a la zona prehistórica y se vuelve realmente bueno a partir de la parte de Drácula. Es una lástima que el juego se acabe poco después. Si el juego hubiese sido más como la revolucionaria parte final (estamos hablando del control de Resident Evil 4 mejorado y 4 años antes!!!) sí que lo consideraría una obra maestra. La sospecha que tengo es que la inmensa mayoría de la gente que lo pone por las nubes sólo lo ha probado y se ha aburrido de él antes de acabarlo porque lo único que destacan es la canción de Mighty Poo y las parodias de "Salvar al Soldado Ryan" y "The Matrix" que todos conocíamos sin necesidad de tocar el juego.



Sobre el desarrollo de Dinosaur Planet aún sabiendo que se trata de un prototipo y que falta cohesionarlo y pulirlo tenemos el producto terminado como Starfox Adventures. Muchos de los problemas que tiene el juego final ya se ven en el prototipo pero habría que saber si son consecuencia del cambio de narrativa al convertirlo a un StarFox o si ya de base Rare lo tenía planteado así. Me temo que es más bien lo segundo.

No me parece variabilidad tener dos personajes que hacen lo mismo y que no interactúan entre sí en toda la aventura. Yo lo hubiera planteado como en Jet Force Gemini: primero los personajes parten de dos caminos distintos que acaban juntándose en cierto momento y partir de entonces pueden recorrer las zonas del otro y abrir nuevas áreas gracias a sus poderes diferenciados (como por ejemplo las habilidades del acompañante, hechizos distintos que hayan aprendido durante la primera parte de la aventura o nuevas habilidades que les pudieran haber dado los Krazoa).
Era tan fundamental tener dos personajes que al final todo el trabajo se lo comió Fox McCloud.

Yo descubrí Conker hace 5 años y me lo pasé entero. Me parece igual de divertido su comienzo con la flor con pechos y la abeja que se la quiere fo*** como el final que sino recuerdo mal parodiaba a Alíen. Para gustos colores evidentemente.

Lo que no me gustó fue la carrera en monopatín por el volcán creo que era, tuve que repetirla cien Veces hasta superarla, pero creo que era porque mi joystick estaba ya mal.

Quien sabe como habría sido Dinosaur Planet terminado y sin el lavado de cara a lo StarFox, creo que si hubiera tenido el mismo level design de las zonas de a "pie" incluyendo los "templos" por llamarlos de algún modo y sus puzles, no se que tanto almacenamiento ocuparían los niveles manejando el Arwing en el mini dvd, ciertamente en el producto final como StarFox , Krystal apenas fue personaje jugable.

Sobre el Conker me lo pase varias veces en el n64 y lo disfrute en todas además de que le metí horas y horas de juego en el multijugador con amigos, la historia no tiene sentido es absurda pero es lo que Rare quería (comedia, humor negro y gore) al menos a mi me entretuvo bastante, incluso pase el de xbox, Live & Reloaded que aun con sus gráficos prefiero por mucho al de n64 y su genial multiplayer.

Hay referencias a otras películas además de las que ya mencionaron, como el exorcista con la "niña" que está en la base de los tediz, el padrino y la naranja mecánica.

Yo también batalle bastante en la parte de la carrera por usar un stick desgastado , pero con un buen stick es relativamente fácil.

Hay un emu de Neo Geo en camino, de momento ya corre el Metal Slug y seguramente más juegos.


Supongo que la idea es darle toda la funcionalidad y luego mejorar el rendimiento, es código abierto, lo poco que se puede ver es que hay varias capas, una de SDL, otra de la libdragon (la buena noticia es que por fin la están mejorando, aunque puede que el tema de la librería ya resulte cansino )

El link del github, no hay binarios aún, pero el proyecto no lleva ni ¿20 días? , según parece tendrán que lanzar distintas versiones para soportar la interfaz SD de cada cartucho flash o una herramienta para insertar las roms dentro del z64.

--

Estoy aprovechando para pasarme el Jet Force Gemini y hay una cosa que me está dejando loco, no recuerdo si las expansiones de munición son libres o específicas, tengo a Juno con 90 balas de francotirador y Vela con solo 20, obviamente aparecen transparentes si aún no tienen el arma y luego están las que solo se pueden pillar en caminos específicos de cada uno, como bajo el agua, lava, etc, pero hace demasiados años que me lo pasé..

@Conker64 increíble noticia. La scene de 64 siempre ha estado muy muerta, y esto puede que le de vidilla.

@Conker64 Vaya, impresionante! Eso es algo que no esperaba... Y no, no cansa lo de la librería, todo lo contrario! Estamos por este hilo para ver las novedades y esperando a que se avance todo lo posible.

@Conker64 He aplaudido tan fuerte que no me quedan manos y aplaudo con los muñones.

Esta semana estuve mirando emus para N64 y resulta gracioso que los de NES y SMS funcionen con compatibilidad parcial baja y con bastantes ralentizaciones o problemas de sonido, el de SNES va a pedales, etc. Y ahora veo una N64 emulando NeoGeo

Conker64 escribió:Estoy aprovechando para pasarme el Jet Force Gemini y hay una cosa que me está dejando loco, no recuerdo si las expansiones de munición son libres o específicas, tengo a Juno con 90 balas de francotirador y Vela con solo 20, obviamente aparecen transparentes si aún no tienen el arma y luego están las que solo se pueden pillar en caminos específicos de cada uno, como bajo el agua, lava, etc, pero hace demasiados años que me lo pasé..

Qué casualidad. Yo me lo pasé el mes pasado desde cero por segunda vez desde mi primera partida en el 2000.
Las mejoras de munición las puede coger cualquiera salvo aquellas que están en zonas donde sólo puede acceder un personaje. Recuerda que el enfrentamiento final...
.

Y hablando de Jet Force Gemini. Me di cuenta de que el agua en este juego está siempre representada con una superficie plana y una textura animada, pero está hecho de una forma muy convincente y parece que hay un suave oleaje del estilo del Wave Race.

Hola, estoy haciendo unos mapas en el zelda OoT y me he encontrado el problema de que las texturas de 128x64 en i4 (16 grados de intensidad) con Gimp, no consigo crear una textura con esas características y el editor la transforma a 4 grises,no es cosa del editor,porque las texturas originales del zelda con esas características si que las coge bien,¿sabéis de algún conversor que pase de 16 tonos de gris a 16 grados de intensidad y que guarde en *.png o de un plugin que lo permita guardar directamente desde Gimp?.

Salud.

Alguno sabe si existe algún hack o homebrew que recopile todos los tableros de Mario Party en una única rom o una rom recopilando todos los minijuegos de forma similar al The Top 100 que sacaron para 3DS?

Me gustaría en N64, pero si existe en cualquier otra consola también me vale. Me parece raro que si existe la opción de crear tableros a nadie se le haya ocurrido antes, pero en google no encuentro nada. Y en la web de la comunidad de Mario Party encuentro cientos de tableros sueltos creados por usuarios, pero no veo nada parecido a lo que comento. Quizás sea imposible por alguna razón, pero me extraña tanto que los tres MP de N64 no usen el mismo motor gráfico y que no se puedan recopilar

Uohhhhhhhhhhhh!!!!!

Dejó por aquí un vídeo que ha aportado @clinisbut en el hilo de la Nintendo 64 que dando datos técnicos desmonta que el Donkey Kong 64 tuviese un bug que solo se solucionaba con el expansion pak. Como aquí se aporta mucha información técnica, pues mejor tenerla a mano.
Y de paso darle vidilla al hilo.

EMaDeLoC escribió:Dejó por aquí un vídeo que ha aportado @clinisbut en el hilo de la Nintendo 64 que dando datos técnicos desmonta que el Donkey Kong 64 tuviese un bug que solo se solucionaba con el expansion pak. Como aquí se aporta mucha información técnica, pues mejor tenerla a mano.
Y de paso darle vidilla al hilo.

Buen aporte. El vídeo aporta bastante información, y bastante bien explicada para que todos puedan entenderlo sin necesidad de tener conocimientos técnicos.

Veo que no lo ha puesto nadie aquí, un frametest del Quake II de N64 que hasta la fecha sólo se comentaba de pasaba su rendimiento en algún vídeo comparativo de versiones, pero nunca centrado en una única versión.

https://www.youtube.com/watch?v=3Ze1Gai5fG0

El canal tiene más vídeos, pero mejor ir comentándolos de uno en uno para que tengamos tema de conversación más tiempo que tampoco van a aparecer Dinosaur Planets cada mes.

SuperPadLand escribió:Veo que no lo ha puesto nadie aquí, un frametest del Quake II de N64 que hasta la fecha sólo se comentaba de pasaba su rendimiento en algún vídeo comparativo de versiones, pero nunca centrado en una única versión.

https://www.youtube.com/watch?v=3Ze1Gai5fG0

El canal tiene más vídeos, pero mejor ir comentándolos de uno en uno para que tengamos tema de conversación más tiempo que tampoco van a aparecer Dinosaur Planets cada mes.

Muy guapo, toca seguir el canal. Gracias por el aviso compi.

No hay muchos canales que se dediquen a analizar fps.

Del Quake II había visto el de DF que comparaban con/sin expansión un poco el rendimiento y ahora este.

Creo que muchos juegos en N64 se comportarían así si no vinieran bloqueados a 30 o 20 (20 suele ser muy estable, acompañado de frameskip a 0).

@Conker64 pero este Quake II no viene bloqueado no? Lo digo porque el framerate a veces ha llegado a 38-40 y las subidas y bajadas no son de golpe.

SuperPadLand escribió:@Conker64 pero este Quake II no viene bloqueado no? Lo digo porque el framerate a veces ha llegado a 38-40 y las subidas y bajadas no son de golpe.

Es justo lo que dice, que los juegos que no están bloqueados a 30 o 20 fps, son una montaña rusa de fps 😅.Otra cosa son los juegos que tienen auto frameskip , que si no llega a 60, directamente hace frameskip a 30 y sino 20, 15, 12 ect, como el GE o PD.
El QII tiene pinta de usar triple búfer con el Expansion Pak y sin frameskip, por eso sube y baja de frames pero no de golpe.

Salud.

Si, así es.

Lo curioso es que muchos FPS en Dreamcast y sobretodo PS2 tienen un comportamiento similar al de este Quake II, yo la verdad es que prefiero la aproximación de Doom 64 que es de lo más sólido y estable.

Por cierto hablando de canales que analizan framerates acabo de encontrar otro, pongo un vídeo del mencionado Doom 64.


Creo que los resultados no son del todo fiables, por ejemplo en el 0:25 cuando se queda quieto, los fps bajan hasta 5 fps.. igual la herramienta de análisis no nota movimiento y entiende como caída, alterando los resultados, siempre creo que este tipo de vídeos hay que tomarlos con pinzas y el que los crea tiene que ser consciente de lo que muestra y si la herramienta está interpretando bien esos resultados, si puede validarlos con fps internos en modo debug mejor.

Lo cual sería una pena porque limita mucho como observar un juego.

Aún así tiene un puñado de vídeos, muchos de N64, puede venir bien para contrastar con otros resultados.

No me parece que este último canal tenga análisis muy fiables de los juegos de Nintendo 64 porque los captura a través de AV y un adaptador a HDMI. Eso tiene que añadir ruido a la señal, lo que haría que dos fotogramas que deberían ser iguales el programa los detecte como diferentes y los números sean más altos de lo que en realidad son. ¿O me equivoco?
Lo extraño es que este principio iría en contra de lo que se ve en sus vídeos, con bajadas abruptas como la que menciona Conker64 o también lo que se ve al final del vídeo del Conker BFD durante la cinemática con las avispas. Viendo varios vídeos sí que parece cuadrar el contador de frames con lo que pasa en pantalla la mayoría de casos, pero hay momentos donde los números no cuadran para nada.

Existe por ahí un parche que pone el GE en "alta resolución". En realidad hay varios, pero me refiero al que lo hace funcionar a la resolución del menú de inicio: 440x330 si no me equivoco. Recuerdo jugar toda la campaña y no notar que el rendimiento fuese peor que el juego original. Al menos no me supuso ningún impedimento para pasarme el juego (en fácil ). La mejora de la imagen sin embargo era muy notable. Necesitaba el Expansion Pak así que supongo que hacía lo mismo que el Quake 2 con el buffer. Ahora no tengo la rom en el ED64 y no puedo volver a probarlo, pero el otro día me fijé que el menú de inicio funciona en progresivo (o eso me parece) y tengo ganas de comprobar si este parche también.
Existe otro parche que hace funcionar al GoldenEye a 640x480 y ahí sí que es un pase de diapositivas, jeje.

Viendo estas cosas me parece una oportunidad perdida no haber aprovechado más el Expansion Pak de esta manera y que más juegos tratasen de aumentar la resolución horizontal y eliminar el antialiasing como hace el Star Wars Racers. Parece que los juegos hubieran tenido un rendimiento muy cercano al modo en baja resolución, pero la calidad de imagen sería muchísimo mejor. Muchos juegos punteros de PS1 funcionan a resoluciones tipo 512x240.

También experimenté un poco con las roms NTSC y PAL del GoldenEye a ver si a ojo detectaba algún cambio en el rendimiento y me di cuenta de que mi ojo biónico no da para tanto. Lo que sí que noté es mucha más luminosidad en la imagen al jugar en PAL al estrecharse las scanlines (en realidad ni las percibo en PAL). Algo que también noté con el Majora's Mask y que ayuda muchísimo a la nitidez del texto y el resto de la interfaz.

@Conker64 oye conker me acabo de acordar de varias cosas del pasado y sólo quería saber como van o si las has mirado:
1-El SDK de N64 que estabais desarrollando entre varios para aprovechar mejor el sistema en juegos homebrew.
2-No estoy seguro de si esto lo soñé o no así que si no es así olvidalo: La creación de una pequeña demo adaptando Castlevania SotN y Daytona USA arcade.
3-Mirar como optimizar el menú del firmware Alt64 para usar en flashcards que funciona supeeeeeeeeeeeeeeeeeerlentoooooooooooooooo (o funcionaba cuando lo probé porque me rendí y volví al original). Y creo que también hablaste de la posibilidad de que este menú pudiera cargar una imagen de cada juego al moverse por el menú de selección en plan la portada del juego.

@Sogun
Sí, es como comentas.

Parece que incluso la forma en que los graba no debe meter todos los frames en el contenedor, es decir cuando 2 frames son idénticos en lapsos distintos, luego claro, eso se lo pasas a la herramienta de análisis y esta entendería que 2 frames repetidos en el contenedor siguen siendo movimiento, pero si no los hay pasa como en el vídeo del Duke Nukem 64, que en la pantalla estática de resultados le da 1 fps..

Creo que los resultados que muestra pueden ser válidos solo cuando hay movimiento continuo, en el caso de Doom 64 son 30fps estables la mayoría del tiempo en el juego real, salvo al mirar alguna sala grande desde algún ángulo concreto (con una caída sostenida) o con mucha cosa en pantalla (algo momentaneo).

Sin duda en el canal que puso SuperPadLand se analizan mejor.

@SuperPadLand
1. Ah, la libn64, lo que pasó es que su desarrollador fue fichado por una empresa y quedó todo a medias, mi parte (y la de Krom) que era la de adaptar todas las funciones del RDP a C para esa librería la hicimos esa misma semana en que se comentó esto. (que a su vez es todo el trabajo que hice en la libdragon).

El resultado es que libn64 junto con el entorno viene tan pelado que no se puede hacer casi nada, no hay disponible funciones básicas como rand, incluso añadir un sprite a la ROM para cargarlo desde la librería es una odisea, la mayoría de mis tests se limitaron a textos, cargar texturas mediante textos o a aportar el medidor de fps que es el que se utiliza en los tests de la libreria.

La libdragon se ha ido mejorando, pero hace tiempo que no la toco, en realidad tengo la ranura SD del Everdrive tan jodida que la última vez arrancó a los 30 intentos..

2. Estuve haciendo un test para saber si Castlevania SOTN correría bien en la consola, en el escenario con más capas, etc , no llegué a terminarlo, pero vamos llegué a la conclusión de que sí que podría.

3. Sí, el alt64 usa libdragon y todo lo que pinta lo hace a golpe de CPU, no utiliza el RDP, de hacerlo podría ir a 60fps, en su momento pensé hacer un menú alternativo con portadas, etc..

Conker64 escribió:2. Estuve haciendo un test para saber si Castlevania SOTN correría bien en la consola, en el escenario con más capas, etc , no llegué a terminarlo, pero vamos llegué a la conclusión de que sí que podría.

¿Es peor hardware para esto que la playstation?. Leyéndote parece que esté en desventaja.

@Señor Ventura
N64 es más rápida.

Pero era para saber si se pueden hacer cosas complejas omitiendo el RSP y para 2D parece dar muy bien el pego, claro que si lo usas para cosas vectorizables como los tiles de scroll ganarías mucho rendimiento o para la música.

El SOTN usa además algún que otro elemento 3D, pero si no son demasiados igual se podría calcular con la CPU.

Conker64 escribió:@Señor Ventura
N64 es más rápida.

Pero era para saber si se pueden hacer cosas complejas omitiendo el RSP y para 2D parece dar muy bien el pego, claro que si lo usas para cosas vectorizables como los tiles de scroll ganarías mucho rendimiento o para la música.

El SOTN usa además algún que otro elemento 3D, pero si no son demasiados igual se podría calcular con la CPU.

Ah, osea, que esa escena del sotn es solo usando la cpu... pues... hostia, si.

@Señor Ventura
La CPU y el RDP

Dejo una imagen curiosa de las tripas del RCP.


Cada chip se lleva la mitad del espacio (ma o meno), lastima la falta de espacio por el verdadero talón de Aquiles (los 4KB de cache de texturas).

Del RSP lo que verdad importa es la unidad vectorial, que es una buena bestia para transformar geometría, decodificar video/audio, etc.

El core es un MIPS para ejecutar el microcódigo y otras operaciones, pero sin FPU, sin mul/div, etc, además ese tipo de operaciones serían convenientes en la CPU que corre a más Mhz y tiene más cache.

Como curiosidad, PS2 tiene las VU en el encapsulado de la CPU lo cual en un caso imaginario en N64 sería dejarle la otra mitad del chip al RDP para ampliar la memoria o capacidades de dibujado. (habría que cambiar el setup de memoria)

@Conker64 Bueno, me habeis entendido xD

He rescatado los parches del GoldenEye que permiten jugar a mayores resoluciones y he sacado algunas fotos comparativas directamente a mi televisor, un Phillips panorámico que tiene la consola conectada por AV.

Como algunos sabréis, el menú principal de las carpetas del GoldenEye funciona a más resolución que el resto del juego (440x330 frente a 320x240, ambos en progresivo). Uno de los parches permite que todo el juego funcione a la resolución del menú, lo que hace que los textos de los escenarios y del menú del reloj aparezcan más pequeños y desplazados (el indicador de munición tiene su posición corregida). Este parche también permite activar y desactivar el antialiasing en medio de la partida, por lo que podemos conseguir claridad extra a costa de algo de dithering. Es necesario el Expansion Pak para que el juego funcione con este parche y que yo sepa sólo está disponible para roms NTSC U. El rendimiento es sorprendentemente bueno.

Los otros parches permiten hacer funcionar el juego a 640x480 (en realidad multiplica x2 la resolución horizontal y vertical original) entrelazado en todo momento, lo que incluye el menú del principio que también está desplazado y empequeñecido. Un parche permite jugar con el AA activado y el otro con el AA desactivado. Hay versiones del parche para roms PAL, pero no he conseguido que funcionen. El parche sin AA es hasta jugable si tienes experiencia con el juego y sabes anticiparte a la acción. Ambos parches requieren el Expansion Pak para funcionar.

Las imágenes. He añadido las versiones originales en NTSC y PAL:


La mejor versión para jugar es sin duda a 440x330p sin AA por la claridad de la imagen y el rendimiento. Lástima que el menú del reloj no esté ajustado. De todas formas esta resolución tan extraña introduce algunos artefactos a la imagen cuando se reescala a 640x480 para mostrarla en la pantalla. Se puede apreciar algo de lo que digo en el contorno de las montañas (es como un antialising muy suave) pero se nota más en el indicador de vida del menú del reloj. En medio de la acción pasa totalmente desapercibido.

Me pregunto si sería posible hacer un parche a 620x240 (realmente 640x224) que es prácticamente la misma resolución que 440x330 y obtendríamos una imagen aún más limpia.

-------------------------

Añado de la última discusión en el otro hilo acerca de Quake 2.

He estado probando la versión de N64 en el hardware real y me ha sorprendido lo nítido que se ve todo. También he ripeado las texturas del primer nivel y me ha sorprendido que todas las texturas del escenario son 32x32 a 8 bits de profundida pero que no tienen aplicado el filtro trilineal. Esto hace que se pixelen en la distancia aunque muy sutilmente en la mayoría de casos porque son texturas con poco contraste. Quizás jugar con el Expansion Pak también ayuda en esto al tener mayor profundidad de color y no tener cambios de tonalidad más abruptos. Sin embargo las texturas de los enemigos son de unos 64x32 a 16 colores; parece que son 5 texturas por enemigo, para las piernas y el torso en estado normal y con heridas, y otra para la cabeza (que no es simétrica). Las armas son modelos poligonales pero son tan simples, las texturas que se les aplican tan cutres, y los cuadros de animación tan escasos que parecen sprites 2D mal escalados.
Las animaciones de los enemigos dan bastante el cante, pareciendo fluídas en determinados casos y siendo un stop-motion cuando los tienes cerca. Entre las animaciones y lo difícil que es apuntar desluce el juego bastante, porque gráficamente es muy agradable y de rendimiento, al menos en las dos primeras, fases va muy bien.

Fue entonces cuando recordé que SubDrag había hecho parches a varios juegos para que se controlaran como en GoldenEye y pensé que Quake 2 era uno de ellos pero me equivoqué. Lo que sí que experimentó es con un parche a 640x480 (en realidad dos parches, uno con AA y otro sin). He probado el parche sin AA y el framerate es muy pobre (no me quiero imaginar con AA activado) y además produce errores de perspectiva en las texturas de algunos triángulos. El parche se cuelga cuando intentas abrir una puerta del primer nivel, así que queda simplemente como una curiosidad. El rendimiento a 640x480 me pareció superior en GoldenEye, anuque también creía que el GE a su resolución original funcionaba mejor de lo que lo hace, así que no me hagáis caso .

Curiosamente ambos juegos son de 12 MB y creo que el juego de Rare le saca mayor partido.

holita a todos, si alguien quiere llevar este hilo que me abra un MP

@Conker64 es el autor original del hilo sólo que antes tenía otra cuenta.

Sí, ya me han puesto como autor

@Sogun
Yo también tengo un Goldeneye editado para 440x330 sin AA y va muy bien la verdad
--


He estado jugando recientemente al RE2 (a ver si algún día saco el randomizer), no sin antes pasármelo en PSVITA-PSX (ClaireA / LeonB) y he visto cosillas interesantes.

En el ordenador hay que introducir NEMESIS en lugar de GUEST, es una buena referencia a RE3

Los ángulos de cámara tardan más en cambiar de lo que recordaba, ¿quizás va acelerado en PSVITA?, aunque en cuanto llevas un rato jugando te acostumbras.

El detalle de saltar las puertas por ser cartucho (que no está presente, pero sí en el RE DS por ejemplo o en PC) creo que no sería demasiado factible, la maquina está al limite descomprimiendo en esos momentos y algunas puertas llegan a pegar tirones en la animación, algún chasquido en la música también (muy poco común), aunque es algo aleatorio, si sales y entras puede que ya no aparezca, si bien podría quedar en cache temporal.. tampoco descarto alguna discrepancia con el Everdrive, aunque tengo recuerdos similares de cuando lo jugué en cartucho original.

Donde si es realmente rápida es en resetear dentro del juego, volver al título, de ahí a la carga de partida y al juego, quicir es tan rápido que el CHAAN RESIDEN IVOL te llega a sonar brevemente dentro del juego, ni texto de prepárate para la pesadilla ni nada.

En cuanto al rendimiento no he notado frameskip, es más de moverse a cámara lenta, con la ametralladora puedes liarla parda y crear algún slowmo con algún jefe que quede demasiado cercano a la cámara, en realidad ayuda un poco a vencerlos , pero no es habitual, hay planos muy cercanos con zombies donde el tema no ralentiza, supongo que depende de la cantidad de chorro de sangre y de la resolución que esta empleando en ese plano de cámara concreto, ya que cambia continuamente, pero no por temas de carga gráfica, es raro la verdad.

Me pregunto si la sangre (sesos y otros pellejos), que a veces es numerosa va con z-buffer o sin él, tendría que echarle un ojo, en CYCLE1 evidentemente da igual que sea transparente o no, el rendimiento es prácticamente el mismo, ahora si no usaran semitransparencia el modo COPY podría aligerar muy mucho la carga.

Una cosa que me pone de los nervios es ver las superficies y otra maquinaria en el original, se descoyunta, hace el baile de San Vito y esas cosas.


En N64 bueno es una gozada ver como la plataforma es la misma arriba que abajo, aunque ahora que me fijo, hay una enorme cantidad de atajos para ahorrar espacio en el cartucho, la imagen va recortada, más allá de otros cambios evidentes en el color, pero tampoco hay animación en el agua.


En cuanto a las animaciones esta el problema de la plataforma origen, sin coma flotante y sin subdivisión de pixel en un port directo, algunas animaciones o se ven demasiado rápido o cuando intentan hacerlas lentas van como a trompicones, hablo más bien de intros y cutscenes, in-game la verdad es que me gustan mucho las animaciones, esta en particular (tomada de N64) me hizo gracia verla, aquí no es tanto eso que comento sino la transición que usaron ya que hay un salto notable de pixeles de un estado a otro.


Mi punto en este sentido es que si hubieran programado usando las capacidades de N64 podrías ver hasta el ligero tembleque de las piernas.


Pues nada completado LeonA ahora a por ClaireB, imagino que el randomizer requerirá otra partida abajo con ClaireA y LeonB, ya que al menos en PSX no se turnan.

@Conker64 @Sogun 440x330p no son 24 kHz ¿? ¿Lo habéis probado en un CRT común con una N64 real? Porque no debería verse la imagen si no es tri-frecuencia.

@Sexy MotherFucker
Es la resolución que trae Goldeneye en los menús pero conservada en la parte jugable, no es nada experimental

@Sexy MotherFucker
En un CRT con la consola real se ve en progresivo. Comprobado por mí mismo ya que tenía la misma duda ante una resolución tan extraña.

Cinco mensajes más atrás puse algunas imágenes comparativas del juego corriendo a distintas resoluciones en el hardware real.

Increíble lo que han logrado con el dinopatch en Dinosaur Planet



Como referencia asi se ve al arrancar el juego sin parche

@Sogun ... ¿Seguro que no es entrelazado? La prueba de fuego es con 1 RGB CSYNC: si florecen scanlines reales en dicha resolución, entonces es progresivo.

Las Model 1, 2, y 3 de SEGA funcionaban a 496x384 (24 kHz), y precisaban de un monitor compatible...

@Conker64 con suerte algún día aparece una beta avanzada y jugable del Resident Evil 0 y podremos ver como sería un Resident programado de cero para aprovechar al N64.

@ALCAMJI Puedes probarlo tu mismo en:
https://dinosaurpla.net/Main/Tech/Mods/

@Sexy MotherFucker El UltraHDMI chiva que es progresivo, y lo detecta por el timing de la señal así que no hay fallo posible.

Pongo unas capturas en spoiler. La primera es en HiRes y la segunda el juego normal:


Se aprecia una mejora en la resolución vertical.
Es un poco extraño ya que siendo vídeo progresivo la resolución vertical esta limitada a 240 líneas. De alguna manera el VI comprime las 330 líneas en 240, mejorando el anti-aliasing, al estilo de los primeros FSAA de PC. Por supuesto también ayuda la mejor resolución horizontal.

@Conker64, ¿tienes información de como maneja el VI cuando la resolución vertical del framebuffer es mayor que la resolución de la salida de vídeo?

@EMaDeLoC

De alguna manera el VI comprime las 330 líneas en 240

Tiene que ser eso por cojones, ya que los CRT de toda la vida son de 15 kHz.

Ahora estaría interesante ver si el VI también hace un apaño con 31 kHz; o sea Embutir 480 líneas progresivas en 240

@Sexy MotherFucker Pues sería interesante, y según los datos de la salida de vídeo del RCP...

Ni de coña.

El pixel clock efectivo de la salida del RCP es de 12'5MHz y es una velocidad que ya es justita para sacar NTSC y PAL a 15kHz. Es obvio que para sacar 31kHz necesitaría por lo menos el doble de velocidad de pixel clock.
Bueno, quizá, siendo creativos, y si el VI se puede ajustar al milimetro, podría sacar 31kHz pero la resolución horizontal se vería drásticamente recortada a 320 o incluso menos. Que supongo que no es lo que estás buscando.

@EMaDeLoC
Se reescala supongo, no he tocado demasiado VI, pero es algo común.

El tamaño máximo del framebuffer que permite N64 es en realidad 1024x1024, de hecho le pues enviar eso a VI, pero lo que más se aconseja si el rendimiento lo permite son 640x240, ya que evita el reescalado.

@Conker64 Bueno, si el framebuffer puede ser de 1024 x 1024 no hay nada más que decir, no solo hace reescalado, además hay hardware dedicado a ello ya que lo hace muy rápido (para un hardware de 1996).
640x240 se ajusta como un guante a la salida de vídeo del RCP y al estandar de vídeo NTSC. Realmente puede llegar a 640x288 en PAL, pero limitado a 50fps. El caso es que al no necesitar reescalado puede ayudar al rendimiento, pero visto, en general, que el reescalado cuesta mucho menos que renderizar una escena, mejor aplicar reescalado.

Ya se mencionó esto hará un año y pico, pero esta bien recordarlo.

Un tío se encarga de reproducir el RCP en un FPGA y ha llegado a avanzar bastante:


Pero este vídeo es del año pasado, aunque asegura que ha ido haciendo progresos:


La placa de desarrollo que esta usando vale más de 500€ https://es.rs-online.com/web/p/kits-de-desarrollo-de-fpga/1346477/
Y aparte del FPGA lleva un R4300 metido en una placa aparte.

De momento como curiosidad esta bien. Con suerte seguirá con el progreso y conseguirá replicar o incluso mejorar el RCP (habla de overclokearlo a 90MHz) y quien sabe si dentro de 10 años el FPGA será algo más asequible...

Hola, ¿puede decirme alguien como se llamaba el efecto grafico que ofrecía sobre las texturas y que no tenia la PS1? mip mapping o así se llamaba?. Es decir, era que se veía muy distinto las texturas sobre los poligonos a como se veía en la PS1, que era todo como mas pixelado o así.

N64



PS1

@dinodini ¿antialising? De todas formas la primera captura está renderizando la resolución x2 o x4 y la de PS1 justo lo contrario, está pillando la res original y estirando la imagen lo que acentúa el granulado.

SuperPadLand escribió:@dinodini ¿antialising? De todas formas la primera captura está renderizando la resolución x2 o x4 y la de PS1 justo lo contrario, está pillando la res original y estirando la imagen lo que acentúa el granulado.

Si, creo que se llamaba asi, antialiasing. Ese efecto no lo tenía ni la PS1 ni Saturn, verdad? Era un difuminado y una sensación de solidez en los polígonos que me encantaba, y que eche en falta en la PS1.