Hilo de detalles y curiosidades de N64

@EMaDeLoC Lo has puesto abajo del todo en el txt?
Yo estoy usando everdrive 2.5 original y el S.O original
Tambien tienes que usar la rom crackeada a las malas yo le pase le juego a shogun y le funciona te puedo pasar el mio para probar
Segun leo es en la v.3.0 donde pasa¿tienes ese por casualidad? y en los clones chinos

Ya de paso que la gente esta probando deberiamos postear los erroes que genera el juego para que la gente lo evite y no pueda guardar la partida hasta que la comunidad lo arregle empiezo yo

He intentado cambiar las opciones para que mostrara en vez de cineman full y demas pero no parecen hacer ningun efecto el codigo es:
8008C857 0041

*Empezar en ranura 2
*Intentar bajar por una cascada cerca de donde tienes que coger champiñones par curar al dinsaurio

@Flash-Original Ya he conseguido que funcionara. Metia DP=05 porque veía dos digitos en los demás juegos y no, es 5 a secas. Ahora ya arranca el juego. No he avanzado mucho, pero luce bien. Es una pena que se cancelase estando tan avanzado.

Yo ahora me gustaria saber la de antes de la inclusion de fox aunque quizas esten en los archivos de la rom

A mi sigue sin irme en el ED64 Plus con el firm Alt64. En cambio con el original poniendo en Options las opciones de TV en NTSC si que arranca. Seguiré indagando y sino a las malas juego con el firm original

Flash-Original escribió:cambia el nombre a Dinosaur Planet.z64

Ve save_db y pon abajo del todo DP=5 (Dinosaur Planet)

Edito de mas cosas que hay:

https://www.youtube.com/watch?v=wuXOgQ4F5ic&ab_channel=TheObsessiveGamer

Perdona he cambiado el nombre como dices pero lo siguiente no sé hacerlo. Que debo hacer concretamente ?

Gracias

@rioazuki tienes que irte al ed64/save_db.txt editarlo y poner abajo del todo DP=5 (Dinosaur Planet)

Así lo haré gracias

@Conker64 te animas a hacernos una de tus reviews del Dinosaur Planet o si la has hecho en otro foro o red social enlázala aquí

A mí me funciona en el ED64 poniendo el modo de guardado en Flash y sin ninguna historia más. De momento lo he probado poco y de lo poco que he visto, flipante. Rare en su línea de exprimir al máximo el potencial de las consolas de Nintendo.

Por cierto... ¿qué tal si Nintendo incluyera el Dinosaur Planet en la futurible Nintendo 64 Mini?

Davidkid escribió:
Por cierto... ¿Qué tal si Nintendo incluyera el Dinosaur Planet en la futurible Nintendo 64 Mini?

Lo veo complicado puesto que Rare actualmente es de Microsoft y quien sabe si quieran soltar la licencia además de ser un juego inconcluso, no es como con el starfox 2 de snes que si se completo.

En cuanto al framerate de Dinosaur Planet supongo que Rare hacia todas las optimizaciones en post producción cuando terminaban el desarrollo y sabemos que el juego no se termino, un ejemplo es Donkey kong 64 que tuvieron que implementar el expansión pak para corregir un bug cuando ya tenían completado el juego.

@SuperPadLand
Pues lo estuve jugando un poco en hardware original, a ver si saco algo de tiempo para una mini review o algo , ahora no sé si funcionaran la mayoría de herramientas de debug.

@Conker64 Estaré pendiente yo también de tu análisis...
En su época estaba flipado por lo que se enseñaban de este juego, lo esperaba con ganas, así que para mí es una maravilla que lo hayan podido localizar y liberar... pero aún no he podido probarlo, y me tira un poco para atrás el que tenga tantos cuelgues, la verdad. Esperaré un poco a ver si alguien se anima a revisarlo.
¿Sabes si hay alguien revisando los fallos para ir parcheándolo y que se pueda jugar sin tanto problema?

