gros noob : prob d'hyper vitesse avec _rowread - Page 1

salut je suis tout débutant en prog et j'ai suivirt le tuto de squale92 qui était super et j'ai appris pleins de trucs géniaux notamment pour faire bouger un sprite en nivo de gris avec _rowread mais le prob c que la vitesse est tres elevée si je me fais bien comprendre. En clair dans le code qd on appuie sur la fleche de droite la variable qui correspond a la position X du sprite s'inscremente et le sprite peut alors se "déplacer" mais le probleme c que c trop rapide (je voudrai faire un jeu d'avions et si le plane va de gauche a droite comme un eclair ca va etre trop simple !)
bref aidez moi plz les boss du C

Le moyen le plus propre c'est d'utiliser une boucle qui réduit la consommation de CPU jusqu'à un certain temps.
Regarde dans le tuto de Squale le passage sur les timers, tu t'en sers pour attendre.

salut jackiechan merci pour la reponse je pense avoir compris comment on se sert des timers mais aps de la facon dont tu compte réduire la consommation de CPU si tu pouvais etailler un peu plus ton explication plz

C'est compliqué en fait.
Si ton prog utilise les niveaux de gris, ça ne facilitera pas la tâche.
Si ton prog est en noir et blanc, un simple appel à idle(); (dans une boucle) suffit.

