Hilo de detalles y curiosidades de N64

Sexy MotherFucker escribió:@Calculinho no me he enfadado, es sólo para que a la próxima @Dio_Brand reflexione antes de cargar contra alguien frontalmente. El chaval me cae de puta madre, y por eso me he molestado en explicarle mi punto. Si me hubiese caído mal o algo, directamente le ignoro

Jajaja, oye, qué yo tampoco me he enfadado ni nada, ni habia tenido intención en ningun momento de cargar contra ti, la realidad es que el gif me hizo tela de gracia y me apetecia ponerlo.

Se agradece toda la información extra, y el detallismo puesto en la explicación sobre el Z-Buffering, siempre pensé que renunciar a ese efecto en n64 iba a resultar en temblequismo poligonal agudo, pero por lo visto el World driver Championship lo dejarón bien apañado. :3

Z-buffer es una cosa, y corrección de perspectiva es otra.

El z-buffer si quita rendimiento, pero la corrección de perspectiva por lo visto sale casi gratis, y por eso ves el world rally este sin exhibir el problema del temblequeo (porque no lo desactivaron, ni hubieran conseguido nada haciéndolo).

Dicho esto, yo quiero 300k polígonos a 20fps

Y luego un port del daytona usa a 100k polígonos a 60fps.

@Señor Ventura yo 700k a 8fps.

Calculinho escribió:@Señor Ventura yo 700k a 8fps.

Joder, si!, 8fps es jugable en ciertos géneros!.

xD

Yo creo que este es un buen momento para consultarle @BMBx64 qué precio hay que pagar por cada cosa.

- Z-Buffer: congestiona un precioso ancho de banda que ya es estrecho de por sí por culpa de la rambus. Desactivándolo ganamos tasa de relleno.

- Anti Aliasing: coste de procesador 0 para la N64 creo recordar, pero imagino que consume espacio en RAM, ¿no?

- Enviroment mapping & reflecciones especulares: esto puede considerarse un segundo paso por textura, por lo tanto debería suponer coste de procesador y espacio en RAM simulatáneamente.

- Corrección de perspectiva: ¿0 coste de capacidad de proceso?

- Tri Linear Mip Mapping Interpolation & Filtro bilineal: ¿coste de procesador?¿Espacio en RAM?

- Automatic Load Management: no me acuerdo ni pará qué sirve esto


Cuando aclaremos esto del todo podremos empezar a fliparnos cada uno con más propiedad ; )

Dio_Brand escribió:siempre pensé que renunciar a ese efecto en n64 iba a resultar en temblequismo poligonal agudo

El Z-buffer no tiene nada que ver con el tembleque de poligonos. El tembleque de la PS1 se debe a usar baja precision matematica para calcular la posicion de los vertices, cuando se mapea el espacio 3D de los modelos al espacio 3D del punto de vista de la pantalla (3D transform). Al usar menor precision, la granularidad del desplazamiento es menor y la distancia de una posicion a la siguiente es mayor, causando que se aprecie un salto.
Dado que, en cualquier escena animada, es frecuente que se realicen movimientos finos para adelante y atras, eso provoca que, por el redondeo, un vertice acabe saltando de posiciones varias veces,

No se si en PS1 es posible si quiera hacer tranform con mayor precision, pero ciertamente en N64 es posible hacer transform con precision menor, especialmente cuando portan juegos de PS1 a N64 en plan chapucero. Prueba juegos que sean port de PS1 y verás algo de esto.
Mas sorprendente es que algunos juegos DE LOS BUENOS de N64 usan tranformacion 3D de baja precision en algunos contextos. Por ejemplo, En Banjo-Kazooie, si miras de cerca a ciertos NPCs de a los que les puedes hablar (porque se estan mas o menos quietos, no como los enemigos), notarás un cierto tembleque, porque internamente sus animaciones se hacen con transformacion de baja precision antes de insertar el resultado en la escena general, que, esta si, se tranforma con mayor precision. De lejos no se nota, pero de cerca, con la vista en primera persona, si prestas atencion, si.

...Y de esta manera acabo de fastidiar la ilusion a los que no se habian fijado DDDDDD

Claro que en PS1, la tranformacion de baja precision es a nivel del renderizador y no se si es si quiera posible hacerlo con mayor precision...
Además en PS1, la distorsion de texturas por falta de perspective correction, tambien contribuye al aspecto temblon y "rotillo". Claro que ahora eso me da igual y hasta lo encuentro interesante.

Sexy MotherFucker escribió:Y por eso si estuviésemos hablando de la Ps2 diría justo lo CONTRARIO, ya que este sistema sufre de un sobredibujado galopante, necesitando buffers de profundidad bien medidos como el comer. Si estuviese hablando de la Dreamcast diría que no necesita nada, pero no por nada, sino porque es un tile-render, etc.

Me interesan estas cosas que comentas. Me pones enlaces?

Calculinho escribió:Aprovecho para preguntar, especialmente a @radorn, si sabemos que el Z-buffering por hardware de la consola usándolo mal lastra tanto el framerate y que PSX lo usaba por software para determinadas cosas. Teniendo en cuenta que en fuerza bruta de CPU N64 es superior ¿No ganaría más implementándolo directamente por software y así descargando el ancho de banda de la RAM para otras cosas?

El problema del Z-Buffer en N64 no hacerlo por software o hardware (o concretamente por microcodigo). A nivel de procesamiento no es tan problematico, dado que forma parte del proceso de renderizado. El Z-buffer es como un framebuffer mas, en este caso, habitualmente, de 16-bit por pixel, igual que el buffer de imagen, pero en vez de almacenar la imagen renderizada en forma de valores RGB, contiene valores de profundidad. Si reinterpretamos esos Z-buffers como imagen obtenemos cosas como esto https://duckduckgo.com/?q=z-buffer+imag ... &ia=images. Cada pixel contiene el valor de la distancia desde la camara hasta el punto exacto de la escena que representa. Cuando mas lejos, un valor mayor, que en este caso interpretan a la inversa para que lo mas lejano parezca mas oscuro, aunque en otros ejemplos lo hacen al reves.

El Z-buffer sirve para varias cosas. Primero, en sistemas sin Z-buffer, como la PS1, el motor del juego tiene que calcular bien las posiciones de cada objeto (que dependiendo del motor pueden ser triangulos independientes o meshes enteros, como un brazo o lo que sea), y enviar al proceso de renderizado todos los objetos en orden, empeazando por los mas lejanos a la camara y acabando por los mas cercanos, para que, de esta manera, los mas cercanos se vean por encima de los lejanos, como es de esperar. Esto no siempre es facil y no siempre sale bien porque dependiendo de muchos factores, un trozo de un objeto puede estar delante y otro detras pero al final todo el objeto acaba delante o detras. Imaginate un objeto medio sumergido en agua. ¿renderizas primero el objeto o el agua? lo que renderizes ultimo queda por encima, y no hay mas que hablar, no hay covertura parcial sin z-buffer, porque con el z-buffer sabes perfectamente la distancia de cada pixel a medida que renderizas, con lo cual, si el siguiente objeto que renderizes en la misma zona, tiene una distancia menor, lo superpones y actualizas el z-buffer, y si está mas lejos, lo descartas. A no ser que el pixel original sea transparente, y entonces mezclas (claro que lo mas inteligente es dejar los objetos transparentes en ultimo lugar, y asi facilitar las cosas)

