Discussion :

[yetimothee]

Bonjour,
Voilà, depuis que je programme des petits jeux 2d, simples mais ça m'amuse avec Allegro principalement, je trouve cela embêtant d'assigner les images au Bitmap* comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
BITMAP* joueur[10] ;
 
joueur[0] = load_bitmap("image1.bmp", NULL);
joueur[1] = load_bitmap("image2.bmp", NULL);
//Et ainsi de suite

J'avais pensé à allouer dynamiquement un tableau et à conserver le noms et nombres d'images dans un fichier texte, et ainsi allouer automatiquement les images aux Bitmap*.

Une bonne idée ?

Merci !

[shenron666]

je pense que c'est une bonne idée
et tu peux te créer une structure qui te servira d'interface mémoire pour les images chargées
quelques fonctions pour la gérer et c'est partit

[Mat.M]

J'avais pensé à allouer dynamiquement un tableau et à conserver le noms et nombres d'images dans un fichier texte, et ainsi allouer automatiquement les images aux Bitmap*.

Merci !

je te conseille d'assimiler plus de concepts du C ou C++ avant d'aller plus loin dans la programmation d'un jeu.
Pour un tableau dynamique en C il faut prendre des listes chainées, sinon en C++ tu as std::vector , std::list...
Donc en C++ cela donnera simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
std::vector<BITMAP *> bitmaps_joueurs;
 
BITMAP* image ;
char nom_fichier[256];
for(int i=0;i<nombre_images;i++)
{
sprintf(nom_fichier,"image%i.bmp",i);
image= load_bitmap(nom_fichier, NULL);
bitmaps_joueurs.push_back(image);
}
//...

[yetimothee]

Hm, je ne projete pas de coder en C++, mais exclusivement en C (pour la beauté de la chose :p).

[Mat.M]

Hm, je ne projete pas de coder en C++, mais exclusivement en C (pour la beauté de la chose :p).

D'accord c'est vrai pourquoi faire simple quand on peut faire compliqué.
Alors si ma méthode est mauvaise comment vas-tu procéder ? Je suis dans l'attente d'une bonne explication

[yetimothee]

Eh ! J'ai pas dis que ta méthode étais mauvaise, mais c'est vrai que je crois que je vais retourner à ce bon vieux C++ (je suis compliqué).

Et j'avais pas vraiment pris le temps de regarder ta méthode, étant donné que c'est du C++, mais ça faciliterais largement le travail

Bon, ben merci à toi, je verrais ce que je peux faire

[Invité]

Hep... depuis quand un tableau dynamique, c'est une liste chainée ?

Il suffit de connaitre à l'avance le nombre d'images, et de faire un petit malloc de la bonne taille... ou alors d'utiliser realloc à chaque nouvelle image, c'est pas grave, on est dans une phase de chargement, pas de problemes de perfs (dans une certaine limite, hein, mais le tableau il a l'air d'etre de taille 10)

Si tu as un fichier simple, qui contient la liste des fichiers à charger, avec un fichier par ligne, tu le parcours une premiere fois pour savoir la taille, et une 2eme pour lire les noms des fichiers... c'est pas si complexe.

[Emmanuel Deloget]

Hep... depuis quand un tableau dynamique, c'est une liste chainée ?

La prose originale dit: "Pour un tableau dynamique en C il faut prendre des listes chainées". Ce qui n'est pas vraiment faux, étant donné que l'ensemble sera plus simple à gérer. Au final - de toute façon, on doit voir le "tableau dynamique" comme un conteneur abstrait.

