Construire un masque pour les sprites

Maintenant, une réflexion sur ton problème de redimensionnement, que tu as évoqué ci-dessus, Jicehel.

J'ai un problème: je n'ai pas d'algorithme applicable pour un coefficient quelconque, autre que 2 ou 1/2. Du moins en Panoramic pur, car en Delphi, avec KGF.dll, c'est facile. Cependant, c'est réalisé par un API (StretchDraw) et non par un calcul fait directement dans la DLL.

Et donc: as-tu un algorithme à proposer ? Pour appliquer par exemple un coefficient de 1,27 ou de 0,83 ? Là, je sèche... Car déterminer ces coefficients, même indépendamment verticalement et horizontalement, ce n'est pas un problème. Il en va autrement pour leur application.

On s'est croisé. En effet, "Enregistrer sous..." mérite d'être implémenté !

Non c'est complexe, mais ça servirait. En fait, ça oblige a faire des moyennes de couleurs en fonction d'approximation.
En plus pour des sprites en Panormaic, on a des règles a respecter comme celle de garder un traitement particulier pour les cases ayant un code RVB de 0,0,0 (car si on fait une moyenne avec une case adjacente, la case ne sera plus transparente).
C'est donc en effet un vrai casse tête et des tests et des réglages seront certainement nécessaires.
Implémenté cette fonctionnalité est un vrai défit, mais si tu y arrives, les principes utilisés permettront aussi de pouvoir effectuer des rotations quelconques car chacune des cases pourra être approximée et les même règles de respect de la transparence seraent à appliquer.

C'est un vrai casse-tête digne de Klaus.... PS: après, pour implémeter la rotation et l'application d'un redimensionnement selon un facteur quelconque, à mon avis, tu peux aussi avoir recours à KGF. Ce n'est pas grave selon moi... C'est pour le travail prépartoire des sprites. C'est un outil prparatoire qui n'est pas transmis avec leu jeu final. Enfin c'est comme ça que je vois les choses...

Nouvelle version:
V1.9 du 22/06/2015

Nouveauté:
ajout d'un bouton "Save image as"

Le code est à jour dans le dossier Outils\Outils graphiques\ de mon WebDav.

On peut maintenant changer de nom pour le sprite en mémoire, avec les sécurités appropriées. Contrôle d'écrasement, validité du nom de fichier, imposer la bonne marque d'orientation - tout est fait.

J'ai trouvé un algorithme de redimensionnement en Delphi. Je vais tenter de le traduire en Panoramic.

C'est un beau dé(l)fit et je pense que ces procédures sont réadaptables. Après il faudra voir pour les performances si tu fais tout en Panoramic pour ce genre d'utilisation (tout du moins tant que c'est utilisé en version interprétée et non compilée).
Je pense que ça promet des procédures interessantes pour des tas d'autres usages graphiques (m'étonnerait pas que JL35 t'en piques pour toutes les applications graphiques qu'il fait   ).
Si les performances sont bonnes il ne serait pas non plus impossible que plutôt que de gérer des tas de sprites de différentes tailles, on n'en fasse qu'un moyen et les plus grands et que l'on utilise tes procédures (si tu y arrives) pour gérer dynamiquement les sprites plus petits  

Nouvelle version:
V1.10 du 22/06/2015

Nouveauté:
remplacement des boutons "Magnify" et "Reduce" par un bouton "Zoom" et un sélecteur de taux de zoom

Le code est à jour dans le dossier Outils\Outils graphiques\ de mon WebDav.

J'ai abandonné de faire le redimensionnement en Panoramic. Déjà, pour un facteur fixe de 2, c'était très len t, mais alors pour un facteur aléatoire, c'est devenu inexploitable. Plus de 10 minutes pour doubler la taille d'un sprite de 200x200 pixels.

J'ai donc choisi d'utiliser KGF.dll pour cette fonction, et c'est quasiment instantané. On peut choisir maintenant le pourcentage de zoom de 10% à 400%, librement.

