Vlad escribió:A mi la super nt me parece la mejor opción porque tiene el potencial de igualar a higan a un precio razonable, y además han anunciado un adaptador de video analógico para sacar 15 khz.
Si no cualquier pc core2duo de 3 ghz que cuestan 4 duros pueden ejecutar retroarch con el core bsnes accuracy sin problemas y si le pones una gráfica ati/amd puedes sacar 15 khz por euroconector con los drivers crt emudriver de calamity, y la única diferencia sería un pelín de más input lag que la consola original o la super nt.
Esta claro que a día de hoy mientras no pulan los bugs de la super nt lo mejor sería snes jr/mini con mod rgb y supercic, y un ossc o framemeister si quieres sacar por hdmi, pero sería sustancialmente más caro.
Por 50 pavos me la compraba ya, por 100 me lo pensaría un poco bastante pero podría caer, pero por 190$ más un montón de gastos extras... prefiero hacerme con una original o un sistema basado en emulador.
La consola en sí no está mal, pero es difícil de "vender" con ese precio, aunque lo justifiquen por costes de FPGA, I+D, etc.
magno escribió:wwwendigo escribió:Ya, si entiendo porqué me dices eso, estrictamente un FPGA "simula" y es así como se habla de su funcionamiento, si hablo de emulación es como reacción a Analogue y la sobrada de decir que ellos han implementado en el FPGA los chips originales. Es lo que dan a entender, que son literalmente los diseños de cada chip trasvasado a un FPGA y eso no puede ser por lo que ya he dicho.
Sí, si sabes cómo funciona perfectamente un chip puedes simularlo (o emularlo por soft) de forma exacta aunque para ello diseñes un circuito que no es 100% como el del original, pero funciona igual y con los mismos tiempos. De la misma forma puedes implementar su funcionalidad en un algoritmo que emule perfectamente su funcionamiento, y los tiempos, si dispones de una cpu suficientemente rápida y control suficiente de los tiempos en el sistema host de la emulación, pues también.
Y sí, es lo que veíamos en un simple PC cuando comprábamos un am386 contra el "original" de intel, la cpu por dentro no tenía porqué ser igual, pero su comportamiento sí lo era.
De todas formas siempre se escapaban pequeños bugs (o lo contrario, la no presencia de ciertos bugs) en estos chips recreados entre fabricantes, como para no pasar aún más en este caso. Es lo que critico de Analogue, es que hay que ser muy prepotente para decir que emulan perfectamente una SNES y después ver que... no es así cuando se producen errores en varios juegos que además hasta son parecidos para más inri a los del emulador Higan (pequeños fallos que estarán basados posiblemente en bugs del hardware real más que en las implementaciones por soft o en el FPGA).
En la emulación también se implementa el funcionamiento de otra forma, la barrera no es clara excepto el ver el hard en un lado y que la otra solución es puramente soft (como mucho el gran problema de la emulación soft, que es el control fino de los timings de cada "chip" emulado y su entorno, pero bueno, cuando ya metemos tratamientos tan distintos de la salida y con latencias de ms añadidas suena un poco a coña que se hable de fidelidad extrema).
Esto es lo que trataba de explicar desde el principio, coincido contigo al 99%. Lo únic en que no coincido es que yo nunca entendí de lo que decía Analogue es lo que te he remarcado en negrita. Nunca leí que hubieran dicho que habían traspasado el diseño de los chips literalmente a la FPGA, desde el principio del desarrollo estaban haciendo implementaciones propias de esos chips, y en algunos foros se comentaba el desarrollo.
Pues en los vídeos promocionales sí dan a entender esto. Sobre todo los reviewers de primer hornada que repiten exactamente las mismas frases una y otra vez.
A ver, en la web en sí tienen algunos flecos que sin decir literalmente esto sí apunta en esa dirección, después todos los reviewers de primera hornada que han recibido el sistema (supongo que gratis y para ellos como mínimo, visto el descarado marketing realizado) dicen básicamente esto, de la misma forma en una review y en la otra, hablan de la magia del FPGA y de la simulación perfecta de cada chip de la SNES, lo cual no me gusta porque no puede ser cierto.
Si no me confundo además en uno de los canales potentes, no recuerdo si era Gamespot o IGN, se hace una entrevista en paralelo a la review (bueno, montaje en vídeo realmente
) donde hablan del tema y sí se desprende eso de sus palabras. Hay que ver muchas reviews para darse cuenta del patrón que no puede ser espontáneo en cada reviewer, pero es más fácil, fíjate cómo ha entendido inicialmente la gente en este post el tema del FPGA y la simulación perfecta como si fueran los mismos chips, 100% accuracy (eso lo han soltado alguna vez los creadores en entrevistas, por cierto, y además juraría que lo ponía en la web antes, es posible que tras los primeros bugs hayan retirado de las descripciones del producto algunas aseveraciones demasiado lapidarias), cuando eso no se puede garantizar. Pueden hablar con eufemismos tipo 99% o 99,99% (más que nada es un eufemismo porque esa cifra es para dar una idea, no porque se pueda calcular dado que los fallos que puedan haber no son conocidos hasta que sale al mercado).
De todas formas, ya te digo que en la web ponen cosas que señalan en esa dirección (y creo que han recortado algunas cosas desde el lanzamiento):
Engineered with an FPGA. No emulation. 1080p. Zero lag. Total accuracy. The Super Nt is not a plug n' play toy. It is the definitive way to explore Nintendo's 16-bit era. Compatible with the 2,200+ SNES and Super Famicom game cartridge library. Explore and re-live one of the greatest video game systems of all time with no compromises.
Decir que además de optimistas van un tanto de sobrados con lo que están asegurando ahí, esto es cómo venden el producto al cliente, sin el contexto que quieras darle de las explicaciones durante el desarrollo que dieran en foros u otros medios, pero... no se pueden usar esas declaraciones para justificar estas aseveraciones publicitarias con la excusa del contexo, oiga no, la mayoría de potenciales clientes o no han conocido el desarrollo y leído sobre él o simplemente no tienen los conocimientos técnicos para separar grano de paja, así que esto se puede entender como publicidad un tanto engañosa, además están tirando mierda a las alternativas básicamente llamándoles "plug'n'play toy" (lo cual es gracioso dado que es lo que la SuperNT es, una experiencia jugable (léase juguete de toda la vida) plug'n'play al no tener que hacer nada especial para usarla).
Recuerda esto, "with no compromises", eso es algo muy alto de asegurar y ya vemos que no es así.
Unparalleled compatibility
The Super Nt uses an original-style cartridge slot and controller ports. This means it is compatible with the original SNES and Super Famicom game cartridges plus the original hardware and accessories. All the way from the Super Gameboy to Mario Paint.
Lo cual no es cierto, ya se ha comprobado, aunque esté muy cerca de lograrlo. Pero es que insisten en el tema si cabe más:
The Super Nt has the same unparalleled compatibility as the Nt mini. The core functionality of the system is engineered directly into an Altera Cyclone V, a sophisticated FPGA. We spent thousands of hours engineering the system via FPGA for absolute accuracy. Unlike the knock off and emulation systems that riddle the market today, you’ll be experiencing the 16-bit era free of compromises. The Super Nt is designed to preserve video game history, with the respect it deserves.
Absolute accuracy que ya sabemos que no es real. Trato despectivo a los sistemas basados en emulación, lo cual incluye, aunque seguramente no sea el principal señalado por Analogue, a los emuladores soft usados en PCs como Higan. Por algo saltó Byuu por este tema, no se sintió aludido así como así, y seguramente le habrá sentado mal cosas como ésta porque él sí estuvo hablando con Analogue y debatiendo de cómo hacer la mejor emulación o simulación de cada parte del sistema. Posiblemente la coincidencia en algunas disparidades entre Super NT e Higan con supernes tenga que ver con tomar soluciones muy similares a temas relacionados con, seguramente la circuitería analógica, y que parecen soluciones salidas de esas conversaciones.
La frase final es para mear y no echar gota (¿no respetan los demás sistemas o emuladores soft la historia del videojuego, Higan, MAME, etc? (a hombros de quiénes se han subido para su proyecto en Analogue si no?, incluso las consolas clónicas basadas en emuladores menos precisos lo intentan, esto es una falta de respeto hacia los rivales comerciales, nada más).
No sé si estás de acuerdo con esto o no, pero te lo digo para que entiendas mi punto de vista y veas que, fuera de que hayan comentado más correctamente el desarrollo de la consola durante éste, a la hora de lanzarla están haciendo las cosas ... tirando a un poco sucias al más puro estilo hombre de marketing.
Pues por caro, creo. Uno de los moduladores que he diseñado es de televisión analógica, y el filtrado de banda vestigial, los filtros de alias para la imbricación de 15625Khz y encima hacerlo PAL y NTSC consume una lógica tremenda. Para hacerte una idea, unos 15000 slices sólo para modular la señal de video en banda base hasta RF...
Además, físicamente en la placa es un coñazo porque necesitas un TXDAC de 1.6 Gsamples/s que es carísimo, en torno a los 100€... o puedes salir en los canales bajos de UHF (21, 22) y usar un DAC de 500 Msamples/s de 12 bits por unos 40€. El problema es que a menor frecuencia, más posibilidades de que la salida analógica interfiera con algo del circuito, tendrías que aislar masas muy bien... O peor, el reloj del sistema se te podría meter, porque funcionando en torno a los 200 MHz tienes el primer armónico cerca de los canales bajos de UHF.
De temas de diseño de circuitos analógico o cómo implementarlos en un FPGA no te voy a discutir ni una coma, bastante me llega con entender la mitad de los tecnicismos que usas y hacerme una idea de lo que hablas (XD).
Pero vamos a ver, lo lógico sería no emular nada del tema analógico con el FPGA, simplemente intentar recrear la electrónica analógica de la consola original en una parte del PCB, que creo yo que el coste no puede ser tan alto porque las consolas tampoco eran caras de fabricar, y simplemente usar las distintas salidas de datos en formato digital (o mejor dicho, las salidas del sistema para generar la salida HDMI en sí), pues el audio antes de la fase de entrada en un DAC en la simulación y en el caso del vídeo la señal generada por los SPPUs para definir cada scanline antes de transformarse en una señal también analógica (que en la Super NT evidentemente tiene que está en formato digital para enviar al buffer mencionado, dando igual si los SPPUs generaban ya directamente la señal enviada al CRT para cada scanline o confiaban en electrónica analógica posterior, que supongo que será la última pero ya te digo que no lo sé a ciencia cierta).
Esto es, mantienes el funcionamiento digital actual de la consola, y simplemente demultiplexas la señal y etapa de procesado en la simulación donde se escriben las scanlines en el buffer de vídeo y otro tanto con la señal de audio, y envías una de las señales replicadas con la demultiplexación a una circuitería digital-analógica que permita tomar esta salida digital y generar la salida vía el formato que prefieras.
Creo que tu solución es más bien como matar moscas a cañonazos, la verdad. Que es por costes está claro que sí, pero que no tenían margen para meter señal analógica con ese precio... ya te digo que tener tienen. Entiendo que quieren ganar lo máximo posible por consola, pero no es muy de recibo lo de justificar la "enorme bajada de precio" contra la NT original sólo porque han quitado las señales analógicas (ojo, que ésta tenía un buen lote de distintos tipos de conectores, no es lo que yo pediría, sólo una alternativa a HDMI por precisión en la simulación, perdón, "implementación"
), si me hablan de la carcasa de aluminio igual les creo más, o que bajan el precio porque cuentan vender más y así conseguir reembolsar el I+D necesario, etc.
No he visto el video que dices del error con el StarFox, pero me gustaría echarle un ojo; si lo tienes a mano, ¿te importaría linkarlo? Si ya lo has linkado en otro post, lo buscaré cuando tenga un rato.
Habría que ver quién está sacando ese mensaje de error que dices, porque StarFox tiene unas rutinas que comprueban si hay conectado algo en el segundo puerto de mandos de la SNEs y en el puerto de expansión por debajo. En el caso que haya otro mando, puede llegar a arrancar, pero si hay un multitap o mandos especiales que consuman mucho, sale un mensaje que dice que el juego no puede arrancar con multitap.
Si es ése el mensaje, no es un error de la FPGA, quizá tengan un bug en el hardware que conecta con los mandos. Y Star Fox hacía esto porque el chip MARIO (la primera versión del SuperFX) consume más que un cartucho normal y se podría exceder los 1.3A de consumo de la fuente si hubiera conectado más periféricos.
Y no, la SNES no queda para gestionar el mando en el StarFox
D Eso no lo ha dicho Argonaut nunca, me he leído todos sus artículos sobre el desarrollo del juego, las reuniones con Nintendo en Kyoto, el inicio del primer prototipo de chip, etc... Además, la CPU es maestra del SuperFX, y éste sólo puede ejecutar las rutinas que le indique la SNES, luego la interrumpe y ésta recibe los datos calculados por el SuperFX (por ejemplo, blitting, relleno de polígonos, funciones trigonométricas...) y compone la imagen final, el audio, mandos, lógica de control, IA...
Te lo menciono en un momento del comentario (juraría que es el último), revisa a ver dónde está, pero ya te digo que es con StarFox 2, no StarFox 1. Lo que dices del consumo podría llegar a ser, pero excepto que los mandos inalámbricos de 8bitdo consuman más de lo que debieran de la consola SNES para mantener la conexión, que digo yo que no deberían pues están diseñados para funcionar con la SNES original (y de hecho funcionan, con este cartucho repro además), pues esto no debería pasar. Amén de que juraría que está probando la consola con sólo un mando conectado, y sin usar por supuesto el puerto de expansión.
Lo que está claro es que ese cartucho repro lo ha usado ya alguna vez, no es el típico material que encuentras en alguien que pruebe la Super NT con un cartucho original perdido entre un montón de cacharros sino material del típico "friki de turno"
, el tipo que lo prueba se ve que es aficionado a conseguir los últimos productos vinculados a SNES (cartuchos recopilatorios de juegos, StarFox 2 reproducido con un cartucho con un SuperFX, etc). Y como se nota que lo ha usado porque espera que funcione correctamente, me da que ese problema le ha pillado en bragas mientras hacía el vídeo, que es algo que no se esperaba (o sea, que no le ha pasado antes con la SNES original, no tendría sentido comprar un cartucho de StarFOX 2 repro para usarlo en una Retron 5, ¿no
?).
Y claro que consume más ese cartucho, pero con el MARIO como con los demás que llevasen algún superFX, otro asunto es que sea más que asumible para el sistema. xD
Sobre lo de Argonaut, fueron declaraciones sobre que Starfox corría básicamente en el superFX, de las misma forma que los propios desarrolladores del chip, como Jez San, han mencionado alguna vez que incluso se barajó la inclusión del chip como cpu principal en vez de la final de la SNES pero se descartó por precio (y particularmente, no me creo esta parte demasiado cuando se cita, más que nada porque la consola estaba más que terminada y a punto de salir al mercado si es que tenían negociaciones así de avanzadas ya en el 90, y por prometedor que fuera el chip de Argonaut como que eso rompería el desarrollo de todos los demás proyectos de otras marcas para la consola, así que no, quizás se habló algo de incluirlo en una posible expansión de la consola o segunda revisión, o se dijo algo no muy en serio y fruto más del entusiasmo, pero vería mucho más lógico el sustituir a la cpu original por el SA1, más que nada porque sí es compatible con la cpu original y no jodería a los demás desarrolladores con una cpu desconocida).
La verdad es que es difícil encontrar menciones del tema, es posible que sea una leyenda urbana, pero a mí me suena, sea una leyenda urbana de los medios o no (si lo he visto ha sido o en alguna revista de prensa o en algún canal de youtube pero digamos que de "buena calidad", tipo pixel2pixel o LaPociónRoja, no en otro lado tipo foro y comentario suelto o canal de youtube random sin mucha calidad). Es posible que simplemente se base en alguna declaración donde se exageraba el papel del superFX, pero lo que no debería haber duda es que computacionalmente en este juego tiene NO un papel relevante, es que es el que lleva la batuta de básicamente todo.
Bueno, la "batuta" no porque es cierto que la SNES se encarga de "arrancar y parar" al SuperFX en sus tareas (le da el control y acceso a código del pack ram y también lo detiene), pero es que en un juego como éste básicamente estaría haciendo todo incluida la IA. Técnicamente no llevaría la batuta, pero estaría haciendo el trabajo de burro de carga, y no me refiero sólo al render en 3D que esto seguro que lo hacía él al 100% (por ejemplo, la detección de colisiones, e IA general deberían correr en el superFX por pura conveniencia, al usar para ello un sistema de coordenadas 3D que seguramente se adaptaba mejor a los posibles de las instrucciones del FX, es que leches, es el mismo sistema de coordenadas que usarían para renderizar la pantalla, sólo que usado para detección de colisiones también).
Es normal, siempre hay bugs en los desarrollos iniciales, pero eso no quiere decir que estén haciendo una implementación lo más cercana a la realidad posible, Y sí creo que en uin futuro será 100% compatible, como no lo era bsnes al principio y al final higan sí lo fue.
Y creo que me entendiste mal en mi otro post... Lo que hace Analogue NT no es "simulación" tampoco, es "implementación". Igual me expliqué mal: simulación es comprobar el comportamiento de un circuito electrónico sin pasar por el chip físico, comprobando la "descripción funcional" (es decir, el comportamiento del circuito) mediante primitivas y ecuaciones lógicas en un ordenador. Simular es coger tu código VHDL, pasarlo por Modelsim (por ejemplo, que es un simulador de circuitos Verilog, VHDL...) y comprobar que las señales internas conmutan en los tiempos que deben y se implementan las funciones deseadas.
Y simular sigue siendo dado que el FPGA básicamente es la útima fase final ANTES de implementar un chip final.
Otro asunto es que Analogue se quede en la última etapa de diseño con esta solución mixta entre hard y soft y ya sea su solución final (o sea, "implementación" porque... ¡¡es el objetivo del proyecto!!, pero para otros proyectos esto sería aún sin ser la implementación real, sino una fase muy cercana al final de la validación y testeo antes de dar el visto bueno y empezar con la producción del chip final (y ahí ya testeo final)
).
Esto ya es un tema de dialéctica. Bien sabes que podrían pasar el diseño final (quizás con varios firmwares madurados) a un fabricante de semiconductores para obtener su propio chip 100% compatible con una snes y posiblemente bajando costes y consumos de forma importante. Yo me lo plantearía, quizás lo hagan para una Super NT 2 a un precio mejor, quién sabe. O una Super NT mini, ya en plan cachondeo.
Lo que sí es que se perdería la flexibilidad de reprogramar al FPGA, lo cual no les conviene ahora ni tampoco para el otro potencial uso de esta consola (simular otras consolas y máquinas con otros firms).
La CPU es un Microblaze, es de Xilinx yestá bastante bien documentado por ahí.
Implementar un DSP en una FPGA es muy fácil, el 65C816 es muy conocido y hay tablas de WesternDigital con todos los timings de todas las instrucciones bien desglosadas en cada etapa del pipeline.
Y no, hombre, el SPC700 no es ni mucho menos un 6502 modificado
Como te oigan en SOny te despellejan. el SPC700 es de Sony y es un micro que además tiene una arquitectura diferente al 6502, y está bastante enfocado al audio por el tipo de indirección indexada que usan algunas instrucciones, además de por su uso intensivo de las páginas directas para buffers circulares.
Además, el 6502 es de Western, nada que ver.
Interesante, la cpu veo que es bastante simple pero tiene los principales ingredientes de una cpu RISC de 32 bits, así que supongo que no habría ningún problema con una CISC de 16 bits que es bastante minimalista (puede ser más jodido de simular en el FPGA de lo que parece, pues los primeros diseños RISCs ahorraban una barbaridad de transistores contra las cpus CISC existentes, amén de ser más rápidas, PERO como el 65c816 de por sí es una CPU CISC muy frugal en transistores.... pues no debería haber problema, es "pequeña" dentro de lo que cabe).
No, si los de Sony seguro que se enfadan si de alguna manera un producto suyo no parece tan original, pero lo que es, es, y lo siento pero la cpu integrada en el SPC700 es un 6502 pero de cajón, aunque no le quieran llamar.
Tiene página zero (igual que el 6502 y es algo MUY característico de esta familia de cpus), un único acumulador, dos registros de direccionamiento, y registros PC y SP, etc, me parece a mí que además como que el set de instrucciones se parece por no decir que es un calco, no me lo saco de la manga, mira:
https://en.wikipedia.org/wiki/Nintendo_S-SMP"The Sony SPC700[3] is the S-SMP's integrated 8-bit processing core manufactured by Sony with an instruction set similar to that of the MOS Technology 6502"
Pero es que además si ves su estructura y funcionamiento en mil fuentes variadas, includo el SNES development manual y demás, es que se ve que es un 6502 adaptado para la tarea (o un clon de sony del mismo).
Es que tiene las mismas limitaciones de juego de instrucciones minimalistas, mismas latencias bajas x instrucción, fuera de los añadidos para la tarea a la que se dedica. No sólo la página cero del 6502, es que también usa la página uno a piñón fijo para la pila. Es que vamos... "si nada como un pato, y suena como un pato, es que es un pato".
O eso o Sony reinventó una cpu "distinta" pero que tiene una coincidencia monumental con el "mojo especial" del 6502, todas sus características y hasta instrucciones en ensamblador casi calcadas (generalistas, no hablo de las añadidas, si el opcode es el mismo ya es otra historia).
Que sí, que es una reencarnación del 6502, hombre.
Bueno, quizá no sea ahora 100% igual que la SNES y sea peor que un higan, pero potencialmente es mucho mejor que la emulación software... Potencialmente un Maseratti corre más que mi Toyota Auris, pero si tiene un defecto en el acelerador y no se pudiera pisar a fondo, eso no lo convierte inmediatamente en peor coche que mi querido Auris.
Yo ni siquiera estoy diciendo que sea peor, pero sí que tiene fallos muy similares a los de los emuladores como Higan. ¿Mucho mejor? Todo depende, también hay margen para mejorar la emulación por soft, en lo que es comportamiento en sí simulando los chips creo que no hay discusión que se puede hacer con la misma precisión en un sistema que en otro. Si hablamos de velocidad o mejor dicho, precisión de tiempos, pues coge un SoC a 2 GHz de una cpu medio potable aunque sea ARM, ponla en un sistema en tiempo real o la brutada pero efectiva solución de un sistema pelado minimalista, donde puedas garantizar predecir el tiempo exacto que te llevará hacer X sin variaciones por otras tareas en el s.o. y mostrarlo cuando toca al simular a la consola, y si la potencia es suficiente conseguirás el mismo resultado.
De momento todo esto da igual porque nos estamos comiendo un montón de lag que reduce a insignificante esos problemas, a base de usar salidas digitales y paneles de TV o incluso aunque sea monitores ultrarrápidos (que por cierto, le sacan una buena ventaja a cualquier cosa conectada a una TV en cuanto a retardo inducido por el panel de la misma), y sinceramente, ni siquiera ese lag está estropeando la experiencia (si se conecta una SNES a una tele moderna estamos en la misma, por cierto, excepto por el tema de crear la señal digital en un buffer en el caso de emuladores y Super NT, pero esto es un frame de retardo normalmente, casi despreciable y normalmente MENOS que el retardo que mete una tele entre que le llega una imagen y la muestra el panel de verdad).
Pero bueno, puestos a ser puristas se puede incluso avanzar y no poco con emuladores soft en... sistemas específicos pensados para garantizar tiempos en ellos. Y lo que puede de dar de sí la mejora del SoC usado en las clónicas de SNES, vamos. Que están usando Cortex A7 aún en la mayoría, una cpu "antidiluviana" ya y nada orientada al rendimiento ni siquiera dentro de cpus ARM.
Si sólo el cambio de Cortex A7 a A53 puede dar sensibles mejoras de todo el tema, no digo ya usar cores prestacionales tipo A57 o superiores (y aquí entroncaríamos con la emulación en PC y la calidad extra que puede dar, o fidelidad más bien). Y por el lado del s.o. usado, pues lo mismo, hay dónde mejorar si se quiere simulación del sistema 1:1 en tiempos.
wwwendigo escribió:Por ejemplo está el tema del bug de los SPPUs que dibujan la cantidad máxima de sprites por línea permitida y los que pasan.... no los muestran (esperable) pero empezando por los de la izquierda (eso no esperable, por cómo está documentado el tema debería ser por el lado derecho o final del scanline donde deberían desaparecer los scanlines, a mí me huele a que alguien metió un sistema basado en FIFO en este tema en vez del esperado LIFO, para gestionar la lista de sprites a renderizar).
Entiendo que es un bug porque es "preferible" que desaparezcan sprites por la derecha que por la izquierda, al moverse los juegos normalmente de izquierda a derecha (scroll horizontal) o de arriba a abajo (scroll vertical), y así evitar la desaparición de sprites considerados más relevantes como los del personaje del jugador.
Error, se puede empezar por la derecha o por la izquierda, dependiendo de la configuración de prioridad de los objetos OAM. De hecho, se descartan los de menos prioridad, y el más prioritario puede ser el sprite 0 o el 127, dependiendo de la configuración:
The second is the priority with relation to the other sprites. This is completely controlled by the sprite's index and the priority rotation setting.
El sprite más prioritario siempre es el primero en dibujarse, pero puede estar a la izquierda o a la derecha.
Mm... entonces las menciones que he visto a ese supuesto bug, ¿se refieren a que funciona al final de forma inversa a la esperable o es una mala interpretación del funcionamiento de cómo se renderiza cada sprite?
Si puedes elegir la forma en que se renderizan en el scanline (desde qué lado) y a su vez puedes elegir si el índice empieza de una u otra forma, todas esas menciones a ese bug supongo que se refieren a un comportamiento anómalo de lo que se espera pero en ambos casos.
Eso es, que si empieza en 0 como más prioritario, ¿es el descartado si hay más sprites a renderizar de lo que permite el índice por el hard? E igual si se pusiera al 127 como prioritario, claro. ¿Es eso lo que pasa con este ya digo mencionado bug? Ya te digo que lo he visto mencionado como comportamiento anómalo con los SPPUs.
Porque si descarta el sprite "128" siendo el 0 el prioritario, no hay ningún bug. El bug sería que no mostrar el 0 siendo el prioritario por mostrar el sprite 128.
Es que esos efectos de los que hablas los programadores de los juegos se las ideaban para que la combinación con una TV de tubo dieran un efecto elegante. Pasa con los sprites invertidos en Seiken Densetsu 3 para hacer el reflejo en el suelo en uno de los palacios al final del juego: el truco es no mostrar el sprite en los frames impares, de modo que en una TV de tubo da la sensación de difuminado y parece un reflejo, pero en cualquier emulador el efecto es más chapucero. Magias de los tubos catódicos y los fósforos de las pantallas.
Ya, parpadearía ligeramente y aparecería algo borroso haciendo eso. Es algo parecido pero menos complicado que lo que dije de la sombra, que "creo" entender qué hace en la realidad (básicamente "apagar" en ciertos timings del scanline y unas cuantas scanlines por debajo del sprite del jugador el cañón de electrones, seguramente cada dos frames o más, y así dar esa sensación de sombra muy ligera y parpadeante que se ve en el original, no es que parezca que se muestra la silueta del avión en sí, sino una especie de ligero parpadeo y algo de sombreado (cañón apagado) a X altura de él).
La emulación digital en realidad queda mejor como sombra, aunque no se parece nada y se pierde la gracia del efecto, que es hasta demasiado sutil para lo complicado que es (o no es mi forma de pensar, que también puede ser, ya que no pienso en "analógico" a la hora de programar para generar imágenes y me parece muy de locos eso de usar los tiempos de scanline para modificarlo al vuelo
). Bueno, teniendo en cuenta que lo de ese juego es todo hipótesis mía de cómo lo generan, el tema de la sombra. Sólo sé que hacen uso de un truco de timings muy justos con scanlines, y por observación de lo que parece verse como resultado final, no es seguro que sea ni remotamente lo que digo (XD).
Lo del sprite invertido cada 2 frames es más fácil de hacer para que quede similar, la verdad (si quieres metes el parpadeo también aunque es un tema un poco peliagudo con la mayoría de paneles, pero también puede venir "bien" la naturaleza de los TFTs ya que seguramente aparecerá difuminado si se conmuta un sprite entre aparecer y no aparecer en pantalla por el tiempo de respuesta del cristal líquido y su cambio de orientación, después el difuminado extra al usar un CRT pues... dithering vamos). Pero evidentemente no es el mismo proceso, aunque pueda parecerse. Además de que la forma en que parpadea un CRT como que es ... inimitable. xD (ojo, y no necesariamente como algo bueno).
Le echo un ojo más tarde, que tu post es tan largo que he llegado extasiado al final
Extenuado, querrás decir extenuado.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")