@Conker64 creo que por ahora no vas a poder deleitarnos demasiado porque tengo entendido que no corre en emulador

Una duda, porque hay dos cajas distintas del mando de color dorado japonés? En que se diferencian? En la parte trasera de las cajas en el nus-... uno termina en c y otro en t pero no les veo diferencia.

@bluedark
Pues no sé si llegaran a parchearlo para hacerlo 100% funcional, puede que eso lleve algo de tiempo.

Por lo poco que he visto están averiguando menús y cosas escondidas, trasteando con los filtros para activar/desactivarlos, etc

@SuperPadLand
Funciona pero es muy inestable, bueno en consola parece que también se cuelga, en los emus basta con ponerlo manualmente a 8MB de RAM y guardado flash, igual un ini actualizado de la base de datos sirva para corregir otras cosas.

Quizás lo ideal es probarlo en CEN64.


En base al dithering parece que corre a 320x240 o 320x228 sin contar las franjas negras.


Se pueden ver wireframes en otros emuladores, pero no creo que funcionen las herramientas de extracción de escena (polígonos), las texturas supongo que también se pueden extraer si no peta el emulador al usar el plugin necesario, todo esto como siempre sin calentarse mucho la cabeza, si fallan las herramientas ya se complica y hay que leer rom de otra forma.

Quizás sería interesante compararlo con cube y ver que cosas cambiaron, efectos, etc..

Pregunta sobre en antialiasing, ¿también se aplica sobre elementos 2D? ¿Porque no todos los textos se ven perfectamente definidos?

@ashurek El antialiasing de modelos 3D no se aplica a modelos 2D. Hay un ligero desenfoque horizontal que se aplica a toda la imagen.
En cuanto a los textos, ¿de qué juego? Los de Mario 64 se ven bien claros porque son pixeles blancos o negros como si fuesen textos de Super Nintendo o NES. En otros juegos los caracteres se diseñaban con su propio suavizado para hacer los textos redondeados en un CRT. El caso más notable son los Zeldas, que si los ves en emulador o con el UltraHDMI se ven horribles, pero en un CRT se ven muy bien.

EMaDeLoC escribió:@ashurek El antialiasing de modelos 3D no se aplica a modelos 2D. Hay un ligero desenfoque horizontal que se aplica a toda la imagen.
En cuanto a los textos, ¿de qué juego? Los de Mario 64 se ven bien claros porque son pixeles blancos o negros como si fuesen textos de Super Nintendo o NES. En otros juegos los caracteres se diseñaban con su propio suavizado para hacer los textos redondeados en un CRT. El caso más notable son los Zeldas, que si los ves en emulador o con el UltraHDMI se ven horribles, pero en un CRT se ven muy bien.

Debe ser esto que comentas. Por ejemplo en los Zelda no se ven muy definidos, la imagen lo explica perfectamente.

El pasado año me pillé una N64 jap con mod RGB y ahora pienso que habría sido mejor opción coger una con el mod que da la opción Deblur. En N64 hay dos filtros de antialiasing, uno solo se puede quitar vía hardware y el otro con códigos gameshark, ¿cual es el que añade dithering?

@ashurek En mi experiencia, el deblur del mod de Tim no funciona muy bien, depende mucho de un timming en un momento concreto que no siempre lo suele coger bien.

En un vídeo de My Life in Gaming te explican y muestran con detalle todos los métodos de deblur para la consola:

@Conker64
Una ocurrencia que acabo de tener y que no sé por qué no me había planteado antes con lo obsesionado que estoy con las texturas en N64...

Como sabrás, las texturas de 4 y 8 bits a color utilizan una paleta que se carga en 2 kB de la caché de texturas dejando únicamente otros 2 kB para la propia textura y sus mipmaps (si los tuviera). No sé cuánto ocupará una paleta de 16 o 256 colores, pero es evidente que hay mucho espacio sin usar en la caché cuando se trata de una textura a color.

