Hilo de detalles y curiosidades de N64

radorn escribió:@Druchi_coupe Esto era mas para el hilo general, pero bueno.
El parche para hardware es este https://www.youtube.com/watch?v=GQjn4nVJIJw

@Sexy Motherfucker igual te interesa este vídeo porque es un ejemplo de como se verían los juegos de N64 gráficamente en condiciones más similares a las de PSX y framerate estable (con corrección de perspectiva afortunadamente).

@radorn Gracias! Probado y rulando

EMaDeLoC escribió:Lo único que hay que conectar a masa es un cable que va soldado desde la placa del circuito en un lado y por el otro pelarlo y enroscarlo en un tornillo del disipador de calor. En la placa el punto esta junto a las salidas RGB marcado como GND.

Seguí la guía al pie de la letra en su día y no estaba lo del cable al tornillo. Veo que lo actualizó en 2017 [enfado1]

13/3/2017 - Added final step of connecting the gound to the heatsink. This should solve the vertical line interference that some people have been experiencing.

Así tengo la instalación.

En fin, es poquita cosa, a ver si encuentro un hueco y acabo de pulirlo. Gracias por el aviso.

PD: He mejorado mis habilidades de soldadura desde entonces [carcajad]

Buenas gente una preguntilla rapida. Quiero un juego de formula uno y por lo que se los mejores son los formula 1 wolrd grand prix el 1 y el 2. El primero puedo conseguirlo tirado y a la mitad de precio que el segundo. Hay mucha diferencia entre el uno y el dos o se puede tirar perfectamente con el uno?

@JoOs_86 Como poco entendido en F1, lo único que te puedo decir es que el F1-WGP tiene una banda sonora fantástica, hecha por Dan Hess, el mismo compositor del PilotWings 64, y el 2 es basura para mis oidos.
La verdad es que no se decirte cuanta mejora o empeoramiento hay en los demás aspectos del juego.

@gelon Pues sí que hacía tiempo que tenías hecho el mod.

@JoOs_86 Creo que el primero tenía un framerate más estable que el segundo porque añadieron polígonos sin mejorar el motor sustancialmente.

GlennPlant les hizo una review, te ayudará a elegir.

https://youtu.be/9geYQorgxQk

https://youtu.be/3-cGyfGxTy0

EMaDeLoC escribió:@gelon Pues sí que hacía tiempo que tenías hecho el mod. [carcajad]

Lo vas dejando..

Entre lo poco que he tocado la 64 y lo último a lo que jugué fue en WiiU y PC, pues quedó para los restos.

A ver si la retomo porque tengo ganas de pasarme el Buck Bumble, una espinita clavada desde tiempos inmemoriales.

¿Alguien sabe qué programa/emulador/plugin utilizan los que hacen vídeos de boundary break/off camera en los que pueden mover la cámara libremente por todo el escenario del juego en cualquier momento?

Por ejemplo: https://www.youtube.com/watch?v=Reaz4aKYci8

Los de Digital Foundry también hacen uso de una herramienta similar y parece que funciona en cualquier plataforma.

Gracias a los dos por las respuestas gente, me da que entonces voy a tirar por el uno, al fin y al cabo es para echar unas partidas, y entre lo de la banda sonora y que el uno es mas estable y juego en una full hd entiendo que hara menos daño a la vista que el dos
En cuanto lo tenga comentare sensaciones.

@JoOs_86 En los análisis de GreenPlant que the puso EMaDeLoC menciona que la calidad gráfica en el 2 es ligeramente superior, pero, si, a costa del rendimiento. También dice que suele estar mas caro por escasear algo mas. Llega a la conclusión de que si tienes que escojer entre uno y otro, el 2 es ligeramente superior. Personalmente creo que me quedaría con el 1, pero, como practicamente ya solo juego con cartuchos de ROMs, no me preocupa, puedo jugarlos todos si quiero xD
En todo caso, la proxima vez, lo de las recomendaciones de juegos, en el "hilo oficial", mejor

@Sogun En el caso de GoldenEye no sé que ha usado, pero en el de Banjo-Tooie un hacker le hizo una versión especial de la ROM con controles de cámara en el segundo mando (si no recuerdo mal), que desgraciadamente no funciona en consola. A mi ese video de GE me tiene pinta de hackeo también, porque no parece que simplemente mueva la camara en la escena que llega al RDP como displaylist, si no que realmente mueve la cámara del juego.
No se que usa, pero no por lo que he podido ver, no se limita a un emulador trucado.

Si perdonar no cai en la cuenta que este no era el hilo oficial. Esta tarde he ido a por el juego y bueno la verdad es que al ponerlo en la full hd de 55" se me ha echo dificil jugar mas de media hora. Que mal que se veo el jodido en esta tele, quiero imaginar que por la sensacion de velocidad y combinado con una tele nueva mal negocio. Porque la verdad juego al los iss, mario 64, nba jam y la verdad es que se dejan jugar en esta tele pero el formula uno es bastante infumable.

Solucionado el tema de las jailbars, nunca es tarde si la dicha es buena [+risas]

Dejo una fumada en forma de viaje psicodélico


Por si un vídeo de 48 segundos no fuera suficiente aquí uno más largo


Se trata de Mario Artist para 64DD y consta de 3 partes:
- Artist Studio, es parecido al Mario Paint de SNES, con diferentes cosas, algunas en 3D
- Polygon Studio, minijuegos rarus y fumadas varias
- Talent Studio, es como una especie de creador de Miis, pero más completo

La verdad es que revisándolo parece una enorme fuente de inspiración para proyectos que vinieron después como WarioWare o incluso Endless Ocean.

