Bonsoir à tous!

Voilà, j'ai un projet en C à faire (un labyrinthe avec bibliothèque SDL), et j'essaie de régler la collision du personnage. En fait, on a l'image d'une pièce, comme ceci :

http://www.noelshack.com/up/aac/sanstitre-977bcea824.bmp

Et donc, pour le mur en face, y'a aucun souci. Par contre, il y a un problème avec le mur de gauche (je programmerais pour le mur de droite selon le même modèle).

Pourtant, les formules que j'utilise sont justes, mais dès lors que j'essaie de faire vérifier une condition, ça ne marche pas, enfin j'ai commenté le code de manière assez détaillée pour que vous compreniez le souci ;). Mais pour faire clair, vu que cette diagonale est perçue comme une fonction, j'essaie de trouver un x bloquant en fonction de la hauteur du personnage dans la carte (en montant, la largeur de la pièce se rétrécit virtuellement, si vous voulez...)

Voici donc le code source, et le projet juste en dessous :

http://pastebin.com/m7b2296be

http://www.sendspace.com/file/11w16d

Merci à quiconque prendra le temps de m'aider T_T.

J'ai pas le temps de lire en détail. Donc j'ai juste jeté un rapide coup d'œil parce que ça sent le problème de int VS float.

a = (506-625)/(212-2);
là j'ai très très peur. Tu es conscient que cette division ne tombe pas juste, et que comme on a des entiers partout, a va recevoir le quotient entier de la division et pas le quotient réel ?

Démonstration en objective caml :

1. (506-625)/(212-2);;

- : int = 0

1. (506.-.625.)/.(212.-.2.);;

- : float = -0.566666666666666652

Si tu veux pour a la valeur du deuxième résultat, il faut caster explicitement un des entiers en double pour forcer à faire tous les calculs en rééls.
a = ((double)506-625)/(212-2);
En plus court, tu peux aussi te contenter d'ajouter une "virgule".
a = (506.-625)/(212-2);

"là j'ai très très peur. Tu es conscient que cette division ne tombe pas juste, et que comme on a des entiers partout, a va recevoir le quotient entier de la division et pas le quotient réel ? "

Je m'en suis rendu compte, c'est justement sur ça que je planche... (parce que ça tombe sur une division par 0...)

"Si tu veux pour a la valeur du deuxième résultat, il faut caster explicitement un des entiers en double pour forcer à faire tous les calculs en rééls.
a = ((double)506-625)/(212-2);
En plus court, tu peux aussi te contenter d'ajouter une "virgule".
a = (506.-625)/(212-2); "

Je vais tenter ça...

ça marche, merci beaucoup, dire que c'était aussi bête -_-...

(en fait, niveau raisonnement, j'avais l'idée que tu as énoncé, mais je savais pas qu'il fallait forcer en double...)

Bon, ce truc la (a = (506.-625)/(212-2);) marche, mais c'est super crado, parceque tu es sur que le prochain gars qui va chagner le code ne va pas voir la virgule, va la virer et kaboom le bug reapparait. personnellement, je ferais le cast explicite parceque le lecteur verra explicitement que tu fais un cast au lieu de le masquer dans une ligne obscure.

godrik=>J'ai utilisé le (double), j'ai pas trop aimé le coup du point non plus XD

Sinon, j'ai un autre souci :

Donc, tout marche à la compilation, etc, c'est chouette. MAIS :

Quand je fais un release, je lance l'application avec les DLL, j'ouvre et ça se referme tout seul...

Si quelqu'un a une idée...

qu'en pense ton debugger ?

"Donc, tout marche à la compilation, etc, c'est chouette. MAIS :

Quand je fais un release, je lance l'application avec les DLL, j'ouvre et ça se referme tout seul... "

Pas compris : dans quel cas est-ce que ça fonctionne (programme compilé comment, lancé comment ?) et dans quel cas est-ce que ça ne fonctionne pas (idem) ?

godrik: Pour dire vrai, j'avais d'abord juste mis la version avec le ".", puis je me suis dit qu'un jour les constantes numériques allaient être changées en variables (probablement de type int) et du coup j'ai ajouté la version avec cast explicite qui est effectivement plus propre.

Je sais pas ce qu'en pense le débugger, il marche parfaitement en compilant avec CodeBlocks.

Mais quand je veux lancer le .exe relâché en Release, plus rien... (j'ai toute les DLL)

mmm, tu veux dire qu'en debug ca marche mais qu'en release ca ne marche pas ?

Qu'est ce qu'il se passe si tu met un breakpoint a la premiere ligne du programme ? est ce que tu rentres dans le debugger ?

godrik=>J'ai fait tous les tests de debug possible mais rien n'y fait...

Dès que le relâche en release, ça y est, il beug complètement, alors qu'en compilant avec CB ça marche parfaitement...

ca marche en debug mais pas en release. C'est ca que tu dis ?
Qu'en pense valgrind en debug ?

<noob> Ça existe valgrind pour windows ? </noob>

Quoi ? il est sous windows ? mmm non pas de valgrind sous windows (d'apres http://valgrind.org/info/platforms.html ).

pas de "memory checker" c'est une condition de rupture chez moi.

Je suis sous windows, mais j'ai ubuntu de disponible à côté...

Valgrind ne sert-il pas uniquement à contrôler les fuites de mémoire ? Il me semble que si, et si le problème venait de là, je pense que ça planterait aussi lamentablement en debug qu'en release.
(Note : ne pas prendre péjorativement le "lamentablement", c'est employé avec humour)

Question con, mais ça arrive parfois d'oublier : si ton programme utilise des images externes, se trouvent-elles bien également dans le dossier contenant ton .exe en release ?
Si c'est bien le cas, recode ton programme en y insérant des tests, notamment sur les allocations dynamiques et isole le code qui fait planter, ça t'aidera sûrement à identifier ce qui cloche.

_viper_, valgrind est un veritable couteau suisse. C'est une memory checker. il verifie les fuites de memoires, les access illegaux en memoire, genere des statistiques d'appel des fonctions et d'utilisation des caches.

Donc si une ouverture de fichier n'a pas marche, il y a probablement de la memoire mal alloue et valgrind beepera.
Je pensais originellement, a une optimisation d'une allocation emmoire en release qui provoque une seg fault.

"Valgrind ne sert-il pas uniquement à contrôler les fuites de mémoire ? Il me semble que si, et si le problème venait de là, je pense que ça planterait aussi lamentablement en debug qu'en release. "

Ne pas croire ça : le comportement d'un programme, surtout relatif à ses accès mémoire peut être complètement différent entre une version de debug (particulièrement si elle tourne dans un débogueur) et une version de release. Et le mieux est de supposer que la différence est imprévisible (plutôt que de s'appuyer sur un ensemble d'heuristique pour prévoir ce comportement).

"Question con, mais ça arrive parfois d'oublier : si ton programme utilise des images externes, se trouvent-elles bien également dans le dossier contenant ton .exe en release ? "

En effet, tout s'y trouve.

Mais il me faudrait un logiciel externe, car Codeblocks ne me sort aucun warning (bon à part les touches inutilisées, mais ça à la limite, c'est pas ça qui fait planter...) et tout marche impeccablement si je compile à l'aide de CB. Mais dès que ça part en release, c'est-à-dire que je ne le lance plus à partir de CB, c'est là que ça plante.

Il n'y a aucun logiciel équivalent à Valgrind sous windows? A la limite, je peux tester sous linux, mais bon ^^