Discussion :

[meastalavista]

Bonjour tout le monde
Je voulais savoir comment faire pour créer un tableau contenant des images(.bmp ou jpg).
J'ai regardé un peu partout mais en vain.
J'espere que vous maiderez a resoudre ce probleme vu que j'ai envie d'avancer dans mon projet d'un jeu de carte.
Merci d'avance

[Dirk-Pitt]

Bonjour,

TImageList ne convient pas ?

[meastalavista]

Bonjour,

TImageList ne convient pas ?

a vrai dire jme suis jamais servie

g plutot envie de stoké tte lé carte ds un tableau,é dappelé une fonction randomize sur ce tableau pr recupéré 6 carte a chaque fois.
voila
si vous voyez une autre solution je suis preneur

[Gilbert Geyer]

Bonjour,

... d'autant plus que TImageList ç'est justement fait pour une collection d'images de tailles identiques comme celles d'un jeu de cartes.

A+

[Clorish]

la classe TImageList est plutot bien.
Mais je lui prefere la version traditionelle : Un array of TBitmap ou TJPegImage.

Ensuite, je te conseille de garder en memoire un seul exemplaire de chaques cartes (images) et de creer un ou des tableaux d'entiers designant l'index de l'image utilisé.
Ca te fera economiser de l'espace memoire ...

[meastalavista]

Merci pour vos reponses
jvé me documenté sur lé timage list vu ke je me suis jamais interessé a ca
Merci encore

[Gilbert Geyer]

Re-bonjour;

g plutot envie de stoké tte lé carte ds un tableau,

monImage:=monImageList.Components[Index: Integer] c'est à peu près kif-kif à un tableau du style
var mesCartes : array [0 ...nbMaxMoinsUne] of TImage.
Dans les deux cas on accède à chaque image par son indice.
Par contre un tableau dans le genre array est plutôt adapté au cas d'images qui auraient des tailles différentes, mais si tu tiens à un tableau du genre array il faudra déclarer la taille de chacune alors qu'avec TImageList on ne déclare la largeur et la hauteur qu'une seule fois pour toute la collection d'images.
Dans les deux cas il faudra trouver des fichiers-image *.bmp ou *.jpg pour ta collection de cartes car ce serait la galère d'avoir à les dessiner le reste c'est plus simple sauf si t'as des règles de jeu compliquées.

A+

[Fabrice ROUXEL 1]

Bonjour,

Il est possible d'utiliser la DLL cards.dll qui contient des images de cartes utilisées par le Solitaire par exemple.
Voici 2 liens qui illustrent son utilisation en Delphi: http://www.programmersheaven.com/dow.../download.aspx
http://www.efg2.com/Lab/Library/Delp...hms/index.html
IL y a également un code ici http://delphipage.free.fr/cards.html

@+

[Clorish]

monImage:=monImageList.Components[Index: Integer] c'est à peu près kif-kif à un tableau du style
var mesCartes : array [0 ...nbMaxMoinsUne] of TImage.
Dans les deux cas on accède à chaque image par son indice.
Par contre un tableau dans le genre array est plutôt adapté au cas d'images qui auraient des tailles différentes, mais si tu tiens à un tableau du genre array il faudra déclarer la taille de chacune alors qu'avec TImageList on ne déclare la largeur et la hauteur qu'une seule fois pour toute la collection d'images.
Dans les deux cas il faudra trouver des fichiers-image *.bmp ou *.jpg pour ta collection de cartes car ce serait la galère d'avoir à les dessiner le reste c'est plus simple sauf si t'as des règles de jeu compliquées.

Justement, TImageList est une sorte de Array of TImage avec en plus des outils pour la gestion generique de tableaux d'images.
De plus la gestion via classes TImage permet d'utiliser plusieurs format (tous ?) des plus courrant.