Bueno el caso es que hace tiempo fue convertido para funcionar en un cartucho flash y no solo eso, también traducido, así que dejo la web de los parches para el que quiera curiosear, los he probado todos y funcionan perfectamente.

Como bonus en esa web hay el F-Zero 64DD que sí recordáis tiene un editor para crear circuitos, naves y más.

Sim City 64 también tiene una traducción bastante avanzada, aplicable a la conversión a cartucho.

gelon escribió:Sim City 64 también tiene una traducción bastante avanzada, aplicable a la conversión a cartucho.

Si ese juego hubiese salido en inglés y en cartucho, habrían volado muchas cabezas...

EMaDeLoC escribió:Si ese juego hubiese salido en inglés y en cartucho, habrían volado muchas cabezas...

Sí, yo creo que es la versión más divertida de Sim City. Casualmente la versión de PlayStation también tiene un modo 3D, pero es cutrísimo al lado del de 64. Una especie de Streets of Sim City mal hecho.

Al contrario, Transport Tycoon tiene un modo 3D en Playstation que es una gozada, para un fan de TT como yo es un caramelito. Lamentablemente es la versión normal de TT, no la Deluxe, con lo que tiene muchísimo menos contenido. A ver si algún día crean ese modo 3D en Open Transport Tycoon Deluxe, sería la hostia.

No sé si algún juego de estrategia más tiene "modo 3D" en Playstation o Nintendo 64. Quizá el A-Train, Railroad Tycoon o alguno de estos, no lo sé.

Conker64 escribió:Dejo una fumada en forma de viaje psicodélico

Por si un vídeo de 48 segundos no fuera suficiente aquí uno más largo

Se trata de Mario Artist para 64DD y consta de 3 partes:
- Artist Studio, es parecido al Mario Paint de SNES, con diferentes cosas, algunas en 3D
- Polygon Studio, minijuegos rarus y fumadas varias
- Talent Studio, es como una especie de creador de Miis, pero más completo

La verdad es que revisándolo parece una enorme fuente de inspiración para proyectos que vinieron después como WarioWare o incluso Endless Ocean.

Bueno el caso es que hace tiempo fue convertido para funcionar en un cartucho flash y no solo eso, también traducido, así que dejo la web de los parches para el que quiera curiosear, los he probado todos y funcionan perfectamente.

Como bonus en esa web hay el F-Zero 64DD que sí recordáis tiene un editor para crear circuitos, naves y más.

Pero los minijuegos tipo Wario Ware ¿los ha creado un usuario o ya venían de serie?

@cegador
Estos minijuegos? Ya vienen de serie


Ayer estuve jugando un rato y me han gustado bastante, el Sim City 64 aún no lo he bajado.

Adivina adivinanza, en qué hardware corre ésta demo técnica:

@Conker64 en un pc del 1998

@Flash-Original
Frío frío

@Conker64 N64

Pon vídeo.

@cegador
Bingo , es de Marshall pero solo puso una imagen sacada desde el chip, por eso se ve tan limpia, además de ser 640x480, lo hizo con la libultra así que a saber lo que podría dar la maquina de sí, con mejores herramientas y conocimientos.

Tiene prototipos antiguos en youtube, como un generador de terrenos:


O test de carreras:

@Conker64 osea, que si no hubiesen necesitado caparla tanto habría estado mas cerca de la dreancast de lo que pensamos.

Sacado desde el chip significa desde el frame buffer?, habría mucha diferencia?.

@Señor Ventura
Si, el framebuffer, al ser su propio programa supongo pudo volcar el frame al cartucho sin más, realmente no sé cuando hizo esa demo.

Para acercarse a la Dreamcast tendrían que haber subido la CPU a 125Mhz, el RCP a 75Mhz y cambiar toda la forma, modelo y distribución de memoria, la verdad es que ahí en ese punto concreto se colaron un poco.

Pero esa imagen está bien para demostrar que puede llegar a poner buen detalle dividiendo bien las superficies.

Mientras tanto en SGI..

Conker64 escribió:Para acercarse a la Dreamcast tendrían que haber subido la CPU a 125Mhz, el RCP a 75Mhz y cambiar toda la forma, modelo y distribución de memoria, la verdad es que ahí en ese punto concreto se colaron un poco.

Yo no creo que se acerque a la Dreamcast, está tiene dos años de ventaja en arquitectura, software y producción.
Pero si que la memoria es el gran problema de nuestra 64. Deberian haber duplicado el bus de la RAM y poner los dos chips iniciales en paralelo. El coste de la placa y del RCP no habría subido tanto, y el ancho de banda sería el doble en el papel, aunque en realidad sería un 50% mayor. Suficiente para que el z-buffer no fuese tanto problema ni generase cuello de botella. Con eso se ganaría bastante.
O quizá bastaría con un buen repaso a las librerías para optimizarlas. El del blog que se ha mencionado varios mensajes atrás hace unas pequeñas optimizaciones que pueden suponer una gran mejora de rendimiento. Y es un pavo solo en sus ratos libres.
Pero en fin, en líneas generales no es mala máquina.

No cabe ninguna duda de que los minijuegos de ese Mario Artist fueron la base de Wario Ware. Creo que también lo confirmaban en una de aquellas entrevistas Iwata Asks, por si alguien no lo tiene claro.

Lo del endless ocean, no se por qué lo dices... juegos de buceo ha habido unos cuantos.

Conker64 escribió:Adivina adivinanza, en qué hardware corre ésta demo técnica:

¡Super FX! ...no, no... hmmmm... ¡Atari Jaguar! no, tampoco... 3DO, M2, 32X... no se... ¿Amiga? ... está dificil la cosa.

Conker64 escribió:realmente no sé cuando hizo esa demo.