(Ceci dit, il est plus simple de faire une liste chainée qui est implémentée à partir d'un tableau qu'un tableau implémenté à partir d'une liste chainée...)

Il suffit de connaitre à l'avance le nombre d'images, et de faire un petit malloc de la bonne taille... ou alors d'utiliser realloc à chaque nouvelle image, c'est pas grave, on est dans une phase de chargement, pas de problemes de perfs (dans une certaine limite, hein, mais le tableau il a l'air d'etre de taille 10)

Je m'insurge!
Le temps de chargement d'un niveau n'a pas besoin d'être extrêmement long. Plus on passe de temps à charger les données, plus on sort du jeu, et plus on frustre l'utilisateur.

Certes, nous sommes là dans des quantités négligeables.

Mais ce que tu dit est quand même faux: les temps de chargement posent des problèmes de performances, car le joueur a une vision directe de ceux ci (étant donné que rien ne se passe). D'où la présence de barres de progression d'ailleurs (pour donner l'illusion qu'il se passe quand même quelque chose).

Si tu as un fichier simple, qui contient la liste des fichiers à charger, avec un fichier par ligne, tu le parcours une premiere fois pour savoir la taille, et une 2eme pour lire les noms des fichiers... c'est pas si complexe.

Oui, mais en même temps, parcourir le fichier une seule fois et ajouter les lignes dans une liste n'est pas d'une complexité monstre non plus.

Moins de code == moins de bugs

[yetimothee]

J'aime voir avancé ce type de débat, c'est assez intéressant je doit dire

Au fait, un tableau pour une image devra contenir un truc comme 150 images, je pense, donc ça devrait-être assez long en chargement, non ?
(et une barre de progression, ça doit pas être le plus dure à faire :p).

[Invité]

La prose originale dit: "Pour un tableau dynamique en C il faut prendre des listes chainées". Ce qui n'est pas vraiment faux, étant donné que l'ensemble sera plus simple à gérer. Au final - de toute façon, on doit voir le "tableau dynamique" comme un conteneur abstrait.

(Ceci dit, il est plus simple de faire une liste chainée qui est implémentée à partir d'un tableau qu'un tableau implémenté à partir d'une liste chainée...)

En soit, je suis d'accord, c'est pas vraiment le probleme...
c'etait juste une question de simplicité, au niveau des concepts...

Parce arriver devant quelqu'un qui explique faire du C, et lui dire, "Tu sais, le C++, c'est plus simple t'as des std::vector tu vas voir tu vas gagner du temps", même si c'est vrai ou quoi que ce soit, je ne suis pas sur que ça soit une grande aide.

Je m'insurge!
Le temps de chargement d'un niveau n'a pas besoin d'être extrêmement long. Plus on passe de temps à charger les données, plus on sort du jeu, et plus on frustre l'utilisateur.

Certes, nous sommes là dans des quantités négligeables.

Mais ce que tu dit est quand même faux: les temps de chargement posent des problèmes de performances, car le joueur a une vision directe de ceux ci (étant donné que rien ne se passe). D'où la présence de barres de progression d'ailleurs (pour donner l'illusion qu'il se passe quand même quelque chose).

Encore une fois, je suis d'accord, les temps de chargements doivent être les plus courts possibles, mais est-ce que simplement avoir une méthode qui marche pour commencer ne suffirai pas ?

Il me semble que ce n'est pas la partie la plus difficile à optimiser par la suite, si les temps de chargements deviennent trop long.

Et d'un autre coté, la seule chose que le monsieur cherche pour l'instant, c'est une idée pour le faire, il verra bien apres, si il a besoin de quelque chose qui marche plus vite.

Moins de code == moins de bugs

Oui, comme toujours.

[Mat.M]

Hep... depuis quand un tableau dynamique, c'est une liste chainée ?

Il suffit de connaitre à l'avance le nombre d'images, et de faire un petit malloc de la bonne taille... ou alors d'utiliser realloc à chaque nouvelle image, .

Tu as parfaitement raison on peut allouer et désallouer avec malloc,realloc et free.
Ceci dit avec un conteneur comme cités précedemment le code source est plus homogène..
et puis je ne sais pas si les exceptions sont bien gérées avec des malloc realloc..
Et puis à chaque fois que tu veuilles obtenir la taille de ton tableau et le dernier élément tu est obligé d'utiliser sizeof
Tandis que avec un conteneur il suffit d'appeler size()

[shenron666]

et puis je ne sais pas si les exceptions sont bien gérées avec des malloc realloc..

il n'y a pas d'exceptions en C, try throw catch sont des mots clef du c++

sinon la liste chainée est une solution à un problème dont on ne connait pas la taille (ici le nombre d'images)
dans son cas, il est possible de connaitre le nombre d'image en parcourant une première fois le fichier
mais utiliser une liste chainée évitera de lire 2 fois le fichier surtout que les accès disque sont au moins 1000 fois plus lents que les accès mémoire

[yetimothee]

Ou alors je met tout simplement le nombre d'images au début du fichier (1ère ligne) ?

[Emmanuel Deloget]

Ou alors je met tout simplement le nombre d'images au début du fichier (1ère ligne) ?

aussi oui

[Mat.M]

il n'y a pas d'exceptions en C, try throw catch sont des mots clef du c++

honte sur moi c'est vrai ! Je vais être banni de ce forum
Ceci dit en win32 c'est peut-être gérable avec des API équivalente comme _Try() je crois

[Emmanuel Deloget]

honte sur moi c'est vrai ! Je vais être banni de ce forum
Ceci dit en win32 c'est peut-être gérable avec des API équivalente comme _Try() je crois

Windows implémente ce que les concepteurs du système on appelé les exceptions structurées, qui sont accessibles via quelques mots clefs propriétaires dans les programmes en C écrits avec Visual C++. On y accède en utilisant __try, __except et __finally.

Au final, ça permet aux programmeurs de gérer les exceptions remontées par le système mais qui ne sont pas catchées par le système de gestion des exceptions C++ (comme par exemple notre délicieuse exception "access violation", ou la division entière par 0).

Ceci dit, malloc() ne fait rien de tout ça. La fonction se contente de renvoyer NULL si elle n'arrive pas à allouer la mémoire.