Donc en fait ... mis a part tout un tas de choses qui servent a rien dans ce cas (tableaux de sauvegarde d'image monoformat) il ne fait rien de plus qu'un simple array of TBitmap (Meilleur classe pour l'interaction avec l'ihm)
Alors pourquoi se trimbaler tout un tas de trucs inutile

- LA taille des image est fixe (32 ou 54)
- Le format unique (TBitmap eventuelement chargé via TJpegImage temporaire et le fameux DIBNeeded)
- Aucune modification/Ajout n'est necessaire pares initialisation (la gestion des decks etant plus simple via un array of integer)

Donc j'opterais pour un array of TBitmap, un SetLength(32/54) et une boucle for de chargement utilisant :
- Soit directement le TBitmap.LoadFromFile.
- Soit un TJpegImage Temporarire puis un LoadFromFile, un DIBNeeded suivi d'un assign sur le TBitmap du tableau mis aux dimentions du TJpegImage.

Bon ok, j'ai eu la flemme de coder tout ca mais ca prends pas plus d'une 20aine de lignes ....
Par contre toutes les pistes sont la.

C'est propre, Clair et efficace.

[Gilbert Geyer]

Re-bonjour,

De plus la gestion via classes TImage permet d'utiliser plusieurs format (tous ?) des plus courrant.

... ce sont tout bonnement les principaux formats qui sont cités dans la propriété Filter de OpenPictureDialog.

Array of TImage ou TImageList : y'a que l'embarras du choix, suffit de choisir. C'est vrai que dans TImageList il y a des trucs peu employés et qu'avec ceux qui restent on fait comme avec des TImage. Et pour ce qui est de l'image elle même le .bmp n'a pas grand chose à envier aux autres car 52 cartes + un dos de carte ça tient plus que largement en mem-vive.

A+

[Clorish]

... ce sont tout bonnement les principaux formats qui sont cités dans la propriété Filter de OpenPictureDialog.

Il me semble que l'on peut meme aller plus loin ... du moment qu'il existe une possibilitée de convertir le format vers une Version DIB.
A priori, meme des format speciaux devraient pouvoir etre manipulées via le Assign si on a un systeme de conversion DIB.
Mais apres faudrais voir plus en profondeur dans les sources et comprendre le fonctionnement reel de la classe TGraphic.

Et pour ce qui est de l'image elle même le .bmp n'a pas grand chose à envier aux autres car 52 cartes + un dos de carte ça tient plus que largement en mem-vive.

Meme si la place manque, je voit mal comment manipuler un format sans utiliser sa version decompressée.
Maintenant si la capacitee de la RAM est limite, on peut les conserver compressées et ensuite les decompresser a la volee en cours d'utilisation.
Mais bon ca empiete sur les perfs processeur et je ne pense pas que ca soit non plus une meilleur idee
Ici ce n'est pas important, mais dans certains cas ca peut l'etre.

Amha, il est plus simple d'upgrader en RAM son PC que en CPU
Ou alors .... faut le jetter et un prendre un qui date de moins de 10 ans

[Gilbert Geyer]

Bonjour,

Clorish a écrit :
Il me semble que l'on peut meme aller plus loin ... du moment qu'il existe une possibilitée de convertir le format ...

... ben oui effectivement qu'en convertissant les formats non-supportés-en-l'état par le TImage en un format-supporté qu'on finit par s'en sortir, bigre ... mais cela ajoute chaque fois une conversion.
A mon avis pour un jeu de cartes vaut mieux fignoler le code du côté du respect des règles du jeu plutôt que de se compliquer la vie avec des formats-image-exotiques vu que le thème n'est quand même pas celui du traitement d'images de qualité photographique.

Clorish a écrit :
Meme si la place manque, je voit mal comment manipuler un format sans utiliser sa version decompressée

... exact pour la mem-vive, et donc le .bmp a encore moins à envier aux autres formats vu que l'espace-disque disponible de nos jours est plus que confortable.

Clorish a écrit :
Maintenant si la capacitee de la RAM est limite, on peut les conserver compressées et ensuite les decompresser a la volee en cours d'utilisation.

... PaintShopPro m'a répondu qu'une image *.bmp de 130 x 200 en 256 couleurs donne un fichier de 27 Ko, donc 52 cartes + 1 dos de carte ça n'occupe que 1431 Ko soit 1,4 Mo en tout (avec des cartes en 16,7 millions de couleurs multiplier par 77/27) je serais donc fortement surpris qu'on utilise encore des ram de faible capacité au prix où les barettes sont descendues depuis fort longtemps.
... et s'il s'agissait d'un jeu de 5200 cartes, avant de me lancer dans d'incessantes décompressions/re-compressions, je comparerais les temps d'exécution avec l'alternative consistant à tout décompresser une seule fois en direction du disque-dur puis de charger chaque carte à la volée en fonction de l'évolution du jeu sachant qu'en plus on peut regrouper toutes les images en un seul fichier.dat via un Stream au cours duquel on mémorise la Position-début-image de chaque carte en prévision d'une re-lecture rapide en sens inverse ... en fait y'a même pas besoin de mémoriser ces Positions vu que chaque image a la même taille, il suffit de les regrouper dans l'ordre croissant ou décroissant de la valeur des cartes et on obtient cette position par une simple formule de calcul et faire PositionCarte[8,Carreau]:=tant ... par contre en les mémorisant une fois pour toutes ça évite d'avoir à les recalculer à chaque fois.

A+

[Clorish]

... ben oui effectivement qu'en convertissant les formats non-supportés-en-l'état par le TImage en un format-supporté qu'on finit par s'en sortir, bigre ... mais cela ajoute chaque fois une conversion.

Je ne parle pas de conversion au sens propre du therme mais d'une methode de decompression fournie par la classe gerant le format.
En fait le principe est simple : Un format de fichier est une facon de structurer les donnéees pixels. On peut utiliser divers types de compressions et ou de calcul dynamique de pixels manquant pour economiser de la place.
Meme compressé, il faudra bien a un moment ou a un autre passer par tous les pixels, donc s'approcher d'un format brut, DIB etant visiblement le plus utilisé.
Une fois que notre classe gerant le format particulier, propose une version DIB de notre image, il semblerais que l'on puisse assigner ce type a une classe bitmap et le manipuler comme bitmap.

Il est vrai que cela s'apparente a de la conversion, mais je pense que cela est plus proche du transtypage que de la conversion proprement dite.
D'apres ce que je sais du assign, je pense que la conversion en format DIB utilise utilise des property de TGraphic qui est le premier ancetre communt a tous les fichiers images .... et donc les seulles a etre sensé copié par le assign.
Apres c'est juste une question de sementique

A mon avis pour un jeu de cartes vaut mieux fignoler le code du côté du respect des règles du jeu plutôt que de se compliquer la vie avec des formats-image-exotiques vu que le thème n'est quand même pas celui du traitement d'images de qualité photographique.

+1
Je parlais de facon plus generale

... exact pour la mem-vive, et donc le .bmp a encore moins à envier aux autres formats vu que l'espace-disque disponible de nos jours est plus que confortable.

Ce n'est pas uen question d'espace dique/ram disponible mais de procede de traitement.
Une image ne peut etre utilisée si on a pas acces aux pixels.
Donc a une version decompressee.
MEme si certains formats sont gerer de maniere phisique par les circuits des cartes videos ... au final il faut bien connaitre la couleur du pixel a afficher a l'ecran.

Apres c'est une question de performances. Si on a de gros besoins, on peut utiliser les circuits integrés pour accelerer les calculs, decompresser les images zone par zones pour un traitement successif, ou image par image, etc ...
La encore je parlais dans le cas general

... PaintShopPro m'a répondu qu'une image *.bmp de 130 x 200 en 256 couleurs donne un fichier de 27 Ko, donc 52 cartes + 1 dos de carte ça n'occupe que 1431 Ko soit 1,4 Mo en tout (avec des cartes en 16,7 millions de couleurs multiplier par 77/27) je serais donc fortement surpris qu'on utilise encore des ram de faible capacité au prix où les barettes sont descendues depuis fort longtemps.
... et s'il s'agissait d'un jeu de 5200 cartes, avant de me lancer dans d'incessantes décompressions/re-compressions, je comparerais les temps d'exécution avec l'alternative consistant à tout décompresser une seule fois en direction du disque-dur puis de charger chaque carte à la volée en fonction de l'évolution du jeu sachant qu'en plus on peut regrouper toutes les images en un seul fichier.dat via un Stream au cours duquel on mémorise la Position-début-image de chaque carte en prévision d'une re-lecture rapide en sens inverse ... en fait y'a même pas besoin de mémoriser ces Positions vu que chaque image a la même taille, il suffit de les regrouper dans l'ordre croissant ou décroissant de la valeur des cartes et on obtient cette position par une simple formule de calcul et faire PositionCarte[8,Carreau]:=tant ... par contre en les mémorisant une fois pour toutes ça évite d'avoir à les recalculer à chaque fois.

Cas general
Pour un jeu de carte c'est clair que ca sert a rien. Saut peut etre a reduire la taille de l'exe en vue de le telecharger depusi le net ... et encore !

Par contre certaines applications (notement le texturage 3D) demande plus de resources. Par exemple notre application actuelle assez basique en somme utilisait pres de 500Mo de memoire pour les textures, reduit a 50Mo en se basant sur des textures compressées, decompressee a la volee lors du calcul de des frames.
Et c'est la qu'entre en jeu le rapport RAM/CPU
decompresser a la volee bouffe de la ressoruce CPU, utiliser des images decompressees bouffe la RAM
Si la machine ne peut supporter cette charge, il faut voir ce qui coute le moins cher a upgrader : La ram ou le CPU ?

Une appli faisant de gros calculs basé sur l'utilisation trs frequente d'une petite serie d'image peut augmenter sa RAM pour accellerer le temps de calcul en utilisant des version decompressées ne prenant pas autant de place que ca en memoire.

Une appli qui effectue peu de traitement mais sur un pack consequent d'images, demande une upgrade CPU.
L'usage de version decompressee demanderais trop de RAM ... pour un CPU somme toute assez peu solicité.

[Gilbert Geyer]

A Clorish :

Sur le fond tu as raison et en plus c'est intéressant.
Par contre je me demande si avec nos échanges on ne risque pas de faire naître une impression de complexité dissuasive chez Meastalavista qui voudrait simplement savoir comment faire pour créer un tableau contenant des images.
Si on l'oriente vers un array of TBitMap on lui met tous les Bmp en mem-vive et une fois pour toutes : + 1,4 Mo, avec 256 couleurs largement suffisantes pour des cartes, vitesse optimale, et en plus on lui simplifie la vie vu qu'il y a plein de codes pour manipuler des Bmp. Par contre rien que pour coder le chargement des 53 fichiers-image il faudrait savoir si les règles de son jeu tiennent compte à la fois du numéro de la carte (1, 2, 3, etc) et de son type (carreau, coeur, etc) ou s'il s'agit d'un tarot-divinatoire car dans un cas il s'agirait d'un simple array [0..52] of TBitMap et dans l'autre d'un array[0..12,0..3]. Jusqu'à présent il n'a parlé que d'un projet d'un jeu de cartes sans préciser si des cartes pour jouer ou pour de la divination générée par un Random (on peut s'attendre à tout !).