Pour le cas des niveaux de gris, il faut écrire un certaine valeur à une certaine adrese de la TI (que j'ai oublié, bien entendu, mais ça ressembe à 0x600005).

ok bon je crois que je vais laisser tomber ce biais la (en + j'utilise els niveaux de gris)
y a pas une maniere moins "propre" pour faire ca ?

Utilise la boucle vide mais sans te préocuper de la consommation.

ired (USER_TIMER));

Un truc du genre : OSFreeTimer (USER_TIMER);
OSRegisterTimer (USER_TIMER, 1);
while (!OSTimerExp

(extrait de la doc modifié)

lol j'ai meme pas fait ca g juste fais avec une boucle for et ca marche d'enfer c tout a fait ce que je voualsi merci pour l'aide

Oui, et d'ailleurs ce que je te propose risque de ne pas marcher parce que je pense que tu as inhibé l'int5 (qui est utilisée par les timer) pour pouvoir utiliser _rowread correctement.

La méhode du for est bien mais pas parfaite, car le temps d'attente correspond à la fréquence du CPU donc si ton CPU est différent en vitesse ton programme sera plus ou moins rapide.

Le meiux dans ce cas est d'utiliser une interruption, or c'est assez complqiué, car il faut la rediriger et incrémenter un compteur dedans et dans ton programme il te reste à faire.

counter=0; while (counter<50);

Tu peux essayer de faire ça:

volatile unsigned short counter;
DEFINE_INT_HANDLER (_timer)
{
counter++;
}

void _main
{
//Sauvegarde l'ancienne interurption dans oldint1
OldInt1 = GetIntVec (AUTO_INT_1);
//Redirge cette interruption sur la fonction _timer
SetIntVec (AUTO_INT_1,_timer);

//Ta boucle
counter=0; while (counter<50);
....

//Restaure l'ancienne interruption
SetIntVec (AUTO_INT_1, OldInt1);
}

merci geogeo je vais essayer ta méthode aussi

Si tu utilises sa méthode, tu dois rediriger l'ai1 avant d'activer les niveaux de gris, sinon ils ne marcheront pas.

wé bon je vais essayer tout ca merci

C'est en effet le port 0x600005 qui peut être utilisé pour réduire la consommation du CPU.
Extrait de j89hw.txt:
$600005 -W Turn off OSC1 (and the CPU), wake on int level 6 (ON key) and ...
:7-5 -
:4 ... int level 5 (programmable timer)
:3 ... int level 4 (link)
:2 ... int level 3 (OSC2/2^19)
:1 ... int level 2 (keyboard)
:0 ... int level 1 (OSC2/2^11)
Note: Make SURE int level 6 is acknowledged before writing $00 to
this port...

Pour sauver le maximum quand on a du grayscale, c'est pokeIO(0x600005,0b10111);

JoseBove : (j'adore ton pseudo ) tu as aussi la possibilité de faire ton jeu avec GraphX 1.1. Comme ça, tu pourras mettre dans un timer la fonction qui lit le clavier puis affiche le sprite, et tu pourras régler la fréquence du timer précisément pour varier entre 1 et 256 frames par seconde.
Tu peux aussi le faire avec TIGCClib (DEFINE_INT_HANDLER + SetIntVec) mais il faudra "bricoler" pour éviter des plantages (GX fait ce bricolage pour toi).

Utilises GX oué, c dommage qu'elle ne soit pas vraiment connue par les programmeurs d'ailleurs ...

Thibaut :
Tu peux aussi le faire avec TIGCClib (DEFINE_INT_HANDLER + SetIntVec) mais il faudra "bricoler" pour éviter des plantages (GX fait ce bricolage pour toi).

Je ne comprends pas du tout ce que tu racontes, et je ne vois pas du tout ce qu'il faudrait "bricoler" en utilisant la solution "évidente".

Moi non plus, je ne comprends pas bien... Thibaut, pourrais-tu t'expliquer ?

Peut être l'histoire avec a5 pour utiliser les ROM_CALSS dans une interruption, mais TIGCC fait ça en enlevant OPTIMIZE_ROM_CALLS?

Si c'est juste ça, ça n'est vraiment pas dur. Ne pas faire un truc aussi simple soi-même est pour moi de la paresse...
Et n'importe quel forum fréquenté par des gens compétents donne la solution.

GX apporte beaucoup d'autres avantages :

* l'histoire du a5, bien sûr
* les fonctions timers ne sont pas exécutées dans l'interruption. Avec la méthode TIGCC, elles sont exécutées dans l'interruption, en mode superviseur. Cela signifie que si le temps d'exécution de la fonction est supérieur à la période de l'AI (à ne pas confondre avec la période du timer qui est plus grande), les AIs inférieures (notamment la n°3 et la n°1, et la n°5 elle-même bien sûr) ne peuvent pas s'exécuter => dérèglement de l'heure, clignotements des niveaux de gris
* le fait que les timers ne bloquent pas les AIs avec GX nécessite que les timers soient protégés contre la "ré-entrée" : un timer ne peut pas être appelé tant qu'il est en cours d'exécution.
* les timers de GX sont exécutables de 1 à 256 fois par seconde. La fréquence qu'on donne est un fréquence moyenne, car l'AI1 impose une période irrégulière. Mais GX compte le temps en virgule fixe afin de respecter impeccablement la fréquence demandée sur environ 10 périodes (ce qui est très bon).
* possibilité d'avoir jusqu'à 4 timers (chacun ayant sa propre fréquence, sinon y'a pas d'intérêt)

Il y a d'autres détails mais je ne m'en souviens plus.


nEUrOO : je suis d'accord avec toi

les fonctions timers ne sont pas exécutées dans l'interruption. Avec la méthode TIGCC, elles sont exécutées dans l'interruption, en mode superviseur.

Tu peux donner un exemple?

bah c'est clair !

Bah pas pour moi, tu veuit dire qu'en faisant des bidouilles avec le mask d'interruptions tu peux protéger l'interruption contre tout dépassement?

Non

"les fonctions timers ne sont pas exécutées dans l'interruption."
veut dire que les fonctions associées aux timers de GX sont exécutées en mode utilisateur, comme le reste du code du programme. Ca a l'avantage de ne pas bloquer l'interruption ni celles de priorités inférieures ET d'éviter les stack overflows car la pile superviseur ne fait que 256 octets (avec quelques variables locales, un tableau, des appels de fonctions, etc, on dépasse vite 256 octets !).


"Avec la méthode TIGCC, elles sont exécutées dans l'interruption, en mode superviseur"
veut dire que la méthode DEFINE_INT_HANDLER + SetIntVec peut provoquer des blocages d'interruptions si la fonction associée est trop longue et que la taille des variables locales ainsi que la quantité d'appels de fonctions est limitée.

Pourrais tu m'envoyer la source de Grphx qui s'occupe de gérer les timers?

Ca fait 1000 fois que tu le demandes ! t'as des problèmes de mémoire

Quand tu auras fini Graphx et quand tu diiffuseras les sources.....

C'était juste un trou de mémoire passager

[Mode memory=NULL]
Je peux avoir une version?
[/Mode memory=FULL]