[HILO OFICIAL] Nintendo 64

@Bimmy Lee realmente con que optimicen lo que ya existe ya sería la hostia. Y esto me recuerda que había un tipo desarrollando un programa que permitiría optimizar la mayoría de juegos de N64 de forma automática o algo así, hay juegos en N64 que pasarían de pesados-aburridos a disfrutables sólo con funcionar más fluidos (Aidyn Chronicles).

Señor Ventura escribió:emm... 90k polígonos por segundo a 20fps, significaría que con la optimización a 60fps está sacando mas de 200k polígonos por segundo con todas las opciones gráficas activadas.

A menos que haya tocado cosas en el proceso, claro.

M64 va a 30fps con caídas esporádicas (NTSC). Y la optimización no va a 60fps constantes, va a unos 40fps cuando tiene que renderizar escenario con algo de distancia. Goldeneye alcanza los 60fps si apuntas al cielo por ejemplo (no recuerdo si de forma normal o con el debug para desactivar la limitación).

Y creo que ha tocado cosas en el proceso, no puedo ver el vídeo con audio, pero creo que ha desactivado el antialising por ejemplo.

Hola compas. Hay algún cartucho everdrive o clónico económico que funcione con romhacks de mario?

Saludos!!

Super Mario 64 es un juego muy modesto en cuanto a carga poligonal y por ello funciona la mayor parte del tiempo a 30 fps a pesar de ser un juego de lanzamiento, con herramientas de desarrollo poco depuradas y conocimientos de programación y modelado en 3D mejorables.

Mueve bastante menos de 90.000 triángulos por segundo, que a 30 fps significaría 3.000 polígonos por frame. El modelo de Mario con la gorra son 752, y los niveles ENTEROS están alrededor de los 1000 polígonos (Bob Omb Battelefield son 962 polígonos, Whomp's Fortress con la torre 1205, Jolly Roger Bay 722, Cool Cool Mountain 929, Lethal Lava Land 1158, Wet Dry World 725 la parte superior y 768 la parte inferior, Big Boo's Haunt se queda un poco por debajo de los 3.000 pero son muchas salas separadas y puntos de cámara fijos). Muchos elementos como árboles y monedas son 2D, y los enemigos en 3D son simples y con un popping agresivo.
Debe de dibujar unos 2.000 polígonos por frame como mucho, y eso considerando que el microcódigo es muy ineficiente y renderiza todo el nivel a la vez (o al menos el trozo que esté cargado). Es decir, que movería alrededor de unos 60.000 polígonos por segundo.
Las partes donde el rendimiento sufre suelen ser zonas donde hay grandes superficies semitransparentes como el tercer nivel cuando entras la primera vez que tiene varias capas de niebla. Lo del submarino quizás se deba a la mala optimización de las colisiones, a parte del agua semitransparente y la falta de optimización de la compilación del código. Otros niveles con agua como Wet Dry World o Tiny Huge Island no sufren esas ralentizaciones.


Se considera que la N64 mueve alrededor de 90.000 polígonos por segundo con todos los efectos activados. Eso equivaldría a 3.000 polígonos por escena a 30 fps o 4.500 a 20 fps que se ajusta a muchos juegos punteros. World Driver Championship se saldria de la norma porque renuncia al Z-buffer y supera holgadamente los 100.000 polígonos por segundo. Indiana Jones and the Infernal Machine también renuncia al Z-buffer, pero renderiza en alta resolución y su rendimiento es mucho peor.
En realidad ya hemos discutido muchas veces que hay muchos factores que afectan al rendimiento y no sólo la carga poligonal. Cosas como varias capas de polígonos semitransparentes para simular humo, el número objetos con los que se pueda interactuar en el escenario de los que hay que calcular las colisiones e incluso la física, efectos de luz en tiempo real, efectos del buffer de imagen, la IA de los enemigos, la resolución de la pantalla....


Vamos, que ver a Super Mario 64 funcionar a 60 fps y con el mismo aspecto gráfico en el hardware original no es para nada descabellado. Juegos muchísimo más complejos gráficamente, con mejores herramientas de desarrollo y más conocimientos de lo que se hacía ya tenían rendimientos similares.
En el vídeo se ve la evolución de un hack con entornos más cargados que los del juego original y con un motor gráfico que ya había sufrido multitud de mejoras y cómo tras aplicar un nuevo mogollón de optimizaciones el rendimiento prácticamente se ha duplicado.
Ya no es que el juego original pueda moverse a 60 fps, es que va a ir sobrado. Lo que ya no sé es si sería posible subirle la resolución desde los 256x224 a 320x240 (es un incremento del 33%). O aplicar filtrado trilineal. Tampoco parece que conserve ningún tipo de antialising.

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

