Quelques questions... - Page 1

Bon, j'ouvre un topic pour y poser de nombreuses questions de nioob sur TIGCC :]...

Ma première question est : comment définir un window pour l'utiliser dans DrawClipRect ? J'ai beau essayer de suivre ce qui est indiqué dans la doc mais ça me met des warnings de partout... Résultat, obligé de coder un void rectangle(int x1, int y1, int x2, int y2, int style) du plus mauvais effet :/

Ma deuxième : comment utiliser OSdequeue pour vider le buffer clavier ? Aec gkeyflush, ça marche une fois sur 3000

DrawClipRect s'utilise de la façon suivante si tu veux faire un rectangle :

void DrawClipRect (const WIN_RECT *rect, const SCR_RECT *clip, short Attr);
Donc si tu veux faire un rectangle dans l'écran V200 dont le coin supérieur est (10,10) et le coin inférieur droit (60,20), tu devra taper en truc du genre :

DrawClipRect (&(WIN_RECT){{10,10,60,20}}, &(SCR_RECT){{0,0,239,127}}, B_NORMAL);

[edit] cross... itoo

[edit] cross...

avec des fonctions qui ont des prototypes à la con comme DrawClipRect, ça ressemblera difficilement à qqchose de propre; tu peux faire comme ça par exemple :

SCR_RECT clip = {{0, 0, 239, 127}};
DrawClipRect(MakeWinRect(x1, y1, x2, y2), &clip, mode);

ou bien encore plus moche si tu veux (avec tigcc il me semble que ça passe) :

DrawClipRect(MakeWinRect(x1, y1, x2, y2), &(SCR_RECT){{0, 0, 239, 127}}, mode);

pour OSdequeue aucune idée, jamais utilisée, y'a que _rowread qui serve sur ti :]

En ce qui concerne le GKeyFlush() normalement ça marche trés bien. Le problème que tu dois avoir c'est un truc du genre :

while (!_keytest(RR_ESC));
GKeyFlush();
//Fin_du_programme

Ce genre de GKeyFlush() est inutile car l'utilisateur appui trop longtemps sur le touche et donc il appui sur la touche aprés l'appel de GKeyFlush.

Zephyr :
Ou bien encore plus moche si tu veux (avec tigcc il me semble que ça passe) :

DrawClipRect(MakeWinRect(x1, y1, x2, y2), &(SCR_RECT){{0, 0, 239, 127}}, mode);

Je programme moche

Au fait j'ai trouvé ça dans la doc :

In GNU C (like TIGCC is), it is generally faster to use this cast constructors instead of calling MakeScrRect:
s = (SCR_RECT){{x0, y0, x1, y1}};

Donc je programme "moche" mais rapide

hmm non, si tu dois tracer plusieurs rectangles, comme la zone de clipping est constante (taille de l'écran), il vaut mieux (c'est plus rapide de) la définir une seule fois plutot que de reconstruire la structure à chaque appel. par contre l'appel à "MakeWinRect", si c'est une fonction, fait perdre du temps (j'ai pas vérifié si c'était une macro ou pas)

Ah oui si c'est pour un usage répétitif je suis d'accord MEA CULPA

faut juste voir ce qu'il veut en faire, si c'est pour ne tracer qu'un rectangle pendant toute l'execution du programme, vaut mieux faire comme tu proposes

moi j'aurais plutôt pensé que l'utilisation de MakeWinRect (qui est un ROM_CALL) est plus lente dans tous les cas.
sinon je pense que lorsqu'on passe en parametre le cast constructor, les valeurs constantes sont directement traduites en empilage de constantes sur la pile dans le code alors que si on passe par une variable intermediaire, il faut rajouter les temps d'accès en lecture de cette variable.

enfin qd on fait appel à des fonctions ultra-rapides comme DrawClipRect(), je pense que le temps de passage des arguments n'est vraiment pas critique en temps la seule chose qui aura une influence visible sur le programme, c'est la taille du code... de ce point de vue-là MakeWinRect ne devrait pas être trop gênant (sauf si on ne change pas les coordonnées entre les différents appels), et pour ce qui est du passage des arguments il ne prend quasiment pas de place puisqu'il s'agit de passer un pointeur (pas besoin de copier le contenu de la structure sur la pile)

ok j'essaierai de me souvenir de makewinrect pour les rectangles :]

ou des cast constructor ...