Esas demos tienen bastante tiempo ya. Creo que incluso las subí por aquí hace tiempo, en un pequeño recopilatorio que hice.

Esa pista de tierra si que no me suena de nada, aunque se nota su estilo. Es nueva?

Conker64 escribió:Si, el framebuffer, al ser su propio programa supongo pudo volcar el frame al cartucho sin más

Se que marshallh antes usaba un cartucho de desarrollo oficial de SNsystems, no recuerdo el nombre, pero claro, eso requiere una tarjeta SCSI y software antiguo de 32bits y drivers, etc, así que imagino que ahora simplemente usará su propio 64drive HW2 por USB en un PC moderno.

@EMaDeLoC
Z-Buffer y framebuffer ya funcionan mejor si se ponen ambos en distintos bancos de memoria, imagina ahora en una estructura como puede tener una Gamecube.

La CPU tampoco rinde como debería, pero por suerte tiene algo de cache.

Yo creo que la idea de "compararla" con Dreamcast es solo por poder producir unas 3D reales con cierta calidad, no un invento a medio camino para mostrar 3D, como dices le faltaba la potencia que tendrían las siguientes consolas.

@radorn
Sí, las demos de los vídeos son de 2010, la de la imagen no sé, la puso en discord.

Me alegro que se vaya dando algo yo por ahora voy con esto,es una versión antigua me tocaria reacerlo con mejor acabado:

Flash-Original escribió:Me alegro que se vaya dando algo yo por ahora voy con esto,es una versión antigua me tocaria reacerlo con mejor acabado:

Pues no luce nada mal, de hecho se ve genial.

yo soy de los que si compararía la consola con Dreamcast y más cunado ambas consolas comparten algunos juegos de sus respectivos catálogos, Rush 2049, Hydro thunder por dar ejemplos, y hyrdo luce increíble con el mod ulltrahdmi, la verdad es que son buenos juegos.

Conker64 escribió:Z-Buffer y framebuffer ya funcionan mejor si se ponen ambos en distintos bancos de memoria, imagina ahora en una estructura como puede tener una Gamecube.

La verdad es que nintendo 64 aun tiene mucho que dar, estoy muy contento con la actualización más reciente del OS del everdrive 64 que aunque no es oficial por no ser de krikzz, tiene más opciones de resoluciones en el menu y se pueden usar savestates permanentes con los juegos de nes que es donde prefiero jugarlos, el d-pad de 64 es excelente.

Puede que en el futuro aparezca un mejor emulador de snes para 64 , no le exigiría el 100% de velocidad obviamente pero con lo que se ha aprendido de la consola creo que si seria muchísimo mejor que el emulador snes 9x alpha del 98.

@Conker64

Muy buena la imagen de la carretera de tierra.
Parece que está hecha a base de muchas texturas de 64x32 píxeles a 8 bits de profundidad, con su correspondiente malla de muchos rectángulos. Esto permite jugar con la altura de los vértices y conseguir superficies con muchos relieves y curvas suaves, ideal para un juego de carreras y especialmente de rallies. Es como lo que dije anteriormente del Rogue Squadron, pero aquí con texturas de más profundidad de color para obtener un resultado más cercano a la realidad y con polígonos más pequeños y texturas más detalladas.

Lo malo de este tipo de texturas que ha elegido es que son tan pesadas que no soportan filtrado trilineal y el resultado puede ser horrible jugando en resolución estándar. El otro día volví a probar Rogue Squadron en baja resolución a ver si se veía tan mal como recordaba y es insufrible. Encima el framerate no mejora.
En unos escenarios más lineales se puede controlar lo que ocurre en pantalla mucho mejor y en un juego de rallies donde apenas haya un coche se puede hacer algo muy potente.

De las demos de Marshall lo que más me gusta son los skyboxes. No sé qué técnica empleará pero tienen mucho detalle (aunque la cantidad de colores no parece muy alta).
En ese sentido los mejores skyboxes que he visto en N64 son los del Pilotwings 64. Especialmente en cuando el clima es 'Sunny' (hay otro cielo diurno pero más nublado y no tan limpio y espectacular). Me refiero al que se puede ver en la pantalla de presentación o en la primera prueba de ala delta:

https://youtu.be/tYMci1g8LOU

PilotWings 64 usa una cúpula de con unos pocos polígonos muy grandes para crear al cielo. Colorea los vértices de esta cúpula para darle distintas tonalidades a las zonas del cielo y tener zonas más claras y más oscuras como ocurre en la vida real. Luego usa texturas en escala de grises y con semitransparencia con mucha resolución y la ayuda del filtrado bilineal para las nubes con un resultado espectacular.
He intentado capturar el cielo mediante un emulador pero no lo consigo al 100%.


Por último cuelgo otra imagen de una demo de Marshall que se ha puesto antes que se podía descargar en un enlace de la descripción del vídeo pero me parece que ya no funciona.



Lo más interesante de esta imagen es que tiene un tamaño de 800x600. No sé con qué intención.

Sogun escribió:De las demos de Marshall lo que más me gusta son los skyboxes. No sé qué técnica empleará pero tienen mucho detalle (aunque la cantidad de colores no parece muy alta).

Estoy bastante seguro de que hace fotografía 360º para generarlos. En la demo de la Midwest Gaming Convention 2011, en una de las primeras demos, hay un campo con cielo y tal, dando vueltas, y si te fijas bien, se ve la sombra del perfil de alguien. No creo que use pocos colores, si no que es foto real y no algo "dibujado" con paleta limitada como lo del PilotWings. Esto requiere mucho dithering y el resultado nunca está tan optimizado como si usas una paleta a medida para pintar desde cero, como en PW64.

