Sinon, j'ai repéré plusieurs colorisations sympa pour certaines de mes conversions (notamment pour derat avec 2 nouveaux scarabées et deux nouvelles araignées). Mais il et vrai que le test de colormaps sur un modèle particulier est un peu laborieux (les numéros ne disent pas souvent grand chose de concret...). D'autant plus qu'il faut le faire avec chaque layer.
Un petit cours sur les colormaps de Diablo II pourra aider à comprendre.
Les joueurs
Ils ont leur couleurs qui changent en fonction des objets qu'ils portent. Dans le jeu, comme tu vois l'objet ET dans l'inventaire ET en animation, il y a 2 familles de colormaps.
Ainsi, les fichiers colormaps brown / gold / grey / grey2 / greybrown servent à coloriser une animation, alors que les colormaps invgrey / invinvgrey2 / invgreybrown sont pour les icônes des objets dans l'inventaire (comme le préfixe "inv" dans leur nom le laisse paraître). Toutefois c'est plus une rêgle générale qu'une loie absolue : même dans le jeu original certaines animations utilisent un fichier colormap "inv*" (et réciproquement une icône peut très bien utiliser un fichier colormap normalement dédié aux animations). Tout dépend en fait des couleurs présentes dans l'animation / l'icône : le choix du fichier colormap a utiliser se fait souvent en fonction de ça.
Le nom de ces fichiers colormaps t'indiquent les couleurs qui vont changer. Brown (marron), pour les armures en cuir, grey et grey2 (gris) pour les armures en métal, greybrown est dans l'ensemble mal nommée car elle a tendance à plutôt changer toutes les couleurs. Note : l'amazone en armure lourde est dorée, d'où je pense au départ la présence du fichier "gold", mais il me semble qu'il n'est en fait pas utilisé par le jeu ... il doit plutôt se rabattre sur les fichiers "greybrown" en fait.
Chacun de ces fichiers colormaps comporte exactement 21 colormaps, et elles sont organisée sur le même thème, c'est pourquoi j'ai repris le nom de ces variations dans le champ "index" (tiré de data/global/excel/colors.txt). Exemple : l'index 12 Crystal Green de greybrown, a son équivalent dans grey2. Les couleurs qui changent au départ ne sont pas les mêmes, mais le résultat final des couleurs qui changent est (plus ou moins) identique.
Note sur les indexs qui "manquent" dans mes listes : si pour "grey2" on passe de l'index 8 à 10 (donc sans le 9), c'est parceque MergeDCC analyse les colormaps, et ne reprend pas ni les colormaps qui ne changent rien (même pas un pixel... on voit ça presque systématiquemnt pour les 2 ou 3 premières colormaps contenues dans les fichiers colormaps des monstres), ni non plus les colormaps qui sont en doublons dans le fichier (1 fois suffit après tout).
il est vrai également que changer chaque layer un par un, c'est lourd quand on veut faire une colorisation globale. Pour palier à ça, j'avais pensé il y a un an à une astuce : on aurait dans une liste le choix de copier la colormap d'un autre layer ("Like TR" par exemple), comme ça quand tu change le layer TR, tous les autres qui le copie changeront également. Ca me semble compliquer un peu l'utilisation de l'interface, mais par contre ça serait bien utile.
par ailleurs, c'est aussi un peu une volonté de ma part : dans le jeu quand on change d'armure, c'est tous les layers TR/LG/RA/LA/S1/S2 ... qui changent en même temps, alors qu'avec mergeDCC on peut faire varier ces couleurs indépendament des autres layers. ... Hmmm une case à cocher "[X] all layers are using the same colormap" pourrait être super utile pour des tests rapide, faudra que j'étudie ça.
Les monstres
Ils peuvent utiliser 2 fichier colormaps qui leur sont en principe réservé : greenblood et randtransforms. Greenblood, comme son nom l'indique, sert à modifier du rouge en ... noir (pourquoi green dans le nom alors, pffff). RandTransforms est particulier : c'est le fichier utilisé par des monstres uniques, et ils utilisent alors au hasard l'une des colormaps dans le fichier (30 variation possible). Il me semble qu'en gros c'est une colorisation de toutes les couleurs de la palette en une autre... Comme tu l'avais déjà remarqué.
Après, chaque animation d'un monstre peut être accompagnée de son propre fichier colormaps spécifique, c'est pourquoi tu voit après GreenBlood et RandTransforms une liste de Token d'animation : c'est les colormaps spécifiques aux monstres de même code. Quand tu sais que Diablo est rouge d'origine, et qu'il a son propre fichier colormap, alors tu sait que tu peut l'utiliser sur un Fallen (FA) qui est rouge d'origine également (et réciproquement, tu peut utiliser FA pour l'animation de Diablo).
A savoir : pour vérifier le niveau de perte de qualité en prenant telle colormap plutot que telle autre, tu peut consulter le compteur en bas de la fenêtre "Unique colors used in the animation : xx". Si tu passes de 119 (Diablo d'origine) à 45 en prenant la colormap DI/4 ... tu te doutes que tu as perdu en finesse.
Les objets
Dans le jeu, il ne peuvent pas en avoir, c'est donc un bonus de MergeDCC
1. Comment fonctionne l'attribution d'une colormap : modifie-t-elle complètement la palette des images ou simplement le contenu des index. En d'autres termes, est-ce que l'ordre des index reste le même et seul leur contenu diffère ?
Sur le principe, la palette ne change pas, ce sont les pixels concernés qui change de valeur. C'est sur le modèle de ce que fait le jeu en mode fenêtré : il tourne alors en 256 couleurs, avec 1 seule palette et pourtant il affiche des changements de couleurs : c'est parcequ'il réorganise les pixels, mais n'utilise toujours qu'une seule et même palette pour tout (il y est forcé en mode 256 couleurs).
Si tu compare 1 frame donnée d'une animation exportée avec 2 colormaps différentes, tu verras que (normalement) les 2 images utilisent exactement la même palette, mais que ce sont les pixels qui ont changés (certains utlisen un autre index de palette).
En d'autre terme :
Dans l'affirmative, ça me ferait gagner un temps précieux en m'évitant le processus de bamisation : il me suffirait de remplacer la palette de l'animation par celle issue d'un image recolorisée. Dans le cas des portails, si seuls les index concernant le bleu sont remplacés par des couleurs différentes (mauve, vert, etc), alors je peux créer mes nouveaux portails en 3 s. Sinon, si toute la palette est réorganisée, je dois créer une nouvelle bam.
tu ne peut pas. Tel que j'ai conçu les colormaps dans MergeDCC, ce n'est pas la palette qui change et les pixels qui restent, mais le contraite : la palette ne change pas mais des pixels changent. Toutes les images qu'exportent MergeDCC utilisent comme modèle la palette de Diablo II (à part les cas spéciaux des index 0 et 1 pour transparence et ombre).
2. Je suppose que le réglage "screen" remplace l'ancien "alpha blending".
Exact. Comme c'était un abus de langage, j'ai fini par me décidier à utiliser le vrai nom (c'est comme ça que cet effet s'appelle sous Paint Shop Pro en tout cas). Mais l'effet lui-même ne change pas, juste son nom n'est plus trompeur maintenant.
Par ailleurs, j'ai trouvé très sympa l'amélioration ergonomique de gestion de la position du pivot dans la fenêtre d'exportation : c'est fou ce que 4 petits mots peuvent rendre un outil encore plus agréable à utiliser.
Tu parle du déplacement fin du pivot (up/down/left/right) ? En fait, au départ j'avais mis des flêches, ça marchait très bien chez moi (sous Seven), mais sous XP j'avais un autre caratère. J'ai donc abandonné mes flêches en Unicode pour utiliser des mots à la place.
Et pour terminer : pour ceux qui ne seraient pas familier avec le principe des colormaps, je vous invite à consulter un vieux tuto que j'avais fait sur le sujet :
paul.siramy.free.fr/_divers2/tmptutcmap il devrait répondre à toute vos questions
![:) :)](./images/smilies/smile3.gif)
Il donne même une méthode pour créer ses propres fichiers colormaps utilisable sous Diablo II (et donc sous MergeDCC également).