Mon Puzzle Game en C

classdroogies · Le 15/10/2012, à 20:57

Bonjour,

Débutant en C, je développe actuellement un petit jeu qui s'appelle puzzle pipe, qui utilise la SDL :

Le but du jeu est de reconstituer la tuyauterie afin d'envoyer le plus de liquide du reservoir du haut vers celui du bas en déplaçant les plaques adjacentes à la plaque vide, à l'aide de la souris façon jeu de taquin.

Toute les pièces présentes doivent faire parties du circuit.

Il faut cliquer sur la vanne en haut à droite pour envoyer le liquide dans le reservoir du bas sous reserve que la canalisation soit valide !

Le jeu compte 10 niveaux pour le moment.

Le design est en cours de refonte (merci Stouf !):

je vais sans doute implémenter d'autre petite chose, ajout du nombre de déplacement comptabilisé, son supplémentaire....

En l'état j'aimerai avoir des avis sur le jeu bien entendu, mais surtout sur mon code....

Voici le lien de ma page google code :

http://code.google.com/p/puzzle-pipe/

En vous remerciant, amusez-vous bien !

Dernière modification par classdroogies (Le 15/10/2012, à 20:58)

classdroogies · Le 17/10/2012, à 20:13

Aucun retour, ça n'intéresse personne ?

bishop · Le 17/10/2012, à 22:27

Salut classdroogies !
Je ne te dirai rien sur le code car je n'y connais rien, par contre, ton jeu est bien sympa, mais un peu difficile pour un cerveau lent comme le mien.
En ce qui me concerne il me faudrait plus de temps.
Je vais le proposer à ma belle qui est férue de puzzles et autres jeux de logique.

Testé sous Natty 11.04. Pas de problème.

Dernière modification par bishop (Le 17/10/2012, à 22:28)

classdroogies · Le 17/10/2012, à 23:18

Merci d'avoir testé ! ça fait plaisir

Bigcake · Le 18/10/2012, à 10:56

Bonjour,

Je me rend compte que je critique beaucoup, mais j'espère que tu n'y verra qu'une liste de critiques constructive dans mon post

