Forum TI-Planet.org

Hello,

j'ai un souci qui me prend la tête en ce moment et qui me fait tourner en rond, si quelqu'un a une idée géniale, je suis preneur.
Voici mon problème : pour le GUI Toolkit, je suis en train d'implémenter une forme de "Depth Buffer" afin de savoir sur quelle fenêtre on clique ou quelle fenêtre on survole.

Donc pour ce faire, chaque fenêtre (en fait chaque widget) se trouve accompagné d'une ID qui est en entier non signé compris entre 0 --> 999.

Ce ID est décomposé en trois chiffres (centaines / dizaines / unités) et chaque chiffre (compris entre 0 et 9) est "upscalé" pour avoir une composante (0 .. 255)
Ce qui fait que je me retrouve (enfin je suis sensé me retrouver avec un trio RGB (0..255, 0..255, 0..255).

Le problème est au retour : quand je clique qq part, je récupère la couleur du pixel correspondant dans le depth buffer, donc le fameux triplet RGB (0..255, 0..255, 0..255) et j'applique la moulinette inverse pour récupérer le Widget ID, mais par le jeux des arrondis, je me retrouve avec un décalage variable de 0 ou 1 qui fait que cela ne marche pas pour faire tourner le programme.

Je suis donc à la recherche d'un algo 100% bijectif (avec les arrondis pris en compte) qui permette de passer de mon WidgetID (0..999) -> RGB (0..255, 0..255, 0..255) et vice versa, retrouver mon Widget ID (exact) à partir d'une couleur RGB (0..255, 0..255, 0..255).

Eventuellement si ca peut aider, je peux limiter le Widget ID à 500 maxi, et possiblement même à 250.

Merci d'avance pour tout bonne idée.

Sly

Comment peux-tu avoir des erreurs d'arrondis en ne travaillant qu'avec des entiers ?

Bref, en notant % l'opération "modulo", comme en Python, si n est ton entier entre 0 et 999 :

Code: Select all

u = n % 10
d = ((n-u)/10) % 10
c = (n-u-10*d) / 100

puis

Code: Select all

r = 25*c
g = 25*d
b = 25*u

Réciproquement, on fait en sorte que r,g,b soient des multiples de 25 avant de retrouver c,d,u.

Code: Select all

c = (r - (r%25)) / 25
d = (g - (g%25)) / 25
u = (b - (b%25)) / 25
n = 100*c + 10*d +u

Bien évidemment, on peut faire plus simple s'il existe une opération de division entière (comme // en Python).

Salut Bisam,

merci beaucoup, ton algorithme fonctionne parfaitement (et ce que j'avais codé avant aussi d'ailleurs cela soit dit en passant). Je ne comprenais pas non plus le problème d'arrondi sur les entiers, sur papier ça devait fonctionner, mais dans les faits, ... et bien non !!

Initialement après avoir pris ta méthode, chacun des "digits" pouvait avoir soit la bonne valeur soit 1 en moins (par exemple le WidgetID 345, pouvait après le double encodage se retrouver entre 234 et 345). Bref problème ailleurs donc.

Investigation approfondi, mode "Columbo ON" ... En fait mon depth buffer était comme l'écran une SDL_Surface "true color", soit 16bits (sous le format 656, soit 6 bits pour le Rouge, 5bits pour le vert et 6 bits pour le bleu). Et le codage du vert (sur 5 bits au lieu de 6 me foutais la pagaille car il y a un arrondi non maitrisé dans l'algo de la SDL visiblement). C'est pas grave pour du rendu et de l'affichage, mais pour mon besoin, ca grille le principe. Ah, le fameux 'Green shift' du true color, voila une bien belle illustration de ses méfaits ...

En passant sur un codage 24bits cela fonctionne parfaitement (c'est luxueux pour un depth buffer, mais ca marche).

Merci pour ton aide.

Ciao

Sly

[...] soit 16bits (sous le format 656, soit 6 bits pour le Rouge, 5bits pour le vert et 6 bits pour le bleu)

Euh, je sais pas très bien compter mais il me semble que 6+5+6, ça fait pas 16 bits... Ce serait pas plutôt 5-6-5 ?

Oui effectivement
Si je compte comme ça aujourd'hui, pas étonnant que je code avec les pieds ...