Et j'ai fait une mini-DLL nommée KGFbitmap.dll qui se trouve dans le même dossier Outils\Outils graphiques. Cette DLL contient la seule fonction de KGF.dll qui est utilisée par build_sprite_mask.bas, et encore uniquement pendant le zoom, et elle est libérée immédiatement après. A la ligne 99, il y aune variable DLL$ pour configurer le cheminn vers la DLL utilisée. On peut y mettre KGF.dll ou KGFbitmap.dll, au choix.

^^ Je m'en doutais mais ce n'est pas grave d'utiliser la DLL pour cette application. Le principal étant de pouvoir travailler ses sprites. Moi ce que j'utilisais beaucoup dans kgf pour le travail des sprite (en plus des miroirs) c'était la fonction permettant de substituer une couleur à une autre car c'est vraiment beaucoup plus rapide que si on le code en Panoramic pur.

Nouvelle version:
V1.11 du 23/06/2015

Nouveauté:
ajout d'un onglet "History"

Le code est à jour dans le dossier Outils\Outils graphiques\ de mon WebDav.

Cet onglet contient un unique objet LIST qui reprend les noms et chemins vers les fichiers sprite utilisés, avec le plus récent en tête. Un paramètre de configuration permet de limiter le nombre de lignes mémorisées (actuellement 30 lignes maxi). Un clic sur une de ces lignes charge automatiquement le sprite en mémoire, en "oubliant" celui qui s'y trouverait éventuellement.

Petite remarque technique: la liste est déposée dans un fichier INI placé dans le dossier où se trouve le programme. Si le programme a été lancé par PANORAMIC_EDITOR, ceci est détecté automatiquement et on utilise DIR_CURRENT$ pour placer le fichier ! Ainsi, on retrouve toujours sa liste, malgré le lancement dans un dossier temporaire de Windows...

Ca ressemble de plus en plus à un utilitaire complet. Je crois que je vais plutot rajouter mes fonctions dedans que rajouter ton programme dans mon ancien outil de traitement des sprites

J'avais la posibilité de modifier une partie d'un sprite en mode loupe en utilisant la pipette pour sélectionner une couleur sur le sprite ou dans la palette, j'avais des couleurs spécifiques accessible comme (0,0,1), (0,0,0),(255,255,0) et 2 couleurs sélectionnables à la pipette et une fonction fill qui permettait de remplir toute une zone avec des points de la même couleur.

Le reste est déjà dans ton outil.

Je n'avais pas codé de fonction pour disposer les sprites sur une planche (je le faisais directement dans mon outil de dessin). C'est vrai qu'avec Pangine2d, cette fonctionnalité serait sans doute plus utilisées tout comme la prévisualisation d'animations.

Il va falloir que j'envisage une pause sur asterV2, pour regarder ce programme.
A+

Merci pour tes commentaires, Jicehel.

Citation :

Je n'avais pas codé de fonction pour disposer les sprites sur une planche (je le faisais directement dans mon outil de dessin). C'est vrai qu'avec Pangine2d, cette fonctionnalité serait sans doute plus utilisées tout comme la prévisualisation d'animations.

Qu'est-ce que tu veux dire par là ? Est-ce que, pour un sprite 64x64, tu veux créer une bitmap de nx(64x64) et placer le sprite en question en n-ième position ? Et extraire la n-ième position pour le retravailler ? Si c'est ça, ça va être coton avec les tunes...

En ce qui concerne le remplacement ou remplissage de couleurs, faut voir. Ca peut se rajouter.

Je pense que la construction de la planche et des tunes doit être indépendante. Les tunes se font sur le sprite extrait. C'est juste au niveau du nommage du fichier qu'il faut coder sa position pour pouvoir réassocier l'info.
Il ne faut pas oublier que les tunes ne correspondent qu'à certains usages des sprites et que dans la plus grande parties des utilisations de sprites, ce sera la détection de collision entre 2 zones rectangulaires qui sera utilisée.