¿No se podría mediante un nuevo microcódigo tener acceso a la memoria que quedase libre de los 2kB que contienen la paleta de colores? Si se consiguiera se podrían hacer texturas a color más grandes o tener filtro trilineal en los tamaños máximos actuales (64x64 a 4 bits de color y 64x32 a 8 bits de color). Sería especialmente útil para texturas de 64x64x4.

A Factor 5 les hubiese venido de lujo algo así para Rogue Squadron. Aunque creo que ellos preferían solucionar la pixelización de las texturas lejanas aumentando la resolución. Doom64 es otro que lo hubiese notado muchísimo.

@Sogun Segúnla guía de formatos de texturas, en Color Indexado el dato de color se guarda en 16bits. Eso significa que se pueden indexar hasta 1024 colores en 2KB de TMEM. Pero el indice es de 8 bits y eso son 256 colores, lo que significa que de los 2KB se quedan 1'5KB sin usar.
Pero no creo que se puedan usar, posiblemente la memoria este cableada con el RDP para funcionar en modo indexado o sin indexar. Así en lenguaje de programación, cuando hay que leer el color de un pixel de la textura, o bien el RDP lo lee como un dato (el color), o como un puntero (indice) que le lleva al color en la tabla adjunta.
Otro detalle es que la TMEM esta construida en bloques de 512bytes dentro del RCP, y sin embargo si o si son 2KB, así que algo hay en el diseño que no deja.
Una prueba circunstancial de que no se podría es que precisamente no se hizo en su momento. Hablamos de 3'5KB bastante golosos para guardar texturas en CI, lo que daría texturas de buena resolución y gran colorido.
Peeeero las texturas tienen que ser cuadradas y los lados de potencias de dos o si no el RDP empieza a dar problemas cuando se repiten en tiles... No sé si esto da igual si son texturas sin repetir.

Habría que ver bien el microcódigo para saber si se podría aprovechar. Le he echado un ojo rápido esta guía oficial del RSP y no parece que el RDP se pueda controlar con tanto detalle.

@EMaDeLoC los parches que salen al final del vídeo los intenté usar yo y no consigo que los pillé el flashcard chino. He leído que se pueden aplicar directamente a las rom, pero yo tampoco lo conseguí.

@ashurek
- AA resample aplica a toda la imagen, vamos, al resultado final de la escena
- AA edge requiere información 3D
- Los rectángulos pueden aplicar filtrado (adicional) solo si están redimensionados por encima del 100% de su tamaño usando CYCLE1/2, normalmente los textos deberían ir con COPY, salvo que tengan cosas raras, como los del Paper Mario o lo que comenta EMaDeLoC, con fuentes diseñadas a conciencia.

@Sogun
El PDF del RDP no está bien documentado, están todos los comandos que maneja, pero no está explicado en detalle toda su funcionalidad.

De hecho tuve problemas para mostrar texturas de 64x64 ocupando los 2KB de TMEM, la paleta en ese caso concreto no puede ir en slot 0 ni 1 cosa que no viene documentada (o quizás si se puede en slot 0, ya que no pisan memoria, pero con otro paso previo que tampoco documentan), aunque supongo que a los desarrolladores les dieron la libultra, las macros para cargar las texturas con todos los parámetros correctos y esto no tuvieron ni que mirarlo.

En el caso de texturas ocupando la otra región de 2KB existe un modo especial: "tiled large image mode", donde el RDP en teoría divide las texturas en tiles (soporta hasta 8) y luego las monta automáticamente, desconozco todos los pasos para hacer correr ese modo, las limitaciones, formatos soportados, etc..

@SuperPadLand Tienes que parchear la ROM correcta y concreta para ese parche o no funciona.
Cuando bajas el parche normalmente te adjunta un número CRC (o CRC32) que identifica a la rom concreta para aplicar el parche.
Si descargas una rom en zip, al abrir el contenedor te aparecerá en una columna los números CRC de los archivos comprimidos, ahí podrás ver si es la rom correcta.
Normalmente dan pistas para saber cual rom usar, generalmente serán americanas.
Yo prefiero parchear las roms aparte y meterlas en su propia carpeta, así las tengo separadas y se a qué estoy jugando en cada momento.

