[Source] [OpenGL] Remake en OpenGL du jeux IK+

**BruceBoc** · 11/04/2007, 21h47

Bonjour,

Voici mon tout premier programme réalisé en OpenGL avec le langage C++.

Pour ceux qui connaissent déja ce jeux développé à l'origine sur Amstrad puis sur Amiga, seul le niveau bonus a été programmé.
Il n'y a donc pas de combat entre différents combattants.
Pour les autres qui ne connaissent pas le jeux, le but est de repousser les projectiles le plus longtemps possible afin d'ammasser le maximum de points.
Pour orienter le personnage, il faut utiliser les flêches directionnelles.

J'ai réalisé ce jeux principalement pour m'initier à l'OpenGl, et c'est pourquoi je n'ai pas créé de menu ou de tableau des meilleurs scores.

Pour avoir la version avec le fichier exe et les ressources, voici le lien : http://alexandre.bocquillon.free.fr/...us%20level.zip

Merci de dire ce que vous en pensez, notamment au niveau du code.

**fearyourself** · 12/04/2007, 10h53

Bonjour,

Quelques remarques :

- Je n'ai pas réussi à compiler le code vu que c'est un code SDL pour Windows... Pourquoi ne pas faire un code justement portable si tu utilises la SDL ?

- As-tu une autorisation pour cela au niveau de la licence ou le jeu est-il libre d'accès maintenant ?

- Au niveau du code j'ai aussi des remarques, ces remarques ne sont pas à prendre d'une facon super méchante, je liste simplement ce que je vois être discutable. A savoir que ton code semble fonctionner (puisque malgré les remarques à suivre, je vois que c'est bien pensé et que ca a l'air de tenir la route vu que je ne peux pas le faire tourner...). Il demeure des points à gérer :

1) Aucun test de retour des fonctions SDL, Fmod...
2) Une utilisation abusive de variables globales qui se cachent dans un fichier .h...
3) Manque de protection des .h déclarant les classes. Cela ne coûte pas grand chose de rajouter des #ifndef/#define dans les .h
4) Ceci

Code :

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

1
2
3
4
 
        while(SDL_PollEvent(&event))
 
        switch(event.type)

est carrément dangereux parce que sans les accolades, après une modification de code, ce sera difficile à comprendre pourquoi cela ne fonctionne pas, surtout parce que l'indentation n'est pas bien définie...
5) Utilisation de SDL_framerate mais dans la fonction Menu tu fais un SDL_Delay(100) dans la boucle...
6) Balle en anglais c'est ball

et non bowl
7) Variables public pour la classe CLevel, je ne vois pas l'intérêt par rapport à demander au niveau de gérer le son en interne et pour le background c'est pareil.
8) Variables public pour les autres classes aussi, très mauvaise idée, on est en C++ ici non en C

9) Détail : Si on appelle plusieurs fois loadbackground, on oublie que c'est déjà chargé.
10) Aucune vérification si IMG_Load retourne un pointeur NULL
11) CBowl libére bien la mémoire mais pas CLevel...

Sur ces remarques un peu chiantes, je voulais dire que c'est tout de même un beau travail, le code est commenté, relativement propre et il semble tourner.

Jc

**BruceBoc** · 12/04/2007, 16h35

Je te remercie beaucoup d'avoir prété attention à mon code fearyourself.

Tout d'abord je ne prend absolument pas ces remarques de façon négatives, puisque c'est exactement ce que j'attendais de ce forum, à savoir corriger mes erreurs de jeunesse, étant donné que je suis débuttant en OpenGL mais aussi en C++.

Ensuite pour ce qui est des remarques :

- Je n'ai pas réussi à compiler le code vu que c'est un code SDL pour Windows... Pourquoi ne pas faire un code justement portable si tu utilises la SDL ?

A vrai dire, mon but est de faire un code compatible et c'est pourquoi j'ai choisi OpenGL et SDL. Cependant ne connaissant rien à Linux, je n'ai aucune idée de ce qui est incompatible dans mon code : peut tu m'en dire plus ?

- As-tu une autorisation pour cela au niveau de la licence ou le jeu est-il libre d'accès maintenant ?