Hay muchos otros supuestos e incluso el Z-buffer tiene sus limitaciones, pero ese es uno de sus principales cometidos. El problema es que, independientemente de lo que cueste calcular los valores Z, tener un Z-buffer implica que tienes que transferir mas datos a alguna RAM... y ese es el problema de la N64, que es memoria unificada, con un bus de 8bit (tecnicamente 9, pero el bit extra se usa para otra cosa, no para datos normales), y muy alta latencia que penaliza cualquier tarea paralela que tengas. Si puedes ahorrarte el Z-Buffer tienes mucho que ganar.

Sexy MotherFucker escribió:- Anti Aliasing: coste de procesador 0 para la N64 creo recordar, pero imagino que consume espacio en RAM, ¿no?

Muchos mas detalles no se, pero si te puedo decir que el AA se aplica en dos "manos de pintura". La primera se aplica en el framebuffer, creo que para los "inner edges", que creo que son los que comparten vertices, y no se si textura tambien. Puede que requiera releer el framebuffer o quiza no. no lo se
La segunda mano, para los outer edges (flotantes o no concordantes), se aplica de la siguiente manera. Durante el renderizado, en el bit extra de la RDRAM (los famosos 9 bit), se almacena informacion de covertura de pixel. Como la mayoria de juegos renderizan a 16bit, son 2 bit por pixel de covertura. Usando estas pistas, el VI, al pasar los datos al DAC, mezcla pixeles adyacentes segun la informacion de covertura. Esto ocurre solo en las aristas de los poligonos y es el causante de ese efecto estraño de distorsion cuando dos objetos intersectan, que incluso sucede con elementos del HUD o los bordes de la pantalla.

@radorn te paso de momento el de Dreamcast, que no encuentro el de Ps2:

https://www.anaitgames.com/articulos/la ... ahercios-6

Cabe decir que este artículo está escrito por David Senabre, un conocido ingeniero y programador informático español debido a su divulgación en diversos medios; no es ningún "forero" hablando de gratis, entiende el tema a la perfección.

@radorn ¿Qué Banjo tiene tembleques? ACABAS DE MATARME EL JUEGO, ya no puede ser mi juego favorito de N64 lo siento ¡Me buscaré otro con todo activado, rocoso, 640x480 y a 10fps!

@Calculinho ¿Seica estamos de carallada? ¡Non me rompa-la cabesa, rapás!
...cuanta exageración, madre mia. xD

@radorn non sexas mexeriqueiro DAME POLIGONOS POR SEGUNDO!

@Sexy MotherFucker
A ver.. en N64 se puede configurar la lógica del z-buffer y hay 2 modos, por pixel y por primitiva.

Se crea un buffer del tamaño de la pantalla, que no es más que un array de ancho*alto con información Z de cada pixel, se va actualizando a medida que se van pintando los triángulos o rectángulos para su correcto posicionamiento, es decir solo en los pixeles que quedan por encima.

Se usa precisión de 16 bits, en un mapa tridimensional se puede situar Z de 0 a 65535, pero no solo ésto, el z-buffer ocupa en RAM lo mismo que el framebuffer y es más, si aumentamos la resolución el número de cálculos también aumenta proporcionalmente, porque el mapa a comprobar es más grande.

La diferencia por primitiva y por pixel es que por primitiva el array se llena de un valor Z que se le pasa como parámetro, lo cual ahorra cálculos y es mucho más rápido, vendría a ser los elementos 2D en un mundo 3D, carteles, arboles, público de cartón .. en cambio por pixel necesita sacar el cálculo de los vértices para trazar la posición exacta.

Funciona como el framebuffer, hay que limpiarlo en cada frame.

En cuanto al AA hay varios modos, uno de ellos no conoce información y lo único que hace es aplicar el algoritmo de filtrado a toda la pantalla, éste es el barato y el que emborrona la imagen, no le cuesta prácticamente nada.

Ahora si quieres el AA que solo suaviza contornos y siluetas, la consola necesita saber datos de antemano y esos datos los recoge del z-buffer, así que ese es el coste.

Por otro lado el z-buffer se puede usar para culling y ahí está el verdadero secreto si se hubiera utilizado bien, leyendo ese array puedes encontrar "paredes", saber cual es su posición espacial y descartar objetos sin tener que montar un código que maneje todo ésto.

La otra utilidad es que ante un display list enorme, el z-buffer puede ser más rápido, lo cual requeriría mostrar una buena cifra de polígonos en pantalla, no los 4000 por frame que se llevaban en la época.

--
Los efectos que requieran cycle2 necesitan el doble de tiempo que cycle1, filtrar texturas es rápido, en 2D no hay diferencia de velocidad, lo mismo pasa al usar o no transparencias, parece que parte del coste ya viene incluido al pintar en 1cycle con respecto a copy, pero ésto seria mejor analizarlo en condiciones 3D reales.

Corrección de perspectiva tiene coste, pero razonable.

--

Los tembleques de PSX:
- No tiene FPU para el cálculo de coma flotante, trabaja con enteros (baja precisión)
- La GPU no puede pintar resultados intermedios a precisión sub-pixel
- No tiene corrección de perspectiva

BMBx64 escribió:@Sexy MotherFucker
A ver.. en N64 se puede configurar la lógica del z-buffer y hay 2 modos, por pixel y por primitiva.

Se crea un buffer del tamaño de la pantalla, que no es más que un array de ancho*alto con información Z de cada pixel, se va actualizando a medida que se van pintando los triángulos o rectángulos para su correcto posicionamiento, es decir solo en los pixeles que quedan por encima.

Se usa precisión de 16 bits, en un mapa tridimensional se puede situar Z de 0 a 65535, pero no solo ésto, el z-buffer ocupa en RAM lo mismo que el framebuffer y es más, si aumentamos la resolución el número de cálculos también aumenta proporcionalmente, porque el mapa a comprobar es más grande.

La diferencia por primitiva y por pixel es que por primitiva el array se llena de un valor Z que se le pasa como parámetro, lo cual ahorra cálculos y es mucho más rápido, vendría a ser los elementos 2D en un mundo 3D, carteles, arboles, público de cartón .. en cambio por pixel necesita sacar el cálculo de los vértices para trazar la posición exacta.

Funciona como el framebuffer, hay que limpiarlo en cada frame.

En cuanto al AA hay varios modos, uno de ellos no conoce información y lo único que hace es aplicar el algoritmo de filtrado a toda la pantalla, éste es el barato y el que emborrona la imagen, no le cuesta prácticamente nada.