Sogun escribió:Lo más interesante de esta imagen es que tiene un tamaño de 800x600. No sé con qué intención.

Por una parte, está lo de GoldenEye, que, en el menú de carpetas, también funciona a una resolución mayor de la de la pantalla. Por otra, si aumentas esa imagen con escalado de íntegros, verás que no son 800x600 reales.
Si a 800 le restas 640, te da 160. De igual forma, si a 600 le restas 480 te da 120. Si divides 800 entre 160, o 600 entre 120, ambos dan 5. Y si divides 640 entre 160 o 480 entre 120 te da 4. 4:5 es el ratio de escalado entre resoluciones, cada 4 pixels de entrada dan 5 de salida. Ahora ve a la imagen, encuentra un ángulo inclinado y cuenta los pixels de la escalera empezando por uno que esté difuminado/interpolado y cuenta escalones desde interpolado a interpolado. Da 4. Si cuentas píxels, incluidos los interpolados, da 5.
La imagen renderizada original era 640x480, pero en algun punto del proceso, hubo un reescalado. No sabría decirte por qué a ciencia cierta, pero es posible que marshallh quisiese aumentarla un poco pero sin difuminar los pixeles crudos demasiado, para que mantuviese la nitidez. Eso, o en algún punto del proceso hay algun software que hace esto automáticamente... no lo se.

En las conversiones a PAL sin barras negras que emplean gráficos escalados (recuerdo que solo GoldenEye, Perfect Dark, Diddy Kong Racing y la beta de 40 Winks renderizan 288p reales) se puede observar un fenómeno similar, pero mas suavizado. Con una captura directa se puede observar un patrón 5:6, pero todos los escalones tienen algo de interpolación, excepto donde los píxeles originales y los escalados se alinean perfectamente, que es cada 6 de PAL y cada 5 de NTSC.
Hsta donde yo puedo razonar, este tipo de escalado usa ratios fijos que van rotando linea a linea: 6/5 da 1.2, o sea, que cada pixel de entrada "llena" 1.2 pixels de salida, por tanto: 1.2 - 2.4 - 3.6 - 4.8 - 6.0
La alineación de hace de la siguiente manera: El pixel de salida 1 toma todo su color del pixel de entrada 1. El pixel de salida 2 se calcula mezclando el color del pixel de entrada1 al 10% y el 2 al 90%. El pixel de salida 3, el 2 al 30% y el 3 al 70%. El 4, 3 al 50% y 4 al 50%. El 5 con, 4 al 70% y 5 al 30%. Y el 6 con 5 al 90% y 6 al 10%. Llegados al pixel de salida numero 7, se repite el ciclo, pues el pixel de salida 7 y el de entrada 6 quedan perfectamente alineados.

Algo comenté de todo esto hace tiempo, y creo que también aporté imágenes, y si no, también en el foro de retroactive.be lo comenté en un hilo donde alguien preguntaba sobre PAL.

Estoy haciendo una pequeña demo inspirada en la imagen de Marshall que puso antes @Conker64.

De momento tengo el skybox hecho y he encontrado una textura para la carretera (van a salir 96 texturas de ahí, a ver cómo queda ).



Como comento en la descripción del vídeo y ya he dicho antes por aquí, he trasladado el cielo de PilotWings 64 y le he hecho algunos retoques como darle distintas intensidades lumínicas. Al final todo el conjunto son 82 polígonos y 5 texturas. En realidad 7 texturas porque he necesitado una textura blanca y otra negra para colorear los vértices y hacer algunos polígonos totalmente transparentes. Por comparar: los Zeldas emplean 160 polígonos y creo que 48 texturas.

Esto está corriendo en GoldenEye pero más tarde lo probaré en Perfect Dark porque ya viene con Sol incluido y efecto lente fotográfica y de deslumbramiento de serie, por lo que quedará todavía mejor.
Perfect Dark también permite usar geometría a modo de skybox que se mueve junto al personaje y que se renderiza siempre al fondo, en lugar de esta "carpa de circo" que he hecho y que tiene poco más de 600 metros de diámetro.

La gracia de este sistema es que creo que es posible separar la capa de las nubes como un objeto que puede rotar como ocurre en los Zeldas. Y siendo muy creativo quizás se pueda hacer desaparecer ese objeto gradualmente mientras otro nuevo aparece y así tener una especie de transición día/noche.

Con un motor gráfico propio lo ideal sería que los polígonos coloreados pudieran variar de tono y color en tiempo real dependiendo de la posición del Sol y la Luna (y sus fases). Se podría tener más polígonos en la parte de la trayectoria de los astros para que esas variaciones de los tonos no fueran tan bruscas como en mi prueba (en el vídeo de youtube no se aprecia mucho). Al tratarse de triángulos sin texturas, ni filtros, ni corrección de perspectiva, ni niebla e incluso sin Z-buffer creo que el rendimiento no se resentiría.

Según lo veo, se podría conseguir un cielo más vistoso y funcional de los que se vieron en aquella generación con menos recursos de los que algunos juegos emplearon para generar los suyos.


EDIT:
Lo he probado en el hardware real y apenas se aprecia el Sol. Todo lo demás queda oculto por la niebla. Había tocado un parámetro que se suponía que eliminaba la niebla pero parece que sólo lo hace en el emulador. Lo investigaré más adelante.

Conker64 escribió:Adivina adivinanza, en qué hardware corre ésta demo técnica:

Como en la cuarentena me sobra tiempo, he decido probar a hacer algo para la N64, probando lo de hacer escenarios con texturas más grandes troceadas, me sucede lo mismo que esa imagen,que se ven las "costuras del troceado", da igual que las haga con la herramienta de trocear del Gimp o manualmente, se ve la unión,¿alguien sabe como arreglarlo?

