PureBasic

Ce qu'on voudrait maintenant, c'est une explication claire et précise des fonctions #WM_ et co, et savoir pourquoi ça fait #WM_CAP_START + x, à quoi ça correspond etc...

On a également un autre problème: le calcul de variables.
On souhaiterait faire une division de 2 valeurs qui nous donne un résultat à virgule, or purebasic nous donne tout le temps la valeur approchée. Je pense savoir pourquoi: 5/2=2, mais 5.0/2=2.5
Notre problème, la division étant de la forme x/y: x est donné par une fonction, et n'est pas un nombre à virgule, y on peut s'en occuper avec des virgules, ce n'est pas un problème, mais notre résultat est arrondi à cause de x, serait t'il possible d'ajouter le .0 au résultat de la fonction, de façon à avoir un nombre à virgule dans notre division?

EDIT On a résolu le problème des Calculs avec les variables cependant on ne parvient toujours pas a comprendre l'histoire des #WM ...

Merci d'avance

Ce sont des constantes, merci de regarder là : http://msdn.microsoft.com/en-us/library ... S.85).aspx

http://msdn.microsoft.com/en-us/library ... S.85).aspx Merci, mais on avais déja vu ça. Le problème c'est qu'il n'y a aucune explication sur le fonctionnement général

Nous avons un problème de compréhension du code à cette partie:
Donc on a à peu près compris la structure avg, mais l'histoire de xx, yy, pos, color, bmp/bmWidth, << 2 on a un peu beaucoup de mal...
Ce qu'on sait/croit savoir:
xx = la largeur de la cam
yy = la hauteur de la cam
pos = la position, mais en quoi et où? La formule on a pas compris non plus...
Color = besoin d'une explication pour PeekL (*bits+pos)
Enfin << 2: << décale la valeur avant le "<<" de 2 bits vers la droite, une explication un peu plus simple peut-être?

Merci d'avance

Le PeekL() sert à lire un "long", c'est à dire les quatre octets donnant les 3 composantes couleur du point + l'alpha. On lui donne une position en mémoire : le buffer mémoire dont l'adresse est contenue dans le pointeur *bits, plus l'offset du long à lire.

Cet offset est calculé de la façon habituelle, sachant qu'une ligne fait x octets. Le <<2 est un décalage logique, c'est une façon "rapide" de faire une multiplication : <<1 multiplie par 2, <<2 multiplie par 4, <<3 multiplie par 3, etc. Ca ne s'apprend plus à l'école?

Donc la position du long à lire est (x + y*(nombre de points par ligne)) * 4

Ghost a écrit :La formule on a pas compris non plus...

je l'avais pourtant précisé dans ma réponse page 2 de ce topic

je me cite :

Dobro a écrit : je ne prends pour l'exemple que la composante rouge

d'abord il prends la couleur rouge presente a l'instant dans la cam (enfin dans l'image scanné)

Pos = (yy * bmp\bmWidth + xx) << 2 ; ceci correspond a la fonction point(x,y)
Color = PeekL(*bits+Pos) ; ceci aussi !!
avg\r + Red(Color) ; met le resultat dans la structure avg

faudrai voir a lire les réponses aussi

@Djes Merci, désolé de pas tout comprendre de suite, nous sommes quand meme dans la section "débutant" du forum.

@Dobro Merci aussi mais ce n'est pas la peine de prendre ce ton puisque tu n'as pas vraiment répondu à la question... Je pense que soit on s'est mal exprimé soit tu as mal compris. On a compris le but général de cette fonction, néanmoins on voudrait comprendre plus précisément le fonctionnement de cette autre méthode, ce qu'a commencé à faire Djes.

Merci, en tout cas, pour votre aide.

Pas de souci, le forum est là pour partager les connaissances. La chance avec PB est qu'il est assez bas niveau et que s'y retrouvent beaucoup de programmeurs oldschool, qui ont l'habitude des pokes et de l'assembleur. C'est un gros avantage pour les jeunes d'acquérir ces notions, à une époque où on est noyé dans les encapsulations qui cachent la réalité. C'est une chance aussi pour les anciens d'apprendre des méthodes plus pragmatiques de développement et de gestion de projets par des nouveaux venus. N'hésitez pas à poser des questions et à apporter ce que vous savez!

Pour le code, il permet simplement de faire une moyenne des couleurs par blocs de 16x16 ; on peut aussi imaginer ça comme un zoom arrière, ou une réduction d'image (/16) ; ça permet de réduire le nombre de traitements, et de travailler sur des données "normées" (0..1)

Dumli a écrit : @Dobro Merci aussi mais ce n'est pas la peine de prendre ce ton puisque tu n'as pas vraiment répondu à la question...

j'avais fini mon dernier message par " "

mais je prends note de ce que tu viens de dire
je vais te faire des vacances, crois moi <-- tiens là aussi ,mais note la différence

j'ai peut etre pas repondu a ta question, mais si je vous avait pas adapté le code posté par cirederff , tu attendrai encore une réponse a ta premiere question !!

faudrai voir a pas mordre la main qui vous donne a bouffer non plus

j'ai peut etre un ton qui te plait pas , mais toi non plus !

Je m'en doutais que tu allais réagir comme ça. Je n'ai jamais dénigré ton travail bien au contraire ! Je t'ai à chaque fois remercié pour tout le temps que tu nous consacres. Et je sais très bien que sans toi nous n'en serions pas aussi loin ! Mais je m'investis beaucoup dans ce projet malgré mes études en parallèle ; donc quand je vois qu'on me dit que je ne prends même pas le temps de lire les messages qui me sont destinés, je le prends mal voire très mal. Je pensais que tu me considérais autrement
Nous essayerons à l'avenir de nous exprimer plus clairement
Voila en espérant avoir été le plus clair possible.
Cordilement,
Tom

PS : Fin du message => => =>