Discussion :

[Mac LAK]

C'est quoi que tu appelle un blending,

Désolé, j'aurais dû donner le terme complet : "alpha-blending", c'est à dire une fusion avec transparence partielle suivant un canal Alpha. Dans ton cas, ton masque Alpha est équivalent au niveau de gris de ton image : à partir de ton halo lumineux (quelle que soit la couleur), tu génères le canal alpha comme si c'était une conversion en niveaux de gris => tu obtiens l'effet désiré, à savoir une "colorisation" de l'image sur une zone déterminée.

car moi mon halo ne fait que retoucher une image et éclaircir les bits de données au fur et a mesure que l'on se rapproche du centre indiqué.
donc pas de fusion, une retouche des bits seulement !!

C'est quand même une fusion : tu n'effectue pas une copie BitBlt, par exemple, n'est-ce pas ? ;-)
A partir de deux images différentes, tu en obtiens une troisième calculée, et tu n'as pas de possibilité de "retrouver" les deux images d'origine à partir de l'image recomposée.

[cyber_N]

Hello (RE) !!
Pour vous répondre à tous les deux:

Pour Mak Lak:
Pour ma part, je n'utilisait pas de fonction telles que AlphaBlending du GDI ou autres; Je me contentait simplement de retoucher les données mêmes de l'image donc les 3 niveaux BVR de l'image (je garde une copie des données originales de l'images pour pouvoir revenir à celle-ci, si besoin est)
ET DONC: PAS DE BITBLT() du GDI !!
Comme je l'ai dit précédemment, j'ai testé ce procédé en Win32 App. et ca marche nikel!! mais même optimisé, en MFC "Single document", quand je souaite ne serait-ce que rafraichir l'écran ... celui-ci est blanc !! (affichage/rafraichissement pas assez rapide)

Tu pourais alors me dire: Bon ok en Win32 App. ca marche .... mais avec plusieurs sources alors....
ET bien c'est pareil cela utilise le même temps de calcul vue que mes sources lumineuses sont tous redessinés au MEME moment!! Je veux dire en un SEUL parcours des bits de l'image pour y incruser les sources!! (faire varier vers le clair les octets R,V, et B au fur et à mesure que le pixel courant qui défile (qui parcours l'image entière) se rapproche des centres des halos; il faut fondre les intensités des couleurs car ces halos on des auras qui s'interpénètrent : il faut connaitre tous les centes avant le calcul bien sûr)

Pour Flo.:
Je crois que le traitement que j'effectue est semblable à celui dont tu me parle sauf que moi, je n'est pas de buffer à proprement parlé.
C'est l'image originale qui fait office de buffer.
Tu va très certainement me dire: oui, mais tu ne poura plus revenir à ton image originale. -> Mais si! en recopiant, au démarrage de l'éditeur et à chaque modification de la carte (sans lumières) les données images dans un tableau que tu te garde sous la main comme attribut de l'objet CBmp (oui j'en est fait une classe, c'est 100 fois mieux)
comme ca : tu verses le contenu du tableau "tampon" dans les données courantes de l'image. Comme ca, tu effectues des calculs minimum.
Comme tu l'a dit à la fin, l'expo. est à exclure enfin à mon sens, car ca passe du clair au noir ou inversement en 4,5 pixels !! c'est pour cela que jutilise les puissances seulement et là, ca fait un joli dégradé paramétrable.
PS: Je n'ai jamais touché aux technologies que tu appelles SSE3, MMX ou XMMX. J'en est entendu parler (en tout cas des performances). :

Pour Clad3:
Je excuse tout même pour: "Qu'en pensez-vous? Surtout toi Mak Lak....".
Même si tu n'est peut être pas vexé, je m'en veux quand même (si si, je t'assures).
Pour répondre à ta question, j'utilise les librairies standards MFC incluses automatiquement quand on lance un nouveau projet sous Visual C++.
(mais standards de chez standards)
Je vous tiendrais au courant (si j'arrive à vous revoir en tout cas toi Clad3 et Flo. sur ce post / envoyez moi vos @mails si vous le souhaitez à cnitron AT wanadoo.fr)

Pour le moment:
Bon ben, .... compte tenu du programme de tests que je viens de réaliser qui consiste à créer un objet CGluEngine (Glu étant une bibliothèque OpenGL) qui permet d'encapsuler les fonctions utiles pour créer un moteur 3D basique et de la simplicité de sa mise en oeuvre et surtout de l'OpenGL en tant que tel, je vais élaborer mon éditeur sur la base d'OpenGL.

J'ai déjà fait un projet avec Visual C++ en "Single document", intégré mon objet et appellé ses méthodes au endroit important comme OnSize (méthode : ReAjuster_scene(x,y) ) ou OnDraw (méthode : Dessiner_scene() ), etc....
et ca marche super bien !! Je pense que c'est sur cette base que je vais continuer. Je me tates de plus en plus, mais il est vrai que, comme ca, ca pourais préparer des projets futurs en 3D.

Pour ma part, je préfère travailler avec Glu que Glut !! (Glut a une structure de programmation qui me dérange surtout sa boucle principale et donc le fonctionnement de ses méthodes)
Voilà l'avancement du travail !!

[Clad3]

Même si tu n'est peut être pas vexé, je m'en veux quand même (si si, je t'assures).

bah te bile pas lol

Enfin bref :
re
J'entend souvent parlé des MFC, mais je n'ai jamais vraiment regarder ... pour moi ( j'ai peut etre tord lol ) c'est une grosse boite a outil permettant de gérer des application fenêtré ( menu , boite de dial ect ... ) .

Ca ne me semble en effet pas l'ideal pour un jeu
Comme tu la remarqué , openGL c'est trés sympa ! Je te conseil le couple SDL / openGL , c'est trés simple d'utilisation et portable bien sur .

voila
good luck ^^