Ahora si quieres el AA que solo suaviza contornos y siluetas, la consola necesita saber datos de antemano y esos datos los recoge del z-buffer, así que ese es el coste.

Por otro lado el z-buffer se puede usar para culling y ahí está el verdadero secreto si se hubiera utilizado bien, leyendo ese array puedes encontrar "paredes", saber cual es su posición espacial y descartar objetos sin tener que montar un código que maneje todo ésto.

La otra utilidad es que ante un display list enorme, el z-buffer puede ser más rápido, lo cual requeriría mostrar una buena cifra de polígonos en pantalla, no los 4000 por frame que se llevaban en la época.

--
Los efectos que requieran cycle2 necesitan el doble de tiempo que cycle1, filtrar texturas es rápido, en 2D no hay diferencia de velocidad, lo mismo pasa al usar o no transparencias, parece que parte del coste ya viene incluido al pintar en 1cycle con respecto a copy, pero ésto seria mejor analizarlo en condiciones 3D reales.

Corrección de perspectiva tiene coste, pero razonable.

--

Los tembleques de PSX:
- No tiene FPU para el cálculo de coma flotante, trabaja con enteros (baja precisión)
- La GPU no puede pintar resultados intermedios a precisión sub-pixel
- No tiene corrección de perspectiva

Comentastes que hacer TLMM necesita estar en 2-cycles,¿entonces mejoraría el rendimiento prescindiendo de él, o repercutiría en la tasa de relleno?,ya que se supone que el TLMM ahorra tasa de relleno al no tener que pintar la textura al completo de su resolución cuando esta lejos de la camara,¿ o me equivoco?.

Luego,si no se hace uso del TLMM, se podría usar texturas de 128px*64px*4bits de escala de grises,ya que no usa tablas de indexado y ocupan los 4KB de la caché de texturas.

Salud.

@dirtymagic Mip-mapping por si solo PODRÍA ahorrar fillrate, pero al ser tri-linear mip-map interpolation, realmente se está haciendo un fundido entre 2 mipmaps diferentes, y eso no ahorra nada, si no todo lo contrario xD.
La cuestion es que, para hacer mip-mapping, sin una buena interpolacion, es mejor comerse el aliasing que los mip-maps tratan de evitar, porque, si no, te quedan un monton de bandas cantosisimas donde el renderer pasa de un mipmap al siguiente.

Lo de las texturas que dices se supongo que se puede hacer, desde luego, y hasta creo que el GoldenEye lo hace para los grandes tallados murales de la fase extra del templo azteca. Pero claro, no puedes usar texturas monocromaticas y coloreado por vertices para TODO. Para muchas cosas, hasta diría que la mayoría, necesitas texturas a color... Si no acabarías con un esquema de color a lo ZX Spectrum, donde los objetos tenian que ser de un solo color + negro.

radorn escribió:@dirtymagic Mip-mapping por si solo PODRÍA ahorrar fillrate, pero al ser tri-linear mip-map interpolation, realmente se está haciendo un fundido entre 2 mipmaps diferentes, y eso no ahorra nada, si no todo lo contrario xD.
La cuestion es que, para hacer mip-mapping, sin una buena interpolacion, es mejor comerse el aliasing que los mip-maps tratan de evitar, porque, si no, te quedan un monton de bandas cantosisimas donde el renderer pasa de un mipmap al siguiente.

Lo de las texturas que dices se supongo que se puede hacer, desde luego, y hasta creo que el GoldenEye lo hace para los grandes tallados murales de la fase extra del templo azteca. Pero claro, no puedes usar texturas monocromaticas y coloreado por vertices para TODO. Para muchas cosas, hasta diría que la mayoría, necesitas texturas a color... Si no acabarías con un esquema de color a lo ZX Spectrum, donde los objetos tenian que ser de un solo color + negro.

Pensaba que siempre usaba TLMM salvo excepciones (Super Mario 64),vamos a mi me da la sensación que tienen 3 niveles de resolución, sobre todo se me hace muy notorio en texturas que son azulejos como en el Goldeneye,pero si que estoy de acuerdo que se ve horrible.
La placa Model 2 usa texturas en escala de grises que luego colorea,no se si funcionan de forma distinta a como lo hace la N64 (Vertex Color),ya que no he encontrado información.
Pero vamos es más que nada por que lo que peor se ve en mi opinión en N64 son la poca resolución de las texturas,debido a la compresión y a la cache de la consola.

Salud.

Estoy viendo un gameplay del world driver championship, y joder, a nada que consigan mejorar el rendimiento de la n64, ya mas potencia que esto definitvamente sería acercarse bastante a los números mínimos para un port decente del daytona usa.

https://youtu.be/_dACWGnfKKw?t=98

Daytona usa arcade:
https://youtu.be/GAcMqFTkAs8?t=204

@Señor Ventura no me pegues, pero a mi me parece que gráficamente ya es mejor el WDC de N64 que el Daytona. Tema aparte es que en el polycount no

Calculinho escribió:@Señor Ventura no me pegues, pero a mi me parece que gráficamente ya es mejor el WDC de N64 que el Daytona. Tema aparte es que en el polycount no

Si que se nota algo en ese sentido, si, lo que pasa es que el daytona funciona a mucha mas resolución, el doble de frames por segundo, una millonada de polígonos mas...

La buena noticia es que el daytona usa tiene que estar malgastando polígonos a saco, porque da la sensación de que ese resultado geométrico se puede conseguir con un número considerablemente menor de ellos.

No se, tal vez 90k polígonos a 60fps con las mejoras que pretenden conseguir, su antialising, corrección de perspectiva, z-buffer a la carta por software... no te digo yo que no pueda salir algo visualmente cercano al arcade. Eso si, las texturas son una incógnita, pero podemos jurar que por ahí si que pegaría el cante.


Por cierto:
https://youtu.be/XV_gdr_ZLeg?t=1183

@Señor Ventura @Calculinho
Siendo optimistas, veo más posible un port de la versión de Saturn.
https://youtu.be/UHZvMCzlQKc?t=2m26s

Tiene un polycount que puede mover la N64 y no hay que adaptar muchas texturas. Se vería muy beneficiado de filtros, transparencias e incluso de niebla para disimular el popping. No costaría mucho a un veterano de la scene conseguir 25-30fps estables.
El mayor problema es la música. O bien alguien la recompone a MIDI + samples o se consigue una compresión razonable en coste de tamaño y proceso, pero sería más complicado de desarrollar.

EMaDeLoC escribió:@Señor Ventura @Calculinho
Siendo optimistas, veo más posible un port de la versión de Saturn.
https://youtu.be/UHZvMCzlQKc?t=2m26s

Tiene un polycount que puede mover la N64 y no hay que adaptar muchas texturas. Se vería muy beneficiado de filtros, transparencias e incluso de niebla para disimular el popping. No costaría mucho a un veterano de la scene conseguir 25-30fps estables.
El mayor problema es la música. O bien alguien la recompone a MIDI + samples o se consigue una compresión razonable en coste de tamaño y proceso, pero sería más complicado de desarrollar.

