Mon zelda ... - Page 1

Bonsoir tous le monde,

Voila, j'ai (presque) terminé ce que je voulais faire : un programme où on bouge Link sur l'écran.

Mais il subsise encore quelques problèmes.
D'abord, voici la source Fichier joint : Zelda.zip (dsl pour les innombrables commentaires ).

Voici donc les 3 problèmes que je vois :

-Ce n'est pas un gros problème (enfin), mais qu'en je compile le programme pour TI-Emu(émulant un HW 3.10) , il va environ 3x plus vite que sur ma TI-89T(HW 3.10) ou que sur VTI (HW 2.05). Donc au cas où essayez de changer #define WAIT xxx dans sprite.h (plus il est grand plus c'est lent).

-On ne peut pas faire de diagonales (mais, je crois qu'il faut utiliser _keytest_optimized).

-ET SURTOUT, les 2 sprites formant un mouvement se succèdent mais beaucoup trop vite !! Voyez plutôt







Je pense qu'il faudrait mettre des pauses

ici

//Efface
Sprite16(*p_x,*p_y,SPRITE_HAUTEUR,zelda_Mask[*p_asav],GetPlane(DARK_PLANE),A_REVERSE);
Sprite16(*p_x,*p_y,SPRITE_HAUTEUR,zelda[*p_asav],GetPlane(LIGHT_PLANE),A_REVERSE);

//Fait les chgt de coord
*p_y += yaug;
*p_x += xaug;

et/ou ici

//Retrace a la nouvelle coord
Sprite16(*p_x,*p_y,SPRITE_HAUTEUR,zelda_Mask[absc],GetPlane(DARK_PLANE),A_AND);
Sprite16(*p_x,*p_y,SPRITE_HAUTEUR,zelda[absc],GetPlane(LIGHT_PLANE),A_OR);


J'ai déjà essayé les For dans le vide (mais trop rapide) et les Timers (mais trop lent).
Ou alors le probleme se situe autre part ??

Sinon pour le _keytest, pour le ralentir, à chaque fois que l'on appuie sur une touche une Variable et incrémentée. Si celle si est égal à 100 on fait x++; (par exemple) et on remet la Variable à 0.
Peut être ce système (plutôt à l'arache ) pose problème et il y a sans doute une meilleur solution ??

(PS : Merci à tous les gars de ce forum qui répondent très rapidement,au tuto de Squale92, celui de TechnoPlaza , les auteurs de TIGCC, de TI-Emu, et VTI )

Je te conseille d'utiliser une librairie graphique qui permet de synchroniser la vitesse d'affichage avec des timers. Son nom est genlib.

Sinon, regarde dans la doc de TIGCC et peut-être aussi dans les tutos que tu as cités des infos sur l'utilisation des timers (indice : tu devras utiliser la fonction SetIntVec).

La fonction SetIntVec() sert bien à désactiver les AUTO_INT (1 et 5 ici ) ??

Sinon entre Genlib et Extgraph ??

Utiliser genlib implique que ton programme dépendra d'un "kernel" et d'une grosse librairie, je la déconseille donc.

Sinon pour le _keytest, pour le ralentir, à chaque fois que l'on appuie sur une touche une Variable et incrémentée. Si celle si est égal à 100 on fait x++; (par exemple) et on remet la Variable à 0.
Il y a sans doute une meilleur solution mais laquellle ??

Et sinon comment utiliser le double bufering ?

sam22 (./7) :
Sinon pour le _keytest, pour le ralentir, à chaque fois que l'on appuie sur une touche une Variable et incrémentée. Si celle si est égal à 100 on fait x++; (par exemple) et on remet la Variable à 0.Il y a sans doute une meilleur solution mais laquellle ??

Tu peux utiliser ton propre gestionnaire d'interruption pour l'auto-interruption n°5 (AUTO_INT_5) à la place de DUMMY_HANDLER, et incrémenter un compteur là-dedans (déclare une variable globale volatile unsigned short counter;).

Et sinon comment utiliser le double bufering ?

http://tigcc.ticalc.org/doc/gray.html#GrayDBufInit

Merci les gars pour vos réponses.
Je pense utiliser une librairie graphique mais avant j'essaye de me resstreindre à TIGCCLIB pour savoir comment sa fonctionne.

Je sais pas si ça peut aider:
http://tigen.org/pws_move/index.php?mod=articles&ac=commentaires&id=132

le résultat d'une soustraction c'est toujours zéro pour toi ?

C'est le principe des virgules fixes. Donc oui il y a des imprécisions. Mais c'est mieux que rien.

Ça permet de gérer des fréquences qui ne sont pas multiples de la fréquence de l'AI5. Il y a des erreurs, mais le calcul en virgule fixe fait que l'erreur moyenne est nulle (enfin presque, il reste des erreurs de l'ordre de T_AI5/32768 (où T_AI5=1/AI5_freq), mais...).

Par exemple, imagine une AI5 à 500 Hz <=> 2 ms et imagine que tu veuilles jouer un son à 167 Hz <=> 6 ms (donc la demi-période à 333 Hz <=> 3 ms). Le calcul en virgule fixe fera que, si on commence à un signal U=0 au moment t=0:
* t = 2 ms (1^er tic de l'AI5) ... r = 2 ms < 3 ms, on reste à U=0
* t = 4 ms (2^ème tic de l'AI5) ... r = 4 ms >= 3 ms, on passe à U=1, r -= 3 ms => r = 1 ms
* t = 6 ms (3^ème tic de l'AI5) ... r = 3 ms >= 3 ms, on passe à U=0, r -= 3 ms => r = 0 ms
* t = 8 ms (4^ème tic de l'AI5) ... r = 2 ms < 3 ms, on reste à U=0
* t = 10 ms (5^ème tic de l'AI5) ... r = 4 ms >= 3 ms, on passe à U=1, r -= 3 ms => r = 1 ms
* t = 12 ms (6^ème tic de l'AI5) ... r = 3 ms >= 3 ms, on passe à U=0, r -= 3 ms => r = 0 ms
etc., donc on arrive bien à un son à 167 Hz, alors que la demi-période n'est pas multiple de la période de l'AI5. C'est pour ça que PolySound utilise cette méthode, mais ça peut s'appliquer à n'importe quel programme.

[autosatisfaction]
Les timers de GraphX par exemple (c'est un système qui permet de lancer une fonction automatiquement, à une fréquence fixée librement par le programmeur).
[/autosatisfaction]

Ouais c'est ça (par contre, tu as voulu dire y=ax je suppose).

En fait j'ai trouvé la solution au problème de la succession trop rapide.
C'est juste qu'il ne fallait pas changer d'image à chaque changement de coordonnées mais plutôt tous les 6 changements.

Sinon, je n'est pas bien compris, quand on interrompt un AUTO INT, il n'est plus actif (par exemple pour le n°1 la verification à 350Hz ne se fait plus, c'est bien ça non??).
Parce que je n'aie pas bien saisie ceci ==> "Tu peux utiliser ton propre gestionnaire d'interruption pour l'auto-interruption n°5 (AUTO_INT_5) à la place de DUMMY_HANDLER, et incrémenter un compteur là-dedans (déclare une variable globale volatile unsigned short counter. " ça voudrait dire qu'on interrompt l'AUTO INT 5 toutes les n secondes (on choisis n grace à des incrémentation) ??

Dernière chose, quand on interrompt l'AUTO INT 1 (qui s'exécute 350 fois par seconde) pour utiliser le gris, cela signifie qu'à la place de l'exécuter, on fait des changements graphiques pour pouvoir afficher du gris ou bien c'est tout autre chose ??

Tu n'interromps pas les AUTO_INT.

Les AUTO_INT désignent des interruptions matérielles, ce sont elles qui interrompent ton programme pour exécuter un petit bout de code. Ces interruptions peuvent être déclenchées par plusieurs sources, en particulier par des timers comme pour l'AUTO_INT_5.

Le système d'exploitation de ta TI (AMS) utilise ces interruptions pour gérer certaines choses qui lui sont propres, mais tu peux choisir de les détourner, c'est-à-dire de remplacer le bout de code exécuté à chaque déclenchement de l'interruption par ton propre code, en particulier par du code qui ne fait rien (DUMMY_HANDLER).

l'AUTO INT 1 (qui s'exécute 350 fois par seconde)

On trouve cette valeur communément admise (sachant que le taux de déclenchement de l'AUTO_INT_1 varie de plus de 10% d'une machine à l'autre) des HW1 dans certaines docs, mais sur la quasi-totalité des calculettes qui sont toujours en activité (HW2, HW3 et HW4 = toutes les TI-68k depuis un certain moment de l'année 1999...), c'est 256 Hz

Thibaut (./18) :
[autosatisfaction]
Les timers de GraphX par exemple (c'est un système qui permet de lancer une fonction automatiquement, à une fréquence fixée librement par le programmeur).[/autosatisfaction]

Sauf que GraphX n'existe effectivement plus parce que le binaire ne marche plus sans recompilation et que tu as perdu les sources, et tu le sais très bien.

Je vois pas le rapport mais c'est pas grave. Sans doute as-tu ressenti l'habituel besoin de démonter le travail des autres.

C'est toi qui as ressenti l'habituel besoin de faire ta pub dans tous les topics, même quand c'est totalement hors sujet.

C'est toi qui l'a ressenti comme une pub. Tu peux parler niveau pub...

Xlib powa

Dehors, le gros troll velu