demande de transparence sur picture, c'est possible ?

Salut, est-ce qu'il est faisable d'avoir une DLL qui permette de rendre l'objet picture transparent si on veut, par une commande style : transparent 1, color
en supposant que 1 représente un picture et color la couleur de transparence qu'on veut.

Non, ce n'est pas possible. Un PICTURE, même en Delphi, n'est pas un objet auquel on peut affecter un attribut de transparence (canal alpha).

Par contre, ceci est possible avec une FORM. Tu peux créer une FORM avec BORDE_HIDE et placer un picture sur ce FORM avec FULL_SPACE. Tu rends ensuite cette FORM transparente ou translucide avec un coefficient entre 0 (totalement transparent) et 255 (totalement opaque).

J'ai une DLL qui fait cela depuis longtemps: c'est SetWindowButtons.dll disponible dans DLLs divers ou dans le dépôt de DLLs. La doc est dans la distribution DLLs Divers. Voici un programme qui montre les possibilités de cette dll:

Code:

label Close0, CacherBoutonX, MontrerBoutonX
label plus, moins
label MontrerForm, CacherForm
label MontrerMiniMaxi, CacherMiniMaxi

dim res%, transparence%

button 10 : top 10,10 : left 10,10 : width 10,140
caption 10,"Cacher bouton X"
on_click 10,CacherBoutonX

button 11 : top 11,10 : left 11,170 : width 11,140
caption 11,"Montrer bouton X"
on_click 11,MontrerBoutonX

button 12 : top 12,40 : left 12,10 : width 12,140
caption 12,"Montrer form"
on_click 12,MontrerForm

button 13 : top 13,40 : left 13,170 : width 13,140
caption 13,"Cacher form"
on_click 13,CacherForm

button 14 : top 14,70 : left 14,10 : width 14,140
caption 14,"Cacher boutons mini/maxi"
on_click 14,CacherMiniMaxi

button 15 : top 15,70 : left 15,170 : width 15,140
caption 15,"Montrer boutons mini/maxi"
on_click 15,MontrerMiniMaxi

form 20 : hide 20 : caption 20,"Form translucide"
top 20,300 : left 20,300

Button 21 : parent 21,20 : top 21,10 : left 21,10
width 21,100 : caption 21,"Plus transparent" : on_click 21,plus

Button 22 : parent 22,20 : top 22,10 : left 22,130
width 22,100 : caption 22,"Moins transparent" : on_click 22,moins


dll_on "SetWindowButtons.dll"
on_close 0,Close0

transparence% = 255

end

Close0:
dll_off
return


CacherBoutonX:
    res% = dll_call2("SetCloseBox",handle(0),0)
    return
   
MontrerBoutonX:
    res% = dll_call2("SetCloseBox",handle(0),1)
    return
   
MontrerForm:
    show 20
    return
   
CacherForm:
    hide 20
    return

plus:
    transparence% = transparence% - 10
    if transparence%<0 then transparence% = 0
    res% = dll_call2("WindowTranparency",handle(20),transparence%)
    return
   
moins:
    transparence% = transparence% + 10
    if transparence%>255 then transparence% = 255
    res% = dll_call2("WindowTranparency",handle(20),transparence%)
    return

CacherMiniMaxi:
    res% = dll_call2("SetMinimizeMaximize",handle(0),0)
    return

MontrerMiniMaxi:
    res% = dll_call2("SetMinimizeMaximize",handle(0),1)
    return

Il y a 3 séries de boutons:
1. Cacher/Montrer Bonton X permet de gérer la croix rouge sur une form !
2. Montrer/Cacher form permet d'afficher une petite FORM contenant 2 boutons, avec lesquels on peut ajuster la transparence de cette même FORM
3. Cacher/Montrer boutons mini/maxi permet de gérer les boutons de réduction et de maximisation d'une FORM

On peut procéder comme suit:
dll_on "SetWindowButtons.dll"
res% = dll_call2("WindowTranparency",handle(numéro_de_fenêtre%),transparence%)
dll_off
On voit que la DLL n'est nécéessaire que pour effectuer l'appel à la fonction. On peut la libérer après et la transparence reste acquise.

Merci Klaus

C'est que je voulais me servir de "picture" et de "image" pour simuler la relation qu'il y a entre le scene2D et le sprite, car je veux me passer de ces deux-là qui ne peuvent pas me servir dans mes jeux.