Absolument aucune. Je n'ai fais ce jeux que pour m'entrainer et en aucun cas pour concurrencer l'original. C'est pourquoi je ne poste pas ce jeux dans des forums autres qu'en programmation. Et enfin, il n'existe aucune version windows à l'heure actuelle donc je ne pense pas que ça les géne.

1) Aucun test de retour des fonctions SDL, Fmod...

C'est vrai que j'en ai pas pris l'habitude, mais je le ferai systematiquement dans mon prochain projet.

2) Une utilisation abusive de variables globales qui se cachent dans un fichier .h...

Je ne sais pas trop comment faire autrement. Faut-il que j'englobe les classe dans une classe moteur comme dans le tuto "Un pong en OpenGl et SDL" ?

3) Manque de protection des .h déclarant les classes. Cela ne coûte pas grand chose de rajouter des #ifndef/#define dans les .h

Je ne suis pas sur d'avoir saisi cet interet. Est-ce que ça permet juste d'éviter une double définition des variables ?

4) Ceci
Code :

while(SDL_PollEvent(&event)) switch(event.type)

est carrément dangereux parce que sans les accolades, après une modification de code, ce sera difficile à comprendre pourquoi cela ne fonctionne pas, surtout parce que l'indentation n'est pas bien définie...

Effectivement il vaudrait mieux mettre des accolades. J'ai du recopier ce passage d'un mauvais exemple.

5) Utilisation de SDL_framerate mais dans la fonction Menu tu fais un SDL_Delay(100) dans la boucle...

C'est ce que je pensais de mieux à faire étant donné que SDL_Delay(100) apparait dans une boucle ou on attend juste que l'utilisateur appui sur ENTER.
Etant donné que le font d'écran est fixe autant economiser le processeur plutot que de rafraichier 75 fois par seconde un écran fixe.

6) Balle en anglais c'est ball et non bowl

LOL je viens de regarder bowl en français signifie cuvette

7) Variables public pour la classe CLevel, je ne vois pas l'intérêt par rapport à demander au niveau de gérer le son en interne et pour le background c'est pareil.

Si j'ai bien compris tu veux dire qu'il faut que je déclare les 2 variables en private et que j'emploi une fonction pour les charger.

8) Variables public pour les autres classes aussi, très mauvaise idée, on est en C++ ici non en C

Oui, c'est à force de bidouiller et aussi "à l'arrache".

9) Détail : Si on appelle plusieurs fois loadbackground, on oublie que c'est déjà chargé.

Que faut-il faire, un test ?

10) Aucune vérification si IMG_Load retourne un pointeur NULL

Comme la question 1, pas pris l'habitude de vérifier.

11) CBowl libére bien la mémoire mais pas CLevel...

Oui mais vu que CLevel reste actif pendant tout le prog, la mémoire sera libérée à la fermeture de prog, ou je me trompe et dans ce ces la il faut que je le fasse avec les autres classes également ?

Merci encore de cet attention.

**fearyourself** · 12/04/2007, 17h07

Envoyé par BruceBoc

Tout d'abord je ne prend absolument pas ces remarques de façon négatives, puisque c'est exactement ce que j'attendais de ce forum, à savoir corriger mes erreurs de jeunesse, étant donné que je suis débuttant en OpenGL mais aussi en C++.

Ca c'est la bonne attitude. A savoir que je critique beaucoup mais cela ne veut pas dire que mon code ne contient pas de temps en temps des trucs super moches ou des choses dangereuses. Je tente de les limiter c'est tout.

A vrai dire, mon but est de faire un code compatible et c'est pourquoi j'ai choisi OpenGL et SDL. Cependant ne connaissant rien à Linux, je n'ai aucune idée de ce qui est incompatible dans mon code : peut tu m'en dire plus ?

Déjà, le

Code :

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

1
2
 
#include <windows.h>

est mauvais et tes includes :

Code :

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

1
2
 
#include <SDL\SDL.h>

Mets des '/' à la place, cela fonctionnera sur tous les systèmes.

Enfin j'ai vu que tu mettais SDL_Image.h, enlève la majuscule, linux/unix fait attention à la casse.

Code :

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

1
2
 
Absolument aucune. Je n'ai fais ce jeux que pour m'entrainer et en aucun cas pour concurrencer l'original. C'est pourquoi je ne poste pas ce jeux dans des forums autres qu'en programmation. Et enfin, il n'existe aucune version windows à l'heure actuelle donc je ne pense pas que ça les géne.