De plus, s'il s'agit d'un jeu de cartes traditionnel, on ne sait pas si Meastalavista veut pouvoir utiliser la DLL cards.dll signalée par Fabrice ROUXEL
Donc pour avancer faut attendre qu'il nous éclaire un peu mieux.

A+

[Clorish]

Sur le fond tu as raison et en plus c'est intéressant.

Oui c'est interessant de discuter de ces choses avec toi
Ca n'ets pas la premiere fois et je doute que ca soit la derniere

Par contre je me demande si avec nos échanges on ne risque pas de faire naître une impression de complexité dissuasive chez Meastalavista qui voudrait simplement savoir comment faire pour créer un tableau contenant des images.

Je suis plus que d'accord ... mais des qu'un debat pointe le bout du nez .. je ne peut m'empecher de me jeuter dedans
De plus, n'ayant pas toutes les donnéees en main, il est pas toujours evident de faire des reponses precises.
Enfin, allez au dela de ce qu iest demander permet des fois de donner quelques idees et voir les choses d'un autre point de vue.
LEs questions posées sont souvent issue de problemes de conception ..

Si on l'oriente vers un array of TBitMap on lui met tous les Bmp en mem-vive et une fois pour toutes : + 1,4 Mo, avec 256 couleurs largement suffisantes pour des cartes, vitesse optimale, et en plus on lui simplifie la vie vu qu'il y a plein de codes pour manipuler des Bmp.