EDIT :

Si, dans delphi je me suis déjà servi d'une proprieté de transparence, sur un picture mais je ne me souviens plus ça fait longtemps que j'ai stoppé delphi 5.

Je vais chercher ça.

Rien ne t'empêche d'utiliser autant de petites fenêtres sans bord, toutes chargées avec une image, pour simuler le comportement des SPRITE. Mais je pense que la transparence que je montre n'est pas celle que tu cherches. Elle s'applique à la fenêtre en entier, et tu as sûrement besoin d'avoir une couleur transparente, de sorte à déplacer un personnage, par exemple, sans qu'on voie le rectangle entourant ce dessin.

Mais je ne comprends pas vraiment pourquoi ce ne serait pas possible avec SCENE2D et SPRITE. C'est justement fait pour cela. Avec les SPRITE, tu as une couleur transparente (le noir). Si tu charges une image dans un SPRITE, les zones noires (RGB 0,0,0) de ce SPRITE ne sont tout simplement pas dessinées, produisant ainsi une vraie transparence de ces zones. Tu peux déplacer un SPRITE sana avoir à réafficher la SCENE2D en entier comme ce serait le cas avec un PICTURE. Tu peux faire chevaucher les SPRITE, les cacher et réafficher, les redimensionner etc, et tout ça sans avoir à t'occuper de gérer l'aspect global de ton plan de jeu. La SCENE2D s'occupe de tout cela automatiquement. En voulant gérer tout cela toi-même, dans un PICTURE, tu n'as aucune chance d'y arriver avec des performances acceptables. JE pense que tu devrais te replonger dans la technique d'utilisation des SCENE2D et SPRITE et tu verras que c'est assez souple d'utilisation. Tu peux même avoir des SPRITE qui changent d'image, un peu à la manière d'un smiley animé, en ayant des objets IMAGE pour chaque état distinct, et à l'aide d'un timer, tu copies les IMAGE dans le SPRITE successivement. Et cela n'affecte pas le reste de la SCENE2D.

Oui je sais ce que tu me dis, le scene2D je le connais, mais il y a des tas de trucs que je ne peux pas faire avec (par exemple y afficher du texte), je ne les aie pas tous en tête car c'était au fur et à mesure de mes découvertes, que j'avais mis sur le forum d'ailleurs, mais le resultat c'est qu'il m'est inutile, le mieux pour moi c'est d'attendre toonic.

Utiliser des micro fenetres c'est trop lourd, surtout deja que avec "image" c'est lourd^^

Je sais qu'il y a manière quelque fois (pas dans tous les cas) de bricoler pour palier à ce qui me manque sur le scene2D ou au niveau des sprites, mais ça rend le systeme plus lourd.

Pour les textes, je t'avais déjà donné une solutiion: tu écris tes textes dans un PICTURE caché par HIDE avec "COLOR n,0,0,0" et "FONT_COLOR n,r,g,b" (0,0,1 pour ressembler à une écriture noire). Tu charges ensuite ce PICTURE dans un SPRITE, et tu as une écriture à fond transparent que tu peux déplacer librement sur la SCENE2D.

Tu places tout ce mécanisme dans un sous-programme, et tu n'as plus qu'à faire:

Code:

txt$ = "mon texte"
n% = mon_numero_de_sprite
gosub affcher_texte

et le tour est joué. Et avec la version de Panoramic que Jack prépare, ce sera encore plus simple:

Code:

call afficher_texte("mon texte",mon_numero_de_sprite)

Si tu veux, je peux te coder la routine afficher_texte, mais ce n'est pas compliqué.

Klaus ich bewundere dein Ausdauer und Güte !!!
Severin

Klaus, I admire your persistence and kindness!
Severin

Klaus, j'admire votre ténacité et sa gentillesse!
Severin

Non je vais essayer ton code pour le texte, mais pour les autres cas à propos de scene2D je ne m'en souviens plus mais bon je vais essayer de réutiliser le scene2D on va voir.

Merci pour ton code^^

Eh Severin, tu n'est pas gentil toi ?

EDIT :
Je viens de chercher sur google et c'est avec Timage qu'on a la transparence pas avec mon picture.
Le Timage simule la transparence sur un bmp en surveillant un pixel dans le coin de l'image pour s'en servir de couleur transparente.