Pero es que ese rendimeinto ya lo podía conseguir la n64 en su día sin apretarle las tuercas a la consola.

La versión saturn creo que le anda por los 90k polígonos (que no quads), o eso tengo entendido. Si el wdc de la n64 consigue 130k polígonos a 30fps, entonces con una solución gráfica similar se podrían conseguir 43fps a 90k polígonos.

Y la cuestión es que si la escena realmente consigue mejorar el rendimiento de los microcódigos, ya hablaríamos de conseguir incluso mas de 43fps.

Todo esto hablando de hechos, no de que sea pan comido conseguir el rendimiento del wdc, se entiende


No vería tan descabellado conseguir el resultado gráfico de saturn, pero cerca de los 60fps, con su antialising, y sus historias.

@Señor Ventura la versión Saturn ronda 50-70k según el tramo, y son quads. El VDP-1 renderiza quads a no ser que lo fuerces, y cuando lo haces se pierde capacidad de proceso, o sea que son quads en el 99% de juegos.

La primera digo.

Sexy MotherFucker escribió:@Señor Ventura la versión Saturn ronda 50-70k según el tramo, y son quads. El VDP-1 renderiza quads a no ser que lo fuerces, y cuando lo haces se pierde capacidad de proceso, o sea que son quads en el 99% de juegos.

La primera digo.

Por cierto ¿Por qué leches estamos hablando de esta fantasía del Daytona USA 64? ¿Hubo algún rumor en la época o es puramente vuestro sueño húmedo partícular? Y otra cosa, cualquier juego 3D homebrew va a ser jodido de hacer, pero elegir uno que usa quads no va a ser más jodido de transformar a triángulos? xD

Aun no me he leido todo el hilo, asi que pido disculpas si ya se ha comentado algo de esto:

Estoy trasteando con la herramienta u64aap y los juegos StarFox 64 y MISSION:IMPOSSIBLE, notorios por su super-borrosidad debido, en mi opinion, a una incomprensible eleccion de filtros.

En la herramienta se pueden activar y desactivar 4 caracteristicas del VI
-Gamma correction - Aplica una funcion gamma fija a la imagen, aumentando su luminosidad a costa de perder rango dinamico en los tonos mas oscuros
-Gamma dithering - Consigue la misma luminosidad, pero a través de un proceso de filtrado que solapa la perdida de rango dinamico de los oscuros a costa de mayor borrosidad
-DIVOT - No lo he entendido demasiado bien, pero creo que es la funcion que suaviza los bordes con las anteiormente mencionadas pistas del bit #9 de la RDRAM
-Dither filter - El renderizado a 16bit habitualmente hace dithering a traves de la tecnica "magic square", cuyo efecto visible es un extraño punteado, especialmente notorio en colores planos. Activar esta funcion introduce ruido aleatorio en los LSB de los componentes de color RGB, solapando/filtrando el punteado estatico del dither.

Creo que la herramienta no soporta todas las configuraciones del VI, porque la informacion inicial en la que se basa todo esto, ofrecida por Zoinkity, parece ofrecer mas cosas.

No parece que la herramienta ofrezca escojer los modos de antialiasing, ni dice nada del "serrate", ni los dos tipos de divot... en fin...

La cuestion es que, tanto SF64/LW como M:I tuvieron la mala idea de usar el filtrado mas agresivo y ridiculo que se les ocurrió (probablemente afectando al rendimiento tambien). Lo mas notorio es que usan el dichoso Gamma dithering, que crea un halo al rededor de cualquier pixel medianamente intenso. Como esto provoca un aumento de gamma, decidieron renderizar con una funcion gamma inversa, para que lo uno con lo otro se cancelase. Pero claro, al disminuir el gamma durante el renderizado (para subirlo otra vez despues), lo que sucede es que el renderizado a 16 bit con dithering por magic-square mete un punteado criminal, y esto retroalimenta al gamma dithering causando aun mas halos al rededor de todo....
Que se cubrieron de gloria vamos

Total, que estoy probando a desactivar el gamma dithering y activar el gamma correction en su lugar, y viendo si el dither filter es capaz de solapar los efectos perniciosos de renderizar escenas tan oscuras a 16 bit...
Lo ideal sería hackear el juego a nivel del motor para que no renderize tan oscuro para empezar, aunque no se si eso es posible o hay que modificar directamente todos los materiales graficos del juego para conseguir eso...

Si alguien recuerda lo oscuro que parecía este juego en los primeros emuladores para PC y no sabia por qué (como yo) esta es la razon. El emu, HLE, emula la renderizacion al framebuffer, pero no los filtrados del VI que corrigen esa oscuridad a costa de un emborronamiento masivo.

Lo cual no resuelve el misterio de a quién se le ocurrió la gran idea de hacer las cosas de esta manera y por qué...
¿Realmente era la mejor opcion? yo diria que parece bastante evidente que no... pero a saber que intentaban conseguir.
Misterios...

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

Calculinho escribió:cualquier juego 3D homebrew va a ser jodido de hacer, pero elegir uno que usa quads no va a ser más jodido de transformar a triángulos? xD

No veo que relacion puede tener eso. Dado que, hasta donde yo se, no se ha filtrado el codigo fuente de ningun Daytona USA, ni tampoco hay ningun motor "clonado" que se pudiese usar como base (y, si lo hubiese, seguro que estaría basado en triangulos), si se hiciera un DU para cualquier plataforma, N64 o la que fuera, habría que hacerlo de cero, asi que la dificultad es la misma...
Vamos, es una apreciacion mia. Igual me equivoco, pero, sinceramente, no veo ningun fallo en mi razonamiento.

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

De mi fracasado hilo de historia alternativa de 64DD

Calculinho escribió:...todavía no hemos sopesado la posibilidad de que la scene diseñe un chip de apoyo de algún tipo que ayude a N64 a corregir alguna de sus carencias con las texturas o cualquier cosa que ayudase a mejorar la fluidez, etc.

Hombre, ese tipo de chips, a lo Super-FX, lo veo un poco superficial en un sistema como N64, la verdad.
No es como en las 16 bit, que podías añadir cosas que ya no es que fueran dificilisimas en la consola pelada, si no tan fuera de alcance como para hacerlas imposibles.

Se puede hacer 3D en las MD y SNES peladas (en la MD bastante mejor por el 68000), pero el rendimiento es penoso aun con escenas muy simples. Metes un chip de apoyo que renderize esas escenas y ponga el framebuffer resultante en formato "tiles" para que lo rasterize el chip grafico de la consola y el salto es brutal. Añades algo que en la consola basica es impracticable o directamente imposible.

En N64 que haces? le añades un PC encima y haces streaming de los resultados a la consola, reduciendola a un mero reproductor de video?... para eso usa un PC directamente.

