Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Programmation C » Feeze? (9 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
geogeo Ecrit le: Vendredi 9 avril 2004 à 18:16 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Comment un programme peut-il gêler le processeur sans faire bugger à l'affichage??

Je pose cette question car il existe peut être un gros bug dans Arkanoid très rare qui bloque le jeu et la gestion des objets sans bloquer l'auto int qui s'occupe des niveaux de gris. Ce bug est peut être survenu à cause d'un manque de mémoire et de la réservation d'un espace avec malloc? Quoi qu'il en soit je cherche à avoir plus de précisions pour isoler ce bug et le corriger.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°1   Marquer comme non lu.
Sasume Ecrit le: Vendredi 9 avril 2004 à 22:34 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Ça veut dire quoi sans faire bugger l'affichage ?

Sinon, un malloc qui échoue revoie NULL, donc si tu prends toujours soin de tester la valeur de retour, tu n'auras aucun problème.
    
./Post n°2   Marquer comme non lu.
geogeo Ecrit le: Vendredi 9 avril 2004 à 23:13 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Sans faire bugger l'affichage> Sans provoquer un clignottement important des niveaux de gris, bref un simple freeze.

Peut être que le gêle du jeu est survenu à cause d'une surcharge d'une interruption? Bloquant l'execution du programme principal?
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°3   Marquer comme non lu.
GoldenCrystal Ecrit le: Samedi 10 avril 2004 à 12:11 Déconnecté(e)    Voir le profil de GoldenCrystal Envoyer un email à GoldenCrystal Visiter le site WEB de GoldenCrystal Envoyer un message privé à GoldenCrystal  

Ben la réponse à ta question est simple:
Prenons par exemple la base -> Ton programme fonctionne bien
Puis une erreur sans barre noire se produit -> Comportement totalement aléatoire, ça peut être une boucle infinie, mais n'importe quoi peut se produire
Conséquence -> Le jeu est bloqué, mais pas l'affichage, puisqu'il est géré par l'interruption 1, qui n'a pas été changée avant le bug
Le seul cas où ça gêlerait l'affichage serait si tu essayais d'exécuter du code protégé contre l'éxécution...
Peut être que le gêle du jeu est survenu à cause d'une surcharge d'une interruption? Bloquant l'execution du programme principal?
c quoi que tu appeles une surcharge d'interruption ?
Sinon, le programe principal peut s'être bloqué pour diverses raisons. Je pourrais énumérer ces raisons, mais la liste est infinie... (car un programme assembleur est totalement libre sur TI :))
Le meilleur moyen de résoudre un bug (hmm faudrait que je fasse un tuto là dessus, moi :p), c'est déjà de regarder ce que tu as changé depuis la dernière fois (changement du compilateur/linker (etc...), ou ajout/modification/supression d'une routine assembleur ou C, ou bien encore, l'optimisation d'une ligne de code,...), le problème a bien 75 % des chances d'être lié à ça (en fait c toujours lié, mais parfois trèèès indirectement...)
Ensuite, si tu ne trouves toujours pas, examine l'endroit où ce produit l'erreur, à ce moment là, si c'est du code C, des printf peuvent t'aider à suivre l'évolution du programme, et si c'est de l'assembleur, un opcode "illegal" peut servir de breakpoint pour te permettre de vérifier si la routine a le comportement attendu (en tout cas, avant de se lancer dans un déboguage comme ça en asm, regarde si tu sauvegardes bien tous les registres que tu utilises (sauf d0-d2, a0-a1), et si tu restaures bien les mêmes registres que ceux que tu as sauvegardés...)
enfin, tout ça devrait déjà être suffisant ^^
Kupo !
    
./Post n°4   Marquer comme non lu.
geogeo Ecrit le: Samedi 10 avril 2004 à 12:57 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Je vois mais il n'existe aucune boucle dans mon code pouvant provoquer ce genre de plantage. J'execute beaucoup de code dans mon interruption pour gérer chaque objet sur le jeu et ce bug s'est produit lors de l'affichage de 50 billes, 3 monstres, 3 raquettes et plus de 20 bonus sur l'air de jeu. Je ne sais pas où ce bug peut ce produire et comment il s'est produit donc impossible de vraiment placer correctement des illegals... Je vais essayer de voir si s'est juste la boucle principale du jeu qui plante mais cela m'étonnerait énormément.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°5   Marquer comme non lu.
GoldenCrystal Ecrit le: Samedi 10 avril 2004 à 14:24 Déconnecté(e)    Voir le profil de GoldenCrystal Envoyer un email à GoldenCrystal Visiter le site WEB de GoldenCrystal Envoyer un message privé à GoldenCrystal  