Aquí sin el filtro bilinear del Blender no se nota excepto una linea que cruza horizontalmente por el medio, que ni siquiera es un pixel ,es como un cuarto.
https://ibb.co/yP8Jtf0

Aquí con el filtrado bilinear, ahí ya se ven todas las costuras, incluso se inventa una linea blanca vertical en todo el medio.
https://ibb.co/xgcbVcH

La imagen original
https://ibb.co/JnPscvF

Salud.

@dirtymagic Las "costuras" entre texturas se deben al filtro bilinear. Lo que estás viendo son un difuminado de los pixels del lado opuesto de la textura. Técnicamente la consola soporta especificar el renderizado de una textura de manera que en vez de repetir la textura cuando se llega al borde, lo que resulta en el mezclado de los bordes opuestos (algo deseable cuando repites la textura, pero no para hacer mosaicos), pero no siempre es facil o posible activarlo. Depende del motor del juego. La alternativa es generar y aplicar las texturas de tal manera que evites el efecto aún con una aplicación normal.
Intentaré explicarlo con palabras a ver si sale bien, porque no tengo ánimos para ponerme a montar un croquis con Paint.

Imagina que quieres hacer un mosaico con texturas de 64x32, de 3x3 "baldosas".
Para que no se noten las "costuras" debido al filtrado de texturas, lo que tienes que hacer es primero, hacer es hacer un lienzo con la resolución total que quieres usar, pero quitando un pixel por cada unión entre texturas.
En este caso, tenemos 64x3, que son 192, y 32x3 que son 96. A estas cifras le tenemos que restar 2, porque en cada eje hay 2 uniones ente texturas, así que del lienzo total de 192x96, nos quedamos con 190x94.
LLegados a este punto, puedes pintar tu textura en el lienzo, y, una vez la tengas, tienes que dividirla de manera que haya un pixel compartido en los puntos de contacto de las uniones.
La primera textura, la superior izquierda siguiendo el orden de lectura occidental, cojes los primeros 64x32 sin mas complicaciones. La siguiente, centro superior, en vez de "cortarla" a partir del siguiente pixel, usa la última columna de pixels de la anterior textura, y que sea la primera columna de la nueva. En la siguiente igual, y lo mismo para el eje verical, en vez de empezar desde la linea de pixels siguiente a la última de las texturas anteriores, vuelve a cojer la última linea de pixels de las texturas anteriores como la primera de las que estás cortando. De esta manera, tienes texturas de 64x32, y en los bordes que tienen contacto va a haber un pixel repetido.



Con estas texturas con este corte peculiar, lo que tienes que hacer es tener cuidado de que, al aplicarlas, las alinees de tal manera en el polígono, que los bordes/ariastas de los polígonos corran a lo largo del CENTRO del primer y último pixel de la textura. De esta manera evitas que se vea la parte de la textura que tiene restos de color del borde opuesto de la textura debido al filtrado.
Es laborioso, pero el resultado es perfecto si lo haces bien.

La alternativa cutre es tener texturas ya generadas sin el pixel compartido, y aplicar el tapado del último medio pixel igualmente. El resultado es que las texturas tienen un aspecto de mal recortadas, pero, al menos, no de haberse dejado un trozo de algo en el borde.

Para aplicar esto con coordenadas UV de coma flotante (0.000000 a 1.000000, -1.0000, etc) como usa el formato OBJ, tienes que hacer algo de matemáticas para calcular los valores porque van a variar en función del tamaño de textura.
Si lo aplicas con coordenadas UV de enteros nativas de N64, es mas "simple". En GoldenEye, por lo menos, los valores UV cuenta 32avos de pixel. O sea, para decirle que en un vértice va el pixel de un eje de la textura 1 en vez de el 0, tienes que darle un valor de 32, o 20 en hexadecimal. Pero si le das un valor de 16 (h10), entonces el vértice empezará a renderizar la textura en en medio del primer pixel (o pixel 0).
De hecho, en ciertos juegos, si logras acercarte lo suficiente para ver los subpixels del suavizado de texturas, verás que es un escalonado de 32 pixels por texel. De cada pixel se hacen hasta 32 mediante interpolación si hay que aumentarla en pantalla.

Esto también significa que una textura no se puede repetir hasta el infinito. Con coordenadas UV de 16bit signed, hay un límite de 2048 texels (65536 / 32) máximos entre extremos desde un centro 0. El límite de texels es independiente
del tamaño de la textura. Una textura de 64x64 solo podría repetir 32 veces seguidas a no ser que crees un vertice nuevo contiguo y empieces otra vez. Pero una de 32pixels se podría repetir hasta 64 veces seguidas de extremo a extremo de ún triángulo o triángulos que compartan vértices.
A veces un juego, especialmente hacks, violan este límite y eso provoca esos triángulos raros donde la textura parece corrompida, porque la coordenada UV ha superado su valor máximo y ha tenido que empezar de nuevo, y la consola pinta el hueco entre uno y otro verices, con la textura en sentido contrario repitiendo, potencialmente, hasta los 2048 texels hasta, alcanzar el valor del siguiente vértice.

radorn escribió:@dirtymagic Las "costuras" entre texturas se deben al filtro bilinear. Lo que estás viendo son un difuminado de los pixels del lado opuesto de la textura. Técnicamente la consola soporta especificar el renderizado de una textura de manera que en vez de repetir la textura cuando se llega al borde, lo que resulta en el mezclado de los bordes opuestos (algo deseable cuando repites la textura, pero no para hacer mosaicos), pero no siempre es facil o posible activarlo. Depende del motor del juego. La alternativa es generar y aplicar las texturas de tal manera que evites el efecto aún con una aplicación normal.
Intentaré explicarlo con palabras a ver si sale bien, porque no tengo ánimos para ponerme a montar un croquis con Paint.