Añadidos mas sencillos podría ser un reproductor de MP3/Opus dentro del cartucho flash aprovechando las patillas de audio que hay en el conector. Mas que eso... no se

Fijate por ejemplo en la SNES. El UNICO chip de apoyo homebrew del que estoy al tanto es el MSU-1, y basicamente es una extension de memoria. No estoy muy seguro en este momento de cual era el metodo de acceso que ofrece, pero basicamente lo que hace es añadir 4GB de almacenamiento extra al que se puede acceder. En el puedes meter, creo, cualquier tipo de datos, pero la mayoria de la gente lo ha usado para sustituir la musica original de los juegos por musica pregrabada y secuencias de video.
El equivalente de eso en cartuchos de N64, al menos el 64drive, que es el que conozco, es el acceso por LBA a la tarjeta SD.

El 64drive tiene tambien comunicacion por USB y el modelo nuevo, a espera de firmware para hacerlo funcionar, tiene un modulo wifi.

Es que realmente, ponerse a estas alturas a hacer extensiones a la N64 lo veo un tanto redundante. Tendrías que meter algo tan potente... sería como hacer un cluster. Y que puedes meterle, un procesador ARM? para hacer que exactamente...
No se... no le veo la gracia.
Si fuera oficial y tuviese software profesional existente, podría tener sentido seguirlo utilizando, pero ahora, con la plataforma oficialmente abandonada, queda raro.

No se... se me ocurre que, igual, una interfaz rara para enganchar 2 N64s en paralelo tendría algo mas de gracia, pero es una puta locura xDDDDDDDDD Y no tengo muy claro que ventajas podría aportar.

@radorn pero te me has ido por donde no era, yo no digo de meter un chip que renderice gráficos superiores, eso se está haciendo ahora con la NES, pero pierde la gracia. Yo te dije si el problema de texturizar de N64 no podría arreglarse con algún tipo de chip.

Si alguien recuerda lo oscuro que parecía este juego en los primeros emuladores para PC y no sabia por qué (como yo) esta es la razon. El emu, HLE, emula la renderizacion al framebuffer, pero no los filtrados del VI que corrigen esa oscuridad a costa de un emborronamiento masivo.

Lo cual no resuelve el misterio de a quién se le ocurrió la gran idea de hacer las cosas de esta manera y por qué...
¿Realmente era la mejor opcion? yo diria que parece bastante evidente que no... pero a saber que intentaban conseguir.
Misterios...

Se filtraron los devkits de la libultra y el código les sirvió para entender qué era cada función, con qué parámetros se llamaban, etc, en aquella época era imposible emular el RCP a buena velocidad, así que todo lo que hacían los emuladores era interceptar esas llamadas y traducirlas a PC.

Total que ni los efectos eran los mismos, eran equivalencias, ni todos los efectos estaban presentes, ni la representación era la misma.

@BMBx64 Ya, pero yo hablo de que en verdad SF64 y M:I renderizan "en oscuro" y luego aplican correccion gamma y los filtros mas bestias de la consola, lo cual resulta en una borrosidad brutal, y no entiendo por qué decidieron hacerlo así. Otros juegos renderizan con gamma normal y no usan correccion gamma por VI y puedes "des-filtrarlos" sin muchos problemas, pero, por culpa de la super oscuridad, estos dos quedan mal hagas lo que hagas: Puedes escojer entre super borroso, super oscuro, o super punteado y con rango dinamico reducido.

Yo las primeras veces que intenté usar emuladores de N64 rapidamente fuí al starfox porque me tenia encandilado y me quedé horrorizado de lo oscuro que se veia. Si vale, error de emulacion, pero es que luego pruebo esto de desactivar filtros en la ROM y me encuentro con que me recuerda mucho a aquellas primeras experiencias con el emulador. ¿Explicacion? el VI.

Calculinho escribió:eso se está haciendo ahora con la NES

A qué te refieres?

Calculinho escribió:Yo te dije si el problema de texturizar de N64 no podría arreglarse con algún tipo de chip.

Pues no creo. "Texturizar" es un paso del proceso de renderizado, y este ocurre en el RCP, y, hasta donde yo veo, no hay modo de "externalizar" ese paso concreto, o cualquier otro, sin trasladar practicamente todo el proceso a otro componente. Incluso si se pudiera, incurrirías en mas trafico en el bus de la RDRAM y el PI, y mayor latencia al tener que andarse pasando cosas de un lado a otro. Así que basicamente o lo haces en el RCP o lo haces en otro lado, no hay mucho mas...
De hecho, el SuperFX es basicamente un ordenador independiente, y, segun creo, el grueso del juego corre en el, siendo la SNES de base poco mas que un "receptor", una terminal. Como el Super GAMEBOY, que tiene toda la circuiteria de una gameboy dentro y luego pasa la imagen resultante a la SNES en forma de tile-graphics.

@radorn lo de NES es esto viewtopic.php?p=1745904513

@Calculinho Ah, eso. Si, lo habia visto hace un tiempo, no recuerdo por donde me encontré la referencia.
Me costó mucho seguirle el rollo al tio porque se empeña en hacer una presentacion filosofico-abstracta, y con ese tono parsimonioso y en voz bajita... me pone de los nervios. Se pasa mas de un cuarto de hora comiendote la oreja para no decir nada interesante, llenandote la cabeza con sus pajas mentales, en vez de ir al grano y decirte que ha diseñado un "emulador" de SNES para NES y explicarte cómo.
Ains...

Total, que es posible que por ser el tio insufrible, me haya saltado cosas relevantes, pero, si le entiendo bien, la cosa esa hace basicamente lo que el Super GAME BOY, quizá con alguna vuelta de tuerca mas, solo que en vez de ser GB en SNES es SNES en NES.

@radorn @BMBx64 @EMaDeLoC @chinitosoccer, y hablando estos días de las olas en Wave Race 64, Digital Foundry acaba de hacerle un homenaje repasando los efectos de agua a lo largo de la historia de los videojuegos:

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

@radorn
Ah, ya me extrañaba que preguntaras eso.

Si no lo has leído ya, igual te interese el texto dedicado en el manual.


El filtro dither que añade ruido aleatorio sobre colores planos, especialmente el negro es horrible.

@Sexy MotherFucker
A ver que tal

Sexy MotherFucker escribió:@radorn te paso de momento el de Dreamcast, que no encuentro el de Ps2:

https://www.anaitgames.com/articulos/la ... ahercios-6

Cabe decir que este artículo está escrito por David Senabre, un conocido ingeniero y programador informático español debido a su divulgación en diversos medios; no es ningún "forero" hablando de gratis, entiende el tema a la perfección.

hijo de perra que pedazo de articulos te ailovio, aqui el indice con todos

https://www.anaitgames.com/articulos/la ... ahercios-1