@EMaDeLoC echo de menos la época donde ibas a foros y encontrabas hilos de lo que querías ya parcheado y todo juntito.

Conker64 escribió:En el caso de texturas ocupando la otra región de 2KB existe un modo especial: "tiled large image mode", donde el RDP en teoría divide las texturas en tiles (soporta hasta 8) y luego las monta automáticamente, desconozco todos los pasos para hacer correr ese modo, las limitaciones, formatos soportados, etc..

¿Con texturas ocupando la otra región de 2KB te refieres únicamente a texturas en escala de grises?

Eso del "tiled large image mode" me recuerda a lo que permite el editor del GE/PD que permite crear tus propios mipmaps y así optimizar el espacio disponible para la textura (2KB en texturas a color y 4 KB en texturas en escala de grises). Te permite tener la textura base y hasta 7 niveles de mipmap. Aunque no tengo claro en qué casos se pueden usar los 7 niveles (una textura de 64x64 usaría 6 niveles para albergar sus versiones 32x32, 16x16x 8x8, 4x4, 2x2 y 1x1). Supongo que proporciones más raras como 128x16 podrían gastarlos usando 64x8, 32x4, 16x2, 8x1, 4x1, 2x1, 1x1. Curiosamente el engine de GE/PD no permite texturas con alguna de sus dimensiones mayor de 128, por lo que texturas de 256 x lo que sea (como por ejemplo 256x32 que usa PilotWings 64 para las nubes del horizonte) hay que reducirlas para usarlas.

Pero como comento, esto no permite aprovechar los 4 kB para texturas a color. Por defecto los mipmaps se reservan la mitad del espacio disponible (2 kB en texturas en escala de grises y 1 kB en texturas a color) y generándolos tú mismo puedes usar esa memoria (que los mipmaps no usan en su totalidad) para permitir texturas con un poco más de resolución. Puedes incluso marcar el número de niveles de mipmaps que quieras sin tener que llegar al último que reduce la textura a 1x1 para conseguir un poco de memoria extra. Por ejemplo, es posible tener una textura 96x64x4 en escala de grises con dos niveles de mipmap cuando por defecto no se generaría ninguno.
Además, crear tus propios mipmaps te permite en algunos casos conseguir más definición en la transición entre los distintos niveles de textura y evitar posibles artefactos que te genera la configuración por defecto. Pero todas estas ventajas son a costa de gastar aproximadamente un 30% más de memoria tanto en RAM como en el cartucho.


Bueno, no está confirmado que no se pueda hacer lo del microcódigo pero si fuese posible tampoco sabemos por donde empezar así que me temo que no lo veremos nunca.


EDIT: no había tenido en cuenta que las texturas a color de 16 y 32 bits no usan paleta y por la tanto se pueden aprovechar los 4 kB de la caché, pero no pueden alcanzar tamaños más grandes (64x32 las de 16 bits y 32x32 las de 32 bits, ambos casos sin mipmaps) así que salvo en casos muy concretos son poco prácticas.

Conker64 escribió:@ashurek

En el caso de texturas ocupando la otra región de 2KB existe un modo especial: "tiled large image mode", donde el RDP en teoría divide las texturas en tiles (soporta hasta 8) y luego las monta automáticamente, desconozco todos los pasos para hacer correr ese modo, las limitaciones, formatos soportados, etc..

¿Y esto no será algo para facilitar hacer fondos con imágenes grandes que las trocea a un tamaño que quepa en caché, en este caso como no tiene que usar TLMM puede usar texturas de 64*32 a 16 bits y ahorrar a los grafistas tener que cortarlo de una forma concreta para que no se vean las juntas? y supongo que generara una malla para mapear la imagen.

Salud.