Imagina que quieres hacer un mosaico con texturas de 64x32, de 3x3 "baldosas".
Para que no se noten las "costuras" debido al filtrado de texturas, lo que tienes que hacer es primero, hacer es hacer un lienzo con la resolución total que quieres usar, pero quitando un pixel por cada unión entre texturas.
En este caso, tenemos 64x3, que son 192, y 32x3 que son 96. A estas cifras le tenemos que restar 2, porque en cada eje hay 2 uniones ente texturas, así que del lienzo total de 192x96, nos quedamos con 190x94.
LLegados a este punto, puedes pintar tu textura en el lienzo, y, una vez la tengas, tienes que dividirla de manera que haya un pixel compartido en los puntos de contacto de las uniones.
La primera textura, la superior izquierda siguiendo el orden de lectura occidental, cojes los primeros 64x32 sin mas complicaciones. La siguiente, centro superior, en vez de "cortarla" a partir del siguiente pixel, usa la última columna de pixels de la anterior textura, y que sea la primera columna de la nueva. En la siguiente igual, y lo mismo para el eje verical, en vez de empezar desde la linea de pixels siguiente a la última de las texturas anteriores, vuelve a cojer la última linea de pixels de las texturas anteriores como la primera de las que estás cortando. De esta manera, tienes texturas de 64x32, y en los bordes que tienen contacto va a haber un pixel repetido.



Con estas texturas con este corte peculiar, lo que tienes que hacer es tener cuidado de que, al aplicarlas, las alinees de tal manera en el polígono, que los bordes/ariastas de los polígonos corran a lo largo del CENTRO del primer y último pixel de la textura. De esta manera evitas que se vea la parte de la textura que tiene restos de color del borde opuesto de la textura debido al filtrado.
Es laborioso, pero el resultado es perfecto si lo haces bien.

La alternativa cutre es tener texturas ya generadas sin el pixel compartido, y aplicar el tapado del último medio pixel igualmente. El resultado es que las texturas tienen un aspecto de mal recortadas, pero, al menos, no de haberse dejado un trozo de algo en el borde.

Para aplicar esto con coordenadas UV de coma flotante (0.000000 a 1.000000, -1.0000, etc) como usa el formato OBJ, tienes que hacer algo de matemáticas para calcular los valores porque van a variar en función del tamaño de textura.
Si lo aplicas con coordenadas UV de enteros nativas de N64, es mas "simple". En GoldenEye, por lo menos, los valores UV cuenta 32avos de pixel. O sea, para decirle que en un vértice va el pixel de un eje de la textura 1 en vez de el 0, tienes que darle un valor de 32, o 20 en hexadecimal. Pero si le das un valor de 16 (h10), entonces el vértice empezará a renderizar la textura en en medio del primer pixel (o pixel 0).
De hecho, en ciertos juegos, si logras acercarte lo suficiente para ver los subpixels del suavizado de texturas, verás que es un escalonado de 32 pixels por texel. De cada pixel se hacen hasta 32 mediante interpolación si hay que aumentarla en pantalla.

Esto también significa que una textura no se puede repetir hasta el infinito. Con coordenadas UV de 16bit signed, hay un límite de 2048 texels (65536 / 32) máximos entre extremos desde un centro 0. El límite de texels es independiente
del tamaño de la textura. Una textura de 64x64 solo podría repetir 32 veces seguidas a no ser que crees un vertice nuevo contiguo y empieces otra vez. Pero una de 32pixels se podría repetir hasta 64 veces seguidas de extremo a extremo de ún triángulo o triángulos que compartan vértices.
A veces un juego, especialmente hacks, violan este límite y eso provoca esos triángulos raros donde la textura parece corrompida, porque la coordenada UV ha superado su valor máximo y ha tenido que empezar de nuevo, y la consola pinta el hueco entre uno y otro verices, con la textura en sentido contrario repitiendo, potencialmente, hasta los 2048 texels hasta, alcanzar el valor del siguiente vértice.

Vale,creo que lo he entendido, voy a ver si consigo cortarlas como dices sin liarme,gracias.

Salud.

Ya he terminado el test de la carretera de tierra:



La textura del terreo es una imagen de 512x384 reducida a 505x373 por el motivo que han comentado @dirtymagic y @radorn. Después esa imagen la he dividido en 96 texturas (8 a lo largo y 12 a lo ancho) de 64x32 de resolución y 8 bits de profundidad de color. Estas texturas no tendrán filtrado trilineal, pero si las reducía a 4 bits se quedaba todo demasiado marrón. Después hice una rejilla de 768 rectángulos de 64x32 unidades de superficie para encajar las texturas de forma proporcionada y controlar el tamaño del texel. A esta rejilla le apliqué varios efectos de ruido para darle el relieve irregular. El problema de hacer irregular el terreno es que se me desajustaron los UVs de las texturas y me tocó retocar todos los polígonos uno a uno (¡son 1536 triángulos!). Por último pinté los vértices para simular sombras según la posición del Sol (esto el Editor lo hace casi automáticamente).

Desgraciadamente la imagen original tenía muchos artefactos de compresión y poco contraste. Aunque la retoqué y mejoré mucho el aspecto no queda algo tan vistoso como la imagen de Marshall. El vídeo de youtube también quita muchos detalles. Dejo dos imágenes en secreto para comparar:



Ahora me he dado cuenta de que me he dejado algunas texturas por corregir...

