Je cherche une lib sdl permettant de tracer des lignes permettant d´inverser les couleurs.
Malgrès une petite recherche sur le site libsdl, je n´ai rien trouvvé de probant (y a pas mal de lib avec des fonctions de tracé de lignes, mais pas avec des fonctions de tracé permettant l´inversion de couleurs)

pas compris, c´est quoi "inverser les couleurs" ?

je connais peu SDL, mais sauf erreur de ma part, ce n´est qu´une surcouche aux API plus classiques, donc au final ca doit reposer sur les implementations des cartes graphiques actuelles.
Inverser une couleur presentement a l´ecran est une operation relativement complexe.. que tu geres ta chaine de swap (double buffering, triple buffering, etc.) a la main, ou que ce soit fait par l´appli, il te faudra sans doute passer par du post-processing.
Si SDL permet des formats de buffer et de couleurs exotiques (i.e. valeurs negatives, non clampees [0, 1], etc.), tu peux ruser avec du blending bien senti ; sinon ben on en revient au traitement de l´image affichee.
Ca se fait tres simplement avec des shaders (on cree une texture a partir du backbuffer,on la passe a un shader, il lit dedans et transforme les couleurs lues ; basique), mais avec ton api, aucune idee.. Meme si tu les moyen de "locker" ton buffer, si tu lis manuellement dedans ca va etre une horreur sans nom de lire dedans..
Bref qqun qui connait SDL pourra surement mieux t´aiguiller, mais je doute que cela soit trivial.

pour ma part j´ai compris la chose suivante :

(r, g, b) > (1 - r, 1 - g, 1 - b), avec r/g/b floats entre [0, 1]

si tu veux, je peut programmer ça en une seconde pour advio2, mais pour la SDL, je crois que tu va être obliger de le faire "à la main". Tu lis un par un les pixel qui compose ta ligne et tu les inverse, il y a pas mal de formule sur le net pour trouver les points qui constitue une ligne.

Sinon il faut regarder si avec la SDL il n´y a pas moyen lorsque tu copie une surface sur un autre de spécifier le type de copie que tu veux faire (copie, ou alors AND ou XOR etc, sur les pixel source et de destinations).

Nan justement il n´y a aucun argument type AND, OR etc...
Quand à utiliser des shaders c´est hors de question ici

Je pense que je vais devoir effectuer les calculs points par points (autrement dit, perfs excécrables...)... donc je pense en fait me tourner vers une autre API.
Merci pour votre aide

Le calcul point par point peut etre completement lourd en effet. Mais, ne parlait on pas d´optimisations, de paralellisation et d´instructions vectoriel il y a peu sur ce forum ?
Pourquoi ne pas plus se documenter sur le sujet et trouver de quoi faire ca avec des instructions du type MMX, SSE, 3DNow ou je-sais-plus-quoi ?

Nan, franchement, c´est aussi parcque ce m´interresse et que j´ai la flemme de rechercher

de toute facon, le plus long sera d´acceder la texture dans les buffers de ta carte graphique. l´optimisation de ton code... un peu rien a faire...

Je cherchais une lib reposant sur la sdl afin de disposer d´un code portable...

j´avoue que tu me colles la !

Cependant, quelques propositions (qui sont surement hors sujet cependant ) :

- si ton but est d´inverser les couleurs pour une surface donnée, pourquoi ne pas précalculer les images changées ?
ça te ferait 2 fois + d´images a stocker, mais tu pourrais les calculer pendant la phase d´initialisation du programme, ce qui ne demande pas un temps critique.
(PS : lock l´image une seule fois, change tous les pixels, puis unlock, car si tu lockes et delockes a chaque pixel, tu t´effondres)

- si ton but est de charger l´image en (par exemple) RGB ou BGR, selon les configs, essaie de faire une fonction de chargement d´image qui charge en RGB ou BGR selon le type de la carte (qui doit pouvoir se récupérer je ne sais trop comment)