Encore une fois je te rapelle que ce n'est pas bien de mettre beaucoup de code dans une interruption... ça peut empêcher l'activation d'autres interruptions (celle des niveaux de gris notemment, voire celle de polysnd si tu la mets dans arkanoid...), et on peut parfaitement se débrouiller autrement, ce qui rend par le même occasion le code plus propre et plus lisible =) Et puis c peut-être pas non plus très pratique pour le débogage.

Sinon pour les sources de bugs, je rapelle que le programme est stocké en RAM et peut très bien se modifier lui même suite à un bug -> comportement totalement imprévisible.

Et est-ce que le code marchait dans ce cas avant, ou tu viens juste de te rendre compte qu'il ne fonctionnait pas ? (Si il marchait avant, qu'est-ce que tu as modifié ?)
Kupo !
    
./Post n°6   Marquer comme non lu.
geogeo Ecrit le: Samedi 10 avril 2004 à 14:59 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Je viens de corriger le bug. Une interruption me paraît indispensable pour gérer tout les objets à des vitesses de déplacements stables et variables. Je viens à l'instant de penser à un truc pour soulager l'interruption.

Maintenant dire que mettre du code dans une interruption n'est pas très lisible ni 'propre' c'est tirer par les cheveux. Je ne vois pas autrement pour déplacer des objets à la même vitesse quelque soit le framerate.

Maintenant ce qui est très difficile dans Arkanoid s'est de gérer une multitudes d'objets (dans ce cas plus de 50) sans ralentir considérablement le jeu et mon bug est apparu dans ce cas là, autant dire très rare.

En tout cas un déboggeur ne m'aurait pas aidé et encore moins les printf... inutilisables.

Pour le programme qui s'auto modifie je n'ai jamais eu ce problème. :)

-Edité le: Samedi 10 avril 2004 à 15:00 par geogeo-
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°7   Marquer comme non lu.
GoldenCrystal Ecrit le: Samedi 10 avril 2004 à 15:09 Déconnecté(e)    Voir le profil de GoldenCrystal Envoyer un email à GoldenCrystal Visiter le site WEB de GoldenCrystal Envoyer un message privé à GoldenCrystal  

Maintenant dire que mettre du code dans une interruption n'est pas très lisible ni 'propre' c'est tirer par les cheveux. Je ne vois pas autrement pour déplacer des objets à la même vitesse quelque soit le framerate.
Ben, une méthode que je considère propre, c'est:
#include <tigcclib.h>

volatile int tick = 0;

DEFINE_INT_HANDLER(MyInt5) {
  tick++;
}

void animate()
{
  // Gestion des objets et tout...
}

void _main()
{
  int loop = 1;
  INT_HANDLER OldInt5 = GetIntVec(AUTO_INT_5);

  SetIntVec(AUTO_INT_5, MyInt5);
  while (loop) {
    while (tick) {
      animate();
      tick--;
    }
    // Code de dessin et autres...
  }
  SetIntVec(AUTO_INT_5, OldInt5);
}
Enfin, l'essentiel, c'est que tu aies résolu ton problème :)

-Edité le: Samedi 10 avril 2004 à 15:10 par GoldenCrystal-
Kupo !
    
./Post n°8   Marquer comme non lu.
geogeo Ecrit le: Samedi 10 avril 2004 à 15:21 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Ouai y a de ça, confère code source pour plus de détails.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°9   Marquer comme non lu.
Folco Ecrit le: Samedi 10 avril 2004 à 15:57 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Plutôt que le illégal pour le débogage, un macro genre _HALT est beaucoup plus souple d'emploi
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
  :: Index » Forum Ti68K » Programmation C » Feeze? (9 réponse(s))
Pages : 1/1     « [1] » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 39.68ms avec 18 requetes