Sinon, c'est bien ça. Pouvoir travailler sur des sprites, les charger à partir d'images, les ajouter sur une planche en n-iième position afin que PANGINE2D puisse les utiliser dans les animations.
Ideallement, pouvoir indiquer les numéros de sprites intervenants dans l'animation pour pouvoir la prévisualiser faire des tests de reglage de vitesse.

Pour le remplacement de couleur, avec les fonctions de KGF je n'avais pas rencontré de difficulté.
Je pourrais te copier le code utilisé pour le faire si tu veux mais honnêtement, te connaissant, tu n'en n'as pas besoin...

Par contre j'avais fais des iamges (icones) pour les outils, si tu veux je pourrais te faire un zip si ça t'interesse (mais je sais que tu en as déjà pas mal).

Ce qui est pratique aussi c'est de pouvoir tester facilement la transparence en remplaçant la couleur 0,0,0 par une couleur non utilisée (comme le magenta ou un rouge vif). On voit tout de suite s'il y aura un problème à l'affichage et on peut remplacer les pixels incorrects.

Merci pour ces explications, Jicehel. J'y vois plus clair, maintenant.

J'ai commencé la conception de la gestion des planches de sprites, tout en gérant en parallèle la même chose pour les masques, masques avec tunes et listes de tunes. Le but étant de produire, tout comme pour un sprite individuel, 4 fichiers identifiés par un début de nom identique, et contenant, respectivement, la planche des sprites (au lieu s'un sprite unique), la planche des masques (au lieu d'un masque unique), la planche des masques avec tunes (au lieu d'un masque avec tune unique) et la liste des tunes pour tous les sprites (au lieu d'une liste de tunes pour un sprite unique).

Au chargement, on choisira le nom d'une planche (identifiée par un préfixe de nom de fichier sous forme de "collection_", ainsi qu'un numéro de sprite, et on verra alors le sprite sélectiionné en affichage. Il y aura des boutons pour aller au sprite suivant et précédant.

A l'enregistrement, on réécrit le sprite dans sa position d'origine.

Est-ce que ces quelques idées correspondent à l'idée que tu te fais de l'usage des planches ?

En ce qui concerne la couleur, je peux effectivement faire pas mal de choses, assez facilement. Pour le moment, je collectionne les idées...

EDIT

Voilà où j'en suis dans ma réflexion sur les planches. Dis-moi ce que tu en penses:

Citation :

' On peut aussi construire une planche de sprites. Ceci est réalisé par la juxtaposition
' horizontale de plusieurs sprites de même dimension, sans une même bitmap. Afin de ne pas entrer
' en conflit avec la gestion existante des sprites "mono-images", ces planches seont déposées
' dans des fichiers nommés "Collection_xxxx(angle).bmp" avec xxxx étant le nom du sprite. Et la
' même présentation d'appliquera sur les fichiers des masques et des masques avec tunes. Le
' fichier texte contenant la définition des tunes contiendra une section par sprite, avec
' une première ligne "sprite n" avec n étant le numéro du sprite dans la planche (1,2,...)
' suivie des lignes des définitions des tunes de ce sprite. Et ainsi de suite pour les autres
' sprites dans la planche. Le préfixe "Collection_" sera appliqué à tous les fichiers auxiliaires
' de la collection, y compris sur le nom du zip.
'
' Au chargement d'une planche, on spécifie le numéro du sprite à charger (mémorisé dans pindex%).
' Il y a des boutons pour aller au sprite suivant/précédant dans la planche. Le bouton "Save"
' va mettre à jour dans la planche, à la même position.
'
' Il y a aussi des boutons pour ajouter un sprite à la fin de la liste des sprites, ou pour
' l'insérer devant le sprite actuellement sélectionné, ainsi qu'un bouton pour supprimer le
' sprite actuellement sélectionné. En cas d'ajout ou d'insertion, c'est le sprite actuel qui
' est copié (dupliqué) en fonction de la localisation choisie. A charge de l'utilisateur de
' modifier le sprite dans la collection, avec un outil d'édition graphique. Le présent utilitaire
' peut ensuite être utilisé pour recréer masques et tunes. Un bouton particulier permet de
' créer une nouvelle collection d'un seul sprite, à partir d'un sprite chargé en mémoire. Cette
' collection peut ensuite être étendue avec les fonctions décrites ci-dessus.

Ca me parait pas mal du tout. J'espère que Jean-Claude ou d'autres quitravaillent de temps en temps sur les sprites comprennetn ou l'on veut en venir et donneront également leur avis. Je ne sais pas si c'est très clair pour eux, mais cet outil pourrait leur faciliter la vie plutôt que de travailler dans un outil de dessin pour certaines fonctions, notamment pour créer des animations et les ajuster.
Pour moi, par exemple pour travailler sur des gros sprites de combattants, c'est carrément pratique car ça peut éviter de devoir repérer à la main chaun des zones sensibles. Je n'avais pas pensé à la création de collection de tunes mais c'est vrai que ce sera beaucoup plus simple aussi que de tout coder dans le fichier source avec des kilomètres de data notamment si les planches ont des tailles différentes, mais ça à priori, ce sera quand même à régler à la main en ajustant tous les sprites d'une planche pour qu'ils aient la même taille. et pour bien les positionner en fonction de cette taille.
PS: Klaus, pourrais tu faire une fonction de fénéant pour ça d'ailleurs. si on nomme tout nos sprites avec un même radical style Barbarian01.bmp, Barrian02.BMP, ... barbarian40.bmp, cette fonction donnerait la taille maximale en largeur et en hauteur pour que l'on ait juste à redimensionner nos sprite en conséquence (voir une autre fonction pour que le porgramme le fasse et que l'on ait plus qu'à déplacer l'image pour y positionner notre sprite).
C'est un type de fonction de confort, donc pas du tout prioritaires, juste une idée pour se faciliter la vie et compliquer la tienne

Pour ton "PS", Jicehel:
même pas nécessaire ! Je prévois de créer un seul fichier BMP contenant la collection des sprites, d'une hauteur de h pixels et d'une largeur de n*w pixels, avec n étant le nombre de sprites, h leur hauteur et w leur largeur. Ils auront automatiquement les mêmes dimensions, et seront codés dans l'unique BMP les uns à côté des autres, sous le nom de "collection_xxxxx(angle).bmp".
Dans la fenêtre initiale (celle où l'on choisit les dimensions), on coche une case ""Collection mode". Si elle est cochée, le fonctionnement de l'ensemble s'adapte automatiquement à cela. Bien sur, il faut dessiner séparément ses images des sprites. Elles peuvent s'appeler comme on veut. Il y aura une fonction d'ajour de sprite en fin de liste,  d'insertion de sprite et de suppression de sprite. Il y aura également une fonction de chargement "en rafale", en prenant tous les BMP d'un même dossier, pour ajouter chaque image sous forme d'un nouveau sprite dans la collection. Donc, tu vois, la notion de "fénéant " est prévue ! Je peux même faire de sorte à dimensionner automatiquement chaque image aux dimensions imposées pour la collection.

C'est là que l'on voit que tu connais bien les informaticiens. Tu prévois tout de suite le mode utilisateur fénéant
Pas d'autres idées pour le moment, on verra à l'usage, mais ça me parait déjà très prometteur et j'espère que les autres en comprendont aussi l'intérêt (hein Jean-Claude) pour leurs jeux (Pour ceux qui ne font pas de jeux, forcément, c'est moins utile )

@Jicehel,
J'en comprendrai l'intérêt quand j'aurais le temps d'y jeter un œil. Mais le coté fainéant de l'affaire va m’inciter...
A+

Avec ce qu'est en train de coder Klaus, ce sera très pratique pour préparer tes sprites animés

Ca commence à bouger... La difficulté, c'est d'intégrer la gestion des planches, sans casser le fonctionnement de l'existant. Mais ça avance.

Nouvelle version:
V1.12 du 25/06/2015

Nouveauté:
intégration de la gestion des "planches" de sprites

Le code est à jour dans le dossier Outils\Outils graphiques\ de mon WebDav.

Encore une version majeure. Dans la fenêtre d'accueil, en-dehors des dimensions des sprites à gérer pour la session courante, il y a maintenant une case à cocher "Collection". Si cette case est cochée, le programme passe en mode "planche".

Une planche est la juxtaposition de plusieurs sprites (nombre non limité). Sur disque, la collection est toujours composée de 4 fichiers qui contiennent respectivement la planche, la planche des masques, la planche des masques avec tunes et la liste des définitions des tunes. Les noms de ces 4 fichiers sont préfixés par "collection_" ce qui permet au programme de les distinguer d'un simple sprite.

En mode "collection", le bouton "Load image" permet de charger une collection, bien sûr, mais également une image BMP seule ou un sprite déjà defini. Dans ce cas, le programme demande si l'on veut construire une planche (collection) à partir de ce sprite. Si la réponse est Oui, alors le programme crée une planche avec 1 sprite, en chargeant éventuellement masque et tunes du sprite existant.

A partir de là, on peut manipuler la planche. 9 nouveaux boutons de fonctionnement apparaissent dans le panel "Toolbox". Ce sont les boutons suivants:
"<<" - aller au premier sprite de la planche
"<" - aller au sprite précédant le sprite actuel
">" - aller au sprite suivant le sprite actuel
">>" - aller au dernier sprite de la planche
"App" - copier le sprite actuel comme nouveau sprite à la fin de la liste des sprites de la planche
"Ins"- insérer le sprite actuel comme nouveau sprite devant le sprite actuel
"Del" - retirer le sprite actuel de la planche (sauf l'unique restant...)
"Change sprite image" - remplace l'image du sprite actuel par un autre fichier BMP (éventuellement redimensionné)
"Add sprites from folder" - ajoute toutes les images d'un dossier comme nouveaux sprites à la fin de la liste des sprites, mais sans tunes. Les images sont éventuellement redimensionnées. On peut avoir un dialogue de confirmation pour les images individuelles.

Bien sûr, pour le sprite actuel (celui affiché à l'écran), on peut construire le masque, définir des tunes, modifier ou supprimer des tunes, tout comme s'il s'agissait d'un sprite isolé.

Alors, la fonction "fainéant", ça convient ?

Je vais explorer ça, certainement demain.

A+

Ca à l'air super (je ne peux pas tester d'ici sans risquer de complications ...).
Vu ta productivité, penses-tu pouvoir ajouter une fonction test animation qui aurait une vitesse de changement de sprite et une liste de sprite pour l'animation (exemple 1;4;5;6; ?
C'est le principe qui est utilisé pour PANGINE et ça permettrait de vérifier que les sprites "s'enchainent bien"

Bonne idée, Jicehel ! Je vais faire ça.

Nouvelle version:
V1.13 du 25/06/2015

Nouveauté:
ajout d'une fonction de test d'enchaînement des sprites

Le code est à jour dans le dossier Outils\Outils graphiques\ de mon WebDav.

Il y a maintenant la possibilité de saisir une liste de numéros de sprites (1,3,7,4,2 par exemple) dans un champ de saisie nommé "Sequence". Si ce champ est vide, il sera automatiquement rempli par la liste des sprites existants, dans leur ordre normal. Le délai entre chaque image est configuré par un spin "Delay" entre 10 et 3000 ms. Un bouton "Test" lance le diaporama. Le bouton "Test" diparaît et un bouton "Stop test" apparaît. Il permet de stopper le diaporama, ce qui revient au mode normal, avec affichage du premier onglet montrant le sprite actuel.