Oui, depuis le debut le preconise un simple array af TBitmap plutot que la lourdeur des TImageList.

Par contre rien que pour coder le chargement des 53 fichiers-image il faudrait savoir si les règles de son jeu tiennent compte à la fois du numéro de la carte (1, 2, 3, etc) et de son type (carreau, coeur, etc) ou s'il s'agit d'un tarot-divinatoire car dans un cas il s'agirait d'un simple array [0..52] of TBitMap et dans l'autre d'un array[0..12,0..3]. Jusqu'à présent il n'a parlé que d'un projet d'un jeu de cartes sans préciser si des cartes pour jouer ou pour de la divination générée par un Random (on peut s'attendre à tout !).

Pas tout a fait d'accord.
Sur le principe oui, mais sur le fond pas tout a fait.
Je trouverais interessant de charger en memoire dans un array of TBitmap la liste des images et de manipuler les decks via des array of Integer.

Prenons un exempel simple d'utilisation : Le Rami.
C'ets un jeu qui se joue avec 3 jeux de cartes si mes souvenirs sont bons.
Je pense donc que c'est plus interessant de charger en memoire 52 Bitmaps et de gerer des decks de 156 Integers, contenant 3 exemplaires des ID (0~51) du tableau de Bitmap.
C'est moins lourd qu'un array of 156 TBitmap ....