@BMBx64 Juas, me alucina que en ese manual recomendasen diseñar los graficos y renderizarlos sin gamma en un formato con tan poco rango dinamico como 15-bit RGB y dejar la corrección a los filtros del VI... No me extraña que lo hicieran tan pocos juegos (al menos de los buenos), porque el resultado es una abominación. ¿En qué coño estaban pensando? ¿No veian lo mal que salía? ¿O la estoy cagando y tienen razón en sus recomendaciones?

Por cierto, ¿Qué manual es ese? yo habia visto manuales "online", en formato HTLM "interactivo", pero eso claramente está en papel.

@Sexy MotherFucker Vi el aviso, pero aún no me lo he visto.

radorn escribió:Por cierto, ¿Qué manual es ese? yo habia visto manuales "online", en formato HTLM "interactivo", pero eso claramente está en papel.

Creo que es la primera documentación que se filtró, un escaneo que tiene pinta de viejo del manual de programacion oficial. Lo interesante de ese documento es que viene con anotaciones a mano, algunas relativas a programación, una desternillante como cuando el manual define la velocidad del SI como "really slow" y al lado aparece "ha ha! No, really..."
El manual lo tienes aquí, y el apunte mencionado esta en la página 48 del documento, 50 del pdf.

Me he encontrado esto por casualidad muestra la RDRAM a bajo nivel solo funciona en hardware real
https://www.romhacking.net/homebrew/102/

@EMaDeLoC gracias!

@Flash-Original No acabo de tener claro para que es ese programa. ¿Es una especie de lector de las hardware ID's de la RDRAM? Este hombre, Zoinkity, siempre hace un monton de cosas de super bajo nivel y documenta todo de forma super detallada, pero pocos hay que realmente puedan decir que le entiendan bien. Yo lo conoci cuando estaba en la comunidad de mods de GE, y hasta el autor del programa editor me dijo una vez que no era capaz de seguir muchas de las cosas que dice.

Esa fuente y modo de composicion de pantalla parece la misma del bootemu de LaC.

@radorn Si no lo he entendido mal, es una rom de diagnóstico de la RDRAM para cuando se hace reparaciones o mods con ella. Por ejemplo, hay mods que cogen placas de las primeras versiones que tienen 2 chips de 2MB y los cambian por 2 chips de 4MB y con el programa podrian ver si la instalación es completamente correcta.

Buenas @BMBx64 . No sé si en el hilo se ha hablado de la N64 comparando con la nintendo DS, pero es que ayer, jugando al Metroid Prime Hunter de DS, vi lo que podría haber sido metroid en N64. ¿Crees que es posible que cualquier juego de la DS funcionase en la 64?
A lo mejor, por tema de resolución, la DS se ve mejor o necesita menos para poder mover más, y parece más potente de lo que en verdad es, pero viendo cosas como final fantasy IV, Zeldas, dragon quests,etc,etc no sé si la 64 podría con ellos.

hyrulen escribió:A lo mejor, por tema de resolución, la DS se ve mejor o necesita menos para poder mover más,

Más que por temas de resolución la DS se ve mejor que la N64 en cuanto brillo y nitidez por la calidad de su señal de vídeo (que ya tiene altos valores RGB color de serie sin ningún tipo de degradación), y por la ausencia de filtros emborronadores, ya que por lo demás una Nintendo DS escupe menos resolución en pixels incluso que una SNES: 256x192.

hyrulen escribió:Buenas @BMBx64 . No sé si en el hilo se ha hablado de la N64 comparando con la nintendo DS, pero es que ayer, jugando al Metroid Prime Hunter de DS, vi lo que podría haber sido metroid en N64. ¿Crees que es posible que cualquier juego de la DS funcionase en la 64?
A lo mejor, por tema de resolución, la DS se ve mejor o necesita menos para poder mover más, y parece más potente de lo que en verdad es, pero viendo cosas como final fantasy IV, Zeldas, dragon quests,etc,etc no sé si la 64 podría con ellos.

Dependerá bastante del juego, pero no he visto nada 2D en NDS que me parezca que una N64 no pudiera mover. A nivel 3D tengo más dudas, no he visto el Prime Hunter, creo que hay juegos muy simples que sí (Brain Training, Nintendogs, etc), pero otros no lo veo tan claro porque incluso en la NDS iban mal, ahora mismo no recuerdo si era un CoD o un Brothers in Arms, pero un FPS militar iba bastante mal de framerate en la portátil ya.

¿Podría con el Dementium II? (Mejor FPS portátil de lo que he probado esa gen) https://youtu.be/hkfZGhPD5J4?t=3m27s

Y antes de decir que se ve mal en ese vídeo, tened en cuenta que la resolución está estirada como cuatro veces el tamaño original.

@EMaDeLoC Tu me estás diciendo "para qué sirve" (al menos una de sus supuestas utilidades), pero no "qué hace".

Aún no lo he probado... bueno, ni yo ni "nadie", porque aun hoy la pagina dice que solo ha habido 2 descargas, y una es mia... El caso es que me he puesto a leer el readme, cosa que os desafío a hacer, y lo que hace es mostrar un porrón de registros del hardware de la RDRAM, cosa que queda bastante claro con el pantallazo
https://www.romhacking.net/homebrew/n64 ... nshot1.png
Supongo que siendo la mayoria de vosotros usuarios de EverDrives nunca se os ha ocurrido usar ningun boot-emulator de los clasicos, pero viendo el aspecto de ese pantallazo, a mi me sugiere, como ya dije antes, que está montado encima del "LaC's Universal Bootemu V1.2 (PD).n64"

Así que lo que he podido sacar en limpio es que se muestran un monton de valores de la RI (Rdram Interface) y los diferentes modulos/chips de RDRAM, mediante registros que hay que interpretar con el README en la mano.
No tengo claro qué clase de errores podrían indicar dichos errores de instalación
Lo unico que, a mi limitado entender, parece que podría servir para tal cosa es esto:

Creo que lo de las "units" que menciona, no es directamente traducible a "chips", si no que los chips te 4MB podrían estar divididos a nivel logico en 2 "units", pero esto es especulacion por mi parte.
Sin embargo, si no fuera así, podría significar de alguna manera que no toda combinacion de chips de RDRAM va a funcionar porque es posible que tengan una direccion base que cause conflicto.

En fin, que venga alguien mas experto y desfaga el entuerto.

Calculinho escribió:...no he visto el Prime Hunter...

Pues no deberías perdértelo si tienes una NDS :
https://youtu.be/w6CGPxCfizg?t=1h24m31s

Sé que juego de guerra dices, pero se debe a lo mal optimizado que está que a que la consola no pueda con él, no recuerdo el nombre, pero he visto videos y da penica

radorn escribió:@EMaDeLoC Tu me estás diciendo "para qué sirve" (al menos una de sus supuestas utilidades), pero no "qué hace".

Es que es casi lo mismo...
¿Qué hace? Muestra los registros del RI y la identificación del los chips RDRAM.
¿Para qué sirve? Muestra los registros del RI y la identificación del los chips RDRAM.

radorn escribió:No tengo claro qué clase de errores podrían indicar dichos errores de instalación.