@Sogun ¿que tasa de frames tiene?, ¿cuanta carga gráfica adicional puede llegar a soportar?, porque 1500 polígonos en pantalla no son pocos para estos hardwares...

¿Crees que podrías alcanzar el detalle en las texturas de la demo en la que te basas?

Sogun escribió:Ya he terminado el test de la carretera de tierra:

La textura del terreo es una imagen de 512x384 reducida a 505x373 por el motivo que han comentado @dirtymagic y @radorn. Después esa imagen la he dividido en 96 texturas (8 a lo largo y 12 a lo ancho) de 64x32 de resolución y 8 bits de profundidad de color. Estas texturas no tendrán filtrado trilineal, pero si las reducía a 4 bits se quedaba todo demasiado marrón. Después hice una rejilla de 768 rectángulos de 64x32 unidades de superficie para encajar las texturas de forma proporcionada y controlar el tamaño del texel. A esta rejilla le apliqué varios efectos de ruido para darle el relieve irregular. El problema de hacer irregular el terreno es que se me desajustaron los UVs de las texturas y me tocó retocar todos los polígonos uno a uno (¡son 1536 triángulos!). Por último pinté los vértices para simular sombras según la posición del Sol (esto el Editor lo hace casi automáticamente).

Desgraciadamente la imagen original tenía muchos artefactos de compresión y poco contraste. Aunque la retoqué y mejoré mucho el aspecto no queda algo tan vistoso como la imagen de Marshall. El vídeo de youtube también quita muchos detalles. Dejo dos imágenes en secreto para comparar:

Ahora me he dado cuenta de que me he dejado algunas texturas por corregir...

¡Joder!,te a quedado muy bien, eso si ¡96! texturas, vaya locura, ¿la nintendo 64 puede con tantas texturas cargadas de golpe?

Por cierto trabajo de chinos lo de cortar las texturas y que casen .

Salud.

@Señor Ventura
He conseguido eliminar la niebla cuando hago funcionar el mapa en la consola pero por algún motivo en el que todavía no he profundizado las texturas de las nubes no se ven. La del Sol sí.
La tasa de frames son 30 fps constantes desarmado, incluso viendo todo el camino. Equipado con dos lanzacohetes cuando veo todo el camino sí que baja (supongo que a 20 fps), pero si me pongo a mitad de camino puedo rotar 360 grados manteniendo los 30 fps en todo momento.
Se puede incrementar muchísimo más la carga poligonal siempre a costa del rendimiento. Yo he llegado a poner más de 10.000 polígonos en pantalla (con una única textura) pero no debía de llegar ni a 5 fps.

Respecto a la textura de la demo de Marshall técnicamente puede que mi textura sea mejor, pero su imagen tiene más contraste y mejor elección de colores que hace que luzca mejor. Así a ojo se ve claramente que "a lo profundo" sólo usa dos texturas (yo uso 8) y "de lado a lado" parece que emplea 12~14 texturas en lo que quedaría entre los postes (yo uso 12). Mi textura es 4 veces más grande.

El aliasing de las texturas no es tan feo como me imaginaba e incluso en primer plano hay algo de filtro bilinear así que no está toda la imagen pixelada. En un CRT los colores son más vivos que en las imágenes que he puesto antes y luce mucho mejor. A ver si consigo arreglar lo de las nubes y saco una foto a la tele. Publicaré también el parche.


@dirtymagic
Pues es una cantidad exagerada de texturas para usar en algo tan concreto como un trozo de terreno. Para que te hagas una idea: hay 14 niveles de GoldenEye y 10 de Perfect Dark que usan menos (Chicago usa 98 texturas). Aunque ahí no estoy contando texturas de objetos y enemigos.
Cada una de estas texturas ocupa 4 kB así que en total son 384 kB en memoria. Teniendo entre 4096 kB y 8192 kB (con el Expansion Pak) tampoco parece tanto.

Sí que fue un trabajo de chinos preparar las texturas. Primero me equivoqué con las matemáticas y las texturas del final se me quedaron cortas, después algunas franjas enteras se me quedaron espejadas. Estuve toda la tarde de ayer con ello.

Sogun escribió:@Señor Ventura
He conseguido eliminar la niebla cuando hago funcionar el mapa en la consola pero por algún motivo en el que todavía no he profundizado las texturas de las nubes no se ven. La del Sol sí.
La tasa de frames son 30 fps constantes desarmado, incluso viendo todo el camino. Equipado con dos lanzacohetes cuando veo todo el camino sí que baja (supongo que a 20 fps), pero si me pongo a mitad de camino puedo rotar 360 grados manteniendo los 30 fps en todo momento.
Se puede incrementar muchísimo más la carga poligonal siempre a costa del rendimiento. Yo he llegado a poner más de 10.000 polígonos en pantalla (con una única textura) pero no debía de llegar ni a 5 fps.

Respecto a la textura de la demo de Marshall técnicamente puede que mi textura sea mejor, pero su imagen tiene más contraste y mejor elección de colores que hace que luzca mejor. Así a ojo se ve claramente que "a lo profundo" sólo usa dos texturas (yo uso 8) y "de lado a lado" parece que emplea 12~14 texturas en lo que quedaría entre los postes (yo uso 12). Mi textura es 4 veces más grande.

El aliasing de las texturas no es tan feo como me imaginaba e incluso en primer plano hay algo de filtro bilinear así que no está toda la imagen pixelada. En un CRT los colores son más vivos que en las imágenes que he puesto antes y luce mucho mejor. A ver si consigo arreglar lo de las nubes y saco una foto a la tele. Publicaré también el parche.