Je me dis que si on peut faire ça avec un picture ce serait cool sinon le mieux c'est sûr c'est d'attendre que la demande sur les PNG dans Panoramic soit exaucée^^

Tu as raison pour TIMAGE. Mais je ne pense pas que cela résolve ton problème. En effet, tu obtiens un composant dont certaines parties de l'image peuvent être transparentes, en fonction de la couleur d'un pixel particulier. Il te faut donc autant de composants TIMAGE que d'images à afficher dans ton jeu, et tu déplaces ensuite ces TIMAGES sur la FORM qui servira de plan de jeu.

C'est bien plus lourd que la gestion des SPRITE. En matière de transparence, la différence est uniquement dans la manière de déterminer la couleur de transparence: dans un TIMAGE, c'est la couleur d'un pixel particulier, et dans un SPRITE, c'est la couleur noire.

Non, c'est à moi de faire en sorte que mes images aient le même fond

Comme ça un seul Timage suffit.

Mais bon, trève, je vais tester (heu re-tester nieme fois) le scene2D^^

EDIT :

Je viens de me souvenir pourquoi je ne pouvais pas utiliser le scene2D dans un éditeur de map.

J'ai besoin d'y placer des images pour constituer une map de jeu, et le scene2D n'accepte pas qu'on y affiche une image, pas de commandes pour ça.

J'ai décidé de faire l'éditeur de map avec des pictures et de l'objet image, ça marchera, mais dans ce cas je ne peux plus utiliser le glissement d'une image qui suit la souris comme je le fais dans le problème que j'ai posé dans l'aide.
Donc du coup, aucunes des deux solutions (scene2D et picture) ne me va.