Pues por ejemplo un tamaño incorrecto, un banco de memoria que devuelve un valor que no toca, cosas así.
Y sirve también de diagnóstico, si un juego se cuelga al cabo de un rato podría ser error de memoria.

Creo que cuando dice "unidades" se refiere a la unidad de memoria instalada (los 4MB de serie) y a la expandida (el expansión pak). Por ejemplo dice:

Es decir, una unidad multibanco, 2 bancos (chips) de 2MB de memoria instalada.
Pero también depende del contexto. Habla de unidades de ciclos de reloj un poco más adelante.

Aparte de lo que he dicho, no veo mucha utilidad a esto más que a muy bajo nivel de programación. De hecho creo que de estos registro ni te enteras, que el SO se encarga de gestionarlos y generar interrupciones si es necesario.

EMaDeLoC escribió:Es que es casi lo mismo...

no...

EMaDeLoC escribió:¿Qué hace? Muestra los registros del RI y la identificación del los chips RDRAM.

si...

EMaDeLoC escribió:¿Para qué sirve? Muestra los registros del RI y la identificación del los chips RDRAM.

ya... y una consola de videojuegos sirve para introducir en ella un programa en algun formato fisico, que se ejecuta en los elementos computacionales de su hardware y, variando la ejecucion de dicho programa de acuerdo con su estado interno y la informacion introducida por un usuario mediante un controlador, habitualmente compuesto de botones, produce señales de imagene y sonido reproducibles por un conjunto de pantalla de video y altavoces.
Y un vehiculo de motor de combustion interna sirve para quemar un combustible derivado normalmente dle petroleo y transmitir la energia resultante a unas ruedas a traves de un sistema de engranajes, vielas, poleas y ejes.
Y una llave inglesa sirve para convertir, mediante friccion, el empuje lineal de la mano a una fuerza de torsión sobre una tuerca.
No se si me entiendes...

Hay que diferenciar funcionamiento y proposito.

La disquisicion inicial era que yo intentando saber QUE HACE, o sea, que funcion realiza, el programa tu me repetiste el principal proposito especificado en la descripcion para el que una persona podría querer usar dicho programa.
Aun mas interesante es saber exactamente de qué manera ayuda la funcion del programa a cumplir el propósito pretendido/anunciado en la descripcion, cosa que, creo que estamos de acuerdo que no tenemos suficientemente clara.

...filosofia... xDDDDDDDD

hyrulen escribió:Buenas @BMBx64 . No sé si en el hilo se ha hablado de la N64 comparando con la nintendo DS, pero es que ayer, jugando al Metroid Prime Hunter de DS, vi lo que podría haber sido metroid en N64. ¿Crees que es posible que cualquier juego de la DS funcionase en la 64?
A lo mejor, por tema de resolución, la DS se ve mejor o necesita menos para poder mover más, y parece más potente de lo que en verdad es, pero viendo cosas como final fantasy IV, Zeldas, dragon quests,etc,etc no sé si la 64 podría con ellos.

La resolución de DS es muy baja, eso le vendría bien a N64 ya que su principal problema es de fillrate, no creo que hubieran demasiados problemas con 1 pantalla, ahora con 2 puede que la cosa no fuera tan bien, DS tiene hardware dedicado para eso.

Sobre los resultados de DS hay que tener en cuenta que los motores 3D ya estaban mucho más evolucionados, se conocían más los trucos, con mejores herramientas y compiladores, el Mario de la DS es más redondeado que el de 64 usando menos polígonos, va compuesto de un esqueleto en lugar de a piezas y se ahorran polígonos innecesarios, etc.

En el 8:30 puedes ver una comparación directa de modelados .
https://www.youtube.com/watch?v=A2gXyEyy_2U

BMBx64 escribió:La resolución de DS es muy baja, eso le vendría bien a N64 ya que su principal problema es de fillrate

¿Que tal sería desactivar scanlines para desahogar eso?.

@Señor Ventura a que te refieres con "desactivar scanlines"?

@radorn en su fanboyismo por la SNES piensa siempre en "scanlines" xD

Se refiere a reducir área de renderizado dentro del frame-buffer, con columnas de pixels en negro, tal cómo hace Resident Evil 4 en Gamecube, y bueno otros de N64, PlayStation, etc.

radorn escribió:La disquisicion inicial era que yo intentando saber QUE HACE, o sea, que funcion realiza, el programa tu me repetiste el principal proposito especificado en la descripcion para el que una persona podría querer usar dicho programa.

Es que no tendrá mucho misterio... Accederá a registros o direcciones de memoria específicas usando alguna función de las librerías o directamente por ensamblador. Más en concreto se lo tendrás que pedir a Zoinkity.
No sé si te refieres a eso, no me ha quedado claro...

radorn escribió:Aun mas interesante es saber exactamente de qué manera ayuda la funcion del programa a cumplir el propósito pretendido/anunciado en la descripcion, cosa que, creo que estamos de acuerdo que no tenemos suficientemente clara.

The point of this is twofold: firstly, to help determine what remarked chips in later consoles actually are, and secondly, as a sort of diagnostic tool to help figure out what went wrong when installing on a board.

La razón de esto son dos: primero, ayuda a determinar que chips renombrados en consolas (revisiones) posteriores son en realidad, y segundo, como una herramienta de diagnóstico para ayudar a averiguar que ha ido mal cuando se instalan en la placa.

Yo no le veo más misterio, más allá de que no tenemos ni idea de electrónica de memorias y no sepamos como interviene una mala soldadura en el código de un registro...

@Sexy MotherFucker Eso ya lo hacen muchos juegos, quitando líneas y columnas de los laterales.
Algunos modos hi-res no son 640x480, sino 320x480 o 640x240 que la consola estira para ocupar toda la pantalla.

EMaDeLoC escribió: sino 320x480 o 640x240 que la consola estira para ocupar toda la pantalla.

Entiendo que el primero es en entrelazado, y el segundo modo en progresivo.

Gracias, yo ya lo sabía, se lo estaba "traduciendo" a Radorn lo que el Ventura quería decir.

EMaDeLoC escribió:No sé si te refieres a eso, no me ha quedado claro...

ciertamente.

EMaDeLoC escribió:más allá de que no tenemos ni idea de electrónica de memorias y no sepamos como interviene una mala soldadura en el código de un registro...