Je suis d'accord mais cela ne te donne pas le droit de le faire. Tant qu'il n'y a pas de demande qu'on retire ce projet, on peut le laisser mais c'est toujours le risque lorsque tu fais un remake.

Il vaut mieux faire un jeu en prenant des ressources gratuites

Code :

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

1
2
 
C'est vrai que j'en ai pas pris l'habitude, mais je le ferai systematiquement dans mon prochain projet.

Et pourquoi pas dans celui-là ?

Code :

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

1
2
 
Je ne sais pas trop comment faire autrement. Faut-il que j'englobe les classe dans une classe moteur comme dans le tuto "Un pong en OpenGl et SDL" ?

Je trouve que c'est plus propre oui. Tu remarqueras que j'ai une classe moteur mais aussi une classe Jeu. C'est dans la classe Jeu qu'il faut le mettre.

Code :

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

1
2
 
Je ne suis pas sur d'avoir saisi cet interet. Est-ce que ça permet juste d'éviter une double définition des variables ?

Non mais la double définitions des classes en fait. Cela peut poser des problèmes à la compilation.

C'est ce que je pensais de mieux à faire étant donné que SDL_Delay(100) apparait dans une boucle ou on attend juste que l'utilisateur appui sur ENTER.
Etant donné que le font d'écran est fixe autant economiser le processeur plutot que de rafraichier 75 fois par seconde un écran fixe.

Alors baisse juste le framerate à 20 par exemple et tu le rechanges après...

Si j'ai bien compris tu veux dire qu'il faut que je déclare les 2 variables en private et que j'emploi une fonction pour les charger.

Voilà, et de l'extérieur tout est gérer magiquement. Ca ne regarde personne sauf la classe en question quelle variable contient la bonne police/sprite...

Que faut-il faire, un test ?

Le plus propre : mettre un booléen à false dans un constructeur, tester ce booléen pour savoir si le tout est chargé. Si ce n'est pas le cas, charger la texture et mettre le booléen à true...

Comme la question 1, pas pris l'habitude de vérifier.

C'est une mauvaise habitude, mettre le code de vérification réduit énormément le temps de debuggage lorsqu'il y a des problèmes...

Oui mais vu que CLevel reste actif pendant tout le prog, la mémoire sera libérée à la fermeture de prog, ou je me trompe et dans ce ces la il faut que je le fasse avec les autres classes également ?

Toujours mettre le code de libération de mémoire. Si un jour tu veux réutiliser ta classe dans un code où il y en aura 300 qui apparaissent et que tu vires au fur et à mesure, c'est la catastrophe !

Merci encore de cet attention.

Je te conseille de reprendre ton code, faire les modifications pour bien comprendre comment ca marche et, si tu veux, je regarderais à ce moment là ce qu'il faut faire pour le faire compiler sous linux.

Jc

**BruceBoc** · 12/04/2007, 18h28

Ok merci, je vai reprendre le code et faire les modifications que tu m'a suggérées. Je te renverrai une nouvelle version d'ici demain probablement.

**BruceBoc** · 12/04/2007, 21h36

Donc voila, je viens de corriger les erreurs de codage, à savoir :

- les '/'

- jai changé

Code :

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

1
2
3
4
5
6
 
#include <windows.h>
en
#ifdef WIN32
#include <windows.h>
#endif

car sinon visual c++ compile pas

- j'ai enlevé la majuscule de SDL_Image.h

- j'ai rajouté tous les tests

- j'ai rajouté les Ifndef dans les headers

- j'ai supprimé "SDL_Delay(100)"

- les variables GLuint et FSOUND sont privées

- j'ai rajouté un test pour ne pas charger 2* la même texture

- j'ai rajouté des destructeurs pour vider la mémoire sur toutes les classes

- par contre je n'ai pas créé de classe moteur pour gérer l'ensemble, car cela me ferai tout restructurer

Le nouveau lien est http://alexandre.bocquillon.free.fr/...plus%20MaJ.zip

Merci de me dire si le code est maintenant portable.

**fearyourself** · 13/04/2007, 10h28

Envoyé par BruceBoc

Merci de me dire si le code est maintenant portable.