Analisis de la gente de Digital Foundry

@ALCAMJI Explican un poco por encima como se han hecho algunas cosas, y el resultado es bastante convincente.

Iluminación y self shadowing:



Mas iluminación:



En tiempo real:

@Sogun
Krom en github tiene ejemplos ASM de textura con color, en escala, etc

Tal como dices las texturas de 16 y 32bit ya usan los 4KB de cache, lo único que varía es como se llena la información en esos 4KB, es como llenar los 2KB superiores y luego los 2KB inferiores, la paleta sería lógico situarla al final de los 4KB.

Desconozco como funciona y gestiona Goldeneye el tema de la TMEM (yo por ejemplo si he usado texturas de 256 de ancho sin problema), pero claro es bastante complejo si empezamos a añadir mipmap que deberían usar los slots disponibles mezclado con el tile mode donde en teoría es para dividir una textura que va a visualizarse como única y no en un set de piezas.

El tema de los mipmaps también es interesante, no sé hasta que punto es beneficioso usarlo teniendo solo 4KB de cache, por un lado tenemos si la conversión sucede en cada recarga de textura, es un procedimiento muy rápido, es solo recorrer la textura con 1 salto para dividirla en 2, con 2 saltos para dividir esta y así, pero esa recarga no debe salir barata si hay muchas de ellas.

Por otro lado la perdida de detalle al usar los slots y parte de esa memoria, puedo entender que el mipmap sea atractivo de cara al programador si sucede de forma automatizada, la textura se genera automáticamente y el sistema determina según profundidad cual de los niveles usa.

Pero también podría funcionar manualmente con un engine que maneje previo paso la carga de texturas, sobretodo al usar los 8MB, carga la textura y cuando lo hace genera los diferentes niveles en RAM, luego según distancia carga en TMEM la textura que corresponde.

En el caso del micro código no es necesario para acceder a las funciones del RDP, todo el RDP es accesible mediante CPU, aunque se podría elaborar uno que primero se ha diseñado y testeado con código de alto nivel en la CPU, en la scene hace tiempo que se usa el RSP para algunas cosas (como CPU auxiliar, o acelerar codecs de vídeo/audio), pero creo que poca gente lo ha usado para llenarlos de comandos para el RDP que es lo que vagamente suele ser un micro código (además de todo el jaleo de transformaciones).

@dirtymagic
No sabría decirte, no he usado esa función y no sé si podría servir para que en una misma superficie se pueda utilizar más de 1 textura, si es para 2D sin duda no hay problema en usar tiles/rectángulos por textura.

Yo en cuanto a texturas y demas no soy muy entendido para cosas como telarañas y con mucha tnrasparencia escala de grises o indexado
Zelda ocarina en algunos casos la mayoria de 32x64 y en casos puntuales uso de 128x64 o 128x32 tambien 16*32 todo esto teniendo en cuenta al tipo de superficie que ira
Y en otros casos con transparencia de 16x8 con color indexado de echo el mas pequeño que tengo creo que es de 4x4 que solo lo uso 1 o 3 veces

Y los de 32x64 los reutilizo para multitextura, todo esto teniendo en cuenta 4kb aunque a veces se glitchea la multitextura no se porque, no se que mas podria aportar tambien que no se puede poner mas de 1 textura con transparencia encima de otra sino se desactiva

Esto pasó desapercibido:



Una ROM que ejecuta Linux en la N64.

una duda el resident zero nunca fue liberado?

rioazuki escribió:una duda el resident zero nunca fue liberado?

Que yo sepa no está ni confirmado la existencia de un prototipo real en manos de un particular ¿Se confirmó su existencia?


@EMaDeLoC ya tenemos Linux ahora podremos usarlo para navegar por internet con un nuevo flashcard que lleve una tarjeta de red wifi.

Estaba viendo este vídeo sobre DLSS:



