etat d'un bit - Page 1

Voila mon pbleme je voudrais connaitre l'etat d'un bit a la position (x,y) d'une image BITMAP (160*100)
j'ai essayé peek_bit (Plan_C0, y*160+x+8)); mais ca marche pô (ca retourne tjours 0). Je pense que le deuxieme argument de peekbit doit etre limité?

avez vous d'autre solutions.?

[edit]
en fait je veux recopier le bit d'une image sur l'ecran mais a chaque fois ca fait du noir
GraySetAMSPlane(LIGHT_PLANE);
DrawPix(x,y,!peek_bit (Plan_C0+4+y*20,x));
GraySetAMSPlane(DARK_PLANE);
DrawPix(x,y,!peek_bit (Plan_C1+4+y*20,x));

La fonction peek_bit à besoin de 2 arguments (lle numéro du bit à tester de 0 à 7 et l'adresse ou ce bit doit être tester.

Tu devrais utiliser la fonction pixtest ou une fonction de ce genre pour tester un bit dans une image.

ouais c'est bien ce que je pensait peek_bit doit etre<8...
sinon, le probleme avec les fonctions graphique c'est qu'on peut les utiliser seulement sur un ecran

Ah ouai, regarde la macro de pixtest d'extgraph et change là à ta sauce.

bon j'ai fait

GraySetAMSPlane(LIGHT_PLANE);
DrawPix(x,y,!peek_bit (Plan_C1+4+y*20+x/8,7-x+(x/8)*8));
GraySetAMSPlane(DARK_PLANE);
DrawPix(x,y,!peek_bit (Plan_C0+4+y*20+x/8,7-x+(x/8)*8));

c'est plus compliqué mais ca marche presque

bon en fait je m'etait planté dans les plans donc maintenant ca marche Nickel

GraySetAMSPlane(LIGHT_PLANE);
DrawPix(x,y,peek_bit (Plan_C0+4+y*20+x/8,7-x+(x/8)*8));
GraySetAMSPlane(DARK_PLANE);
DrawPix(x,y,peek_bit (Plan_C1+4+y*20+x/8,7-x+(x/8)*8));

bon j'aurais p'tetre du chercher un peu avant de poster ...

Bha vive l'assembleur pour ca quand même ....

C'est plus simple en assembleur? enfin la c'est pas hyper compliqué quand meme

J'ai pas dit que ca c'était compliqué
Mais en C on arrive tout de suite a une epxression lourde ... en assembleur ca se fait bien ;-)

Euh, ton deuxième argument, 7 - x + (x/8)*8, il s'écrit 7 - (x & 7) non ?
tu te compliques la vie on dirait...

a ouais ben je connais pas trop les operateurs binaires, ah c'est plutot cool, quoique je viens d'essayer et ca prend 4 octets de plus...GCC aurait t'il une meilleure optimisation?
sinon x/8 ca s'optimise pas en x>>4?ou un truc dans l'style?

x>>3 car 2³=8

non c'est x >> 3... mais ça tu t'en fous de toute façon le compilateur le fait automatiquement. D'ailleurs j'ai écrit (x & 7) mais j'aurais aussi bien pu mettre (x % 8) ça revient au même (la première écriture est une optimisation mais elle est elle aussi automatique).
Ma manière de l'écrire prend plus de place ??? ça m'étonne, mais je ne connais pas assez l'assembleur pour faire plus de commentaires...
tu peux aussi l'écrire (-x-1) % 8 mais je ne vois pas en quoi ce serait mieux...

je ne ferais pas confiance au compilo a votre place

jackos king a raison meme x>>3 n'est pas optimisé

Il ne transforme pas x / 8 en x >> 3 ???

En fait, l'optimisation ou non de x%2 en x&1, ou de x/4 en x>>2, par exemple, dépend des options de compilation, il me semble (genre Os ou O3)...
du moins, ct le cas pour le prog sur lequel j'ai testé, il y a de ca maintenant fort longtemps