Es que veo dificilisimo que una mala sodadura en un chip de memoria vaya a dar un error de ese tipo, si no que lo mas probable es que sencillamente impida que arranque la maquina. Y, en todo caso, determinar errores de datos, que sería el tipo de problema que daría una mala instalacion fisica (soldar) sería mas claro con un test de memoria como el memtest86 de PC.
A mi me parece que todo esto no tiene que ver con errores tan basicos como soldar mal, si no con cuestiones mas relacionadas con la logica de los modulos y el controlador de memoria, la RAMBUS Interface.
El bus fisico de la RAM en N64 no es como los modulos de memoria de PC, con CIENTOS de lineas fisicas, donde un error de una linea fisica puede afectar a un determinado rango o posicion de memoria y no necesariamente a todo el conjunto. La RAMBUS de N64 es un bus de 9bits de datos y un total de, creo, 36 patillas por chip, o un numero similar, donde, para colmo, los chips van conectados en cadena y no en paralelo, y creo que el metodo de conexion es que, excepto ciertas patillas, como las de alimentacion, la mayor parte del resto de patillas son parejas, siendo una la "entrada" y otra la "salida", por la cual se conectan al siguiente chip de la cadena (o al terminador de circuito)., asi que practicamente son la mitad de lineas totales, 9 para datos y otras 9 o menos, para señalizacion. No creo que el chip pueda ofrecer la mas minima funcionalidad si no están todos o casi todos los pins conectados. No me parece que una solucion de software pueda ofrecer muchas oportunidades de identificar problemas fisicos en este caso, dado que la consola ni arrancaría si el problema fuese una mala conexion física.

Todo esto de inspeccionar los registros me suena a problematica a nivel logico, y no malas conexiones fisicas.

@Sexy MotherFucker Entiendo que hay ciertas limitaciones y reglas y que no es totalmente arbitrario (a menos que quieras destrozar aun mas el rendimiento), pero en N64 basicamente puedes renderizar a la resolucion que quieras y luego encargarle al VI que reescale.
Lo ideal es establecer un ratio de conversion fijo de pixels de FB a pantalla.
Por ejemplo, la mayoria de juegos NTSC usan un ratio 1:1 (240:240) en el eje vertical y 1:2 (320:640) en el horizontal, mientras que en su conversion a PAL, para evitar las bandas negras, se usa un ratio de conversion 5:6, donde 5 lineas del framebuffer acaban ocupando 6 en la pantalla, lo cual convierte 240 a 288 "limpiamente". Esto se consigue siguiendo un patron ciclico de proporciones de las lineas de framebuffer que se han de mezclar para producir las lineas de salida.
En un ratio de conversion de 5 a 6, nombremos las 5 lineas originales con las letras A B C D E y añadamos F como primera linea del siguiente grupo de 5. Las lineas resultantes se calcularían así:
1 = 100% A
2 = 10% A + 90% B
3 = 30% B + 70% C
4 = 50% C + 50% D
5 = 70% D + 30% E
6 = 90% E + 10% F
y, para empezar otra vez el ciclo:
7 = 100% F

La interpolacion horizontal se hará de forma similar. No es un algoritmo que de unos resultados muy nítidos, aunque esto no sorprende a nadie a estas alturas xD.

Supongo que tambien hay otros metodos de escalado, pero fijo que son mas costosos.
Este metodo ya es costoso en si, obligando a leer varios pixels del FB por cada pixel de pantalla, sobre todo si no solo tienes que escalar el horizontal, si no tambien el eje veritcal de la imagen.

Te contesto mejor en este hilo:

radorn escribió:

Sexy MotherFucker escribió:De todas formas el original en Nintendo 64 también tiene errores que parecen de emulación, como por ejemplo las pixelaciones que se producen en ciertas texturas de vez en cuando, como las de la charca en la caseta del pescador de Lake Hylia en cuanto la cámara por defecto se desvía hacia un ángulo supuestamente muerto en la que entiende el jugador no debería estar viendo nada mientras está pescando, así que supongo que la consola desactiva el filtro o algo.

Esto sería mas bien para el hilo de detalles, pero bueno:

Creo que se de que hablas, y pasa en todos los juegos.
Yo deduzco que es una limitacion del filtro de texturas, pero no tengo ni idea de qué lo provoca. Alguna explicacion matematica/computacional tiene que tener. En PilotWings 64, con sus escenarios tan grandes con polígonos gigantescos, a los que, te puedes acercar un monton, especialmente con el jetpack, o aterrizando en cualquier superficie con el girocoptero pero sin decelerar hasta detenerse para que no se acabe el juego, puedes facilmente ver este curioso d/efecto.
Como ya digo, no sé por qué pasa, pero me ha recordado algo sobre el filtrado de texturas de la N64, o, al menos, el de muchos microcódigos, y que, en ciertos juegos que permiten acercarse de forma particular a algunos objetos, puede hasta apreciarse a simple vista.
Lo que hace el filtro de texturas es generar mediante filtro bilinear (lo de trilinear viene por la interpolacion entre mip-maps, que es como una tercera dimension) 32texels interpolados a partir de cada texel original.

De hecho, en GoldenEye, para mapear una textura a un triangulo, las coordenadas UV que se usan en cada vertice para decir que punto de la textura le corresponde, son enteros de 16bit con signo, y tiene una precision de 32subdivisiones de texel. O sea. si quieres que tu vertice empiece en el texel 1,1 de la textura, tus coordenadas UV tendrán que ser 32,32 (pero en hexadecimal o binario, claro) aunque, con el "sangrado" que causa el filtro bilineal, siempre es mejor añadir otro medio pixel para excluir la parte que se funde con el pixel anterior, asi que añade otros 16 (medio pixel).
De esta manera tenemos que, asumiendo que este patron sea universal, una textura en N64 puede repetirse a lo largo de un unico triangulo, hasta 2048 texels (65536 subtexels interpolados) de punta a punta con las coordenadas UV 0,0 en el centro. La cantidad de veces que una tetxtura en concreto se pueda repetir ya depende del tamaño de la textura en si. Con una de 32x32, la textura puede repetirse 64 veces de punta a punta (32 en direcion negativa y 32 en positiva, y no estoy hablando de efecto espejo, si no de meras repeticiones). una de 64x64, solo 32, una de 128, 16 veces.

Volviendo a lo del zoom, en ciertos juegos, y creo que turok 1 y 2 son dos ejemplos donde se puede apreciar, si te acercas lentamente a ciertos objetos atravesables, como algunos arbusos o plantas, puedes llegar a poner la camara tan cerca de un poligono que llegas a ver los sub-texels interpolados, que ya son meros pixeles no filtrados.
Si alguien puede sacar una imagen mejor, porque yo en este momento...

No se si esto realmente tiene que ver con esa extraña distorsion que se produce al ver algunos poligonos desde ciertos angulos, pero creo que alguna relacion ha de tener.

Pero por ejemplo eso es algo que no se ve NUNCA en Super Mario 64, o al menos yo no recuerdo haberlo visto jamás, el cual según Miyamoto emplea TLMMI. ¿Tendrá algo que ver el aplicar bilineal a "palo seco" o TLMMI, que se le dará mejor a la consola esto último?.

¿O nos estamos comiendo la cabeza de más y simplemente nos encontramos ante casos de códigos mal pulidos?

El ejemplo que yo digo es que estás pescando con el agua perfectamente transparente y filtrada, cuando de pronto el filtro se "rompe" y por unos segundos se aprecia la capa pixelada de la textura, para a continuación volver a arreglarse cómo si nada.