¿Esta tecnología se aplicará a los emuladores? Quiero decir... cargáis el emulador de N64 a su resolución original y vuestra tarjeta Nvidia con Tensor Cores os saca la imagen a una resolución 4K, rellenando los píxeles vacios mediante IA y "mejorando" la calidad de las texturas y suavizando los dientes de sierra en tiempo real. ¿Es posible esto o estoy diciendo una chorrada?

¿estarán trabajando ya en ello los cracks de los emuladores?

@cegador con una IA a la que le digas como procesar cada cosa de la forma que quieras todo es posible, el problema es desarrollar dicha IA de forma efectiva que puede tardar décadas y la potencia del hardware para hacerla funcionar aplicando todos esos procesos. Para que te hagas una idea el nuevo OSSC Pro que no usa IA ni nada, sólo reescala con algoritmos guapos lo hará hasta 1080p nada más (igual que el OSSC normal) pese a que los rumores dicen que costará sobre 300$ y a la pregunta de porqué no 4K la respuesta fue que la FPGA que tendrían que usar para procesar esa conversión haría el precio final prohibitivo.

Con todo me sorprende que costando 300$ y costando el doble que el original (si es que lo cuesta que por ahora es rumor) no reescalase al menos hasta 1440p teniendo en cuenta que el original lo hace a 1080p con una FPGA anterior.

Ya estan sacando mas cosas de dinosaur planet

DinoMod 2.2 features a ingame menu to choose from many options including patches and cheats.
It will be controlled with the D-Pad. Activate it any time with D-Pad right.
Navigate with Dpad-up/down
confirm with D-Pad right
cancel/quit with D-Pad left
Download: https://www.dropbox.com/s/2mbz6agokdv47 ... delta?dl=0

DinoPatch 2.2 uses the same code as Dinomod but features just the game patches and has no ingame menu.
This is intended for all those who just want to play the game or doing speedruns.
Download: https://www.dropbox.com/s/phhs8i0smia9c ... delta?dl=0

Apply the xdelta patches to rom_crack.z64

You can find further updates and a lot more information regarding Dinosaur Planet here:
https://discord.gg/cm6eCKKy
DinoMod and DinoPatch are made by Nuggs. You can find him on this discord too.


https://www.youtube.com/watch?v=8QjKc70qkAk&ab_channel=BanjoFella

@Flash-Original

Muchas gracias.
Lo he estado probando y aún no es estable del todo, pero te permite ver muchas cosas que con la rom filtrada no se podían ver en el hardware original.
Me ha gustado en especial poder manejar a Sabre y la opción de quitar el antialising, aunque no funciona del todo bien. Parece que el antialising sólo se quita por completo cuando estás manejando a Kristal y cuando manejas al otro personaje lo que hace es hacer el antialising aún más agresivo... lo que tendrían que intentar es conseguir la opción de quitar el dithering. El rendimiento sí que que mejora pero sigue habiendo zonas donde se ralentiza bastante; en especial cuando estamos combatiendo. No hay una mejora tan espectacular como lo que se veía en el vídeo que se filtró hace años donde en casi todo momento va totalmente fluído (comparad la parte de la moto de nieve en el minuto 47:00).


Y aquí en el minuto 25:15


Algunas cosas que querría comentar tras probar el juego y ver zonas más avanzadas gracias a youtube durante estas últimas semanas:

-Me parece el juego más bonito de Nintendo 64, más bien por lo que intenta mostrar que por cómo lo muestra. Se nota que en él ha trabajado gran parte del equipo de Diddy Kong Racing y Jet Force Gemini por lo preciosista de los escenarios. Nada que ver con Donkey Kong 64, Banjo Tooie o Conker, que serán técnicamente más brutos pero no tienen escenarios por los que apetezca perderse.
-Sin embargo hecho en falta más músculo técnico que acompaña a la dirección artística. En los mencionados DK64 y BT, además de en Perfect Dark, Rare demostró un trabajo en el texturizado muy por encima de lo que se había visto en cualquier otro juego del sistema. Dinousaur Planet es un paso adelante respecto a Jet Force Gemini pero se queda atrás respecto a estos tres colosos. Y la verdad es que esperaba que todo el buen hacer de Rare se concentrara en este título.

