Spoiler, click to toggle visibilty
Es la tecnica de los 16 colores , creo que no ha habido nadie que la haya intentado porque si la haces menual requiere mucho trabajo, aunque crear un programa o script es trivial.
Hay dos formas de tener transparencia, una es por medio del color 0, la otra es por medio del alpha (aqui es donde yo tengo mi duda ya que no me consta que mugen use correctamente el componente alfa de las paletas, aunque deberia de hacerlo).
Tenemos los sprites del personaje 1 y los sprites del personaje 2, la idea es empalmar los sprites , entonces se hace una especie de cruza de colores, por eso lo de los 16 colores, ya que 16 x16 = 256. supongamos que en un pixel va el color 1 del personaje 1 (digamos el mas ooscuro o el contorno) y ahi se cruza con el color transparente del personaje 2 , entonces en el sprite "empalmado" ahi iria un valor de 1, luego seguimos el contorno y ahora en otro pixel el color 1 del personaje 1 se mezcla con el color 2 del personaje 2, entonces ahi ponemos un 17 (16 +1) , luego en otro pixel se empalma con el color 2 del personaje 2 ahi tendriamos un 33 (32+2).
El numero se refiere al color de la paleta en el sprite; ahora, cuando se carga en mugen, dependiendo del personaje que queramos mostrar (el 1 o el 2) es la paleta que vamos a utilizar, es decir, si queremos mostrar al personajes 1 en su paleta 1, mostramos la paleta 1,1 , pero si queremos mostrar el personaje 2 en su paleta 1, cuando se hace la transformacion se cambia a la paleta 2,1.
Si vemos la paleta 1,1 en un editor de graficos se veria algo asi transparente, linea, piel, pantalon, camisa; en cambio si vemos la paleta 2,1 se veria transpuesta:
transparente
linea
piel
pantalon
camisa
Hasta aca se oye muy facil "solo" preparas tus sprites y haces el cambio de paleta, y ya , ni cuando te agarran y te meten en un customs state se rompe esto (a menos claro que el maldito del p2 utilize cambios de paleta en el custom state). Pero ahora falta ver los problemas de esta tecnica:
1) Hacer la separacion o mezclado de colores a mano es brutal; auqneu coom te comento, con un script o programa es sencillo, cuando se descubrio el metodo me ofreci para programar dicho script, pero nadie dijo necesitarlo en ese momento, ya despues me dedique a mi motor y deje eso de lado.
2) los sprites tienen que ser del mismo tamaño, por lo que no puedes cropera exacto. Aunque con la memoria de las computadoras actuales creo que esto casi no tiene importancia.
3) el limite de 16 colores, bastante obvio.
4) Coordinar las animaciones; no creo que sea un gran problema, pero existe, el sprite 5,5 de un personaje se usa para una cosa, pero se usa para otra con el otro personaje; o la animacion de caminar del personajes 1 es de 12 frames cada uno durando 5 ticks, y eld el personaje dos son 10 frames de 4 ticks cada uno. Tomando en cuenta los problemas comunes de lso personajes transformables creo que esto seria algo normal o hasta facil para alquien que hace personajes transformables.[/spolier]
Técnicamente es lo que mencionaba, al momento sale más fácil hacer un full, bueno no tanto, pero si el par de chars, ya que es algo complejo estar buscando los puntos de intersección de cada uno de los sprites a mezclar para después asignar un color en cada paleta que muestre el sprite requerido (hablando de trasformaciones completas y no de solo unos cuantos sprites), de hecho la limitante no son los 256 colores de los 8 bits se pueden usar paletas de 16, 24 y 32bits, pero sin una herramienta que haga el trabajo es técnicamente imposible y la idea principal a todo esto era lograr algo así como los cromos 3D que dependiendo desde que ángulo se vean te muestra una imagen diferente.