Discussion :

[ZouBi]

Bonjour,
Depuis un ou deux mois, je débute en C.
J'ai tout de suite décider de faire un jeu 2D exploitant le SDL, FMOD...
Je sais pas trop où j'veux en venir, mais pour l'instant l'univers est tiré de Mario.
Ce projet n'est qu'à titre personnel.
Enfin voilà, j'en suis arrivé à un stade, qui me semble sans bug, mais le jeu n'a toujours aucun intérêt.

Ce que j'aimerai, c'est que si certains d'entre vous ont le temps et le courage, c'est d'examiner le code, ainsi que le jeu, et de me dire si ma méthode de programmation est bonne...
Je n'ai suivi aucun tutorial, j'ne fesais que chercher des informations sur certaines fonctions ou autres sur des sites, ou en postant sur ce forum, quand j'en avais besoin.

Donc en fait, j'voulais apprendre par des professionels, connaisseurs ou autres, si je partais sur un bon chemin en codant de cette manière...
Si vous avez des remarques, conseils, ou comment puis je faire pour optimer le code actuel...

J'vous laisse le ZIP en pièce jointe contenant les sources, et le jeu...

Merci d'avance

EDIT :

Derniere Version
http://www.mediafire.com/?oxgydsgnp9s

C : Sauter, V : Courir

[dev_tours]

bonjour

selon moi je ferai une decoupe plus elementaire de tes fonctions... en effet je vois des fonctions qui font une page.. voire plus... personnellement je prefere faire plusieurs petites fonctions plus elementaires, des fois meme necessaires qu a la fonction de depart ( c est a dire que je la met pas dans le header ) car je trouve que c est plus lisible et plus facile a manipuler.

une autre chose que je trouve dommageable sont les imbrication un peu excessives... au dessus de 3-4 tests je preveligie un switch, plus lisible.

ce ne sont cependant que des observations d amateur

cordialement

ps : pourquoi pas des parametres par defaut?

void initPerso(Perso* Personnage, int x, int y, int w, int h, int vitesseLMax, int vitesseHMax, char* fichier, int nbSprites, int fixe, int deplacement, int saut, int retourne, int frappeMin, int frappeMax, int r, int v, int b);

[ZouBi]

Tout d'abord merci pour tes conseils !

Donc je ne prends pas de valeur par défaut pour rendre le code plus "portable".
Genre je veux l'utiliser dans un autre programme utilisant un autre personnage se décomposant pas de la meme manière que celui ci, il n'y aura seulement que les arguments de la fonction à changer au lieu du programme.

bonjour
ce ne sont cependant que des observations d amateurs

Désolé, je ne vous avais pas cité, mais j'attends les critiques de tout l'monde, amateur ou professionels !
C'est pas parce qu'on est professionel qu'on est forcément meilleur.

[Kujara]

C'est pas parce qu'on est professionel qu'on est forcément meilleur.

Pas obligatoirement meilleur, même si c'est souvent le cas.

En revanche, un pro est presque toujours plus stricte point de vue qualité du code ^^.

Bref.

Mon avis perso, apres 3 minutes passé sur ton code :

1) arg, c'est en C
2) pour du taff d'amateur, j'ai vu pire.

Avant de rentrer dans les details sur comment ameliorer ton code, quelques question :