euh oui en relisant je me rends compte que le "il" de la dernière phrase peut être ambigu, il fait référence au passage des arguments, pas à MakeWinRect()... (que l'on utilise MakeWinRect() ou un cast constructor, il suffit de passer un pointeur)

et en effet si les coordonnées sont des constantes, un cast constructor est préférable ^^

!up

quand on fait if (blabla || blublu), les deux |, c'est pas censé être l'équivalent du OU ?
Parce que je fais un code du genre :

int key;
key = 0;
while ((key != KEY_ENTER) || (key != KEY_ESC))
key = ngetchx();

Ça me réduit sensiblement la taille du prog et la boucle me fait n'imp

ben, oui, puisque si une condition est fausse, l'autre est vraie, donc le OU sera tjs vrai... j'imagine que tu voulais plutôt mettre un && ^^

Mmmmh moui faudrait que j'essaye avec des && ^^

Ah oui deux autres questions :

- Comment faire pour que le programme compilé sorte en deux fichiers, l'un en .89z et l'autre en ppg ?
- Qui peut sortir un "Mille Bornes" de son placard et me dire combien de cartes il y a de chaque dans le tas (je sais qu'il y a 106 cartes mais j'ai des doutes sur le nombre de 25, 50, 75, etc ^^ (le rapport avec le C est que je fais un Mille Bornes en C ))

Si tu utilises l'IDE, va dans le menu "project", "options" et coche la case qui va bien.

!up

IIl y a un probleme de vitesse que je n'arrive pas a comprendre.

Pourquoi ceci :

 int i;
for (i=0; i<=159; i++)
{SetPlane(0);
BitmapPut(0,0,grisclair,&{SCR_RECT}{{0,0,i,99}},A_REPLACE);
SetPlane(1);
BitmapPut(0,0,grisfonce,&{SCR_RECT}{{0,0,i,99}},A_REPLACE);}

est 3 fois plus rapide que ceci :

 int i;
for (i=159; i>=0; i--)
{SetPlane(0);
BitmapPut(0,0,grisclair,&{SCR_RECT}{{i,0,159,99}},A_REPLACE);
SetPlane(1);
BitmapPut(0,0,grisfonce,&{SCR_RECT}{{i,0,159,99}},A_REPLACE);}

[edit]mauvaise memoire

dans le second cas, l'assembleur généré utilise probablement un dbra (decrement and branch) pour la boucle
cela implique que ton i est nécessairement stocké dans un registre, aussi => plus rapide pour le lire que s'il est en ram (ce qui est possible dans le premier cas)

aussi, ton scr_rect, tu devrais le déclarer en dehors de la boucle, dans une variable ; qu'il soit pas redéfini deux fois à chaque passage de la boucle
(le compilo le fait peut-être tout seul, mais pas gagné)

squale92 :
aussi, ton scr_rect, tu devrais le déclarer en dehors de la boucle, dans une variable ; qu'il soit pas redéfini deux fois à chaque passage de la boucle (le compilo le fait peut-être tout seul, mais pas gagné)

ah oue, pas bete (mais il faudra que je vois si ca va pas etre _trop_ rapide pour ce que je veux faire )

Martial Demolins :
Il faudrait voir le code généré pour comprendre mieux ce qui se passe.

oué, mais bien galère, maintenant, pour voir le code généré...
il faut passer par tigcc en mode debug, puis lancer le prog sous tiemu, et sous tiemu, ouvrir le débugguer en mode source...
(vu que le switch qui avant servait sous tigcc pour avoir les fichiers asm générés avec commentaires sert maintenant aux infos de debug)
(cela dit, il doit toujours être possible d'avoir les .s, mais sans les commentaires... => utile seulement si programme bien court)

squale92 :
il faut passer par tigcc en mode debug, puis lancer le prog sous tiemu, et sous tiemu, ouvrir le débugguer en mode source...

et vu que ti-emu rame chez moi, je vais etre oblige de filer le code source C de ce que je fais, code source digne d'un debutant pas doue

tu fais un prog tout petit contenant juste ce que tu veux voir
tu compiles, en désactivant la suppression des .s (dans le temps, y'avait une option dans tigcc ide pour ça)
=> tu auras les .s ; non commentés...
mais si tu poste le code asm et le code C du petit programme, ça devrait être possible de s'y retrouver

naPO :
Pourquoi ceci :

 int i;
for (i=0; i<=159; i++)
{SetPlane(0);
BitmapPut(0,0,grisclair,&{SCR_RECT}{{0,0,i,99}},A_REPLACE);
SetPlane(1);
BitmapPut(0,0,grisfonce,&{SCR_RECT}{{0,0,i,99}},A_REPLACE);}

est 3 fois plus rapide que ceci :

 int i;
for (i=159; i>=0; i--)
{SetPlane(0);
BitmapPut(0,0,grisclair,&{SCR_RECT}{{i,0,159,99}},A_REPLACE);
SetPlane(1);
BitmapPut(0,0,grisfonce,&{SCR_RECT}{{i,0,159,99}},A_REPLACE);}

Probablement parce que BitmapPut préfère que les clippings clippent la partie droite plutôt que la partie gauche ? (cela dit, je ne vois pas pkoi ça serait le cas, dans les deux cas il n'y a aucun décalage à faire... encore une des bizarreries d'AMS ?)

j'ai constaté ça sous vti, et j pense que pour le code C que je sors, je peux faire confiance à vti

heu oui l'optimisation des dbra aurait plutot rendu la 2eme fonction plus rapide si je ne me trompe pas; au passage si tu veux gagner un tout petit peu, essaie à tout hasard de remplacer "i--" par "--i" dans ta boucle, je ne sais pas si gcc s'occupe de ça tout seul ou non