Problème avec Extgraph - Page 3

Bon ben je crois que je vais arrêter la programmation sur TI parce que là....pfuiii

Sur Warcraft je suis rendu aux Privilege Violation

et sur Adventure in A World of Warcraft (whaou) je suis à Adress Error sur des If !!!

ah le mauvais

C'est pas ma faute c'est TIGCC qui est mal fait euh (aïe aïe aïe )

Non franchement y a des problèmes au niveau des répétitions de if ou de switch j'ai l'impression....
Ca plante alors que y a aucune raison....
Je rajoute un truc qu'il y a déjà 15 fois avant et ça plante !

Rising Sun :
C'est pas ma faute c'est TIGCC qui est mal fait euh (aïe aïe aïe )

C'est malin de repousser la faute de ton incompétence sur les autres... Si tu ne sais pas programmer, c'est uniquement de ta faute et pas de la nôtre.

Non franchement y a des problèmes au niveau des répétitions de if ou de switch j'ai l'impression....
Ca plante alors que y a aucune raison.... Je rajoute un truc qu'il y a déjà 15 fois avant et ça plante !

http://tigcc.ticalc.org/report.html
Si tu penses qu'il y a un bogue dans TIGCC, ce formulaire est là pour ça! Reporter le bogue là nous permet de le corriger (ou de te dire que le problème est dans ton code et où il se trouve, et éventuellement le corriger quand-même), râler n'apporte rien à personne!

10 contre 1 que le problème vient de lui, et même probabilité pour que ça soit une erreur d'inattention

Cf. le premier paragraphe.

Houla ! Eh c'était une blague !

Je vois pas quelle inattention pourrait conduire à ça... suffit que jerajoute un case/break pour que ça plante alors que y a rien de nouveau...

Rising Sun> Bon, pour GrayClipSprite32_OR_R, je laisse tomber ?

Rising Sun
: Je vois pas quelle inattention pourrait conduire à ça... suffit que jerajoute un case/break pour que ça plante alors que y a rien de nouveau...

Alors tu m'envoies ton code (en suivant les instructions là: http://tigcc.ticalc.org/report.html - en particulier, il me faut du code complet et compilable) pour que je puisse déboguer le problème.

PpHd
: Question: Tu t'y connais en interruptions ?

Bon, alors, qu'est-ce qui ne va pas ?

> Kevin : C'est fait
> Sasume : Ben de toute façon ça servira à d'autres personnes et ça améliorera la lib

De quoi tu me parles ?

cf post ./69

Mais comment veux-tu que je debogue si tu ne m'envoie pas le programme en question ?

Je te REdonne l'adresse

http://databob.free.fr/Upload/Warcraft%20Battles.zip

Oui je sais il y a une Privilege Violation quand tu quittes le jeu
Mais il suffit que t'enlève toute la partie acquisition de cible,
mouvement qui se trouve au début de la seconde boucle do
(tous les for(n=0;n<8;n++) et for(n=0;n<16;n++))

Voilà Happy Swimming dans mon splendide codage (huhu)

OK, je n'avais pas compris.
Je préfèrerais un programme où tu isoles le bug... Je n'ai pas trop envie de devoir lancer le jeu et de chercher une situation où le bug se manifeste.

Ce genre de bogues est souvent très difficile à isoler.

Je comprends, mais j'ai fait un test, et le clipping semble être correct. Je n'ai pas envie de passer du temps à traquer le bug.

Je vais voir ce que je peux faire. Mais c'est le genre de bogue vraiment difficile à isoler.
En tout cas, je comprends parfaitement qu'il n'y soit pas arrivé lui-même.

Vraiment ?
Bon, ne te dérange pas pour ça, je le ferai.

Il n'y a rien qui dit que le problème est dans ExtGraph. Il pourrait très bien être dans TIGCC ou (le plus probable) dans son programme.

Il y a un rte à 0x7f004 qui est exécuté en mode utilisateur. Devant, il y a: 00 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07. Après, il y a: move.w %d0,0x600018; move.w #0x18,%d0; 0: dbf.w %d0,0b; move.b 0x60001b,%d0; not.b %d0; andi.w #0xff,%d0; rts, bref notre fonction _rowread.

Voilà le dump du linker:

   clrscr:
   ../../lib/tigcc.a .text: (local)
     0x002C34: 20 78 00 C8 20 68 06 74 42 A7 4E 90 58 8F 20 78 00 C8 20 68 06 78 4E D0
   Segment: ../../lib/tigcc.a (Code, All Relocs Included)
   ../../lib/tigcc.a .text end: (local)
   __dummy_handler__:
   ../../lib/tigcc.a .text: (local)
     0x002C4C: 4E 73
   Segment: ../../lib/tigcc.a (Code, All Relocs Included)
   ../../lib/tigcc.a .text end: (local)
   _rowread:
   ../../lib/tigcc.a .text: (local)
     0x002C4E: 33 C0 00 60 00 18 30 3C 00 18
   L1: (local)
     0x002C58: 51 C8 FF FE 10 39 00 60 00 1B 46 00 02 40 00 FF 4E 75

Le problème est que quelque chose écrit 00 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 par dessus clrscr, et que donc le prochain appel à clrscr passe à travers, jusqu'à __dummy_handler__ qui fait un rte, et cela en mode utilisateur -> plantage.