Pourquoi tu programme ? ( tu programme pour toi, pour t'amuser ? pour te preparer a passer programmeur pro ? pas de raison ?)

Pourquoi un jeu ?

Pourquoi en C ?

Quel avenir pour ton petit jeu ?

[ZouBi]

Avant de rentrer dans les details sur comment ameliorer ton code, quelques question :

Pourquoi tu programme ? ( tu programme pour toi, pour t'amuser ? pour te preparer a passer programmeur pro ? pas de raison ?)

Pourquoi un jeu ?

Pourquoi en C ?

Quel avenir pour ton petit jeu ?

Pour le moment, je programme pour m'amuser, mais je suis aussi en DUT Informatique, mais j'ai pris de l'avance en C ( on est à peine en train d'étudier les structure ).
Donc en même temps, c'est aussi pour me préparer.

Pourquoi un jeu, parce que les jeux vidéo sont ma passion depuis petit, et si possible j'aimerai en faire mon métier, mais ceci doit etre dur...

Je programme en C, parce que je ne connais pas encore le C++, et je ne voulais pas m'y mettre tant que je me sentirai pas à l'aise avec le C.
Mais maintenant, ce serait mieux d'y passer, car ca doit alléger le code source je pense, ou le rendre plus lisible, moins compliqué... non?

Quel avenir? Aucun. C'est à titre personnel, histoire de tester mes compétences. Je ne sais absolument pas où je veux en venir avec, aucun but.
Mais pour la suite, je vais essayer à rajouter des méchants, et attaquer le scrolling sur la map.

[Kujara]

mais ceci doit etre dur...

Très.

Mais bon, c'est hyper fun, aussi, donc ça compense.

Je programme en C, parce que je ne connais pas encore le C++, et je ne voulais pas m'y mettre tant que je me sentirai pas à l'aise avec le C.

Le C c'est bien pour apprendre les bases, mais ça sert pas a grand chose de s'y eterniser si tu ne compte pas vraiment l'utiliser plus tard.

Mais maintenant, ce serait mieux d'y passer, car ca doit alléger le code source je pense, ou le rendre plus lisible, moins compliqué... non?

Plus compact, plus lisible, plus modulable, plus general.
Il y a un grand débat qui traine sur le forum, quelque part, parlant de C vs C++.

Ce debat ne s'applique pas dans le domaine du jeu video. La quasi totalité des jeux profesionels commerciaux utilisent c++.

Quel avenir? Aucun. C'est à titre personnel, histoire de tester mes compétences. Je ne sais absolument pas où je veux en venir avec, aucun but.
Mais pour la suite, je vais essayer à rajouter des méchants, et attaquer le scrolling sur la map.

Sinon tu peux aussi profiter du c++ pour en faire un pseudo moteur pour jeux du même genre, ça t'apprendra a penser modulaire et generique, et donc a structurer correctement ton code.

ps : Si tu as des questions plus pointues sur le c/c++, va faire un tour coté forum C et c++ de devellopez.com, ou demande moi par MP ^^.

[ZouBi]

Bonjour,
Je fais suite à ce sujet, car j'ai donc appris entre temps le C++.
Et donc décider de reprendre ce programme pour le remettre en forme version C++...

J'ai donc réfléchi, penser, et commencer le code, mais j'ai compris au bout d'un moment que je m'étais gouré dans ma gestion des classes...
Donc je m'explique...
J'ai ma classe Perso, là tout va bien normal...
Là où je coince, c'est pour la gestion des sprites, élements du décor, et les niveaux...

J'ai donc créé une classe Sprite, qui contient donc un nom, la taille du sprite, et un type SDL_Image que j'aurai pris soin de charger avec le constructeur avec Img_Load()...

Ensuite, une classe Element, qui contient les coordonnées de celui-ci, et un pointeur vers un objet Sprite qui correspond donc à son image en gros.

Plusieurs Elements peuvent charger sur un meme Sprite, ca evite de devoir charger plusieurs fois la meme image, c'est plus optimisé.

Bref, mon soucis, est que je ne vois pas du tout comment structurer ma classe Level, qui contiendra les informations sur tous les Elements qui la compose...

Donc quand j'y ai reflechi, j'ai tout de suite pensé que ma gestion Element-Sprite, etait mal faite...

Pouviez vous m'aider?

J'aimerai bien être en contact permanent avec quelqu'un via MSN...
Qui pourrait m'aider, non à ecrire le code, mais à bien me faire comprendre comment gerer les differents modules et tout, et repondre à mes questions...

[moechofe]

Bref, mon soucis, est que je ne vois pas du tout comment structurer ma classe Level [...]

Elle contiendra certainement la liste des blocs qui constituent le niveau, et peut être leurs propriétés : mur, piège, pièce, tortue... (Ce qui correspond a ta variable Bloc dans ton code source)

Avec peut être aussi des évenements pour faire réapparaitre les montres, ou pour faire bouger les éléments du décor.

[ZouBi]

ok, elle m'parait bien ton idée.

Mais comment j'pourrai enregistrer un level dans un fichier?
Car avant, j'utilisais l'écriture binaire... Mais ici, ca fonctionnerait pas car, j'utilise les pointeurs, donc si j'enregistre maintenant un objet de type Element, en le rechargeant, le pointeur sur Sprite, ne sera plus valide. C'est là que j'bloque aussi.
Ensuite dans ta classe level... Tous les élements, je les stocke dans un tableau de type Element* ?

[moechofe]

Mais comment j'pourrai enregistrer un level dans un fichier?

En serialisant par exemple:
http://en.wikipedia.org/wiki/Serialization
http://fr.wikipedia.org/wiki/Sérialisation

Tous les élements, je les stocke dans un tableau de type Element* ?

Pas forcément, tu peux les séparer. Imagine que tu souhaites avoir deux plans : un plan avec les blocs infranchissables, et un plan avec des éléments du décor qui passent devant le joueur.

Il y a deux grandes façons de faire :

Soit, tu utilises un tableau pour stocker les éléments. La position dans le tableau détermine les coordonnées de l'objet :
array( x, y ) = mon élément

Soit, tu utilises une liste incrémentale ou tu stockes tes structures :
list( i ) = struct( x, y, mon élément)

Dans le premier cas ; c'est bien si tu as beaucoup d'éléments à stocker (un par couple( x,y ) Le cas le plus courant. Mais ce n'est pas très pratique si tu souhaites avoir plusieurs éléments en même endroit.

Dans le deuxième cas ; c'est bien si tu n'as pas beaucoup d'éléments à stocker (un boss, un élément particulier qui se déplace et qui n'a pas de position fixe dans le niveau). Mais il est souvent nécessaire de parcourir toute la liste, notamment pour trouver un élément particulier. Avantage, tu peux avoir plusieurs objets au même coordonnée.

Tu peux très bien faire les deux, et c'est surement ce que tu fait déjà :
Le personnage est tout seul, mais si c'est un jeu multijoueur, tu aurais surement une liste avec des pointeurs vers plusieurs objets "joueur".

Je sais pas si c'est très clair

[ZouBi]

En serializant par exemple:


Il y a deux grandes façons de faire :

Soit, tu utilises un tableau pour stocker les éléments. La position dans le tableau détermine les coordonnées de l'objet :
array( x, y ) = mon élément

Soit, tu utilises une liste incrémentale ou tu stockes tes structures :
list( i ) = struct( x, y, mon élément)

C'est clair.
La première méthode est bien pour les petits jeux, mais là, avec une grande map, ca va faire lourd, le tableaux...
Ensuite, en second choix, tu veux que j'utilise une liste chainée...
Trop compliqué, doit y avoir plus simple...

Mais est ce que ma méthode de liaison Sprite <-> Element, est bonne?
Par la suite, pour les tortues et tout, je compte faire une autre classe heritant de Element pour Tortue... et pareil pour les autres types...

Ensuite, concernant les objets franchissable ou pas, ca sera un attribut booleen dans Element qui nous l'informera...

Bon j'vais essayer de mieux y reflechir, surtout sur la gestion du level...

Merci pour ton lien, j'vais y jeter un coup d'oeuil.

[moechofe]

C'est clair.
La première méthode est bien pour les petits jeux, mais là, avec une grande map, ca va faire lourd, le tableaux...

Pas forcement, ça dépend du nombre de valeur possible que tu as à coder pour chaque élément : un entier ?, un octet ?, ou pire une valeur comprise entre 0 et 2.
0 n'étant rien, 1 étant un bloc de brique, 2 étant un bloc d'herbe. Dans ce cas, tu peux encoder tes données en les compressant à la manière du GIF(LZW) : en binaire donc.

0 : rien
10 : brique
11 : herbe

la chaîne : 110111100101011 (au pif)
correspond donc à :
herbe, rien, herbe, herbe, rien, rien, brique, brique, herbe

Bien sur, ces données sont destinées à être stockées dans un fichier. Pour l'affichage, tu décodes dans un tableau.

Autre chose intéressante, si ton niveau est uniquement à scrolling horizontale, tu peux encoder colonne pas colonne et non pas ligne par ligne comme il paraît logique de le faire. Ainsi, tu peux être en mesure de décoder les données en provenance de ton fichier au fur et à mesure que le personnage avance. Tu économiseras de la mémoire.

[ZouBi]

Pas forcement, ça dépend du nombre de valeur possible que tu as à coder pour chaque élément : un entier ?, un octet ?, ou pire une valeur comprise entre 0 et 2.
0 n'étant rien, 1 étant un bloc de brique, 2 étant un bloc d'herbe. Dans ce cas

0 : rien
10 : brique
11 : herbe

la chaîne : 110111100101011 (au pif)
correspond donc à :
herbe, rien, herbe, herbe, rien, rien, brique, brique, herbe

Donc ce que je pourrai faire, c'est déjà fusionné Sprite & Element...
dans une meme classe qui contiendrait SDL_Image, w, h, le numero d'identification ( 2 pour la brique... ).

Derniere chose, dans le level, ton tableau à 2 dimensions (x,y).
Les coordonnées sont à titre relatif? ( 3 = 3 pixels, ou 3 = 3*TAILLEX)
où TAILLE correspondrait à la taille d'un sprite... Je sais pas si j'arrive à me faire comprendre.

Car si dans le premier choix, à titre relatif, là, le tableau serait vraiment enorme ( une map de 500 pixels de haut, et 10000 de large... )
Ca ferait un tableau de 500*10000 de type char, contenant chacun le numero d'identification de l'element ( 1 pour brique, 54 pour poisson... ).

Serait-ce une bonne méthode?

[moechofe]

Donc ce que je pourrai faire, c'est déjà fusionné Sprite & Element...

Si j'ai bien compris : les élements correspondent aux graphiques comme les briques qui te permettent de déssiner le niveau.

Les sprites, eux sont censés pouvoir se déplacer ou posséder une animation.

Tu peux donc imaginer que la classe sprite est une fille de la classe element.
Et tu devra les traiter différents à l'affichage.

[...] le tableau serait vraiment enorme [..]

Alors oui, bien sur, les index du tableau (x,y) correspondent à une position sur une grille. On appel ça des Tiles (http://en.wikipedia.org/wiki/Tile-based_game)

Si tes graphiques ont une dimension de 32x32 pixels, ta grille aura la meme dimension. Un élement qui est sur le 64eme pixel, il aura la position 2 sur la grille.

Ca reste une vision très simple, car en réalité il est tout a fait possible d'avoir des élements graphiques et des sprites plus grand que la grille.

[moechofe]

J'ai remarqué que dans ton éditeur, il est possible de placer les briques au pixels près. C'est donc incompatible avec le système de tiles.

Si tu souhaites vraiment pouvoir placer les élements graphiques au pixels près, et c'est tout à fait possible (des jeux comme lemmings ou soldat fonctionne de cette manière) :
Tu dessines ton niveau avec les élements graphiques.
Puis tu compiles le résultat avec quelques chose d'analysable par ton programme pour gérer les collisions.

Dans le cas de lemmings, il faut effectivement possèder un grand tableau dans lequel tu stockes les pixels. Il t'indiquerons si le pixel est franchissable ou non.

Et encore une fois, il existe des astuces pour alléger le bordel.
Si ton niveau possède des scrollings, tu décodes tes informations au fur à a mesure que le personnage se déplaces. Imaginons que ton écran affiche 640x512 pixels (au pif), la taille rélle du tableau devrait etre de 640+640+64 x 512+512+64. Cela permettra au scrolling d'etre fluide, pendant que le moteur décodes les informations.

Autre technique intéressante, en travaillant en binaire : 0 = franchissable, 1 = non franchissable.
En stockant toutes les informations dans une liste, et avec un algorithme adapté, il est très facile de connaitre l'état franchissable d'un pixel.

[stilobique]

Salut

Je suis pas programmeur donc perso je pourrait pas t'aider, mais en tout cas c'est plutôt pas mal comme 1er jeu en C, niveau code je peut pas dire mais c'est déjà fluide et bien gérer, par contre utiliser une image pour le menu c'est pas géniale je trouve ; dans mes projets généralement j'opte pour une solution qui permet de traduire facilement le soft (enfin je le dit à ma team ).

Voila sinon vivement le jeu en C++ avec des combats

[moechofe]

C'est vrai, c'est un très bon premier projet. C'est la raison pour laquelle je réponds à tes questions.

Et si vraiment tu es intéressé par la programmation, je t'invite à explorer les autres langages assez rapidement. Tu te rendras compte que les techniques de programmation sont plus importantes que les lignes de codes elles-mêmes.

[ZouBi]

Si j'ai bien compris : les élements correspondent aux graphiques comme les briques qui te permettent de déssiner le niveau.

Les sprites, eux sont censés pouvoir se déplacer ou posséder une animation.

Tu peux donc imaginer que la classe sprite est une fille de la classe element.
Et tu devra les traiter différents à l'affichage.

Donc je résume, la classe Sprite contient l'image, et la taille de celui ci...
Genre l'objet Brique, aura comme attribut une SDL_Image le representant donc, pret à être afficher, et sa taille.

Ensuite, pour chaque brique sur la map, correspondra à un Sprite par pointeur, donc ici, pointera sur l'objet Brique instance de Sprite, avec en plus ses coordonnées, afin de ne pas avoir à charger l'image de la brique en memoire, pour chaque brique, ca prendrait trop de ressources pour rien. Voilà.
Donc ce que j'avais pensé, c'est ne pas avoir de class Element, mais que tous les coordonnées de toutes les briques ou autres, soient intégrées à la classe Level, qui fera directement le lien avec le sprite Brique. Mais voilà le problème, comment stocker toutes les coordonnées?

J'ai remarqué que dans ton éditeur, il est possible de placer les briques au pixels près. C'est donc incompatible avec le système de tiles.

En effet, et prenons par exemple une tortue qui se deplace...
Je ne vais pas la faire déplacer d'un tile à chaque pas, il me faut donc obligatoirement traiter avec des coordonnées en pixels.

Et encore une fois, il existe des astuces pour alléger le bordel.
Si ton niveau possède des scrollings, tu décodes tes informations au fur à a mesure que le personnage se déplaces. Imaginons que ton écran affiche 640x512 pixels (au pif), la taille rélle du tableau devrait etre de 640+640+64 x 512+512+64. Cela permettra au scrolling d'etre fluide, pendant que le moteur décodes les informations.

Autre technique intéressante, en travaillant en binaire : 0 = franchissable, 1 = non franchissable.
En stockant toutes les informations dans une liste, et avec un algorithme adapté, il est très facile de connaitre l'état franchissable d'un pixel.

Le Scrolling, je m'en occuperai plus tard, tout d'abord j'aimerai en arriver au meme point que le programme en C, mais en C++ et avoir déjà un bon moteur.
Ensuite concernant le "franchissable ou pas", ca sera indiqué dans Element je pense, car il y a aussi le "semi-franchissable" ( on peut passer à traver par en dessous, mais pas par au-dessus )

Salut

Je suis pas programmeur donc perso je pourrait pas t'aider, mais en tout cas c'est plutôt pas mal comme 1er jeu en C, niveau code je peut pas dire mais c'est déjà fluide et bien gérer, par contre utiliser une image pour le menu c'est pas géniale je trouve ; dans mes projets généralement j'opte pour une solution qui permet de traduire facilement le soft (enfin je le dit à ma team ).

Voila sinon vivement le jeu en C++ avec des combats

lol, merci beaucoup, ca encourage beaucoup.
Mais justement, c'etait pas vraiment fluide, car en fait, la méthode que j'utilisais, c'est que pour chaque brique, je chargeais l'image dans la memoire...
Donc quand on editait le niveau et qu'on mettait des briques de partout, ca commencait à laguer.

C'est vrai, c'est un très bon premier projet. C'est la raison pour laquelle je réponds à tes questions.

Et si vraiment tu es intéressé par la programmation, je t'invite à explorer les autres langages assez rapidement. Tu te rendras compte que les techniques de programmation sont plus importantes que les lignes de codes elles-mêmes.

Je suis en DUT Info, et justement, on est en train d'apprendre la theorie de la POO. On voit aussi d'autres langages, mais cet approfondissement envers le C++ et les jeux vidéo, ce n'est que par occupation, et passion ( en effet, on travaille que sur des applications consoles... )


Donc pour en revenir à mon point actuel...
Je suis bloqué pour gérer le level et les differents elements.

Donc voici mon idée...
Je garde cette liaison entre Sprite, qui contiendra l'image ou l'animation, et Element qui contiendra les coordonnées, et informations sur celui ci ( franchissable... ).
Jusqu'à maintenant, la liaison entre Sprite et Element se fesait par pointeur, mais je pense que les codes numeriques seraient plus appropriés ( 1 pour brique... ), donc ca m'a fait penser à un Enum, qui contiendra tous les elements du jeu...

Ce qui aurait été plus simple, c'est de créer et charger tous les sprites dans un tableau... où Sprites[BRIQUE] pointerait lui sur le sprite brique.
et dans la classe Element, on aurait comme attribut :

Code :

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

int type = BRIQUE;

et pour l'afficher :

Code :

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

ecran::affiche(Sprites[BRIQUE], m_x, m_y);

( le tableau Sprites[] serait donc une variable globale. )

Au fait, quand on crée une classe, avec des fonctions static comme ici ecran::affiche(), on peut l'appeler de n'importe où dans le programme, ca ne pose pas de problème?

Bon maintenant, se pose la question du Level...
Je suis en train d'y reflechir, comment stocker tous les élements qui la constituent, ainsi que leur coordonnées...
Bon la classe contiendrait comme attribut un tableau de pointeurs sur Element.
Mais ensuite comment sauvegarder un level dans un fichier qui contiendrait donc les elements et leur position, et donc qu'on pourrait retranscrire dans le programme en lisant le fichier...

[moechofe]

Donc je résume, la classe Sprite contient l'image, et la taille de celui ci...

Ne confonds pas spirite et élément graphique :
Les sprites sont mario, les tortues, les poissons : il possède des coordonnées, des vitesses de déplacement, des états morts, vivants ou en vol, des pointeurs vers les étapes graphiques de l'animation (des SDL_Image), plus le numéro de l'image en train d'être affichée.

Les graphiques contiennent beaucoup moins d'informations :
Un pointeur vers un SDL_Image, et un type : bloquant, franchissable, franchissable par dessous, etc.

Genre l'objet Brique, aura comme attribut une SDL_Image le representant donc, pret à être afficher, et sa taille.

Vérifie si SDL_Image ne contient pas déjà la taille.

En effet, et prenons par exemple une tortue qui se deplace...
Je ne vais pas la faire déplacer d'un tile à chaque pas, il me faut donc obligatoirement traiter avec des coordonnées en pixels.

Si tu possède la position en pixel, tu possède aussi la position en Tiles, il suffit de diviser par la taille de la grille.

[...] mais je pense que les codes numeriques seraient plus appropriés ( 1 pour brique... ), donc ca m'a fait penser à un Enum, qui contiendra tous les elements du jeu...

Exactement !

Au fait, quand on crée une classe, avec des fonctions static comme ici ecran::affiche(), on peut l'appeler de n'importe où dans le programme, ca ne pose pas de problème?

Ça dépend de sa portée, si la fonction est déclarée en public et que l'inclusion l'est aussi, alors la réponse est oui.

Bon maintenant, se pose la question du Level...
Je suis en train d'y reflechir, comment stocker tous les élements qui la constituent, ainsi que leur coordonnées...

Plusieurs solution de codage :
Un fichier texte :

Code :

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

1
2
3
4
5
6
7
8
level 1
"Mon premier niveau" 1321x120
[elements]
12x61 brique bloquante
42x47 brique franchissable_dessous
12x128 herbe
[monstres]
30x37 tortue

Ou quelque chose de plus élaboré, mais qui n'escessitera un encodeur logiciel :
Un en-tête contenant le type de format de fichier perso
Le nom, la taille du niveau, la durée du jeu, la position de départ
Le nombre d'éléments graphique
Le nombre de bonus (pièce)
Le nombre de monstres
La liste des éléments graphiques
La liste des bonus
La liste des monstres

Les trois nombres (élément graphique, bonus, monstre) te permettront de connaître le nombre de donnée à récupérer dans chaque liste.

[ZouBi]

Ne confonds pas spirite et élément graphique :
Les sprites sont mario, les tortues, les poissons : il possède des coordonnées, des vitesses de déplacement, des états morts, vivants ou en vol, des pointeurs vers les étapes graphiques de l'animation (des SDL_Image), plus le numéro de l'image en train d'être affichée.

Les graphiques contiennent beaucoup moins d'informations :
Un pointeur vers un SDL_Image, et un type : bloquant, franchissable, franchissable par dessous, etc.

Tout d'abord, ce que j'appelais sprite, c'etait juste l'objet contenant le SDL_Image, mais bon c'est confus, va falloir que je trouve un autre nom.

Bon, ce que je vais faire, c'est ne pas gérer ce que tu appelles les sprites, à part le perso, biensur, mais seulement les élements graphiques ( briques... ).

Par la suite donc, je ferai un classe parent Sprite, et ma classe perso actuel heritera de cette classe, et tous les autres classes ( poissons, tortue... ) heriteront de cette classe.

Vérifie si SDL_Image ne contient pas déjà la taille.

En effet, SDL_Image contient dejà la taille, donc ma classe actuel Sprite ne servirait donc à rien.
Je créerai un tableau globale, contenant la liste de tous les SDL_Image dont j'aurai besoin.
Genre :

Code :

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

Images[BRIQUE] = Img_Load("brique.bmp");

Afin qu'elle soit accessible partout dans le code.
C'est une bonne idée? Car je vois toujours marquer qu'il faut éviter ces variables globales, mais je ne vois pas d'autres solutions.

Plusieurs solution de codage :
Un fichier texte :

Code :

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

1
2
3
4
5
6
7
8
level 1
"Mon premier niveau" 1321x120
[elements]
12x61 brique bloquante
42x47 brique franchissable_dessous
12x128 herbe
[monstres]
30x37 tortue

Il va falloir que j'y réfléchisse à cette syntaxe, mais la tienne m'a l'air cool.
De plus, les termes "bloquante" ne sont pas à mettre, puisque cette attribut est connue dans la classe Element.

Bon, par contre, comme on sait jamais combien d'Element il y a dans une map, afin de les stocker dans un tableau, je vais devoir allouer dynamiquement, mais j'ai entendu parler de vecteur qui nous permettrait d'omettre la taille d'un tableau.
Je vais m'y interresser.

Donc pour récapituler
Global:
Tableau SDL_Image* contenant tous les Elements Graphiques.
A chacune des cases correspond un enum
Sprites[BRIQUE] = Img_Load(...);

Classe Element:
Element, contient un type enum ( BRIQUE ) correspondant à son type, et son sprite ...
coordonnées x et y, et statut franchissable ou non.

Classe Level:
Tableau d'Element, généré par un fichier.
Position de depart du personnage.


Donc en fait, t'avais raison, le franchissable ou pas, faut bien l'indiquer dans le fichier texte.
Mais pour bien créer un fichier, ou charger un fichier de ce type, y a t il des fonctions me facilisant la tache?
car avec fgets, et compagnie, ca va etre lourd...