en gros, écrivez toujours ce que vous pensez : considérez que c à vous d'optimiser, pas au compilateur !
(et comme ça, votre code restera optimisé, meme sur un autre compilo )

Il me semble que x/4 ne peut pas être optimisé en x>>2, pour la bonne et simple raison que x/y est défini pour des entiers signés comme (x/y>=0?x/y:-((-x)/y)) (arrondissement vers 0 et pas vers l'entier inférieur).

Par contre, avec GTC, on peut mettre #pragma comp (fast_divide) pour optimiser x/4 en x>>2

Euh, ton deuxième argument, 7 - x + (x/8)*8, il s'écrit 7 - (x & 7) non ?

Il s'écrit même ((~x) & 7)

Pollux :
Il me semble que x/4 ne peut pas être optimisé en x>>2, pour la bonne et simple raison que x/y est défini pour des entiers signés comme (x/y>=0?x/y:-((-x)/y)) (arrondissement vers 0 et pas vers l'entier inférieur).

Par contre, avec GTC, on peut mettre #pragma comp (fast_divide) pour optimiser x/4 en x>>2

A mon avis la bonne solution est d'utiliser des entiers non signés, pas d'introduire un pragma qui fera bugger des programmes C valides.

cool ton truc pollux: 4 octets de gagné

nitro> Les programmes C valides n'utilisent pas ce pragma, c'est tout. Et personnellement dans tous mes programmes je n'ai jamais eu besoin de cette 'nuance' ; et comme en général on utilise un 'int' et pas un 'unsigned int' quand un nombre est compris entre 0 et 32767 (entre autre, parce que c'est très simple de faire (long)my_int, alors que c'est bien plus difficile de faire (long)my_uint - ce qui d'ailleurs pénalise fortement les 'unsigned int' précisément quand on doit utiliser les instructions de division comme divu... donc les int sont souvent adaptés à ce genre de problème), à mon avis c'est une option très utile qui peut faire économiser de la place (et de la vitesse!) à la plupart des programmes.

Il s'écrit même ((~x) & 7)

Euh mais oui, en plus je l'ai presque écrit mais j'oublie toujours l'existence de cet opérateur

x/y est défini pour des entiers signés comme (x/y>=0?x/y:-((-x)/y))

Oh là là... heureusement que je n'utilise quasiment que des unsigned short
Le modulo aussi est défini bizarrement ?

Sally Brown
: Le modulo aussi est défini bizarrement ?

Oui.
Et en plus, le débordement des nombres signés n'est pas défini en C, la réduction modulo 256, 65536 ou 65536² n'est garantie que pour les non-signés.

Moui, mais sur TI je crois qu'on peut faire cette supposition sans trop se tromper... Il faudrait changer bcp de choses pour se plier entièrement à cette règle, donc autant ne pas y penser

Faux, les optimiseurs de GCC vont faire n'importe quoi avec votre code!

Tu vas pas me faire croire que (unsigned int)(x+y) ne donne pas le même résultat que (unsigned int)x+(unsigned int)y... Ou alors beaucoup de programmes vont être breakés.

c'est tout a fait possible.. (enfin il me semble..)

./26> la logiqe voudrait que les deux expressions que tu propose donnent un résultat pas forcément identique...
enfin, il me semble, d'apres ce que mes prof ont dit sur les types et autres

Vous connaissez une différence entre l'addition signée et l'addition non signée sur un 68000 ?

Un exemple concret: les optimisateurs peuvent optimiser:
int a=...,b=...;
int x=a*a, y=b*b;
if (x+y<0) ...
en:
int a=...,b=...;
int x=a*a, y=b*b;
tout court, et c'est leur plein droit. Je ne pense pas que c'est fait actuellement sous cette forme (il n'y a pas encore de "value range tracking"), mais c'est prévu, et puis ce n'est qu'un exemple.