En otro orden de cosas, hace poco que Olivieryuyu actualizó su blog donde describe el desarrollo de un microcódigo propio basado en el que usó Factor 5 y que él mismo destripó para poder emularlo en el plugin GlideN64:

https://olivieryuyu.blogspot.com/

Es interesante ver los objetivos que se ha marcado al final del texto:
* Point lighting
Iluminación por píxeles en lugar de por vértices, que ofrecería unos degradados más naturales y unos efectos de luces en escenarios espectaculares.

* Triangle strips
Esto sirve para que los modelados ocupen menos en memoria. Los vértices que comparten toda la información se consideran como uno solo en lugar de tener un vértice por cada triángulo. Esto ya lo hace el Editor del GoldenEye, así que no sé si se refiere a otra cosa o si no estaba implementado en el microcódigo de Factor 5.

* "Texture rectangle" done by the mean of a triangle
A ver si alguen sabe a lo que se refiere con esto, porque a mi me suena a renderizar por quads.

* RDP displaylist (you simply don't process the RDP commands one by one in the RSP but you simply retrieve them from RDRAM and ship them directly to the RDP).
Alguien con más conocimientos del hardware que nos explique esto y qué implicaciones tendría, aunque suena a mejora en el rendimiento.

* Save the average of the Z of a triangle in a unused part of the RDP triangle command, send data to RDRAM, then the CPU would sort by Z the data and send to the RDP. We could get rid of Z buffer in this way.
Se elimina el Z-buffer y en su lugar se usa otro sistema más simple para ordenar los triángulos respecto a la cámara. No estoy muy convencido de cómo quiere hacerlo y sospecho que va a dar problemas con polígonos que se intersectan como por ejemplo el plano del agua del Mario 64.

* For special TRIs, check first if they are not trivially rejected before executing the rest of the command. Potentially to be done as well for TRI command
Suena a más mejoras de rendimiento

* Rewrite the organization of the microcode and the overlays. Currently we have no more IMEM space!
¿Qué era el IMEM? Me suena a que consiguiendo más espacio puede preparar al microcídigo para hacer más cosas chulas.

* Rejection instead of clipping as an option (with usage of precised clip ratio macro)
¿Esto se refiere al descarte de polígonos que quedan fuera del punto de vista de la cámara? Podría significar un nuevo paso en la optimización de la carga poligonal en pantalla. Pasaríamos de renderizar niveles enteros como en Mario 64, a renderizar los trozos del nivel que son visibles como en GoldenEye a finalmente renderizar sólo los polígonos en pantalla con este microcódigo. Suena demasiado bien.

* Finally port the ucode to libdragon, get rid of any reference to libultra
@conker64 ¿Esteríamos más cerca de tener un kit de desarrollo funcional y poder crear motores gráficos en 3d eficientes?

* Last but important thing: name the microcode 🙂

Avanza lento pero es apasionante.

Sogun escribió:* "Texture rectangle" done by the mean of a triangle
A ver si alguen sabe a lo que se refiere con esto, porque a mi me suena a renderizar por quads.

Suena a que en vez de usar dos triángulos para un sprite, usar uno y que el RDP cree otro automáticamente. En pantallas llenas de sprites como juegos 2D o los marcadores de Wave Race (que está a tope) ahorraría memoria y procesamiento.

Sogun escribió:* RDP displaylist (you simply don't process the RDP commands one by one in the RSP but you simply retrieve them from RDRAM and ship them directly to the RDP).
Alguien con más conocimientos del hardware que nos explique esto y qué implicaciones tendría, aunque suena a mejora en el rendimiento.

Literalmente lo que significa, que en vez de que el RSP coja un comando de la RDRAM para luego pasarselo al RDP, que el RDP los reciba directamente. Elimina tiempos muertos del bus y agiliza el procesado de la displaylist.

Sogun escribió:* Save the average of the Z of a triangle in a unused part of the RDP triangle command, send data to RDRAM, then the CPU would sort by Z the data and send to the RDP. We could get rid of Z buffer in this way.
Se elimina el Z-buffer y en su lugar se usa otro sistema más simple para ordenar los triángulos respecto a la cámara. No estoy muy convencido de cómo quiere hacerlo y sospecho que va a dar problemas con polígonos que se intersectan como por ejemplo el plano del agua del Mario 64.

Pues pinta que lo quiere hacer tal y como describe, calculando el Z del centro del triángulo y ordenandolos con la CPU. Este método es simple y provocaría clipping en triángulos que se crucen, pero es mucho más rápido y bastaría con un buen diseño del 3D para evitar la mayoría de problemas. Hablamos de un rendimiento como el WDC sin el engorro de crear microsintrucciones específicas para el RCP.

Sogun escribió:* Rewrite the organization of the microcode and the overlays. Currently we have no more IMEM space!
¿Qué era el IMEM? Me suena a que consiguiendo más espacio puede preparar al microcídigo para hacer más cosas chulas.

La IMEM es la memoria de instrucciones del RSP. Supongo que quiere optimizar el microcódigo para que ocupe menos y así no tener que cargarlo cada cambio de operación o que haga más cosas de una vez.

Sogun escribió:* Rejection instead of clipping as an option (with usage of precised clip ratio macro)
¿Esto se refiere al descarte de polígonos que quedan fuera del punto de vista de la cámara? Podría significar un nuevo paso en la optimización de la carga poligonal en pantalla. Pasaríamos de renderizar niveles enteros como en Mario 64, a renderizar los trozos del nivel que son visibles como en GoldenEye a finalmente renderizar sólo los polígonos en pantalla con este microcódigo. Suena demasiado bien.

Si, parece que significa eso. Libraría a los programadores de crear rutinas para reducir los polígonos a renderizar según la posición de la cámara. Desde luego que suena bien.

Sogun escribió:* Finally port the ucode to libdragon, get rid of any reference to libultra
@conker64 ¿Esteríamos más cerca de tener un kit de desarrollo funcional y poder crear motores gráficos en 3d eficientes?

Al menos para esa parte del microcódigo, y quitada esa parte que es la más chunga de la N64, animaría al resto de la comunidad a terminar un kit.

Sogun escribió:Avanza lento pero es apasionante.

djlogan83 escribió:Hola compas. Hay algún cartucho everdrive o clónico económico que funcione con romhacks de mario?

Saludos!!

El ED64 Plus es copia de un modelo antiguo de everdrive, yo lo tengo y funciona muy bien

https://a.aliexpress.com/_mrtoG5g

X_Glacius escribió:

djlogan83 escribió:Hola compas. Hay algún cartucho everdrive o clónico económico que funcione con romhacks de mario?

Saludos!!

El ED64 Plus es copia de un modelo antiguo de everdrive, yo lo tengo y funciona muy bien

https://a.aliexpress.com/_mrtoG5g

Y puedes jugar con romhacks de mario?

Gracias por en elace!

El problema de los mods de Super Mario 64, es que la mayoría están pensados para jugarlos en emulador y no tiran en N64, no es por el flashcard.

Salud.

@Sogun el Mario a 60fps iría muy apretado no? Lo digo porque 60K poligonos a 30fps implicaría irnos a los 120K en 60fps. Entiendo que se desactivarían cosas para ganar rendimiento, pero aun así ¿Se puede ganar 30K poligonos desactivando cosas y que el juego visualmente no empeore notoriamente?

El principal problema de N64 parece ser siempre la resolución, cualquier subida en ella tiene una penalización importante en el rendimiento ¿No hay algo que se puede hacer para ayudar con esto? ¿Usar los 8MB de RAM?




@djlogan83 tienes que mirar que dichos hacks sean comaptibles con hardware original, lo suelen indicar en las descripciones. Yo tengo unos cuantos y funcionan bien.

Igual este tipo de preguntas técnicas vendrían mejor en el otro hilo

Sogun escribió:* RDP displaylist (you simply don't process the RDP commands one by one in the RSP but you simply retrieve them from RDRAM and ship them directly to the RDP).
Alguien con más conocimientos del hardware que nos explique esto y qué implicaciones tendría, aunque suena a mejora en el rendimiento.

Eso ya lo hace la libdragon, la CPU procesa los comandos del programa y los envía a RDRAM, el RDP lee la lista de la RDRAM (se ejecutan en orden), la otra forma es que el RSP se comunique directamente con el RDP en el XBUS, pero no hay memoria para almacenar todos los comandos, tiene que ir en una sucesión de cargas.

Por lo visto, Fast3D (el ucode que usan los juegos de lanzamiento) estaba mal estructurado y copiaba memoria a buffer temporales, para luego volver a mover esa memoria a destino, entre otras cosas.

Una duda, usando el ED64 Plus que tiene selector PAL-NTSC, ¿hay diferencia de jugar roms NTSC en una consola PAL a hacerlo en una consola NTSC? Gracias!

@X_Glacius inapreciables. La ROM es la que le dice a la consola a que hz funcionar, si 50 o 60. Pero por el propio diseño de las consolas estos hz no son exactos, así que usar rom NTSC en consola PAL hace que vaya a 61hz y una rom PAL en NTSC a 49hz.

Resultado: El juego va un "nada" más acelerado o más lento según el caso que usándolo en su consola propia. Yo juego casi todo NTSC a esos 61hz y no he tenido ningún problema ni noté nada. Y ahora que te he contado esto creo que ya sé porque la capturadora de vídeo me grababa los juegos de N64 a golpes, seguramente esta frecuencia "rara" de problemas

SuperPadLand escribió:@X_Glacius inapreciables. La ROM es la que le dice a la consola a que hz funcionar, si 50 o 60. Pero por el propio diseño de las consolas estos hz no son exactos, así que usar rom NTSC en consola PAL hace que vaya a 61hz y una rom PAL en NTSC a 49hz.

Resultado: El juego va un "nada" más acelerado o más lento según el caso que usándolo en su consola propia. Yo juego casi todo NTSC a esos 61hz y no he tenido ningún problema ni noté nada. Y ahora que te he contado esto creo que ya sé porque la capturadora de vídeo me grababa los juegos de N64 a golpes, seguramente esta frecuencia "rara" de problemas

gracias! me alegro de haber ayudado jaja

Yo hay una cosa de la que estoy convencido desde hace años, y es que, de haber un cartucho lo suficientemente grande (llámese 64dd) de unos 600/700 megas, la n64 habría podido con el motor de half life, que si no recuerdo mal estaba basado en el de quake2, que la 64 movía sin despeinarse.
Viendo cosas como perfect dark, la verdad es que half life tampoco impresionaba demasiado en su época.
Que opinais vosotros? Habría podido moverlo a palo seco la 64?
Es cierto que habría que recortar texturas, porque si no recuerdo mal, half life pedía 32mb de ram y la 64 apenas tenía 8mb con el expansion pack, pero creo que tanto de procesador como de gráfica iba bien equipada.

El motor de HL es una modificación del de Quake, la RAM tal vez no fuera tanto problema ya que en teoría se podría hacer streaming desde el cartucho, aún así habría que adaptar las texturas ya sea cortandolas y mantener su resolución a costa de mayor geometría en los escenarios o mantener la geometría original y bajar la resolución de las texturas, los modelados de personajes también habría que bajarle geometría y no creo que se pudiera mantener la animación facial,aún así, creo que iría bastante justo de fps, como le pasa precisamente a Perfect Dark.

Salud.

¿Habéis jugado al Custom Robo? Es un exclusivo de Japón que tiene traducción al inglés. Estuve ayer echando una partidilla y pinta muy bien. Tiene un rollo Pokémon pero con robots y combates en tiempo real.

https://www.romhacking.net/translations/3237/

Si, claro, desde luego iria a una media de 20fps siendo generoso, pero vamos, por la época tampoco noa habríamos enterado tanto, estábamos acostumbrados a ese framerate, a turok2 me remito.
Pero vamos, habría sido la bomba, evidentemente con lo que vendía n64 ya en esos años (99, 2000...) ni se molestaron en plantearselo, pero me gusta pensar que habría sido muy posible

Debido al límite del cache de texturas de la N64, no hace falta tanta RAM. Con 1MB puedes guardar mínimo 250 texturas, que son más que de sobra para un nivel y los diferentes assets (textos, iconos, etc). Te quedan 3MB para el resto, código, geometría, sonido, y framebuffer.
El problema de HL es que tiene bastantes diálogos y bastantes niveles con texturas distintas, y en el exterior hay muchos fondos. La geometría es bastante detallada. Habría que hacerle un buen downgrade al juego que ya en el original es bastante simplista en cuanto a gráficos (pero puntero en la época).
Pero sería interesante de verlo.

Dudo mucho que pudiera trasladarse la experiencia original del HL a N64, una adaptación o un spin-off sería otro tema, pero en HL no sólo está el apartado gráfico a recortarse, el juego presumía de un motor de físicas muy complejo y realista, además sino recuerdo mal los enemigos tienen unas IA bastante avanzadas y a su vez pone bastantes al mismo tiempo en algunos momentos, luego hay que sumar el festival de efectos de explosiones, rayos, etc.

En DC la beta en momentos de acción cae a 10-15fps, la versión de PS2 tiene zonas donde va a 60fps, pero también tiene zonas de acción donde baja a 20-25fps.

EMaDeLoC escribió:Debido al límite del cache de texturas de la N64, no hace falta tanta RAM. Con 1MB puedes guardar mínimo 250 texturas, que son más que de sobra para un nivel y los diferentes assets (textos, iconos, etc). Te quedan 3MB para el resto, código, geometría, sonido, y framebuffer.
El problema de HL es que tiene bastantes diálogos y bastantes niveles con texturas distintas, y en el exterior hay muchos fondos. La geometría es bastante detallada. Habría que hacerle un buen downgrade al juego que ya en el original es bastante simplista en cuanto a gráficos (pero puntero en la época).
Pero sería interesante de verlo.

¿No alcanza el cartucho para transferir texturas y datos al vuelo según se vaya necesitando?.

Es decir... guardar todo un nivel en 4MB sin opción a cambiar nada durante el mismo...

Señor Ventura escribió:

EMaDeLoC escribió:Debido al límite del cache de texturas de la N64, no hace falta tanta RAM. Con 1MB puedes guardar mínimo 250 texturas, que son más que de sobra para un nivel y los diferentes assets (textos, iconos, etc). Te quedan 3MB para el resto, código, geometría, sonido, y framebuffer.
El problema de HL es que tiene bastantes diálogos y bastantes niveles con texturas distintas, y en el exterior hay muchos fondos. La geometría es bastante detallada. Habría que hacerle un buen downgrade al juego que ya en el original es bastante simplista en cuanto a gráficos (pero puntero en la época).
Pero sería interesante de verlo.

¿No alcanza el cartucho para transferir texturas y datos al vuelo según se vaya necesitando?.

Es decir... guardar todo un nivel en 4MB sin opción a cambiar nada durante el mismo...

En un cartucho tendrás que comprimir datos así que no te va a alcanzar para hacerlo al vuelo ya que necesitas un tiempo de carga para descomprimirlos, esto pasa en muchos juegos de N64. De todas formas en el supuesto que se habla aquí es de un formato físico de 600-700mb y eso en esa época sólo puede ser CD, no existe otra tecnología que permita esto así que tienes que adaptar el juego a que tendrás que volcar datos cada poco, aquí ya entraríamos a teorizar que velocidad de lector y que caché de datos tendría si saliera para N64, pero siendo Nintendo y su "que no cueste más que cuatro duros" no apostaría demasiado alto.

La alternativa en la época fueron las unidades Zip: https://hardzone.es/reportajes/que-es/h ... iscos-zip/

Pero el lector costaba tanto o más que un lector CD y el "disquete" era más caro que un CD y con menos capacidad (1994 a 1999 100megas, 1999 a 2002 250 megas y 2002 en adelante 750mb), a mayores no eran confiables ya que los discos morían sin más y que en 1998 llevó a la compañía a juicio por ello.

En esa época sólo el CD podía ofrecer esas capacidades de datos a un precio económico, lo ideal hubiera sido que las consolas CD tuvieran más RAM o un HDD de 50-100mb para instalar los datos más importantes y reducir cargas, pero a saber cuanto costarían entonces.

@X_Glacius Yo no lo conocía y tiene buena pinta, me lo apunto en mi extenso backlog xD

Señor Ventura escribió:¿No alcanza el cartucho para transferir texturas y datos al vuelo según se vaya necesitando?.

Es decir... guardar todo un nivel en 4MB sin opción a cambiar nada durante el mismo...

Hay juegos de N64 y PS1 que con la RAM disponible los escenarios son enormes. Carmageddon 64, que está horriblemente optimizado, tiene toda la ciudad para que la recorras cargada en memoria sin cargar datos al vuelo.
Que además según el escenario no necesitas 250 texturas, te pueden bastar 100 y éstas estar en tamaños menores de 4KB, así que hablamos de menos de 400KB de memoria ocupada y todo el resto en lo que el juego necesite.

En teoría los cartuchos alcanzan los 5MB/s de transferencia, pero si cargas toda la memoria vas a provocar un parón en el juego por estar el bus y la RAM ocupados, aunque sea de 1 segundo. Para hacerlo de forma transparente habría que poner zonas concretas y simples que permitan la carga progresiva de los datos sin afectar al juego, suponiendo claro que quieras un efecto de "nivel continuo" como el de HL. El problema es que no había tal "nivel continuo" porque incluso en PC te comias una pantalla de carga al ir de un sitio a otro. Y en PC los requisitos mínimos del juego eran bastante superiores a los de la N64, especialmente con sus 24MB de RAM.
Hay que contar que si algunos datos están comprimidos, comerán CPU, por lo que los datos deberían ser muy sueltos y pequeños y sustituyendo poco a poco los del juego para que el jugador no lo note. Es una pesadilla para un programador.

Poderse se puede hacer, hay algún juego que lo hace, el Indiana Jones si no me equivoco, pero lo hace de textura en textura, no todo un nivel de golpe.

@EMaDeLoC Exacto, es tal cual comentas, si os fijais los escenarios en half life tampoco son tan exageradamente grandes, pues existen pantallas de carga bastante terribles entre secciones del mapa, se podría hacer esto mismo en n64, incluso dividiendo en porciones más pequeñas los mapas y metiendo más pantallas de carga, que con la velocidad de carga del cartucho seguramente irían mucho más rápido que si lo tuvieras que cargar desde un cd o incluso desde un disco duro mecánico de los que se usaban en los pc´s de la época.
Realmente yo no veo nada en half life que no se vea en perfect dark, si es verdad que la variedad y detalle de texturas de half life es muy superior, pero a nivel de físicas, destrucción de entorno, ia de los enemigos, lo veo muy similar.
Otra cosa son las animaciones faciales, eso entiendo que habría que descartarlo, pero vamos tampoco es un gran sacrificio a nivel jugable

Si con las "animaciones faciales" os referis a esto, tampoco es que sea tecnología alienígena que no pueda mover la N64, solo abren y cierran la boca. Es ponerle 6 triángulos más, literalmente, a la cara y animar los vertices.
En Turok 3 el nivel de complejidad de la animación facial es muy superior: https://youtu.be/8s71AGKtMwc?t=4974

Más me preocuparía a mí la compresión de todos los diálogos, que hay bastantes.

Bueno, entonces si podemos mover un HL tan fácilmente, el Daytona USA del que hablamos alguna vez ni os cuento.

@SuperPadLand yo siempre digo lo mismo. No creo que HL se mueva fácilmente en N64, pero sí creo que dado el suficiente sacrificio /trabajo, con sus pertinentes modificaciones o recortes, un port funcional no vomitivo puede ser posible. Seguramente empeorando el sonido, con menos geometría en X cosa, o animaciones algo peores en otro lado y lo típico, pero igual puede salirte un juego imprescindible del catálogo aún así
Sé que no es tu caso, pero mucha gente piensa siempre en ports 1:1 de la máxima calidad del PC más top del momento, cuando siempre nos referimos a adaptaciones a la consola, con sus cosas buenas y malas.

Un saludo!

@Falkiño ah no, si yo lo digo porque me hace gracia que cuando hablamos del Daytona USA arcade del 93, todo eran problemas para que la consola pudiera moverlo a 60fps y es un juego que se ejecuta en una SEGA Model 2 que calza una CPU de 25mhz y usa 1 mega de RAM, pero ahora el Half Life que pide una CPU de 133mhz y 24mb de RAM más un disco duro, apenas tiene problema si reduces la geometría.

Y no digo que no fuera posible su adaptación que cosas más imposibles hemos visto como Quake II en PS1, Just Cause en PS2, Dead Rising en Wii, Alone in the Dark IV en GBC, etc. A saber como quedaría, yo creo que el problema del port no va tanto en la geometría y calidad gráfica general, sino que ese juego pone bastantes enemigos en pantalla con su IA y tiene un motor de físicas que le queda grande a una consola de quinta gen, como ya dije incluso en PS2 en momentos de acción cae a 20-25fps.

Veo más realista pensar que Unreal hubiera podido salir en N64 en la época porque es similar a Half Life, pero pone menos enemigos en pantalla y lo más importante, no tiene motor de físicas. De hecho Unreal estuvo en desarrollo para PS1 y lo cancelaron, supongo que porque vieron que tras ir sacrificando cosas para que funcionase en PS1 lo que les quedaba era un FPS del montón que hasta mancillaba el nombre del original: https://www.unseen64.net/2009/06/03/unr ... cancelled/

Pero en N64 con 8MB de RAM y tres veces más CPU yo lo veo viable.

Edit: Ojo que los vídeos ejecutan los archivos del proyecto de PS1, pero en el motor Unreal de PC (no hace falta fijarse mucho porque no hay tembleque y se mueven fluidos).

@SuperPadLand cuando usted lleva razón, lleva razón xD

Sobre Half-Life en Nintendo 64 ya se habló en un hilo hace tiempo (¡9 años!).
https://www.elotrolado.net/hilo_crees-que-half-life-puede-correr-en-nintendo-64_1901022

No he mirado todos los mensajes que escribí, pero sigo pensando lo mismo que en el primero. No sé si se puede portar el motor tal cual, pero se puede hacer algo que visualmente sea igual a Half-Life. Por poder, se podría ver exactamente igual aumentando la carga poligonal para no perder detalle en las texturas a costa de mandar el rendimiento al carajo. Pero simplificando algunos elementos y ajustando las texturas con cabeza se podría conseguir un equilibrio muy bueno.
Eso si no tenemos en cuenta que hay que meter todo el juego en un cartucho con capacidad limitada. Entonces sí que habría que hacer sacrificios en la calidad de la textura y complejidad de escenarios (además de los audios).

Hablaba en mi primer mensaje sobre el efecto de la linterna y más tarde recordé que en la intro del Donkey Kong 64 hay algo parecido, pero seguramente es posible porque se trata de una superficie plana. Ahora se me acaba de ocurrir que quizás se pueda hacer algo como las Lentes de la Verdad de los Zelda que dé el pego.

SuperPadLand escribió:es un juego que se ejecuta en una SEGA Model 2 que calza una CPU de 25mhz y usa 1 mega de RAM

Con perdón de la expresión, los cojones...


La model 2 lleva una CPU RISC a 25MHz, luego dos Z80 de apoyo, un 68000 para el sonido y 6 procesadores DSP para los gráficos. Y el mega de RAM se lo come solo en framebuffer.
Aquí todas las especificaciones.

Si fuese solo una CPU de 25MHz y 1 MB de RAM, no habrían tenido tantos problemas con el port del Daytona a Sega Saturn.

Sogun escribió:Sobre Half-Life en Nintendo 64 ya se habló en un hilo hace tiempo (¡9 años!).
https://www.elotrolado.net/hilo_crees-que-half-life-puede-correr-en-nintendo-64_1901022

No he mirado todos los mensajes que escribí, pero sigo pensando lo mismo que en el primero. No sé si se puede portar el motor tal cual, pero se puede hacer algo que visualmente sea igual a Half-Life. Por poder, se podría ver exactamente igual aumentando la carga poligonal para no perder detalle en las texturas a costa de mandar el rendimiento al carajo. Pero simplificando algunos elementos y ajustando las texturas con cabeza se podría conseguir un equilibrio muy bueno.
Eso si no tenemos en cuenta que hay que meter todo el juego en un cartucho con capacidad limitada. Entonces sí que habría que hacer sacrificios en la calidad de la textura y complejidad de escenarios (además de los audios).

Hablaba en mi primer mensaje sobre el efecto de la linterna y más tarde recordé que en la intro del Donkey Kong 64 hay algo parecido, pero seguramente es posible porque se trata de una superficie plana. Ahora se me acaba de ocurrir que quizás se pueda hacer algo como las Lentes de la Verdad de los Zelda que dé el pego.

Cuando hablamos de la capacidad potencial de la máquina para hacer tal o cual cosa, el tamaño del cartucho no puede ser una traba. No vamos a estar en 1996 toda la vida.

Hace ya tiempo que un cartucho de 600MB no es nada.

@EMaDeLoC y no crees que un HDD combinado con 24 megas de RAM viene a equivaler a lo mismo gráficamente? Amén de que HL también se apoya en aceleradora gráfica.

@SuperPadLand Siendo justos, HL se ejecuta sobre un sistema operativo que se comerá un buen cacho de RAM. De procesador el mínimo es un Pentium 133MHz, así que a nivel de CPU no es muy diferente de la N64.
Pero sin duda haría falta recortes y trabajo para adaptar una versión a otra.

@EMaDeLoC y de gráfica que necesita?

@SuperPadLand Creo que se podía ejecutar los gráficos por software a 320 x 240, pero no estoy seguro. A trompicones con un 133, claro, pero puede correr.

SuperPadLand escribió:@EMaDeLoC y de gráfica que necesita?

Puede funcionar sin aceleradora 3D como el Quake 1, al fin al cabo el motor del HL es una modificación del Quake engine.

Salud.

@dirtymagic es que es eso, yo creo que la gráfiica de n64 daría de sobra para mover half life por hardware. De hecho creo que fué la primera consola en montar una aceleradora 3d no?

VideoGamePerfection vuelve a tener en stock su cable S-Video premium para N64

https://videogameperfection.com/product ... 64-svideo/

Ya solo quedan 9 y tardan bastantes meses en reponer el stock por si a alguien le interesa.

Ya que nos venimos arriba ¿Por qué no adaptar el Half Life 2 a 320x240?

SuperPadLand escribió:Ya que nos venimos arriba ¿Por qué no adaptar el Half Life 2 a 320x240?

Perfectamente viable a 1 Frame por minuto, 😅.
Así dura más el juego , un win - win de manual.

Salud.

SuperPadLand escribió:@Falkiño ah no, si yo lo digo porque me hace gracia que cuando hablamos del Daytona USA arcade del 93, todo eran problemas para que la consola pudiera moverlo a 60fps y es un juego que se ejecuta en una SEGA Model 2 que calza una CPU de 25mhz y usa 1 mega de RAM, pero ahora el Half Life que pide una CPU de 133mhz y 24mb de RAM más un disco duro, apenas tiene problema si reduces la geometría.

Y no digo que no fuera posible su adaptación que cosas más imposibles hemos visto como Quake II en PS1, Just Cause en PS2, Dead Rising en Wii, Alone in the Dark IV en GBC, etc. A saber como quedaría, yo creo que el problema del port no va tanto en la geometría y calidad gráfica general, sino que ese juego pone bastantes enemigos en pantalla con su IA y tiene un motor de físicas que le queda grande a una consola de quinta gen, como ya dije incluso en PS2 en momentos de acción cae a 20-25fps.

Veo más realista pensar que Unreal hubiera podido salir en N64 en la época porque es similar a Half Life, pero pone menos enemigos en pantalla y lo más importante, no tiene motor de físicas. De hecho Unreal estuvo en desarrollo para PS1 y lo cancelaron, supongo que porque vieron que tras ir sacrificando cosas para que funcionase en PS1 lo que les quedaba era un FPS del montón que hasta mancillaba el nombre del original: https://www.unseen64.net/2009/06/03/unr ... cancelled/

Pero en N64 con 8MB de RAM y tres veces más CPU yo lo veo viable.

Edit: Ojo que los vídeos ejecutan los archivos del proyecto de PS1, pero en el motor Unreal de PC (no hace falta fijarse mucho porque no hay tembleque y se mueven fluidos).

Leí hace tiempo que Unreal para N64 estuvo en desarrollo, o al menos era la intención, pero que finalmente se descartó. De hecho me suena que en la publicidad de Nintendo aparecía como un de los futuros juegos, aunque de esto no estoy seguro.

@guillian-seed pues de eso no tenía ni idea, sólo del de PS1.

Aparentemente iba a salir en 64DD pero fue cancelado por el retraso del accesorio y su poco éxito: https://nintendo64.fandom.com/es/wiki/Unreal

@EMaDeLoC que pena

De la versión playstation si hay imágenes... que no haya trascendido ni una de la versión n64... para mi que ni empezaron con el desarrollo.

dirtymagic escribió:

SuperPadLand escribió:Ya que nos venimos arriba ¿Por qué no adaptar el Half Life 2 a 320x240?

Perfectamente viable a 1 Frame por minuto, 😅.
Así dura más el juego , un win - win de manual.

Salud.

No veo el problema, hay que recortar la geometría y eliminar la iluminación, quizás algunos niveles hubiera que eliminarlos-adaptarlos claro, pero no lo veo mucho más complicado que lo que ya hemos teorizado con el primero.

@SuperPadLand Hombre no me jodas, sería otro juego, estamos hablando de que half life1 se puede portar tal cual sin sacrificar mucho más que texturas mas bajas, sonido de peor calidad y alguna pantalla de carga más.
Esto sería hacer un downgrade criminal, no tiene sentido, sería otro juego

@Bullrun bueno, lo de que el HL1 sólo se sacrifica eso no lo veo tan claro eh, yo creo que hay que recortar bastante más y con el HL2 pues se recorta al mismo nivel para recrear los escenarios y juego, podían incluso hacer un HL1 y 2 con el mismo motor gráfico para N64 por ejemplo.

@SuperPadLand Claro, pero es lo que digo, sería hacer un juego de nuevo con otro motor, no tiene mucho que ver con lo que estamos hablando, el motor source no va a tirar en una 64, ni siquiera creo que rule en una ps2

@Bullrun bueno, pero eso ya pasaría con el primero y no ha impedido teorizar