@Señor Ventura por partes.
- Sprites: eso es precisamente lo que le recorta mucho su número útil. si usas
de 8x8 se te van en un momento al combinar. Si usas
de 32x32, en elementos más pequeños desperdicias muchos, ya que se pillan siempre todos los tiles del modo
de tamaño. Aquí la info:
https://wiki.superfamicom.org/spritesIf the OAM Size flag is 0, the sprite uses the smaller size, otherwise it uses the larger size.
O pequeño, o grande. Si miras más abajo se ve cómo se establece en VRAM.
En MD:
https://segaretro.org/Sega_Mega_Drive/SpritesSprites consist of between 1 and 16 tiles, which are arranged in the following ways depending on their size setting
Ahí está el truco que permite exprimir el número al máximo.
De andar transfiriendo a VRAM para sobreescribir los sprites, mejor olvidarse. Eso consume mucho, se come muchos recursos que vas a necesitar para otras cosas y más si quieres un juego a 60 fps en máquinas tan justas.
Vale que usan el DMA (la MD tb tiene
https://segaretro.org/Sega_Mega_Drive/DMA ) pero ese mismo DMA te va a hacer falta para otras cosas, y los sprites son mucha información (a nivel
de px) como para usarlo en eso, se te come corriendo.
[Nota]: curiosamente es lo que uso yo en MSX para superar el bajo límite que trae, encima que no hace mirror. Pero claro en más
de 1 personaje ya difícil
de usarlo, y se consume sus buenos recursos.
- Efectos: no exactamente, la CPU es la que debe establecer los parámetros. El acceso al VDP por el bus maestro lleva su retardo y no debe abusarse. Ambos VDP pueden hacer deformaciones ondulantes como la que pusiste (incluso los 8-bit pueden).
- Interrupciones: no estaría tan seguro. El M68k soporta interrupciones
de manera excelente:
https://en.wikipedia.org/wiki/Motorola_68000#InterruptsIncluso vectorizadas para automatizar más el proceso. Es sabido que el Atari ST por ejemplo ya incluye 4 temporizadores
de interrupciones en el propio sistema y el M68k las despacha que da gusto.
- Fondos: por tile, pero con trampa, nuevamente:
In Mode 0, you have 4 BGs of 4 colors each. To calculate the starting palette entry for a particular tile, you calculate:
ppp*4 + (BG#-1)*32
Es decir, pilla los 4 colores contiguos. Difícilmente usable nuevamente.
¿
De dónde sacas eso
de la MD?, que yo sepa se tienen 4 paletas
de 16 colores, y los tiles no tienen límite
de colores, pueden usar cualquiera
de los 16
de la paleta elegida, que se indica en la nametable, el tile a dibujar y con qué paleta, es decir podrías aprovechar el mismo tile y pintarlo con colores distintos.
https://segaretro.org/Sega_Mega_Drive/Planeshttps://bigevilcorporation.co.uk/2012/03/23/sega-megadrive-4-hello-world/Es decir los tiles se definen en hexadecimal (0-15 o sea 16 valores) y en el nametable pones la paleta
de las 4 quieres usar para dicho tile.
- Resolución/tamaño: pero lo que en 256 con 6 tiles
de ancho te ocupa X, ese mismo X a 320 puedes usar 7,5 tiles (que sería 7 u 8 según prefieras). Es decir tienes más densidad. No entiendo como siendo algo tan sencillo como un número en resolución aún se puede estar discutiendo sobre eso.
- Cartucho: con eso no te líes mucho, puse esa imagen pq era la que había. Pero los cartuchos en SNES llevan su propia circuitería
de mapeo, creo que se llamaba MAD-1 el más típico y básico. En MD no llevan, salvo el SSF2 que al ser 40Mb se pasaba y necesita su mapper. Si los cartuchos eran más caros no era por gusto.
- CPU: buf si ya me conozco al 6502 y derivados
de sobra tranquilo. Los unrolling valen para todos, pero se usan cuando se pueden, ya que ocupan más memoria y van en relación al número
de elementos tratados, por ej. un unrolled
de 4 pues es para tratamiento
de elementos tomados en múltiplos
de 4. Y repetir código es inviable, aparte
de ocupar mucho espacio, si cambias el método que haces buscarlo en los otros 390 sitios donde lo has usado?, eso es un criadero
de bugs impresionante. Y nuevamente le sirve a cualquier CPU, a todas les cuesta un salto. Vamos que la ganancia
de esas cosas que pones valen para todas, pero si no se usan es por sus motivos.
Al igual que pasara en el 6502, el modo Direct es para paliar su falta
de registros. Aquí los vemos:
https://en.wikipedia.org/wiki/WDC_65816/65802https://en.wikipedia.org/wiki/Motorola_68000_series8x32-bit
de propósito general.
Por eso si nos vamos a las instrucciones del 65816 pues le pasa lo mismo que al 6502 (este enlace es bueno):
https://archive.org/details/Programming_the_65816Son del tipo ADC: add
memory to accumulator with carry. No hay operaciones entre registros. Es decir, el modo Direct
es el que debe usarse, pero para igualarse con las CPUs que sí que tienen registros y pueden operar entre éstos.
- Another World en Apple II GS: no sirve, el Apple puede dibujar directamente en pantalla (como el PC). Las consolas lo hacen reescribiendo los tiles situados en VRAM, algo poco recomendable y que no fue diseñado para eso. Es por eso que en consolas este tipo
de juegos siempre perdían rendimiento. Por eso hay que comparar consola con consola.
PD: en principio no hace falta que me conteste nadie o cite. Ya puse la info que tenía pensado poner, incluso diría que más. Y viendo que hay bastante turbiedad en la información y tal, no voy a seguir con el tema. Para mí este tema está finalizado aquí donde lo dejo. A partir
de ahí cada uno que piense lo suyo.
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[mad]](/images/smilies/nuevos/miedo.gif "loco")
![[poraki]](/images/smilies/nuevos/dedos.gif "por aquí!")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
![[hallow]](/images/smilies/nuevos/hallowen.gif "calabaza")
, en el caso de Golden Axe me quedo con la version de Turbografx CD(PC engine CD). 
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")