-Es necesario el Expansion Pak para hacer funcionar la rom, pero no estoy seguro de si se está empleando para algo. Sospecho que es debido a que los kits de desarrollo tenían 8 MB de RAM y todavía no habían adaptado el programa a 4 MB. Quizás hay muchas herramientas de debug funcionando en segundo plano y por eso el rendimiento es tan pobre sin mostrar nada superior a otros títulos (incluso si éstos se ralentizaban también lo hacían manejando mucha más chicha en pantalla). También explicaría por qué el vídeo de arriba funciona muchísimo mejor. Lo único que se me ocurre que obligaría a usar el EP es que todos los escenarios están interconectados sin cargas (al menos mitad y mitad del juego) y algunos son bastante complejos por lo que tendrían que estar cargados en RAM de antemano a la espera de mostrarse en pantalla.

-Tiene detalles muy buenos como los árboles que se mueven con el viento, hojas que caen y fruta que vuelve a crecer. En general en temas de partículas destaca para bien (lo único que me parece feo es el polvo rojo en el que se deshacen los enemigos). Pero luego hecho en falta detalles que viéndolos en otros juegos de la misma compañía pensé que estarían todos recopilados en su "último" título. Cosas como que se moje la ropa y gotee cuando sales del agua al igual que ocurría en Conker. O el agua que a pesar de tener una textura animada muy currada no es más que un plano cuando en juegos como DKR o JFG tenía un oleaje y unos brillos que aquí se han perdido. También en JFG el personaje dejaba un rastro en el agua o en los Banjos las texturas de las salpicaduras era de una resolución altísima mientas que en Dinosaur Planet se ha sustituido por un chapoteo poligonal que no queda muy bien.

-El dueño de la tienda parece sacado de una generación superior. Tanto el modelo, como las animaciones y el texturizado están a otro nivel. Tricky también está muy logrado aunque le fallan los ojos en algunos planos cortos. El General Scales también está muy bien. Curiosamente Kristal y Sabre parecen más simples. Kristal es muy expresiva, eso sí. El modelo de Fox es más complejo pero su cara-cartón lo hecha a perder respecto a los otros dos.

-El control es bastante nefasto, la verdad. Lo de sacar el bastón/espada manteniendo el botón Z que además sirve para fijar objetivos y centrar la cámara me parece una cagada gorda. Muchas veces cuando he acabado una conversación o activado algún objeto en cuanto recupero el control del personaje estoy apuntando y disparando hechizos. La arbitrariedad para saltar de los bordes o descolgarte es muy frustrante, también lo es la altura que debe tener una pared para poder treparla que parece que depende de la situación. El combate es malo, malo, malo; me dedico a aporrear el botón de ataque sin que el enemigo ponga resistencia y ni siquiera centro el objetivo porque acaba siendo contraproducente con el tema del bastón. Los movimientos evasivos como si no estuvieran. Que el rendimiento caiga en picado cuando inicias un combate tampoco ayuda en absoluto.

-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. Al menos los acompañantes sí que son distintos. No sé cuánta culpa tendrá que tuviesen que cambiar la historia cuando pasó a ser un Star Fox, pero me temo que esto ya era así desde el principio.


Le dedicaron un episodio en DF Retro al prototipo y sale uno de los desarrolladores comentando cosas del proyecto. "Confirma" la teoría que siempre tuve de que el tigre Timber, co-protagonista del Diddy Kong Racing, iba a tener su propio juego al igual que ya estaban en desarrollo los de Banjo y Conker.

He estado siguiendo este blog https://olivieryuyu.blogspot.com/?m=1 durante un año en el que explica la creación de un microcodigo con el fin de optimizar los códigos existentes, documentando el código así como la lógica de cada algoritmo utilizado.