Ca l'est, je vais tester sur mon ordinateur ce soir normalement, je te tiens au courant.

J'ai rajouté un makefile et j'ai modifié quelques trucs mais je n'ai pas de support OpenGL sur cet ordinateur donc cela va devoir attendre

Jc

**Strider_fr** · 16/04/2007, 21h17

Envoyé par BruceBoc

Absolument aucune. Je n'ai fais ce jeux que pour m'entrainer et en aucun cas pour concurrencer l'original. C'est pourquoi je ne poste pas ce jeux dans des forums autres qu'en programmation. Et enfin, il n'existe aucune version windows à l'heure actuelle donc je ne pense pas que ça les géne.

Salut, à propos du droit d'auteur, pourquoi ne pas demander à l'auteur d'IK+ ? Il s'agit d'Archer MacLean et il est toujours présent dans le monde des jeux vidéo. Peut-être que quelqu'un ici pourrait t'indiquer comment le contacter ?
Pour info : http://fr.wikipedia.org/wiki/Archer_Maclean

Bonne continuation dans ton projet !

(signé un fan d'IK+

)

**BruceBoc** · 16/04/2007, 22h14

Merci de t'y interresser, mais je ne vais tout de même pas essayer de le contacter et ceci pour 2 raisons :

- La premiere est que je n'estime pas ce jeux ou plutôt démo suffisamment complet pour le distribuer par contre si quelqu'un souhaite le reprendre ça ne me pose aucun problème

- La 2ème est que rien n'indique que ce soit Archer MacLean qui posséde encore les droits. En effet ce choix incombe à mon avis l'éditeur qui a repris le jeu pour le porter sur game boy advance.

Merci quand même de me le proposer mais je le poste avant tout pour m'améliorer.

**fearyourself** · 18/04/2007, 00h14

Voici une version qui fonctionne sous linux chez moi.

J'ai modifié un peu le main et j'ai enlevé ton fichier Variables.h...

Si quelqu'un est motivé pour changer les ressources, j'en ferais une contribution à part entière. Il faudrait simplement modifier les images et le sons....

Jc

**loka** · 18/04/2007, 12h55

Je peux faire ça ce week end si vous voulez.

j'ai tester le jeu, il marche bien mais j'ai pas regarder plus loin par manque de temps actuellement

**ironzorg** · 18/04/2007, 13h12

Personnellement je trouve que le code n'est pas si mauvais que ça ( si tu es le débutant dont tu nous parles ) ...

A part les variables globales et les non tests de retour de chargement ( beerk

), rien de bien méchant

**BruceBoc** · 18/04/2007, 17h07

Merci beaucoup d'avoir rendu ce code compatible.

Une petite question au passage, je viens de regarder le main et je vois que tu a rajouté :

Code :

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

1
2
3
 
    (void) argv;
    (void) argc;

juste avant le return EXIT_SUCCESS, et j'aimerai savoir à quoi sa sert.

**fearyourself** · 18/04/2007, 18h29

Envoyé par BruceBoc

Merci beaucoup d'avoir rendu ce code compatible.

Une petite question au passage, je viens de regarder le main et je vois que tu a rajouté :

Code :

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

1
2
3
 
    (void) argv;
    (void) argc;

juste avant le return EXIT_SUCCESS, et j'aimerai savoir à quoi sa sert.

C'est pour éviter un warning de type unused parameter.

Jc

**BruceBoc** · 18/04/2007, 19h01

Ah ok, merci pour l'info.

**loka** · 19/04/2007, 07h49

Voici des nouveaux sprites, libres (les balles sont de moi sous paint

)

**fearyourself** · 19/04/2007, 09h50

Envoyé par loka

Voici des nouveaux sprites, libres (les balles sont de moi sous paint

)

Niquel, je regarde cela ce soir, quelle est la provenance ? Ou est-ce écrit dans le .rar

Jc

**loka** · 19/04/2007, 14h28

C'est pas écris dans le rar car : les balles sont de moi et les sprites de brule lee sont d'un auteur inconnu (et retouchés par moi).

J'ai aussi un Background possible prit dans rpg maker, je le mettrais quand j'aurais trouvé une petite musique sympa et libre.

Je voudrais savoir sinon : les bruits des rebonds et autres sont libre ? sinon j'ai déjà ce qu'il faut pour ça ^^