J'avais jamais pensé à l'élimination de doublons par palettes, j'ai jamais vu de convertisseur qui gérait ça. D'ailleurs je me demandais ce qu'ils avaient à l'époque pour ne pas se perdre dans des roms de 16Mo.
Je rêve un peu d'un logiciel avec gui capable de prendre une liste de png/bmp/autres en entrée, qui sauvegarde cette liste avec tous les attributs et offsets qu'on veut et qui est capable de "compiler" des roms C direct et d'exporter un fichier qui définit les numéros de tiles, pointeurs vers les maps, palettes... VB6 me tend les bras mais j'ai peur que ça devienne vite limité niveau vitesse de traitement.
Pour le jeu j'ai pas donné beaucoup de nouvelles mais ça a encore avancé (surtout niveau propreté et organisation du code en fait). J'essaierais de faire une petite vidéo avant de partir ce soir
Encore quelques bugs durs à chopper avec les foutus missiles, une histoire de signe je crois.
Sinon, ça me ferait fort plaisir d'avoir un (des) avis extérieur(s) sur mon fader, pour savoir si il est pourri ou très pourri. J'aimerais éviter de devoir passer par des tables de palettes précalculées à cause de la taille, et puisque de toutes façons, il faudra pouvoir fader de n'importe quelle couleur vers n'importe quelle autre.
En gros mon code compare une plage de couleurs depuis la ram palettes avec des valeurs à atteindre en rom et ajuste chaque composante de chaque couleur selon qu'elles soient inférieures ou supérieures à la valeur à atteindre.
Le pire c'est de devoir convertir du format de palettes NG vers du RVB "dans le bon ordre" pour pouvoir faire des additions/soustractions.
Je sais qu'il y a moyen d'optimiser pour n'avoir qu'une boucle pour toutes les couleurs (au lieu d'un pour les palettes, et une pour les couleurs), et que les 3 passes pour les composantes peuvent tenir dans un boucle aussi. Mais sinon je vois rien d'autre...
http://furrtek.free.fr/tmp/as_fader.asm