Lors du deroulement du jeu, quand on pioche une carte dans le deck (ie depiler un element du tableaux) on obtient un ID et on affiche a l'ecran le bitmap contenu dans le tableau de TBitmap, a cet ID.

De plus, s'il s'agit d'un jeu de cartes traditionnel, on ne sait pas si Meastalavista veut pouvoir utiliser la DLL cards.dll signalée par Fabrice ROUXEL

J'opterais pour un jeu de bitmap personnels .... ca semble reinventer la roue mais c'ets plus modulaire. On peut a loisir personaliser et/ou mettre a jour le jeu.
Apres tout ... 54 images ce n'ets pas tres difficile a creer

Par contre, Opter dans un premier temps pour l'utilisation de fichier bitmaps generés automatiquement a l'aide de la dll cards me semble un bon compromis.
Je ne connait pas cette dll mais j'imagine qu'un TRessourceStream suivi de SaveToFile devrais faire l'affaire ....

[Dirk-Pitt]

... ou un outil du style de Resource Hacker.

[Clorish]

... ou un outil du style de Resource Hacker.

Tout a fait .. mais jusqu'a present j'ai toujours plus vite fait de chopper les ressources via TRessourceStream que de trouver et installer ce genres de logiciels

[Dirk-Pitt]

Pour info http://www.angusj.com/resourcehacker/

[Gilbert Geyer]

A Clorish :

Ca n'ets pas la premiere fois et je doute que ca soit la derniere

... la preuve, on continue.

... mais des qu'un debat pointe le bout du nez .. je ne peut m'empecher de me jeter dedans

... moi c'est pareil, mais pour certains débats je ne m'y jette que pour lire.

De plus, n'ayant pas toutes les donnéees en main, il est pas toujours evident de faire des reponses precises

... si l'énoncé du problème est incomplet ou si les données disponibles pour le résoudre sont incomplètes la réponse la plus précise c'est des questions, on va quand-même pas se mettre à deviner dans les non-dits. Faut qu'ils causent clairement ceux qui posent des problèmes.

Enfin, allez au dela de ce qu iest demander permet des fois de donner quelques idees et voir les choses d'un autre point de vue.
LEs questions posées sont souvent issue de problemes de conception ..

... tout à fait d'accord.

Oui, depuis le debut le preconise un simple array af TBitmap plutot que la lourdeur des TImageList.

... disons que l'on aurait pu retenir un TImageList juste pour l'utiliser comme un conteneur d'images sans y utiliser le reste mais comme pour le reste un array of BitMap suffit j'y vois aucun inconvénient.

Je trouverais interessant de charger en memoire dans un array of TBitmap la liste des images et de manipuler les decks via des array of Integer ... Le Rami.

... pigé avec l'exemple du Rami.

DLL cards.dll ... J'opterais pour un jeu de bitmap personnels .... ca semble reinventer la roue mais c'ets plus modulaire. On peut a loisir personaliser et/ou mettre a jour le jeu. Apres tout ... 54 images ce n'ets pas tres difficile a creer

... ma préférence irait également vers l'utilisation d'un jeu de Bmp personnels, mais au lieu de les créer je partirais sur une base de copies d'écran plutôt que de tout dessiner moi-même.

Par contre, Opter dans un premier temps pour l'utilisation de fichier bitmaps generés automatiquement a l'aide de la dll cards me semble un bon compromis.
Je ne connait pas cette dll mais j'imagine qu'un TRessourceStream suivi de SaveToFile devrais faire l'affaire ....

... sur le site delphipage dont Fabrice ROUXEL a donné le lien il se trouve justement un bout de code où les Stream's sont utilisés ... ça devrait permettre, une fois qu'on a les Bmp en mémoire de les sauver sur disque pour les personnaliser. Comme en plus les cartes de la Dll ne sont rien d'autre que celles utilisées par le jeu du "Solitaire" de simples copies d'écran permettraient de les récupérer pour les personnaliser.

A+

[Clorish]

... sur le site delphipage dont Fabrice ROUXEL a donné le lien il se trouve justement un bout de code où les Stream's sont utilisés ... ça devrait permettre, une fois qu'on a les Bmp en mémoire de les sauver sur disque pour les personnaliser. Comme en plus les cartes de la Dll ne sont rien d'autre que celles utilisées par le jeu du "Solitaire" de simples copies d'écran permettraient de les récupérer pour les personnaliser.

Faire 54 copie d'ecran + sauvegarde la ou une simple boucle for suffit

"Soit Faignant ! Soit Faignant ! Et tu vivras longtemps !" :p