Freddy_Gwendo a écrit :Après plusieurs heures de test, voici mes premières impressions.
(...)
Intéressant tout ça. Merci du retour, je vois bien qu'il y a du boulot derrière. Je vais y répondre point par point, mais avant : une autre version :
MergeDCCv2_sources_20120712.zip
- garde en mémoire l'état du dernier écran d'Export. Plus besoin de tout remettre comme il faut à chaque lancement (entre autre les couleurs). La "box" par contre n'est pas sauvegardée, je prévoit quelques petites modifications à ce sujet bientôt. Les directions et frames changant à chaque animation, je n'ai pas sauvegardé non plus ces 2 champs.
- correction mineure d'un bug graphique potentiel en utilisant des effets graphiques (tel qu'alpha-blending) lors de l'export. Si après mélange d'un pixel d'une "aura" avec le pixel en dessous on obtient exactement la couleur de fond ou d'ombre, alors j'utilise à la place la prochaine couleur approchée, mais en aucun cas l'une de ces 2 couleurs.
- mineur : ecran d'Export : le bouton "Cancel" devient "Close" et fonctionne maintenant.
- utile : changer un champ de la Box met à jour les autres en rapport. Il y a des tests d'intégrité qui empêche de mettre n'importe quoi. J'ai prévu -2000 à +2000 pixels (donc image de 4000 x 4000) comme taille max, ça devrait aller.
- et... tadaaaa ! j'allais me coucher, puis j'ai pensé à une bidouille possible dans mon code. Je l'ai faite, et en changant simplement 2 signes "+" en signe "-" désormais les ombres portent à droite ! (mais seulement celles exportées, je n'ai pas touché aux ombres de l'écran principal. C'est donc bizzarre pour l'instant, mais je me suis dit que pouvoir exporter les ombres dans le sens BG étaient une priorité par rapport à 2 écrans synchronisés.
[indent]
[/indent]
Quel est l'intérêt de l'exportation aux formats tga et png ? Les fichiers obtenus ne disposent que de 256 couleurs, sans masque alpha. Du coup, l'utilité de travailler sur ces formats n'a pas grand intérêt.
Tout à fait d'accord, dans l'état actuel des choses. C'est juste qu'Allegro me permet de sauvegarder au format TGA, alors je l'ai proposé à mon tour. Par contre (tout comme pour un GIF d'ailleurs), choisir ce format ne force pas nécessairement le fond à être transparent. Actuellement, le seul format intéressant pour moi est le PCX, c'est le seul qui réduit la taille des fichiers pour l'instant. J'ai prévu d'écrire plus tard mes propres fonctions de créations d'image, et LA je pourrais proposer ce que tu souhaites. Mais ça sera un gros boulot... Ou alors... peut être que je peut faire un TGA avec de l'alpha, mais ça sera en 16 millions de couleurs, à tester. Je repousse en tout cas à plus tard.
Certains tokens de monstre ne disposent pas de toutes les images des modes qui leur sont associés (le plus souvent, c'est DT, et pas seulement pour les créatures convoquées...). Dans ce cas, la fenêtre de visualisation propose la ligne suivante :
[INDENT]frame_index =0[/INDENT]
De même, certains tokens proposent des modes sans aucune image (ex : K9). Id pour certains objets.
Tout à fait. A cela 2 raisons. D'une part les animations dans Diablo II sont quasi toutes en DCC, sauf quelques une en DC6 (ça tu peut le vérifier en consultant la fenêtre de debug du cache des fichiers, les derniers fichiers sont toujours en haut, et s'il y a des DC6 au lieu de DCC, tu as alors une animation qui ne marchera que plus tard). Par exemple Méphisto, et le mode DT de Diablo je crois. J'ai prévu de lire ces DC6 comme si c'était des DCC, c'est juste que pour l'instant ce n'était pas une priorité.
Par ailleurs, tout simplement l'animation en question n'existe pas. Je ne suis ainsi pas sur que le token OY existe vraiment dans le jeu : je n'y trouve aucun DCC assoccié. Dans les MPQ il y a ainsi quelques "traces" de travail inachevée, comme ces animations incomplètes.
Pourrais-tu préciser quelque-part la signification et le mode de calcul des paramètres de la box ? Avec un peu de pratique, ça permettrait de définir assez rapidement les bons réglages selon la taille et la position des images à exporter.
Ho c'est simple (enfin j'espère). Prend une image exportée. Le coin en haut à gauche a des coordonées, qui sont habituellement (0 ; 0) si le repère est justement le pixel en haut à gauche. Mais la Box utilise comme repère le pivot du sprite. Il est forcément quelque part plus ou moins au millieu de l'image, et ce pixel là a lui (pour la Box), les coordonées (0 ; 0). Par conséquent, le coin haut/gauche a des coordonées négatives par rapport à ce repère.
Autre façon de présenter les choses : sur une image du jeu (un screenshot), choisi arbitrairement l'emplacement où tu veut positionner une unité. Au niveau du sol, la position indiquée par le cercle entourant les PJ et PNJ d'habitudes. prend le millieu de ce cercle. C'est LE pivot du sprite. C'est cet emplacement que vise mon axe blanc dans la fenêtre principale de l'éditeur. Hé bien, pour savoir exactement où placer une animation donnée, dont tu as d'une part les images exportées et d'autre part la BOX qui a été utilisée, il te suffit de placer le coin haut/gauche de l'animation à l'emplacement donné par les coordonées (Left ; Top) de la box. Exemple : (-20 ; -80) : à partir du pixel du pivot du sprite, vas 20 pixels à gauche, 80 pixels en haut, et tu as le pixel du coin haut/gauche de l'animation que tu voulais positionner. Si tu regarde ce que ça donne, tu devrait voir qu'alors ton animation a les pieds exactement dans le cercle que tu visais au départ.
En gros, l'éditeur analyse toutes les frames exportées, pour savoir la taille minimum de l'image qui pourra contenir entièrement les sprites
ET les ombres (c'est pourquoi, à cause de ces ombres, le millieu de l'image n'est PAS l'axe autour duquel tourne l'animation). Il donne ainsi les coordoonées des 2 coins de cette image (ou des 4 bords, c'est pareil), ainsi que les dimensions.
Note : changer les données de cette "Box" fait que tu joue sur la taille des images exportées, mais également sur les placement des sprites a l'intérieur ! Donc, pour répondre à ta question plus loin demandant (à juste titre) comment exporter tous les modes d'un coup, je te répondrais qu'en attendant tu peut forcer une box très grande pour toutes les animations que tu vas exporter, et ainsi elles seront toutes alignées entre elles ! Exemple : (-300 ; -300) - (300 ; 100) donc taille = 601 x 401 : tu remet ça dans la box à chaque fois, et tu as ce que tu voulais je pense (mais ok, ca sera encore mieux quand ça sera automatique). Attention ! Si tu clique dans les champs de directions et frames tu perd ce que tu as saisi dans la box (ça fait parti des trucs que je doit améliorer)
Remplacer "Alpha blending" par "delete dark pixel" ne fonctionne pas à tous les coups. Là aussi, avec la pratique, on finit par le savoir au premier coup d'oeil.
Conséquence : il faudra se passer de certains modes qui ne passent pas.
Il faudrais pouvoir éclaircir le Layer avant d'appliquer l'effet Delete Dark Pixel, et à priori ça résoudrait beaucoup de problème. ca sera pour plus tard.
Cela dit, j'ai envisagé un test qui permettrait peut-être de s'en sortir. En gros, ça consiste à isoler l'animation concernée par l'alpha blending, puis à l'exporter en trouvant les bonnes options d'effets ainsi que la bonne couleur de fond. Ensuite, il suffira de supprimer les ombres (si elles existent), de créer un fichier bam et de l'associer via un effet spécial soit dans le fichier .cre, soit dans un sort qui serait lancé soit par un script, soit par un objet (par exemple une baguette invisible que l'on affecterait à la créature : chaque fois qu'elle l'utiliserait, l'effet serait affiché à l'écran).
- ma démarche serait la même que la tienne : isoler le layer spécial.
- pour la couleur de fond : noir fortement conseillé si tu utilise un autre effet que Delete Dark Pixel
- éviter les ombres : n'importe quel effet graphique. Si tu veut dessiner un layer normal mais sans ombres, une astuce : Delete Dark Pixel avec niveau = 0
- pour recomposer (superposer) facilement : force les Box aux même valeurs pour chaque export des layers individuels
Pour l'instant, le seul format d'animation exploitable pour les monstres est celui de IWD avec 2 fichiers par action (directions Ouest et Est). En revanche, les animations de créatures pourront s'intégrer dans les formats BG2.
Si ça peut t'aider (mais pas forcément), tu peut utiliser le champ de Directions pour ne sélectionner que les directions Ouest dans 1 export (avec Box forcée), puis les directions Est dans un deuxième export, avec la même Box forcée dans les 2 cas. Mais bon ... autant tout extraire d'un coup je pense.
Quid de la possibilité d'exporter toutes les actions (modes) et toutes les directions en une seule fois ?
Le but du jeu n'est pas de gagner du temps dans la procédure d'exportation, mais de pouvoir bénéficier pour chaque créature d'un jeu de fichiers bmp ayant RIGOUREUSEMENT la même palette et la même taille.
En l'état, seules les images appartenant au même mode possèdent la même taille (...)
voir plus haut
(...) et la même palette. Du coup, les palettes des actions NU, A1, DT, etc..., sont différentes et il devient très compliqué, voire quasi impossible, de créer certains formats d'animations BG2 regroupant plusieurs actions dans le même fichier .bam, sans perte de définition dans la qualité des images.
Ha oui, tu m'en avais parlé de ce problème. Hummm je suis surpris quand même. Je pensais qu'en utilisant les même paramètres d'index et de couleur (pour background et shadow), ça serait toujours la même palette qu'on aurait.
Au fait : comme j'ai éliminé le bug graphique potentiel (voir début du post), je pense qu'avec cette dernière version c'est d'autant plus vrai que tu aura les mêmes palettes (mais à tester !). Je sais que dans la version que tu as utilisé je cherchais un pixel non-utilisé pour les ombres, alors que là plus la peine. Donc, de bons espoirs, mais à valider tout de même.
Quid de la possibilité de couper les images ? Je pense au Kraken dont la taille dépasse - et de loin - 256x256.
Comme chaque action produit des images à la taille différente, il est très compliqué de les "splitter" sans se mélanger les pinceaux lors de la conversion bam pour bien les repositionner.
De plus, j'ai vérifié : il serait possible de les couper au format 256x256 sans perte de détails. Toutes les images pourraient être contenues dans un canevas de 256x256 à condition de rogner à gauche ou à droite. C'est ce que je ferais si cette version de l'éditeur était la version finale. Mais comme ce n'est pas le cas...
Je n'avais absolument RIEN prévu à ce qujet. Hummm... ça ne devrait pas être très compliqué, connaissant à l'avance la taille de la Box, je pourrais très bien prédécouper selon des tailles voulus par l'utilisateur. Je sent qu'il faudrais une ou deux autres variables pour permettre d'identifier la partie coupée dans le nom de fichier. Mais ça me semble faisable tout ça.
En fait, il est tout à fait possible d'intégrer des bam de taille supérieure à 250x256.
Simplement, ça demande de les "splitter" en plusieurs parties et d'utiliser une procédure d'intégration différente. En fait deux : une pour l'intégration dans les cartes, une autre pour gérer les animations de créatures (ex : Dragons, Grande Wyverne, Tanarri, Demogorgon...).
Mais c'est vrai que ce n'est pas une procédure usuelle et qu'il n'existe pas beaucoup de fichiers bam d'animation de décor concernés aussi bien dans le jeu vanilla que dans les mods.
Oui, j'avais fait un programme il y a des années pour me permettre d'intégrer le dragon (MDR1) dans D2. Je m'étais bien amusé à tout réassembler
Le fichier de réassemblage était celui-ci :
► Afficher le texte
file = MDR1\MDR11\MDR11100.BAM
file2 = MDR1\MDR11\MDR11200.BAM
file3 = MDR1\MDR11\MDR11300.BAM
file4 = MDR1\MDR11\MDR11400.BAM
file5 = MDR1\MDR11\MDR11500.BAM
file6 = MDR1\MDR11\MDR11600.BAM
file7 = MDR1\MDR11\MDR11700.BAM
file8 = MDR1\MDR11\MDR11800.BAM
file9 = MDR1\MDR11\MDR11900.BAM
file10 = MDR1\MDR11\MDR11102.BAM
file11 = MDR1\MDR11\MDR11202.BAM
file12 = MDR1\MDR11\MDR11302.BAM
file13 = MDR1\MDR11\MDR11402.BAM
file14 = MDR1\MDR11\MDR11502.BAM
file15 = MDR1\MDR11\MDR11602.BAM
file16 = MDR1\MDR11\MDR11702.BAM
file17 = MDR1\MDR11\MDR11802.BAM
file18 = MDR1\MDR11\MDR11902.BAM
file19 = MDR1\MDR11\MDR11104.BAM
file20 = MDR1\MDR11\MDR11204.BAM
file21 = MDR1\MDR11\MDR11304.BAM
file22 = MDR1\MDR11\MDR11404.BAM
file23 = MDR1\MDR11\MDR11504.BAM
file24 = MDR1\MDR11\MDR11604.BAM
file25 = MDR1\MDR11\MDR11704.BAM
file26 = MDR1\MDR11\MDR11804.BAM
file27 = MDR1\MDR11\MDR11904.BAM
file28 = MDR1\MDR11\MDR11106.BAM
file29 = MDR1\MDR11\MDR11206.BAM
file30 = MDR1\MDR11\MDR11306.BAM
file31 = MDR1\MDR11\MDR11406.BAM
file32 = MDR1\MDR11\MDR11506.BAM
file33 = MDR1\MDR11\MDR11606.BAM
file34 = MDR1\MDR11\MDR11706.BAM
file35 = MDR1\MDR11\MDR11806.BAM
file36 = MDR1\MDR11\MDR11906.BAM
file37 = MDR1\MDR11\MDR11108.BAM
file38 = MDR1\MDR11\MDR11208.BAM
file39 = MDR1\MDR11\MDR11308.BAM
file40 = MDR1\MDR11\MDR11408.BAM
file41 = MDR1\MDR11\MDR11508.BAM
file42 = MDR1\MDR11\MDR11608.BAM
file43 = MDR1\MDR11\MDR11708.BAM
file44 = MDR1\MDR11\MDR11808.BAM
file45 = MDR1\MDR11\MDR11908.BAM
directions = 10.2 +11.2 +12.2 +13.2 +14.2 +15.2 +16.2 +17.2 +18.2
directions2 = 28.6 +29.6 +30.6 +31.6 +32.6 +33.6 +34.6 +35.6 +36.6
directions3 = 28.6M +29.6M +30.6M +31.6M +32.6M +33.6M +34.6M +35.6M +36.6M
directions4 = 10.2M +11.2M +12.2M +13.2M +14.2M +15.2M +16.2M +17.2M +18.2M
directions5 = 1.0 +2.0 +3.0 +4.0 +5.0 +6.0 +7.0 +8.0 +9.0
directions6 = 19.4 +20.4 +21.4 +22.4 +23.4 +24.4 +25.4 +26.4 +27.4
directions7 = 37.8 +38.8 +39.8 +40.8 +41.8 +42.8 +43.8 +44.8 +45.8
directions8 = 19.4M +20.4M +21.4M +22.4M +23.4M +24.4M +25.4M +26.4M +27.4M
delete_shadow = NO
show_pivot = NO
output_format = PCX
use_palette =
;d2_palette = d2pal_act0.pcx
more_info = YES
debug = NO
;box = -100 -100 100 100
horizontal_cut = 3
vertical_cut = 3
use_truecolor = TRUE
Au niveau purement informatique cependant, on ne devrais pas avoir besoin de faire ça ! On devrait pouvoir créer une BAM de taille qu'on veut, et ça serait le moteur lui-même qui devrait se charger de découper (si tant est qu'il y ai un réel besoin de découpage).
Suffit pour ce soir (ou matin ?
) A la prochaine fois.
Pourquoi les Ordres de Paladins ne comportent-ils que des hommes ? Et si tout ceci n'était qu'une fable racontée par les mâles pour dissimuler la vérité ? Ce mod tente de rétablir la vérité, du moins SA vérité...
http://www.zimage.fr
, je détecte que les images vides ont bien été créees, d'où le PopUp qui dit que c'est OK, mais comme je ne regarde pas si sur C: ça a marché ou pas (c'est que du Debug) tu n'en est pas prévenu
J'ai cherché le format BMP pour commencer et ... ça fait 
mais bon tant pis, ça à l'air de bien marcher quand même.
Envoyé par Paul Siramy 
Sinon, autre solution, radicale : supprime le fichier "setup.bin" dans le sous-répertoire "ressources" là où est placé MergeDCC.exe. Relance l'outil. Refait ton paramétrage des fichiers MPQ, et le reste (fenêtre d'export) est entièrement remis aux valeurs par défaut interne dans MergeDcc. Note : l'avant dernière version, j'avais mis du bleu et rose, mais comme ça venait en contradiction avec la doc sur le format BAM que j'avais, j'ai remis le vert et noir par défaut.