Recientemente lo ha finalizado y está buscando colaboración para crear demos y test para probar el rendimiento del mismo.

Teniendo en cuenta los proyectos de decompilación, podría en un futuro reemplazar los microcodigo de roms oficiales por este, mejorando el rendimiento, calidad de imagen, fps más estables...

@celgadis_84 si sale bien sería una cosa bastante loca. Yo no puedo ayudar porque requiere que testee gente con conocimientos de programación

No sé si esto va aquí, pero el turok 2 tiene 2 ediciones, una con la caja con relieve y una con la caja sin relieve (tiene una impresión que la imita).

La que no tiene relieve creo que es la uk.

La española venía con relieve

Mi Turok 2 comprado el dia de salida en España si tiene relieve símil a escamas.

@Sogun Tiene sentido que hay alla mucho poligono de echo incluso te apuesto a que iban a meter mas cosas (tienda del dinosaurio) he llegado a probar a poner muchas cosas en una habitacion cerrada con texturas y tal y he llegado hacer algo a la altura de twilight princess (si no fuera por el espacio del cartucho se podrian hacer cosas mas brutas)

Mas bonito no equivale a mayor modelaje sino a cuestiones de diseño quizas te refieras a eso

Lo del expansion pak creo que es por que no llega a usar las 8mb no creo que lastre el rendimiento a esto tambien es algo a medio hacer aunque parezca echo el juego,faltan bastantes cosas a retocar a mi modo de ver

rioazuki escribió:La que no tiene relieve creo que es la uk.

La española venía con relieve

P13RR3 escribió:Mi Turok 2 comprado el dia de salida en España si tiene relieve símil a escamas.

Hay una sin, que lo único que tiene es una impresión que da la sensación de relieve, lo pude comprobar de primera mano cuando pude hacer una mejora de estado (las 2 unidades Pal Esp), tengo fotos pero cuesta apreciarlo en ellas.

Los colores también cambian y se ven más sencillos en el caso de la caja de menos relieve.

Con Relieve;


Sin Relieve;

Creo que además salieron dos versiones de Turok 2, una primera solo en inglés y después otra multiidioma.
La primera recuerdo que lo alquilé nada más salir y luego lo compré a 6000 pelas en español.

Flash-Original escribió:@Sogun Tiene sentido que hay alla mucho poligono de echo incluso te apuesto a que iban a meter mas cosas (tienda del dinosaurio) he llegado a probar a poner muchas cosas en una habitacion cerrada con texturas y tal y he llegado hacer algo a la altura de twilight princess (si no fuera por el espacio del cartucho se podrian hacer cosas mas brutas)

Mas bonito no equivale a mayor modelaje sino a cuestiones de diseño quizas te refieras a eso

Lo del expansion pak creo que es por que no llega a usar las 8mb no creo que lastre el rendimiento a esto tambien es algo a medio hacer aunque parezca echo el juego,faltan bastantes cosas a retocar a mi modo de ver

¿Cómo has podido editar el DP, con el Goldeneyes setup editor?
La N64 mejora mucho a la mínima que le pongas un poco de mimo en el diseño de escenarios y texturas, si lo haces a lo bruto con texturas repitiéndose en polígonos gigantes o peor, texturas estirándose en una superficie gigante ,sin cuidar la iluminación por vértices o creando texturas acordes al sistema al final se queda en una PSX con filtros y unos FPS paupérrimos, no es muy allá en geometría, pero si diseñas las cosa con sus limitaciones en mente, pueden salir cosas resultonas, la N64 depende más del buen gusto de los grafistas que de una fuerza bruta que le haga destacar de los demás que por ejemplo si que tenia DC.

Salud.

El motor tiene cambios no sirve el goldeneye setup editor, han tenido que investigar de 0 o sea ejecutar el emulado activar el debugger y investigar

Flash-Original escribió:El motor tiene cambios no sirve el goldeneye setup editor, han tenido que investigar de 0 o sea ejecutar el emulado activar el debugger y investigar

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.

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.