@dirtymagic
Pues es una cantidad exagerada de texturas para usar en algo tan concreto como un trozo de terreno. Para que te hagas una idea: hay 14 niveles de GoldenEye y 10 de Perfect Dark que usan menos (Chicago usa 98 texturas). Aunque ahí no estoy contando texturas de objetos y enemigos.
Cada una de estas texturas ocupa 4 kB así que en total son 384 kB en memoria. Teniendo entre 4096 kB y 8192 kB (con el Expansion Pak) tampoco parece tanto.

Sí que fue un trabajo de chinos preparar las texturas. Primero me equivoqué con las matemáticas y las texturas del final se me quedaron cortas, después algunas franjas enteras se me quedaron espejadas. Estuve toda la tarde de ayer con ello.

Yo he conseguido arreglar las texturas con los consejos de @radorn, así que más o menos ya se como trocearlas y montarlas en blender, eso si como hay que recortarle X pixeles de largo y ancho, por el camino a perdido la posiblidad de repetirse verticalmente que había preparado previamente , de lejos no se nota a penas pero de cerca sí.
https://ibb.co/1qvhQr3

Yo sólo uso 8 texturas de 32*32*8 de los bordes que posiblemente podrían ser 4 y no se notaría mucho y 8 texturas de 128*32*4 para la carretera.
Eso sí 928 polígonos para 70 "metros" de carretera pelada,no creo que salga a cuenta,
https://ibb.co/5hYjFBz

Lo de tantas texturas lo decía más por tener que mostrarlas a la vez, ya que la caché las carga una a una, que por lo que ocuparan en memoria.

Salud.

dirtymagic escribió:por el camino a perdido la posiblidad de repetirse verticalmente que había preparado previamente , de lejos no se nota a penas pero de cerca sí.

Si en un eje vas a hacer repetición en vez de mosaico, entonces no hagas lo de repetir los pixels del borde en ese eje.
También podrías intentar diseñar una zona concreta de la textura que sea reversible y se pueda repetir, aunque sea invirtiendo el sentido cada vez que cambies de un polígono a otro.
O también podrías hacer una pequeña textura de transición entre la zona de mosaico y la de repetición.

Yo no tengo ninguna experiencia con los photoshops del mundo, y no puedo ayudarte en cómo clavar el efecto, pero con empeño e ingenio todo eso se puede hacer.

@Sogun
Muy chula

Has pensando en ponerle algo de detalle a los lados para ver como quedaría un escenario así de detallado?

Asombroso. Resulta que el humo de cuando Mario se quema el trasero estaba corrompido por aplicar la textura especificando un formato equivocado, y por tanto se renderiza de forma incorrecta.
https://www.retrorgb.com/super-mario-64 ... years.html

El humo culero que todos conocemos:


Con el arreglo:


El hacker zoinknoise (¿alter ego de zoinkity?) lo ha arreglado con este parche:
https://www.romhacking.net/hacks/5008/

¿Realmente es un bug que se les pasó o dedidieron dejarlo así deliberadamente? hmmm

EDITO: Supongo que si que es un bug. Recuerdo que en su día me pareció un efecto bastante churrero que no casaba con lo demás y lo que esperaba de la consola. Luego me acostumbré a ello y lo racionalicé de diferentes formas, pero, lo cierto es que, con ese humo negro, es como si el culo de Mario estuviese hecho de neumáticos viejos xDDDD

@radorn Pues es curioso lo del humo, pero me parece un bug demasiado evidente como para que se les pasara o no pudieran arreglarlo a tiempo. Se trata de una sola línea de código y la mecánica del culo ardiendo tiene su propia animación, así que debieron testearla varias veces. Vamos, dudo que el o los encargados de texturas no se dieran cuenta de donde estaba el problema después de llevar meses toqueteando cientos de ellas.
A mí no me resultó raro. Con los píxeles parece que el fuego del culo esté crepitando más que en una llama continua y no queda mal. Igual el director de arte o quien fuese dijo que se quedara así, que molaba.

@EMaDeLoC Pues hoy lo he puesto en la consola, y, la verdad, creo que la teoría del bug se sostiene.
Te reconozco que resulta extraño que no arreglasen algo aparentemente tan sencillo y evidente, y eso puede llevar a pensar que igual lo dejaron así a propósito, pero tambien puede ser, simplemente, que nadie se quejó y había otros fuegos que apagar.
Yo insisto en que la primera vez que vi ese humo tan punteado, viendo otros efectos mucho mas logrados en el mismo juego, me resultaba cutre.

A mí en su día no me pareció tan feo el humo pero sí que contrasta con el aspecto de render que tiene todo el juego. Tampoco creo que algo tan evidente se les escapara. Creo que les salió así sin querer y pensaron que quedaba mejor que lo que tenían previsto y lo dejaron. Esas marañas de píxeles cuando se superponen varias da un aspecto menos repetitivo de lo que daría la textura original. Puede que incluso demasiadas capas de semitransparencia afectara al rendimiento.

Sigo puliendo el cielo que mostré antes con algunos consejos que me han dado en otro foro aunque no consigo que se vea bien en el hardware original.
Retocando la forma en la que se renderiza la textura con una herramienta del Editor muy avanzada y que se me escapa completamente se ha conseguido un aspecto más natural y cercano a lo que se veía en PilotWings 64. Queda de lujo:

El emulador mas perfecto de n64 actualmente cual seria el parallel n64? lo probe y era una autentica pasada

Perdón por el ¿off topic? Pero... ¿Creen que hubiera sido posible en N64 un juego como KOF98? ¿Y algo como un MvsC2 (mezclando sprites con escenarios 3d)?

Claro,sólo hay que ver el Killer Instinc Gold, los personajes son sprites y los escenarios 3D.

Salud.