Ah oui, il faudrait que je précise ce qu'il y a devant:

   Segment: WB data.o (Code, All Relocs Included)
   WB maps.o .text end: (local)
   names:
   tigcc_compiled.: (local)
   WB data.o .text: (local)
     0x0029B4: 46 61 6E 74 61 73 73 69 6E 00 00 00 00 00 00 00 00 00 00 00 43 61 70 69 74 61 69 6E 65 00 00 00 00 00 00 00 00 00 00 00 43 68 65 76 61 6C 69 65 72 00 00 00 00 00 00 00 00 00 00 00 46 75 73 69 6C 69 65 72 00 00 00 00 00 00 00 00 00 00 00 00 4D 6F 72 74 69 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 50 72 EA 74 72 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 6F 72 63 69 E8 72 65 00 00 00 00 00 00 00 00 00 00 00 00 42 72 69 73 65 73 6F 72 74 00 00 00 00 00 00 00 00 00 00 00 47 72 75 6E 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 68 65 76 61 75 63 68 65 75 72 20 64 65 20 6C 6F 75 70 00 54 61 75 72 65 6E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 68 61 73 73 65 75 72 20 64 65 20 74 EA 74 65 73 00 00 00 42 65 72 73 65 72 6B 65 72 20 74 72 6F 6C 6C 00 00 00 00 00 53 68 61 6D 61 6E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 6F 72 63 69 65 72 2D 64 6F 63 74 65 75 72 00 00 00 00 00 45 73 70 72 69 74 20 6D 61 72 63 68 65 75 72 00 00 00 00 00
   u:
     0x002AF4: 01 90 00 00 00 02 00 0D 00 05 00 01 00 00 00 01 00 02 00 00 02 58 00 32 00 04 00 14 00 08 00 01 00 00 00 07 00 00 00 00 03 20 00 64 00 06 00 1E 00 05 00 01 00 00 00 08 00 00 00 00 01 F4 00 00 00 03 00 16 00 06 00 05 00 00 00 00 00 00 00 00 01 C2 00 00 00 03 00 1E 00 08 00 06 00 00 00 00 00 00 00 00 00 FA 00 FA 00 01 00 0A 00 03 00 04 00 00 00 01 00 02 00 00 00 C8 01 2C 00 01 00 0C 00 03 00 04 00 00 00 03 00 04 00 00 01 2C 00 FA 00 02 00 0D 00 03 00 02 00 00 00 05 00 06 00 00 01 F4 00 00 00 01 00 0F 00 03 00 01 00 00 00 00 00 00 00 00 02 8A 00 32 00 03 00 17 00 08 00 01 00 00 00 0F 00 00 00 00 03 E8 00 64 00 02 00 23 00 09 00 01 00 00 00 10 00 00 00 00 01 C2 00 00 00 02 00 14 00 08 00 04 00 00 00 00 00 00 00 00 02 58 00 00 00 03 00 1A 00 04 00 04 00 00 00 00 00 00 00 00 00 FA 00 FA 00 02 00 0D 00 03 00 04 00 00 00 09 00 0A 00 00 00 C8 00 FA 00 01 00 0B 00 02 00 04 00 00 00 0B 00 0C 00 00 01 5E 00 C8 00 03 00 0C 00 03 00 02 00 00 00 0D 00 0E 00 00
   Segment: ../../lib/tigcc.a (Code, All Relocs Included)
   WB data.o .text end: (local)

Bref, ça m'a l'air d'être un débordement classique.

Le code fautif est:

   .L96: (local)
     0x000B42: 32 10 48 C1 30 51 20 01 E5 88 D0 81 E5 88 D0 88 D0 80 41 F9
     0x000B56: <4B: mapuni (->)>
     0x000B5A: 31 83 08 00

dans play dans WB game.o. Je vais avoir la source C correspondante dans un moment.

Voilà le code assembleur et la ligne C:

.L96:
#L146	mapuni[un[n][YTEMP]][un[n][XTEMP]]=n;// L'unité occupe une 2ème case  }  break;  }  }
	move.w (%a0),%d1
	ext.l %d1
	move.w (%a1),%a0
	move.l %d1,%d0
	lsl.l #2,%d0
	add.l %d1,%d0
	lsl.l #2,%d0
	add.l %a0,%d0
	add.l %d0,%d0
	lea mapuni,%a0
	move.w %d3,(%a0,%d0.l)

Contexte:

if(un[n][MOVE]==0)
{
switch(un[n][DIR])
			{
...
				case 4:
					if(mapnum[un[n][Y]][un[n][X]-1]==1 && mapuni[un[n][Y]-1][un[n][X]-1]==0)
						{
							un[n][MOVE]=1;														// L'unité bouge
							un[n][TEMP]=0;														// Début du mouvement
							un[n][XTEMP]=un[n][X-1];									// Coordonnées futures
							un[n][YTEMP]=un[n][Y];										// Coordonnées futures
// !!!!!!!!!!							VVVVVVVVVVVVV
							mapuni[un[n][YTEMP]][un[n][XTEMP]]=n;			// L'unité occupe une 2ème case
// !!!!!!!!!!							^^^^^^^^^^^^
						}
				break;
			}

Ah oui, l'offset calculé est 0x3E80, c'est-à-dire 16000, ce qui est de loin en dehors de la capacité de mapuni (800 octets).
Bon, si avec ça tu ne vois pas où se trouve l'erreur...

Tiens ben puisque tu as l'air motivé je t'autorise à debugger Formula 0 et tant qu'à faire le rendre compatible avec les dernières releases de TI-GCC (j'irais même jusqu'à le mettre en GPL, c'est dire si j'y mets de la bonne volonté )