1. Si tu utilises des images ayant le même fond, cela peut passer tant que les images ne se chevauchent pas. Dès que les images commencent à bouger (déplacement d'un personnage) et se chevauchent, tu verras l'image de dessous cachée par le fond de l'image de dessus...

2. pour affichier une image de fond dans un SCENE2D, il suffit de créer un SPRITE de la taille de la SCENE2D et lui donner cette image. Où est le problème ? Tous les autres SPRITE viendront s'afficher par-dessus.

Petite info technique:
les PICTURE (comme les ALPHA) sont en fait des contrôles qu'on appelle "windowless". Ce sont des contrôles qui n'ont pas de fenêtre Windows, pas de handle. Si une fenêtre doit être réaffichée, Windows ne sait même pas qu'il faut réafficher ces objets. C'est la responsabilité de l'objet qui les contient de les réafficher. C'est tout le contraire d'un TIMAGE.

L'avantage, c'est que ces objets se chargent bien plus vite au démarrage du programme, de l'ordre de 10 à 100 fois plus vite. C'est pour cella que même MicroSoft conseille de n'utiliser les TPICTURE que là où c'est strictement indispensable. Les SPRITE ont le même avantage: ils ne sont pas connus de Windows et ne participent pas à la lourde surcharge de gestion de l'environnement Windows. C'est Panoramic qui s'en occupe via la gestion de leur contenant, la SCENE2D. Essaie de créer 100 ou 200 PICTURE dans une FORM et obtenir des peformances raisonnables ! Tu n'auras pas ces problèmes avec SCENE2D et SPRITE.

OK merci de ces informatons intéressantes Klaus

Pour ce qui est de la map sur le scene2D je ne peux pas la mettre sur un seul sprite et l'agrandir à la taille de la map, car la map est consituée de plusieurs couches :

Le concepteur de la carte clique sur un menu à droite de l'écran, il choisit les sols, puis sélectionne un sol (de l'herbe, de l'eau, de la lave etc...) cette image de sol est collée au curseur de la souris et quand il clique sur une case de la map, le sol s'affiche sur la map à l'endroit du click, ensuite il choisit un autre sol etc....
Quand il a fini la couche des sols, il sauvegarde, et choisit les décors par exemple, il clique sur un décor proposé (arbre, puit, rocher, etc...) et de la même façon que les sols il le place sur la map.
De même pour la couche des personnages, la couche des objets, etc...

Avec le scene2D je ne peux pas faire ça.

Pourquoi pas ? Tu pourrais imaginer d'avoir Plusieurs SPRITE immobiles dans ton SCENE2D, le premier représentant le terrain à constituer, les autres le ou les outils à cliquer et/ou à tirer.

Dès que tu cliques sur un outil, tu génères en fait un nouveau SPRITE que tu colles à la souris, de sorte à le déplacer sur le SPRITE servant de "terrain", et là, tu le laches à l'endroit voulu. Tu auras créé auparavant des variables genre dim sol%(500,...), decors%(500,...), ... et tu mémorises dans ces tableaux les numéros des SPRITE correspondants, éventuellement avec leurs paramètres (position x/y, ...). Tous ces SPRITE se superposent sur le "terrain" sans problème.

Au moment de la génération finale, il te suffit de parcourir tes tableaux dans un ordre logique (sols, puis décors, puis personnages, puis ...) pour générer le résultat final.

Tu imagines quand même combien ça va me faire de sprite pour une map de 25x25 cases de 16x16 pixels ?

ça fait 625 sprites pour couvrir toute la map, et ça c'est juste pour les sols, aprés il y a encore 4 couches.
Même si je fais une couche de sols et que je la sauvegarde en fichier bmp et que je charge ce fichier bmp dans le scene2D pour faire la couche de décors (arbres, rochers, etc), je ne vois pas comment je vais faire les autres couches par dessus, mais déjà ça me fait beaucoup de sprites en cours.

Une question à propos des sprites justement, on ne peut pas créer des sprites à la volée, il faut qu'ils aient été déjà créés et déclarés non ?

Tu peux créer des SRIE à la volée. La commande SPRITE peut être placée à tout endroit du programme, en réaction à un clic de souris par exemple. C'est tout à fait dynamique, exactement comme la création de tous les autres objets Panoramic, également. Et le nombre possible de SPRITE, s'il n'est pas techniquement illimité car ça n'existe pas, est extrèmement élevé - les 625 dont tu parles, et même plusieurs milliers ne posent pas de problème.

La difficulté réside en fait dans la méthode de gestion de ces pièces de puzzle. C'est bien pour ça que j'avais suggéré de créer des tables par catégories de SPRITE, et je développe l'idée un peu:

Code:

' ***** liste des tables des éléments à utiliser
' ***** chaque élément est défini dans un fichier (structure à définir)
' ***** l'indexe dans ces tables identifient de façon unique un élément
' table des éléments de sol
dim n_elements_sol% : ' nombre d'éléments de sol en table
dim table_elements_sol$(500) : ' noms de fichiers décrivant les éléments de sol
' table des décors
dim n_elements_decor% : ' nombre d'éléments de decor en table
dim table_elements_decor$(500) : ' noms de fichiers décrivant les éléments de decor
' ... etc pour tous les autres types d'éléments

' ***** liste des tables des SPRITE par niveau fonctionnel
' ***** les tables sont des tableaux à 2 dimensions
' ***** chaque SPRITE est identifié par son numéro et a éventuellement certains attributs
' ***** parmi ces attributs, on note: le numéro d'élément à utiliser (d'une des tables éléments)
' ***** ses coordonnées (x,y)
' ***** éventuellement sa taille et/ou ses dimensions
' ***** éventuellement d'autres attributs
' ***** tous ces attributs sont stockés dans la deuxième dimension - une "ligne" par sprite
' table des SPRITE de type "sol"
dim n_sprites_table_sol_max% : ' nombre maxi de SPRITE dans la table SPRITE de type sol
n_sprites_table_sol_max% = 500
dim n_sprites_table_sol% : ' nombre de sprites "sol" en table sol
dim sprites_table_sol%(n_sprites_table_sol_max%,5)
' (x,0) = numéro de SPRITE
' (x,1) = numéro d'élément de type sol
' (x,2) = coordonnée x du sprite
' (x,3) = coordonnée y du sprite
' (x,4) = autre attribut
' (x,5) = autre attribut
' table des SPRITE de type "décor"

' ***** système de créaton des SPRITE
dim n_sprite_sol% : n_sprite_sol% = 10000 : ' valeur de départ pour la création des SPRITE de type sol
dim n_sprite_decor% : n_sprite_decor% = 20000 : ' valeur de départ pour la création des SPRITE de type decor
... etc pour chaque type de SPRITE
dim max_sprite_sol% : max_sprite_sol% = 19999 : ' numéro maxi de SPRITE à créer de type sol
dim max_sprite_decor% : max_sprite_decor% = 29999 : ' numéro maxi de SPRITE à créer de type decor
...

et ainsi de suite. Tu obtiens ainsi une photo de la situation de ton terrain avec tout ce que tu y as déposé. Tu peux aussi, facilement, identifier un SPRITE déjà déposé en cliquant dessus - tu obtiens son numéro en réaction au clic et tu peux ainsi aisément le retrouver dans ces tables. Et comme tu peux affecter librement des numéros de SPRITE, tu peux même définir des plages de numéros par type de SPRITE, de sorte que le clic de donne immédiatement le type de SPRITE ciblé, rien que par son numéro, comme par exemple:
1...1000 sont les SPRITE du terrain et des outils
10000...19999 sont les SPRITE de sol
20000...29999 sont les SPRITE de décor
etc.

De toute manière, il faut bien que tu puisses interagir sélectivenemt avec tes différents éléments. Et il faut surtout que tu puisses revenir sur un élément déjà placé afin de l'annuler ou le déplacer si besoin est. Et là, la méthode des SPRITE est souveraine car elle garantit une parfaite indépendance des différents éléments les uns des autres, bien que cela s'affiche ensemble dans la SCENE2D. Et ce n'est qu'à la validation finale qu'on construit une image de synthèse.

Si tu utilises un PICTURE pour déposer des éléments, dès que cet élément est déposé, tu n'as plus aucun moyen d'y renevir, de l'annuler ou de le déplacer. Cela opère une fusion ou un remplacement des pixels dans un canvas, et on ne peut traiter le canvas qu'en tant qu'entité. Comment traiter, dans un PICTURE, la superposition, éventuellement partielle, de deux éléments ? Impossible. Une fois déposé, on ne peut plus dissocier un élément du PICTURE.

Bon, ce que je te dis là, ce sont des réflexions d'ordre technique et théorique. A toi évidemment de voir par rapport aux fonctionnalités du logiciel que tu souhaites créer. Je voulais simplement de donner une idée de la souplesse d'utilisation des SPRITE.

Merci beaucoup Klaus, tu me fait beaucoup avancer sur Panormaic là !

Ta méthode et ton code je les adopte illico !!!

Sinon pour ça :

Citation :

Si tu utilises un PICTURE pour déposer des éléments, dès que cet élément est déposé, tu n'as plus aucun moyen d'y renevir, de l'annuler ou de le déplacer.

J'ai déjà prévu un code qui permet de revenir en arrière sur 30 coups je crois, j'ai affiché la technique dans le topic "partager vos sources" mais me souviens plus du nom.
En tous cas, tu me rends copain avec le scene2D là

Oui, j'ai vu ta technique.

Ceci dit, tu as vu qu'avec les SPRITE, on peut modifier, pas seulement revenir en arrière en défaisant pas à pas ce qu'on a fait, simplement parce qu'on peut cibler n'importe quel SPRITE, même le premier déposé. C'est plus souple.

Ma satisfaction, c'est d'avoir pu te mettre sur une nouvelle piste - à toi maintenant de l'explorer !

Oui j'avais bien lu ce que tu disais à propos de la sélection du sprite et de ses infos, et c'est vraiment cool !

Je suis content que tu aie pu m'expliquer tout ça, je repars sur une bonne base là avec les sprites de Panoramic.

EDIT :
Je viens de voir que j'avais pas mal avancé mon éditeur de map utilisant les pictures, et je l'avais mis en berne à cause de l'impossibilité de faire glisser une image sur la map et accrochée au curseur, comme je l'ai mis dans le topic aide, et maintenant que tu me dis que mon editeur de map peut être fait avec le scene2D Je vais finir cet éditeur en picture et le mettre en petit exemple de ce qu'on peut faire en panoramic, je vais juste le spécialiser pour un jeu en particulier qui me tiens à coeur, un jeu de rôles textuel et je ferais une version en scene2D comme outil perso pour faire un jeu de stratégie au tour par tour, du style de héroes of might and magic II,

Rien à faire, cette fois j'en suis dégouté à jamais du scene2D

J'ai essayé, suite à un post d'aide pour Lodcho, de faire un déplacement de sprites animés, impossible, tu verras le post de lodcho.

Donc je suis obligé d'attendre Toonic si je veux vraiment faire des animations, car Panoramic c'est même pas la peine.
Et tu me connais, ce n'est pas faute d'avoir essayé ^^
Merci quand même pour ton appui, c'est important !