Pour le jeu en lui même, les moins :
- Pas de makefile dans les sources
- Pas d'animation quand l'eau coule (mais c'est compréhensible, le projet est jeune)
- Les puzzles sont différents mais le décor ne change pas d'un poil (ça donne un coté monotone, mais idem, le projet est jeune)
Les plus :
- La possibilité d'ouvrir la vanne avant la fin du décompte
- Type de jeu casse-tête comme on les aime
- Le jeu est plus dur qu'il en à l'air (pour le premier puzzle, j'y suis allé pépère, finalement, il a fallut que je me grouille !!)

Pour que ton jeu est une durée de vie plus longue, au lieu de créer toi même les puzzles un par un, ce qui serai fort à faire (et du coup super intéressant en terme de programmation) serai une génération automatique des puzzles, et qu'il y ait plusieurs niveaux de difficulté.

Pour ce qui est du code, on a clairement pas les même habitudes de mise en forme, ce qui me 'choque' le plus :
- Tu ne mets quasiment aucun espace autour d'un simple '=', pareil pour pas mal de '>' et '<', ce qui rend moins clair le code
- Tu mets des '{' et '}' pour des if ou des for qui ne contiennent qu'une seule ligne
exemple : dans interface.c, fonction Game_Menu_Bouton() :
cette fonction est écrite en 8 lignes, elle pourrai être écrite en 3 sans affecter la clarté du code :

if ((mouseposx >= surfposx) && (mouseposy >= surfposy) && (mouseposx <= (surfposx + surfsizex)) && (mouseposy <= (surfposy + surfsizey)))
        return 1;
return 0;

- Tout tes .c contiennent exactement les mêmes #include, pourquoi ne pas mettre tout tes #include dans, par exemple, game.h ?
Comme ça dans chaque fichier tu n'a qu'un seul #include à mettre
- Aucune fonction 'static' (à rajouter devant les fonctions qui ne seront utilisés que dans une seul fichier .c)
- Tu a beaucoup de ligne vide entre les déclarations et même en générale...ce qui allonge la taille de tes fonctions, du coup, pour relire une grande fonction, il fautt faire des aller-retours haut <-> bas
- "i++" fait une instruction de plus que "++i" (après sa dépend des optimisations que fait ton compilateur)

Bon tout ce que je dit là, c'est mon point de vue, mon ressenti, après je ne sait pas comment toi ou les autres voit ce genre de mise en forme.
En tout cas pour un 'débutant en C', c'est plutôt pas mal du tout !
Si j'ai le temps, je regarderai si t'a pas de fuite de mémoire ou autre joyeusetés

Dernière modification par Bigcake (Le 18/10/2012, à 11:15)

classdroogies · Le 18/10/2012, à 19:52

Salut,

merci d'avoir pris du temps pour tester et regarder mon code !

Bigcake a écrit :

Je me rend compte que je critique beaucoup, mais j'espère que tu n'y verra qu'une liste de critiques constructive dans mon post

Ton post correspond exactement à mes attentes

Bigcake a écrit :

Pour le jeu en lui même, les moins :
- Pas de makefile dans les sources
- Pas d'animation quand l'eau coule (mais c'est compréhensible, le projet est jeune)
- Les puzzles sont différents mais le décor ne change pas d'un poil (ça donne un coté monotone, mais idem, le projet est jeune)

Pour le makefile, je n'ai pas encore pris le temps de le faire, j'ai préféré me concentrer sur le code du jeu.

Pour ce qui est du design, il est en court de refonte, mais il vrai que des animations seraient un plus ( petite bulle, ondulation pour l'eau...).

Pour le décor j'avais pensé faire des variantes, électricité, gaz...

Bigcake a écrit :

Les plus :
- La possibilité d'ouvrir la vanne avant la fin du décompte
- Type de jeu casse-tête comme on les aime
- Le jeu est plus dur qu'il en à l'air (pour le premier puzzle, j'y suis allé pépère, finalement, il a fallut que je me grouille !!)

Merci, ça fait plaisir. J'ai déjà eu ce retour : "bah c'est facile" et finalement......Comme quoi il ne faut pas ce fier au apparence

Bigcake a écrit :

Pour que ton jeu est une durée de vie plus longue, au lieu de créer toi même les puzzles un par un, ce qui serai fort à faire (et du coup super intéressant en terme de programmation) serai une génération automatique des puzzles, et qu'il y ait plusieurs niveaux de difficulté.

C'est clair, j'ai commencé a y réflechir, j'en suis encore au stade du gribouillage sur papier....
Pour l'instant je crée mon circuit, puis je mélange manuellement, tout ça via un editeur de niveau. Mon objectif c'est de continuer à créer mes circuits manuellement, mais que le mélange se face automatiquement selon 3 niveaux de difficultés.

Bigcake a écrit :

Pour ce qui est du code, on a clairement pas les même habitudes de mise en forme, ce qui me 'choque' le plus :
- Tu ne mets quasiment aucun espace autour d'un simple '=', pareil pour pas mal de '>' et '<', ce qui rend moins clair le code
- Tu mets des '{' et '}' pour des if ou des for qui ne contiennent qu'une seule ligne

Effectivement c'est une sale habitude que j'ai prise pour les espaces

Pour les accolades, comme j'utilise des snippets avec geany....mais je préfère avec, c'est pour moi plus lisible.

Bigcake a écrit :

exemple : dans interface.c, fonction Game_Menu_Bouton() :
cette fonction est écrite en 8 lignes, elle pourrai être écrite en 3 sans affecter la clarté du code :
if ((mouseposx >= surfposx) && (mouseposy >= surfposy) && (mouseposx <= (surfposx + surfsizex)) && (mouseposy <= (surfposy + surfsizey)))

        return 1;

return 0;

Bien vu, je ne l'avais pas repéré celle-ci !

Bigcake a écrit :

- Tout tes .c contiennent exactement les mêmes #include, pourquoi ne pas mettre tout tes #include dans, par exemple, game.h ?
Comme ça dans chaque fichier tu n'a qu'un seul #include à mettre

Merci, ça aussi c'est une mauvaise habitude, je me suis fais un template dans geany et comme en abruti je C/C mes includes dans chaque fichier....

Bigcake a écrit :

- Aucune fonction 'static' (à rajouter devant les fonctions qui ne seront utilisés que dans une seul fichier .c)
- Tu a beaucoup de ligne vide entre les déclarations et même en générale...ce qui allonge la taille de tes fonctions, du coup, pour relire une grande fonction, il fautt faire des aller-retours haut <-> bas
- "i++" fait une instruction de plus que "++i" (après sa dépend des optimisations que fait ton compilateur)

La déclaration "static" est un aspect du C que je n'ai pas encore approfondi, va falloir m'y mettre
Il est vrai que j'ai tendance à aéré pas mal mon code, mais c'est pour moi plus lisible.
Le coup du i++ est une chose que j'avais complètement zappée, merci pour le rappel

Bigcake a écrit :

Bon tout ce que je dit là, c'est mon point de vue, mon ressenti, après je ne sait pas comment toi ou les autres voit ce genre de mise en forme.
En tout cas pour un 'débutant en C', c'est plutôt pas mal du tout !
Si j'ai le temps, je regarderai si t'a pas de fuite de mémoire ou autre joyeusetés

Encore une fois merci pour le temps que tu as passés a étudier tout ça !

Je vais revoir mon code, et continuer à faire évoluer mon jeu.

Au fait, j'éspère que tu es allé plus loin que le niveau 1

classdroogies · Le 20/10/2012, à 17:57

Je viens de passer certaines fonctions utilisées seulement dans son fichier source en static, comme suggéré :

Bigcake a écrit :

- Aucune fonction 'static' (à rajouter devant les fonctions qui ne seront utilisés que dans une seul fichier .c)

J'avais un question par rapport à cela, mon compilateur me renvoi un avertissement :

game.h:56:13: attention : ‘Game_Level_Player’ declared ‘static’ but never defined [-Wunused-function]

C'est avertissement n'est pas grave en soit, mais pour respecter une bonne pratique n'est-il pas préférable de regrouper les fonctions static dans un fichiers.h et les globales dans un autre, afin d'éviter l'inclusion des fichiers contenant des fonctions static dans des fichiers non concernés ?

Dernière modification par classdroogies (Le 20/10/2012, à 18:01)

Bigcake · Le 20/10/2012, à 20:38

classdroogies a écrit :

Pour le makefile, je n'ai pas encore pris le temps de le faire, j'ai préféré me concentrer sur le code du jeu.

A oui, j'y ai pas pensé, mais c'est vrai y a des gens qui utilisent autre chose que la consoler pour coder

classdroogies a écrit :

Effectivement c'est une sale habitude que j'ai prise pour les espaces

Tu devrais essayer de te forcer à y faire attention pour prendre la bonne habitude.
Quand tu retouchera du code qui a 6 mois et que tu a plus trop en tête, la clarté a ce niveau la est importante
elle est aussi importante si tu veux pas refouler les gens qui lisent ton code.

classdroogies a écrit :

Au fait, j'éspère que tu es allé plus loin que le niveau 1

oui, mais du coup, je savais a quoi m'attendre pour les niveaux suivant

classdroogies a écrit :

game.h:56:13: attention : ‘Game_Level_Player’ declared ‘static’ but never defined [-Wunused-function]
C'est avertissement n'est pas grave en soit, mais pour respecter une bonne pratique n'est-il pas préférable de regrouper les fonctions static dans un fichiers.h et les globales dans un autre, afin d'éviter l'inclusion des fichiers contenant des fonctions static dans des fichiers non concernés ?

Personnellement, je ne déclare pas mes fonctions 'static', j'ordonne mes fonctions dans mon .c de façon à ce qu'il ne me fasse pas de warnings
Après, si l'ordre me permet pas de faire disparaître le warning, je déclare la fonction qui me pose problème dans le .c (ça arrive pas des masses)
Le coup des fonctions 'static', ça permet surtout à ton compilateur de faire des optimisations

Bon, sinon j'ai testé ton binaire avec valgrind dans une condition assez spécial et j'ai eu le droit a un segfault au premier test ! hé hé ! (rire sadique)
bon, par contre, je peux pas encore te dire d'où vient le pb parce que j'ai fait le test avec l’exécutable que tu fournit et non avec le code source une fois compilé.

Dernière modification par Bigcake (Le 20/10/2012, à 20:47)

classdroogies · Le 20/10/2012, à 21:14

J'ai fait le test en séparant mes fonctions static des autres, afin de permettre une inclusion uniquement dans le fichier concerné, je n'ai plus de warning.

Après il faudrait peut être que je revois mon organisation au niveau du code, j'ai trouvé cet ouvrage bien sympa :

http://emmanuel-delahaye.developpez.com … -codage-c/

Bigcake a écrit :

A oui, j'y ai pas pensé, mais c'est vrai y a des gens qui utilisent autre chose que la consoler pour coder big_smile

Pas bien compris ce que tu voulais dire ....tu utilises quoi justement comme éditeur ?

Pour valgrind, j'avais déjà test mais je n'ai pas su analyser la chose ! J'ai utilisé la commande fournie par la doc Ubuntu :

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --show-reachable=yes ./puzzlepipe

Dernière modification par classdroogies (Le 20/10/2012, à 21:19)

Bigcake · Le 20/10/2012, à 21:45

classdroogies a écrit :

Pas bien compris ce que tu voulais dire ....tu utilises quoi justement comme éditeur ?

Ben en fait, quand je t'ai dit que y avait pas de Makefile dans tes sources, ça me paraissait évident que ceux qui codent en C ai forcement un Makefile, mais en fait, tu utilise un IDE graphique (rien de honteux, sauf si on veut troller ) donc, c'est pas si évident que ça que tu ai un Makefile
De mon coté, je fait tout dans un terminal :
- emacs pour l'édition (le meilleur éditeur pour le terminal <= ATTENTION GROS TROLL POILU SPOTTED)
- make +gcc pour la compilation
- valgrind / gdb / libfence pour le débuguage
- Divers alias shell pour réduire la taille des lignes de commande
- Divers script.sh pour éviter des taches répétitives
Ça fait très "old-school", mais je trouve ça tellement plus pratique de pas avoir à toucher 2 la souris toute les 30 sec quand je code.

classdroogies a écrit :

Pour valgrind, j'avais déjà test mais je n'ai pas su analyser la chose ! J'ai utilisé la commande fournie par la doc Ubuntu :

En fait je me suis mal exprimé, c'est pas valgrind qui ma sortir le segfault, j'ai voulu faire un test dans certaines conditions, et j'ai lancé valgrind avec pour voir si tu avait pas de fuite de mémoire.
Finalement, j'ai pas vu grand chose à part le segfault, qui est du aux conditions et non a ce que fait valgrind.

Dernière modification par Bigcake (Le 20/10/2012, à 21:52)

classdroogies · Le 20/10/2012, à 22:24

Perso je préfère la console pour pas mal de chose et suis fan des environements de bureau minimaliste. Pour ajouter des bigoudis à ton troll , j'envisage de test vim.....et emacs afin de voir celui qui me correspond le mieux.
C'est dans les vieux pots qu'on fait les meilleures confiotes

Dernière modification par classdroogies (Le 20/10/2012, à 22:25)

Zakhar · Le 20/10/2012, à 23:06

Bigcake a écrit :

Pour ce qui est du code, on a clairement pas les même habitudes de mise en forme, ce qui me 'choque' le plus :
- Tu mets des '{' et '}' pour des if ou des for qui ne contiennent qu'une seule ligne
exemple : dans interface.c, fonction Game_Menu_Bouton() :
cette fonction est écrite en 8 lignes, elle pourrai être écrite en 3 sans affecter la clarté du code :
if ((mouseposx >= surfposx) && (mouseposy >= surfposy) && (mouseposx <= (surfposx + surfsizex)) && (mouseposy <= (surfposy + surfsizey)))
        return 1;
return 0;

Alors là je ne suis pas d'accord avec toi BigCake.

Le fait de mettre des { } même quand il n'y a qu'une seule instruction est une bonne pratique.

Du reste, en Java, donc la syntaxe en ce qui concerne les crochets est avoisinante, il y a même des règles automatiques pour le vérifier.

Le rationale est que si un jour, en faisant une maintenance, tu rajoutes une instruction, c'est vite fait d'oublier qu'il n'y avait pas de crochets et donc de produire un code qui ne fait plus du tout ce qu'on veut.

Donc pour expliciter, au contraire il faut toujours écrire :

  if ( condition )
   {
      instruction;
   }

Parce que le jour où ça devient :

  if ( condition )
   {
      instruction1;
      instruction2;
   }

au moins ça fonctionne comme souhaité...

tandis que tu n'as pas mis les crochets, c'est vite fait d'avoir

  if ( condition )
      instruction1;
      instruction2;

qui à l'évidence ne fait pas du tout ce qu'on souhaite...

La seule exception éventuellement est si l'instruction est vraiment courte, mais dans ce cas, et pour qu'il n'y ait pas de confusion possible lors d'un futur ajout, il vaut mieux ne pas faire de retour de ligne, du genre :

  if ( flag ) return 0;

Mais cela dit, on peut tout aussi bien écrire

  if ( flag ) { return 0; }

je trouve ça personnellement encore plus lisible.

(Bien sûr dans l'exemple simpliste on voit rapidement l'erreur, mais quand on a toute une arborescence de crochets, c'est vite fait de ne pas s’apercevoir qu'il en manque à un niveau).

P.S.: j'ai indenté à la mode "GNU", bien sûr certains préfèrent le K&R d'origine... les goûts et les couleurs sont dans la nature, à vous de choisir votre style et vous y tenir !

Bigcake a écrit :

- "i++" fait une instruction de plus que "++i" (après sa dépend des optimisations que fait ton compilateur)

Alors là pareil...
-1) je ne recommande pas (sauf exception à commenter !) de faire des optimisations de ce niveau à la place du compilateur... en général ça rend le code bien moins lisible, le boulot du programmeur est de faire un programme qui tient la route, pas d'optimiser ce qui va être généré selon le processeur ciblé.
-2) une instruction de plus... pour quelle cible processeur ?
-3) i++ et ++i ne font pas la même chose... comment peux-tu proposer hors contexte l'un à la place de l'autre !..

Dans certains cas "pointus", par exemple lorsqu'on joue avec les instructions atomiques et les barrières mémoire, on est effectivement obligé d'aider un peu le compilateur. Mais c'est surtout pour qu'il ne fasse pas d'optimisation qui pourraient casser le programme (comme le fait de déplacer des instructions qui n'ont pas l'air reliées). Dans ces cas extrêmes, on peut en arriver à certaines optimisations... mais certainement pas pour un i++ / ++i !..

Exemple (extrait d'un code que j'ai écrit qui gère une file lifo en DCAS -sur i386/amd64):

  do
    {
       old_Head.age  = pHead->age;

       asm volatile ("" : : : "memory");  // Compile only barrier: age MUST be
                                          // read BEFORE pFirst to protect from ABA

       if ( (old_Head.pFirst= pHead->pFirst) == NULL )
           break;
       new_Head.age   = old_Head.age + 1;
       new_Head.pFirst= old_Head.pFirst->pNext;
    }
#ifdef LIFO_32
  while ( 
          ! __sync_bool_compare_and_swap (
                                            (__int64_t *)pHead     ,
                                          *((__int64_t *)&old_Head),
                                          *((__int64_t *)&new_Head) 
                                         )
        );
#else
  while ( 
          ! __sync_bool_compare_and_swap (
                                            (__int128_t *)pHead     ,
                                          *((__int128_t *)&old_Head),
                                          *((__int128_t *)&new_Head) 
                                         )
        );
#endif

Là on est obligé d'aider le compilateur (instruction asm volatile ... = barrière de compilation ). Si on ne le fait pas, comme il voit un test avec un break de la boucle et une instruction avant le test qui réalise une affectation sans rapport avec le test, le compilateur va se dire :
"chouette, je peux optimiser ça !", en effet, si le test fait sortir de la boucle, on n'a pas besoin de l'affectation. Donc tout simplement, le compilateur va placer l'affectation qui est avant le test après le test.
... et là... paf, le programme ne marche plus. En effet, il est vrai que si on sort de la boucle par le break, on a fait l'affectation pour rien... mais si on ne sort pas de la boucle, il est crucial (pour éviter le Syndrome ABA) que la première affectation soit faite AVANT celle faite dans le test.
Mais ce sont des cas extrêmes, et pour cela il vaut mieux commenter (comme c'est fait) pour que lorsqu'on relit plus tard on se rappelle du pourquoi de la chose (ici protection contre le "ABA syndrom", vous pouvez regarder sur Wikipedia, c'est un machin amusant !)

Dernière modification par Zakhar (Le 20/10/2012, à 23:39)

Bigcake · Le 21/10/2012, à 00:12

.

Dernière modification par Bigcake (Le 15/11/2012, à 22:12)

Zakhar · Le 21/10/2012, à 01:23

BigCake, tu es probablement un programmeur exceptionnel qui ne fait aucune erreur, et je te tire mon chapeau.

Pour les crochets, j'ai expliqué la raison. Personnellement, et c'est le cas de beaucoup de programmeurs qui n'ont pas ton talent BigCake, il m'est arrivé plus d'une fois de me tromper et de chercher de longues minutes après avoir rajouté une instruction alors que j'avais omis les crochets.

Aussi, je t'accorde que préférer :

  if ( condition ) {
    instruction1;
    instruction2;
  }

ou

  if ( condition )
    {
      instruction1;
      instruction2;
    }

est cosmétique. Mais pour ce qui est de l'instruction unique, pour les raisons que j'ai expliqué à parce que je fais humblement des erreurs (et ceux qui me relisent aussi) je persisterai à écrire autant que faire ce peut :

  if ( condition )
    {
      instruction1;
    }

Quant à ton histoire du i++ / ++i, ça m'intrigue...

Voici un petit code tout basique :

#include <stdio.h>

int main()
{
  int i = 0;

  printf( "%u\n", i++ );
  printf( "%u\n", ++i );
}

compilé :

gcc test.c -o test -g

et vu sous nemiver:

int i = 0;
0x00000000004004fc  <main+8>:  movl   $0x0,-0x4(%rbp)

  printf( "%u/n", i++ );
0x0000000000400503  <main+15>:  mov    -0x4(%rbp),%edx
0x0000000000400506  <main+18>:  addl   $0x1,-0x4(%rbp)
0x000000000040050a  <main+22>:  mov    $0x40062c,%eax
0x000000000040050f  <main+27>:  mov    %edx,%esi
0x0000000000400511  <main+29>:  mov    %rax,%rdi
0x0000000000400514  <main+32>:  mov    $0x0,%eax
0x0000000000400519  <main+37>:  callq  0x4003f0 <printf@plt>
  printf( "%u/n", ++i );
0x000000000040051e  <main+42>:  addl   $0x1,-0x4(%rbp)
0x0000000000400522  <main+46>:  mov    $0x40062c,%eax
0x0000000000400527  <main+51>:  mov    -0x4(%rbp),%edx
0x000000000040052a  <main+54>:  mov    %edx,%esi
0x000000000040052c  <main+56>:  mov    %rax,%rdi
0x000000000040052f  <main+59>:  mov    $0x0,%eax
0x0000000000400534  <main+64>:  callq  0x4003f0 <printf@plt>
} 
0x0000000000400539  <main+69>:  leaveq 
0x000000000040053a  <main+70>:  retq

On constate exactement le même nombre d'instructions pour le ++i et le i++ (6 instructions assembleur 386)
Dans un cas il charge il ajoute 1 avant puis charge edx, dans l'autre il charge edx puis ajoute 1 après.

Dans quel cas donc est-ce plus intéressant d'avoir i++ ou ++i

... sans doute pour d'autres cibles que le i386/amd64 (ci-dessus). Je suis impatient d'apprendre !..

Bien sûr mon cas d'exemple est trop simpliste pour un -03
Car dans ce cas, le compilateur se rend compte qu'on n'a pas vraiment besoin de i dans le main après les printf, et il fait un mov 1 et 2 "en dur". Mais le nombre d'instruction reste le même puisque c'est dans les deux cas un mov "en dur" d'une constante que le compilateur sait calculer.

Bigcake a écrit :

Pour moi, un programmeur doit comprendre ce qu'il écrit (surtout en C)

Oui, ça c'est sûr, le C ça ne pardonne guère !..
Les static et tout ce que tu citais par exemple, c'est important pour les fonctions, si un jour on rajoute d'autres fichiers au programme général pour ne pas se prendre les pieds dans le tapis (comme les crochets quand on rajoute des instructions ! )

Dernière modification par Zakhar (Le 21/10/2012, à 01:29)

classdroogies · Le 21/10/2012, à 03:22

Moi tu sais les accolades j'vais les mettre quand même..... je me cite :

classdroogies a écrit :

Pour les accolades... je préfère avec, c'est pour moi plus lisible.

Sinon tu veux pas jouer a un p'tit jeu sympa pour te détendre

Parce que là, c'est bon quoi....

Une chose est sûr, il y a une personne ici qui a pris le temps de jouer au jeu (pour info objet du post), de lire le code (au passage tu aurais lu qu'il y avait bien plus que de simple accolades en trop, dans la fonction en question), de faire un retour constructif, et qui ne post pas en étalant sa science, puis en disant le contraire tout de suite après :

Zakhar a écrit :

Mais cela dit, on peut tout aussi bien écrire
if ( flag ) { return 0; }
je trouve ça personnellement encore plus lisible.

Perso je trouve ça encore moins lisible, mais je n'ai pas ta Culture du C, qui malheureusement ne m'aide pas vraiment a avancer !

A bon entendeur

Un troll avec des bigoudis j'pensais pas que c'était possible

Dernière modification par classdroogies (Le 21/10/2012, à 03:50)

Zakhar · Le 21/10/2012, à 09:39

Ce n'est pas un troll.

Tu veux une autre justification des accolades, la voila :

  if (cond1)
    if (cond2)
      instruction1;
    else
      instruction2;

C'est un code parfaitement correct, écrit sans accolades comme BigCake les aime bien.
Pourtant gcc va râler sur ce code qui est "dangereux".

En effet, est-ce bien ça que j'ai voulu dire ou alors plutôt ça

  if (cond1)
    if (cond2)
      instruction1;
  else
    instruction2;

parce que là c'est tout autre chose !..
Et comme on est en C et pas en python, gcc va conseiller de mettre des accolades (maintenant je mets 2 instructions pour ne pas choquer).
En effet cela permet de différencier

  if (cond1) {
    if (cond2) {
      instruction1;
      instruction2;
    }
    else {
      instruction3;
      instruction3;
    }
  }

de

  if (cond1) {
    if (cond2) {
      instruction1;
      instruction2;
    }
  }
  else {
    instruction3;
    instruction3;
  }

Donc oui, techniquement un if, avec son else qui suit et les instructions dedans sont une seule et même instruction, et on peut l'écrire là où toute instruction est valide, sans accolade... mais le compilateur lui-même considère cela comme "ambigu" dans certains cas.

Donc mon intervention n'était nullement un troll, mais juste pour reprendre ce qui t'était donné pour un "conseil" et que je considère (à mon humble avis) comme une erreur.... Mais du reste tu avais juste sur ce point puisque tu avais utilisé les accolades.

Comme l'autre "conseil de marabout" consistant à préférer ++i plutôt que i++ ... celui là je ne l'avais jamais vu, et comme je suis curieux d'apprendre, j'ai fait le test et mis le résultat : aucune différence en terme d'instructions contrairement à ce qui fut affirmé. Mais là on va attendre le "pourquoi" de bigcake, il y a certainement une raison à ce conseil !

@classdroogies : désolé de ne pas avoir pris le temps de lire ton code. Je voulais juste éviter que tu suives des "faux bons conseils" (et encore un fois, tu avais "bon" de toute façon pour les accolades).
Je n'avais pas compris que ton post c'était "donnez-moi des conseils si vous lisez mon code".
Car par ailleurs, il existe des règles de style dans tout langage de programmation qui s'appliquent dans l'absolu à tout code que l'on peut écrire.

Je me garderai donc bien à l'avenir d'intervenir sur ton sujet, même si quelqu'un te donne des conseils complètement loufoques, puisque je n'ai pas lu ton code !..

Dernière modification par Zakhar (Le 21/10/2012, à 09:45)

classdroogies · Le 21/10/2012, à 11:12

C'est incroyable cette façon autaine et vindicative que tu as de t'exprimer.

Super tu cites des passages que j'ai déjà lu du K&R

Zakhar a écrit :

Je me garderai donc bien à l'avenir d'intervenir sur ton sujet, même si quelqu'un te donne des conseils complètement loufoques, puisque je n'ai pas lu ton code !..

Une bonne chose....mais sache que j'ai tout de même un cerveau et que je ne prend pas tout ce que l'on me dit pour argent comptant ! Et ce que j'ai lu c'est simplement un concours de : c'est moi qui est la plus grosse

Zakhar a écrit :

Car par ailleurs, il existe des règles de style dans tout langage de programmation qui s'appliquent dans l'absolu à tout code que l'on peut écrire.

Celle-ci, elle est bien bonne ! Débutant ne signifie pas ignare.....

Dernière modification par classdroogies (Le 21/10/2012, à 16:57)

Zakhar · Le 21/10/2012, à 11:26

classdroogies a écrit :

je ne prend pas tout ce que l'on me dit pour argent comptant !

Tant mieux, il faut toujours avoir un peu d'esprit critique !

En fait tu nous dis au post #1 être débutant, mais c'est certainement loin d'être le cas.

Un peu de lecture pour le longues nuit d'hiver (anglais)

Dernière modification par Zakhar (Le 21/10/2012, à 11:29)

Bigcake · Le 21/10/2012, à 12:04

.

Dernière modification par Bigcake (Le 15/11/2012, à 22:12)

Zakhar · Le 21/10/2012, à 14:48

Au temps pour moi, tu parlais donc de "i++" utilisé en tant que chaîne de caractère dans un programme, et non pas de l'instruction i++

Du coup je comprends mieux, parce que j'avais du mal à voir le différence en nombre d'instructions entre i++ et ++i (je parle de I++, l'instruction d'incrémentation pre/post, pas d'une chaîne de caractère).

Ca m'apprendra à lire les posts, puisque pour comprendre il fallait lire le code... ce qui était demandé au #1

Toutes mes excuses donc à tous les deux.

Dernière modification par Zakhar (Le 21/10/2012, à 14:50)

Bigcake · Le 22/10/2012, à 16:40

Zakhar a écrit :

[..]Encore du garbage[..]

k...Pathétique.

Bon, alors je me suis repenché sur le segfault que j'avais pu constaté, et a priori, tu n'y est pour rien, ça plante à l'initialisation de la lib SDL

J'ai essayé ton jeu sur un autre poste, SDL a pas réussi à m'ouvrir le son alors que j'étais en train d'écouter de la musique....
j'ai fermé mon lecteur, mais j'ai quand même eu le droit à l'erreur :

ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
! ERREUR : L'initialisation du module SDL_MIXER à échoué : No available audio device'

Ce qui me fait te suggérer qu'il serai mieux que tu fasse un message d'erreur au lieu de quitter quand le son n'arrive pas à s'initialiser.

J'ai fait d'autres tests :
- Je suis tombé à 0 au chrono mais j'ai réussi à finir alors que le le réservoir était a 75% remplit.
J'ai quand même perdu alors que le tuyau coté jeu avait plus de 50%,
Il m'a annoncé que j'avais perdu seulement une fois que le réservoir s'est vidé entièrement
Est-ce prévu pour se passer comme ça ? le joueur ne devrai-t-il pas perdre tout de suite ? ou gagner quand même ?

- Je suis tombé à 0 au chrono, j'ai finit le chemin de tuyau avant que le réservoir ne tombe à 0%.
J'ai cliqué sur la vanne vers les 50%, ce m'a permis de gagner.
Est-ce prévu pour se passer comme ça ? le joueur ne devrai-t-il pas perdre comme précédemment ?

Oh! j'allais oublier, ça m'a gonflé qu'il n'y ai pas de Makefile, du coup :

NAME = puzzlepipe

SRC = game.c \
        interface.c \
        menu.c \
        player.c \
        puzzlepipe.c

OBJ = $(SRC:.c=.o)

CFLAGS = -Wall  `sdl-config --cflags`
LIB =  `sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer

all: $(OBJ)
<tab>gcc -o $(NAME) $(OBJ) $(LIB)

# install - valable pour debian squeeze et *buntu 12.04
install:
<tab>sudo apt-get install libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev

gdb:
<tab>gcc -g -o $(NAME) $(SRC) $(LIB) $(CFLAGS)

clean :
<tab>rm -rf *.o *~  \#* $(NAME)

fclean : clean
<tab>rm -rf $(NAME)

re : fclean all

<tab> est évidemment a remplacer par des vrai tabulations

Dernière modification par Bigcake (Le 15/11/2012, à 22:15)

classdroogies · Le 22/10/2012, à 20:33

Bigcake a écrit :

Zakhar a écrit :
[..]Encore du garbage[..]
k...Pathétique.

.....c'est clair......passons....

Bigcake a écrit :

Bon, alors je me suis repenché sur le segfault que j'avais pu constaté, et a priori, tu n'y est pour rien, ça plante à l'initialisation de la lib SDL
J'ai essayé ton jeu sur un autre poste, SDL a pas réussi à m'ouvrir le son alors que j'étais en train d'écouter de la musique....
j'ai fermé mon lecteur, mais j'ai quand même eu le droit à l'erreur :
ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
! ERREUR : L'initialisation du module SDL_MIXER à échoué : No available audio device'
Ce qui me fait te suggérer qu'il serai mieux que tu fasse un message d'erreur au lieu de quitter quand le son n'arrive pas à s'initialiser.

J'ai moi aussi quelques messages relatifs au son :

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred

message déjà rencontré sur d'autres applications, rien de gênant.
et certaine fois à la lecture d'un son du jeu :

No SoundFonts have been requested

Pas trouvé ce que cela signifiait....
Cependant aucun problème au niveau de l'init, et ceci même quand j'écoute de la musique, j'utilise uniquement alsa.
Effectivement un message d'erreur au niveau de l'interface, sans bloquer l'appli serait bien mieux

Bigcake a écrit :

J'ai fait d'autres tests :
- Je suis tombé à 0 au chrono mais j'ai réussi à finir alors que le le réservoir était a 75% remplit.
J'ai quand même perdu alors que le tuyau coté jeu avait plus de 50%,
Il m'a annoncé que j'avais perdu seulement une fois que le réservoir s'est vidé entièrement
Est-ce prévu pour se passer comme ça ? le joueur ne devrai-t-il pas perdre tout de suite ? ou gagner quand même ?

Pas bien compris, tu as quand même perdu malgré avoir résolu le circuit, et envoyer du liquide dans le réservoir du bas ? il y a un bug alors...

Bigcake a écrit :

- Je suis tombé à 0 au chrono, j'ai finit le chemin de tuyau avant que le réservoir ne tombe à 0%.
J'ai cliqué sur la vanne vers les 50%, ce m'a permis de gagner.
Est-ce prévu pour se passer comme ça ? le joueur ne devrai-t-il pas perdre comme précédemment ?

L'objectif est de récupérer le maximum de liquide dans le reservoir du bas.
Le chrono est là afin de déclencher la vidange du réservoir du haut. le joueur à donc 90s + le temps de vidange du reservoir source.
Le joueur gagne à partir du moment où il arrive a envoyer du liquide au reservoir du bas, et ceci ne peut ce faire que si le circuit est correct et que tout les tuyaux sont utilisés.
Le joueur perd si il n'arrive pas à résoudre le circuit et donc à envoyer du liquide dans le reservoir du bas dans le temps imparti soit 90s + la durée de vidange du reservoir.
La quantité de liquide récupéré détermine le score. Si le joueur termine et qu'il reste du temps au chrono, il obtient alors le score de 100 points (reservoir du bas plein) + le bonus chrono.
J'aurai du écrire ça sur mon premier post

Bigcake a écrit :

Oh! j'allais oublier, ça m'a gonflé qu'il n'y ai pas de Makefile, du coup :

La classe à Dallas !! Merci !

Dernière modification par classdroogies (Le 22/10/2012, à 20:37)

Bigcake · Le 22/10/2012, à 21:27

classdroogies a écrit :

Pas bien compris, tu as quand même perdu malgré avoir résolu le circuit, et envoyer du liquide dans le réservoir du bas ? il y a un bug alors...

Mmmmm, j'ai pas très bien expliqué effectivement...
Et en fait non.... y a pas de problème du tout...
J'avais juste pas fait gaffe a ça dans ton enoncé :

classdroogies a écrit :

Il faut cliquer sur la vanne en haut à droite pour envoyer le liquide dans le reservoir du bas sous reserve que la canalisation soit valide !

Dernière modification par Bigcake (Le 22/10/2012, à 21:30)

classdroogies · Le 22/10/2012, à 23:32

Bon j'ai fais quelques petites modifs de mise en forme...nouveau commit sur google code.

A la recherche des espaces disparus ....nouvelle organisation des includes, avec, au passage, suppression du fichier config.h au profit de interface.h, dans lequel j'ai mis mes defines, enum, structures.....

J'ai fait également une ou deux retouches sur des opérateurs d'incrémentations/décrémentations, un sujet sensible

Chut....

Exemple dans la fonction Game_Level_Load :

//Si on est pas à la fin de la ligne on charge la donnée
if (carac_get != '\n')
{
	level[num_line].piece[i++] = num_get;							
}
//Sinon on change de ligne et donc de niveau
else
{
	i = 0;
	++num_line;
}

Ce qui me parait pour ce cas là être une bonne chose.

Je vais maintenant organiser mon projet en dossier et me pencher sérieusement sur l'utilisation du makefile.

Encore une fois merci !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/10/2012, à 20:57

Mon Puzzle Game en C

#2 Le 17/10/2012, à 20:13

Re : Mon Puzzle Game en C

#3 Le 17/10/2012, à 22:27

Re : Mon Puzzle Game en C

#4 Le 17/10/2012, à 23:18

Re : Mon Puzzle Game en C

#5 Le 18/10/2012, à 10:56

Re : Mon Puzzle Game en C

#6 Le 18/10/2012, à 19:52

Re : Mon Puzzle Game en C

#7 Le 20/10/2012, à 17:57

Re : Mon Puzzle Game en C

#8 Le 20/10/2012, à 20:38

Re : Mon Puzzle Game en C

#9 Le 20/10/2012, à 21:14

Re : Mon Puzzle Game en C

#10 Le 20/10/2012, à 21:45

Re : Mon Puzzle Game en C

#11 Le 20/10/2012, à 22:24

Re : Mon Puzzle Game en C

#12 Le 20/10/2012, à 23:06

Re : Mon Puzzle Game en C

#13 Le 21/10/2012, à 00:12

Re : Mon Puzzle Game en C

#14 Le 21/10/2012, à 01:23

Re : Mon Puzzle Game en C

#15 Le 21/10/2012, à 03:22

Re : Mon Puzzle Game en C

#16 Le 21/10/2012, à 09:39

Re : Mon Puzzle Game en C

#17 Le 21/10/2012, à 11:12

Re : Mon Puzzle Game en C

#18 Le 21/10/2012, à 11:26

Re : Mon Puzzle Game en C

#19 Le 21/10/2012, à 12:04

Re : Mon Puzzle Game en C

#20 Le 21/10/2012, à 14:48

Re : Mon Puzzle Game en C

#21 Le 22/10/2012, à 16:40

Re : Mon Puzzle Game en C

#22 Le 22/10/2012, à 20:33

Re : Mon Puzzle Game en C

#23 Le 22/10/2012, à 21:27

Re : Mon Puzzle Game en C

#24 Le 22/10/2012, à 23:32

Re : Mon Puzzle Game en C

Pied de page des forums