Je pense que ce poste à déjà été crée et si c'est la cas j'en suis navré. J'ai fait pasmal de recherche mais je commence à saturer.
Voila mon problème, j'ai crée une fenêtre sur laquelle je fait évoluer un personnage.
J'avais effectuer un premier jet en CMD, mon programme marchais parfaitement bien. Depuis peu, je suis passer en 2D en utilisant les même lignes de codes que celui du CMD sauf pour l'affichage. Mais au bout de quelques seconde de jeu, le programme plante. Je code actuellement sous neatbeans et je ne sais pas trop comment gérer les erreurs. J'ai donc décider de tenter de lancer le programme en mode débugueur (sans point d'arrêt) et le programme m'annonce qu'il y a eu un segementation défault.
D'après ce que j'ai pu voir sur les forum, certain dise que cela peu venir que le "event" s'empile sans jamais être dépiler ce qui justifie l'erreur mais je n'ai pas trouver d'autre information à ce propos.
Si vous voulez, je peux vous passer le code mais c'est pas très propre c'est pas commanter et il y a beaucoup de ligne... et j'oubliais que pour la compilation c'est pas éviendent surtout que j' n'utilise pas une version ressente de SDL j'utilise la version 1.2.13.
De plus, (je pense que le problème est lier) je n'arrive pas à lancer le ".exe" sans passer par l'IDE. Je suis ouvert à toutes propositions car actuellement, à cause de ca je vais devoir mettre un peu en pause mon programme, cela ne sert à rien de programmer avec une telle erreur...
En vous remerciant (je suis toujours a disposition pour donner des informations complémentaire).
Pourrais-tu préciser où la segmentation fault arrive, il se peut que ce soit de ton côté (chargement à l'infini de sources par exemple, c'est assez courant au début de SDL ^^). Si tu as un code à montrer (surtout les variables utilisé pour les textures)
Le faite que tu ne puisses pas lancé le .exe depuis ton explorateur de fichier est surement causé par le fait de le lancé depuis un nouvelle endroit (les programmes ont un chemin relatif dépendant de l'endroit d'où on les lancent). Il doit manquer des textures lors du chargement et ça crash.
Alors pour ce qui du chargement infini, je ne vois pas comment le vérifier. Comment puis-je te faire passer mon code ? (du moins la partie concernée)
Le point d'arrêt du debugueur semble se trouver lorsque que je prepart un "rectangle" (pas initialiser mais bien préparer)
Pour ce qui est de l'exe, le programme a l'aire de se lancer mais il s'arrête immédiatement, comme si il crashais et je suis aller vois dans mon "log" (les printf) et tout semble fonctionner correctemekt 😅 (genre ouverture de fichier et initiatialisation des éléments)
- Edité par VictorBravo 16 septembre 2020 à 10:23:44
Tu peux utiliser l'outil code ( </> ) pour poster ton code.
Pour vérifier le chargement à l'infini peut se voir avec le task manager de Windows avec la RAM qui augmente continuellement. Ici je ne penses pas qu'on le verra car on a l'air d'écrire là où il ne faut pas dans la mémoire.
Tu charges tes textures en plein milieu du jeu et a chaque tour de boucle quasiment, tu devrais les charger une fois pour toute au début du programme puis les libérer a la fin plutot que de le faire a tous les tours de boucle, ca n'a aucun interet.
Concernant ton problème, regarde le retour du pointeur après avoir chargé ta texture, car la, si le chargement échoue pour une raison quelconque, tu ne le vérifie pas, et si le chargement échoue ton pointeur sera null, et l'utiliser derrière amènera forcément a un crash.
J'ai fait un 1er essaye (je poursuivrais ce soir) mais pour le moment, rien de bien concluant. Après avoir affecter cube, j'ai fait afficher sa valeur et elle n'est jamais à 0. Ci dessous, le résultat des dernier lignes de mon printf du "cube" ajouter à la ligne 105.
Bah personnellement je le ferais crasher et je regarderais la variable qui est en cause du crash, puis je remonterais jusqu'au moment ou cette variable a pris une mauvaise valeur et je chercherais a comprendre pourquoi. par exemple si c'est bien cube qui est en cause il se peut que ce soit juste le chargement qui a échoué.
Pourquoi ? je ne sais pas je ne suis pas devin, il faut regarder les messages d'erreurs dans ta console.
Je n'ai pas de message d'erreur dans la console c'est mon plus gros problème mais je vais suivre tes conseils et essayer de voir si une valeur tombe à null alors qu'il ne devrais pas si non je crois que je vais encore stagner un moment sur ce problème ^^' dans tout les cas, merci de votre aide !
Ton printf() est en ligne 105, mais tu charges cube à l'intérieur des for() des lignes 63 et 65. Et tu ne libères jamais cube quand tu n'en as plus besoin (au minimum, sans fouiller trop profond dans ton code, après les lignes 74, 83 et 93). Au cas où tu l'ignores, faire un SDL_LoadBMP() crée une nouvelle surface, donc ton programme va consommer allègrement de la mémoire jusqu'à ce qu'il n'y en ai plus.
- Edité par edgarjacobs 16 septembre 2020 à 17:27:20
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Attention avec "cube" tu ne vérifie jamais si cube est null, ce qui témoignerait d'une erreur lors du chargement. Si tu ne test pas ton pointeur tu as possibilité d'envoyer le pointeur null dans ton code et c'est vraiment pas bon :/
Pour ce qui est de charger intelligemment les textures on va programmer orienté module (un module = une fonctionnalité / lot de fonctionnalités).
Dans affichage.c tu peux déclarer un tableau global statique, pour le partager à travers toutes tes fonctions et le garder privé. Ce tableau te servira à mettre tous tes pointeurs de textures utiliser. Tu dois donc les charger avec le init du module et les décharger avec de_init du même module. C'est un façon de faire très puissante de faire du code, même si un peu lourde (on est assez proche du fonctionnement objet du C++, en version plus archaïque xD ... et sans la surcharge T-T )
Merci de l'information BrigitteLPM mais le problème actuellement c'est que je ne sais pas vraiment faire de la programmation orienter objet, mais j'en prends bonne note pour mes futur mise à jours !
mais il est vrai que plus ca va et plus je me rend compte que c'est assez lourd à charger les textures (en théorie car en pratique je vois pas de problème pour le moment)
Et pour ce qui est de la gestion d'erreur, il y a pas mal d'endroit ou c'est très mal gérer et qu'il va faloir que je m'y mette.
Pour ceux/celle qui voudrais savoir, je laisse une petite capture d'écran de ce que je suis entrain de faire :
(je tiens à préciser que malgré le visuel simple à l'heure actuelle, le code est bien plus complexe de base, je passe à la 2D depuis moins d'un mois mais beaucoup de chose on été préparer prés 2D comme la génération du terrain)
- Edité par VictorBravo 16 septembre 2020 à 19:31:01
Merci de l'information BrigitteLPB mais le problème actuellement c'est que je ne sais pas vraiment faire de la programmation orienter objet, mais j'en prends bonne note pour mes futur mise à jours !
Edité par VictorBravo il y a environ 1 heure
Ce n'est pas de la programmation orienté, ça en est proche : par exemple on ne peut pas instancier (ou avec grande difficulté)
// .c
static int m_place;
static int m_size;
static Car **parking;
void Parking_init(int nbr_place){
parking = malloc(sizeof(Car*)*nbr_place);
m_place = nbr_place;
m_size = 0;
}
void Parking_size(){
return m_size;
}
void Parking_addCar(Car* car){
if(m_size != m_place){
parking[m_size] = car;
m_size++;
}
}
void Parking_removeLastCar(){
if(m_size > 0){
m_size--;
// on s'occupe pas de décharger
}
}
void Parking_free(){
free(parking);
}
Bon l'exemple est un peu inutile... et incomplet mais le principe est là.
Plantage de la page avec SDL
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent