Ecran qui saute!! - Page 1

voila mon code

GrayOn();

debut:
while(!_keytest(RR_ESC))
{


if(_keytest(RR_LEFT))
{
while(_keytest(RR_LEFT));
if(aff==0)
goto debut;
x-=b;
OSContrastDn();
aff=*cont();
sprintf(a,"Cont %02d",aff);
ClearGrayScreen2B(GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
}
if(_keytest(RR_RIGHT))
{
while(_keytest(RR_RIGHT));
if(aff==s)
goto debut;
x+=b;
OSContrastUp();
aff=*cont();
sprintf(a,"Cont %02d",aff);
ClearGrayScreen2B(GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
}

DrawGrayStr2B(40,60,"Regler avec <- et ->",A_NORMAL,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
DrawGrayStr2B(47, 70, "ESC pour quitter", A_NORMAL,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
DrawGrayStr2B(68, 80,a,A_REPLACE,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));

GraySprite32_OR(2,24,32,dessin_C0,dessin_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite32_OR(63,23,32,barre_C0,barre_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(27,4,16,clair_C0,clair_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(70,4,16,fonce_C0,fonce_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(113,4,16,noir_C0,noir_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(c,31,16,gauche_C0,gauche_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(93,31,16,droite_C0,droite_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
GraySprite16_OR(x,31,16,bare_C0,bare_C1,GetPlane(LIGHT_PLANE),GetPlane(DARK_PLANE));
}
GrayOff();

mai a chaque fois que l'ecran est efface et redesiner ca saute comment empecher ca ????

Il faut faire du double buffering... Ca doit être qqpart dans la doc de TIGCC.

Et sinon, petit conseil : essaye de faire "void *light=GetPlane(LIGHT_PLANE),*dark=GetPlane(DARK_PLANE);" puis de remplacer les "GetPlane(LIGHT_PLANE)" par "light". Il y a des chances que ça réduise la taille du programme, et en tout cas ça sera sûrement plus lisible...

Je ne comprends pas tout à fait où est ton problème.
Premièrement, utilise STP la balise [ pre ] pour ton code source, parce que là c'est difficile...
Sinon, je pense que dans ton programme actuel, tu n'as pas la nécessité de dessiner ton écran en boucle. En fait sors le dessin de la boucle où tu gères les touches. Tu n'a besoin de redessiner l'écran que si quelque chose a changé.
Deuxième possibilité: le double buffering. C'est certainement le plus simple, mais je ne connais pas puisque je ne m'en suis jamais servi.
rayStr2B(40,60,"Regler avec <- et ->",A_NORMAL,clair,fonce); [...] memcpy(GetPlane(LIGHT_PLANE),clair,LCD_SIZE); memcpy(GetPlane(DARK_PLANE),fonce,LCD_SIZE); }

Une autre possibilité est de dessiner sur deux buffers à la place de GetPlane(LIGHT_PLANE) et GetPlane(DARK_PLANE) et de ne les copier sur l'écran qu'à la fin. En clair:char *clair=malloc(LCD_SIZE), *fonce=malloc(LCD_SIZE);
while(1)   {
  memset(clair,0,LCD_SIZE);     //Efface l'écran
  memset(fonce,0,LCD_SIZE);     //Efface l'écran
  DrawG

Tu comprends?

oui mai avec extgraph ca donne koi??

Ben ça donne ça.

je ne voit pas pk utiliser un memset!!!!!

Et si tu lisais les posts, tu aurais vu :

Il faut faire du double buffering... Ca doit être qqpart dans la doc de TIGCC.

qui est la réponse à ta question

Au passage: http://tigcc.ticalc.org/doc/gray.html#GrayGetPlane

GrayGetPlane
void *GrayGetPlane (short plane);

[...]
Deprecated alias: GetPlane

J'en ai marre de voir les gens utiliser sans arrêt les noms marqués dépréciés dans la doc (et ceci depuis plusieurs mois déjà). Je me demande s'il y a un moyen de mettre l'attribut deprecated à une macro comme #define GetPlane GrayGetPlane, comme ça vous aurez un beau warning à chaque utilisation...

y'a pas de mal à les utiliser, et c'est très courrant dans le monde professionnel, car ça correspond le plus souvent aux prototypes connus par le plus de personnes possibles...

Pourquoi vous avez changé de nom ?

vince
: y'a pas de mal à les utiliser, et c'est très courrant dans le monde professionnel, car ça correspond le plus souvent aux prototypes connus par le plus de personnes possibles...

C'est à cause de gens comme ça que des projets comme GCC ne déprécient pas seulement, mais suppriment dans la release d'après. Jusqu'à présent, nous avons toujours opté pour la compatibilité maximum, mais vu les abus (fonctions dépréciées utilisés dans de nouveaux programmes, alors qu'elles ne sont là que pour faire marcher les vieux programmes!), je vais finir par faire comme eux!

Sasume
: Pourquoi vous avez changé de nom ?

Parce que toutes les fonctions de niveaux de gris ont maintenant un nom en Gray*.

./11 > Ce serait dommage...

qui sait...

exemple, y'a eu une vague de "deprecated" sur l'agl qu'on utilise au taf personne n'est passé aussitôt aux nouveaux si bien que dans la nouvelle version les deprecated ne passaient plus à la compil... résultat, les applis sont passé dans des moulinettes qui convertissaient les deprecated en verbes internes (qui étaient restés publics) au final ils regrettent amèrement leur changement (toujours inexpliqué) de nomenclatures vu qu'ils ont passé 90% du temps hotline//support sur l'année 2002 à aider les clients à se passer des verbes internes (qui eux allaient changer et les clients refusaient le nouveau produit si il n'était pas qualifié)

joli croisé avec kevin, réfléchis y à deux fois... il faut NECESSAIREMENT que la solution la plus simple ET la plus rapide pour l'utilisateur soit de migrer ses fonctions comme toi tu l'entends sinon il contourne...

Dans notre cas, il suffit de faire un remplacement global de GetPlane en GrayGetPlane, SetPlane en GraySetAMSPlane etc.! Nous avons juste changé les noms pour les rendre plus consistents (tous en Gray*), l'interface n'a pas du tout changé. Et ça m'a bien arrangé pour les niveaux de gris à 3 plans, parce que je n'ai eu qu'à remplacer Gray par Gray3P partout. (Les noms dépréciés n'ont pas été adaptés évidemment. Donc au plus tard si vous voulez passer aux 7-8 niveaux de gris, vous devrez de toute façon apprendre la nouvelle nomenclature.)

vince
: joli croisé avec kevin, réfléchis y à deux fois... il faut NECESSAIREMENT que la solution la plus simple ET la plus rapide pour l'utilisateur soit de migrer ses fonctions comme toi tu l'entends sinon il contourne...

Bref, tu es toi aussi pour jeter des warnings, voire des erreurs, en masse?

nan, je suis pour la conservation des synonymes tant qu'ils ne sont pas contradictoires ou réutiliser, quitte à alourdir un tant soit peu le compilo

tien d'ailleur comment on peut afficher 7 nivo de gris????

vince
: nan, je suis pour la conservation des synonymes tant qu'ils ne sont pas contradictoires ou réutiliser, quitte à alourdir un tant soit peu le compilo

Ben, c'est ce qu'on fait actuellement. Mais tu vois bien à quoi ça porte, et comme tu le dis toi-même "il faut NECESSAIREMENT que la solution la plus simple ET la plus rapide pour l'utilisateur soit de migrer ses fonctions comme toi tu l'entends sinon il contourne...".

Il faut dire que le problème est aussi en partie que les tutoriaux sont souvent préhistoriques (datant de TIGCC 0.91 ou 0.92) et pas mis à jour depuis des lustres. C'est de là que les nouveaux prennent les anciennes fonctions, dont, en étant nouveaux, ils ne devraient idéalement même pas connaître l'existence! Les nouveaux devraient repartir sur des bases nouvelles, mais les vieux tutoriaux les exposent à toutes sortes de vieux dérelicts. On trouve même des short _ti89; dans certains tutoriaux.

cerede2000
: tien d'ailleur comment on peut afficher 7 nivo de gris????

Avec mes routines. Ont vient d'ailleurs d'en parler, cf. topics/36707-fopen-et-argument.

avec graphlib, également

Bon sang, vous avez bientôt fini de faire de la pub pour les librairies kernel obsolètes? graphlib est dépassée pour plusieurs raisons:
* la moitié des fonctions qu'elle contient sont déjà dans la ROM, donc duplication inutile et gaspillage de place (surtout parce que la librairie est dynamique et qu'on ne peut donc pas tout simplement virer les routines qui ne servent pas),
* pas de support natif du double-buffering (alors que mes routines contiennent une version adaptée du double-buffering de TIGCCLIB).

* elles sont encore utilisées, donc non obsolètes
* de nombreuses fonctions sont plus rapides que celles de la ROM (c'est pas dur)
* troll powa !
* il pose une question, j'y répond.

Nan, graphlib est obsolète car Kevin ne l'aime pas, nuance.

Kevin Kofler
:

vince
: nan, je suis pour la conservation des synonymes tant qu'ils ne sont pas contradictoires ou réutiliser, quitte à alourdir un tant soit peu le compilo

Ben, c'est ce qu'on fait actuellement. Mais tu vois bien à quoi ça porte, et comme tu le dis toi-même "il faut NECESSAIREMENT que la solution la plus simple ET la plus rapide pour l'utilisateur soit de migrer ses fonctions comme toi tu l'entends sinon il contourne...".

Il faut dire que le problème est aussi en partie que les tutoriaux sont souvent préhistoriques (datant de TIGCC 0.91 ou 0.92) et pas mis à jour depuis des lustres. C'est de là que les nouveaux prennent les anciennes fonctions, dont, en étant nouveaux, ils ne devraient idéalement même pas connaître l'existence! Les nouveaux devraient repartir sur des bases nouvelles, mais les vieux tutoriaux les exposent à toutes sortes de vieux dérelicts. On trouve même des short _ti89; dans certains tutoriaux.

la solution est peut-être donc de proposer ET de maintenir a jour de tutoriaux compétitifs tout en restant compatible avec les versions en cours du compilateur...

pour graphlib, j'ai du mal a déterminer si c'est ta rancoeur contre le kernel ou une vraie raison qui...
*une fonction est en rom, si un doublon est plus efficace, pourquoi le refuser ?
*si on n'a aucunement besoin du doublebuffering pourquoi s'en encombrer ?

flanker
*on peut largement considérer une fonction obsolète même si elle est encore utilisée, cependant son remplacement n'est pas obligatoire
*
*#pascrayon#
* et un maximum de points de vue lui permettra de choisir librement

./25 il est possible en effet.

flanker *on peut largement considérer une fonction obsolète même si elle est encore utilisée, cependant son remplacement n'est pas obligatoire

cf le topic sur le C, qui n'est pas obsolète car on continue à s'en servir

Nan mais pour backgammon, graphlib ne sert à rien, surtout

et ouai ce ke je peut trouver graphlib???