- En ce qui concerne la gestion des couleurs, peut etre peux tu trouver ton bonheur dans le champ format de la structure SDL_Image, qui contient entre autre les données b_loss, b_shift etc... qui permettent, finalement, de définir comment amener les couleurs a terme...

Tu as quelques librairies sur le site de SDL, dans la rubrique "library" qui sont des add on, peut etre peux tu trouver ton bonheur la dedans ?
Pas d´autres propositions pour l´instant

+1 godrik

inutile d´essayer de meme penser a lire pixel par pixel dans ta texture..

"inutile d´essayer de meme penser a lire pixel par pixel dans ta texture.."

C´est vrai en partant du principe qu´il que l´image est dans la memoire de la carte graphique et qu´il faut la traiter a chaque rafraichissement sinon ca ne pose pas de probleme.

Completer mon post précedent j´ajouterai que l´optimisation que je proposais est tout a fait portable puisqu´il sagit uniquement de bien structurer son programme (donc sans appel a instructions spécifique a un processeur particulier). Le tout est d´avoir un compilateur qui vectorise le code lorsque c´est possible. Comme le fait le compilateur d´intel ou meme GCC (4.0 (environ)).

en parlant de vectorisation.
quelqu´un aurait il des informations sur comment ecrire du code pourqu´il soit vectorisé par les compilos ?

pour gcc je sais pas, mais pour icc, c´est facile : tu écrit du code normallement, et il le vectorise tout seul.

Sinon, avec vc++, les conteneur de la stl sont prévue pour "pouvoir" être vectorisé (enfin, les calculs qui se font dessus). Mais bien sûr, rien en garantie que ce soit fait.

ce qui est de GCC, apres un tres breve recherche sur le net je peux vous proposer seux sites :

http://gcc.gnu.org/projects/tree-ssa/vectorization.html
pour savoir ce qu´il faut [pas] faire.

Et http://linuxfr.org/~Montaigne/19587.html
pour voir qu´il y a du monde qui s´y interresse et qui disent des trucs interressant.

"C´est vrai en partant du principe qu´il que l´image est dans la memoire de la carte"

ok sur ce point ; si on se debrouille pour garder une copie "locale" maison dans son propre format de l´image a l´ecran, ca revient a un bete traitement ; en DX ca pourrait se resumer a un CopyRect, un Lock/Unlock et un filtre, mais ca reste quand meme tres loin de la souplesse et de l´efficacite d´un shader. Mais je doute que la SDL permette bcp de controle de ce point de vue :-? Avis aux experts.

La vectorisation est interessante pour le "processing" des donnees en lui meme, mais rappelons juste qu´au mieux, en SSE, tu traites 4 FLOATS a la fois > bcp de conversions a blancs pour rien ; autant faire du pseudo-fixedpoint maison et bosser sur des _int32, encore faut-il que les donnees soient alignees..

Sinon, pour la vectorisation, meme si certains compilos font de l´excellent boulot (merci ICC ;) ), plus on facilite la tache de ce dernier, plus c´est efficace : il y A des methodes pour favoriser la vectorisation et l´autovectorisation. Par exemple des arrangements de donnees alternatifs sont bcp utilises ; ex typique, au lieu de traiter des vector3 x/y/z avec du padding, on va traiter des tableaux de x, de y et z, cet arrangement permet de rendre trivial des operations paralleles, meme si c´est moins "immediat". Et bcp d´autres choses comme ca ; de meme il y a des astuces pour les autres technos, comme l´HT (decouplage et independance de plusieurs traitements imbriques), le netburst (operations bit a bit un poil differentes), etc.
C´est bcp s´embeter pour pas grand chose en general, mais il reste des moyens de "favoriser" ces choses dans certains cas ; cela dit si on un pb vraiment specifique, on preferera ecrire soi meme le code vectorise/parallelise grand coup de SSE inline et autres joyeusetes (ca marche d´ailleurs tres bien pour tout ce qui est convolutions, calculs matriciels, etc.)