Jette un oeil sur le tuto de prografix car il evitent la console, mais au prix d´un projet pas très propre.
L´idéal reste Devcpp et ses devpaks je pense

j´irai voir ça demain

dsl, pour la SDL j´étais à côté avec mes ignore specific lib ; j´utilise pas cette lib, mais dans beaucoup de projets libc(d) et mscvrt(d) font ch**r... bref :D

sinon pour le coup de la console... hmmm... en win32 on peut associer une console à un processus ( pratique par exemple pour faire des sorties textuelles immédiates sans passer par OutputDebugString), donc il a p-e moyen de faire l´inverse : une fois le processus créé, il y a p-e moyen de se débarasser de la console :-? Bon, j´en sais trop rien cela dit, mais il me semble que c´est un peu comme que sont réalisés les services nt ( maintenant le C# permet de le faire " facilement" mais sauf erreur de ma part, à l´ancienne, on fait une appli normale et on se débarasse en cours de route de toute la partie interface utilisateur). Tout cela est tres hypothétique mais si la console est un vrai probleme, c´est p-e une piste à creuser...

J´ai une petite question.
Est ce que on peut introduire du code SDL pour et les melanger avec du code graphique windows et LGV peut tu continuer ton expliquation sur les matrices

mélanger du code SDL et du code api win, a priri ce n´est pas conseillé, ça ne marche pas pareil, au niveau de la création de la fenetre graphique d´une part ( l´un te dmeande de faire un projet API win, l´autre console win), ni au niveau de la structure de gestion de surface d´autre part.

Cependant, ayant les sources de SDL, rien ne t´empeche de piquer a droite a gauche.
Tu pourrais charger une image en tant que SDL_Surface*, utiliser les opérations de rotation dessus, puis la convertir en format WinAPI, que je ne connais que trop peu.

Ruffi pose de temps en temps des questions sur MFC il me semble, donc il touche un peu a la prog Win Api, peut etre en sait il +.

Pour les matrices, tu veux la formule mathématique ?

" mélanger du code SDL et du code api win, a priri ce n´est pas conseillé, ça ne marche pas pareil, au niveau de la création de la fenetre graphique d´une part ( l´un te dmeande de faire un projet API win, l´autre console win), ni au niveau de la structure de gestion de surface d´autre part.

Cependant, ayant les sources de SDL, rien ne t´empeche de piquer a droite a gauche.
Tu pourrais charger une image en tant que SDL_Surface*, utiliser les opérations de rotation dessus, puis la convertir en format WinAPI, que je ne connais que trop peu.

Ruffi pose de temps en temps des questions sur MFC il me semble, donc il touche un peu a la prog Win Api, peut etre en sait il +. "
d Ok

" Pour les matrices, tu veux la formule mathématique ? "
d:)Non plus haut il y avait lgv qui m´expliquer des chose sur les matrices j´ai pas tres bien compris

Pour ne plus avoir la console avec sdl c´est pas tres complique, il suffit de la detruire.
Tu appelles FreeConsole() au debut de ton programme.
Pour ca faut inclure windows.h

i_am_the_law > excellent !

inconnu : bah, si t´es pas familier, tu dois pas avoir de code sous la main pour gérer des matrices, donc pas la peine de te compliquer la tâche pour rien ( surtout pour une rotation...)

le point important dans ce que je disais c´est d´appliquer la transformation inverse à l´image d´arrivée plutôt que la transformation direct à l´image de départ.

X = ( x y)^t ( vecteur colonne)
X´ = ( x´ y´)^t

transfo. direct : X´ = R x X
ça revient à dire, je prends chaque pixel de mon image, je le rotate. Mais avec les erreur d´arrondi ( les coordonnées de pixels étant entieres), ça va te laisser des trous dans ton image. On est aussi obligé de clipper sans quoi on risque de tracer en dehors de l´écran

transfo.inverse : R^-1 x X´ = X
là on fait le contraire : pour chaque pixel de l´image d´arrivée, on regarde son antécédent dans l´image de départ. Du coup, plus possible qu´il y ait de trou. Et comme on ne parcours que la surface de l´image finale, on n´a pas a clipper.

Ensuite, tu verras qu´en faisant ça, la rotation est plutot " moche" et pixelisée... L´idée est dont d´effectuer qq opérations en plus.
quant tu fais :
R^-1 x X´ tu obtiens X~ de coordonnées flottantes, qu´on arrondit pour trouver X entier, pixel " antécédent". Ben en filtrant en bilinéaire, tu conserves X~ et tu fais une relation barycentrique faisant intervenir les 4 pixels voisins pour determiner la couleur du pixel rotaté. On peut aussi filtrer sur un voisinnage plus grand, à coup de spline et de gaussienne, ou alors supersampler l´image de départ, y´a plein de moyens différents.

Commence par la rotation, on reviendra sur le filtrage plus tard qi t´as des soucis.
Un exemple de ce que tu veux faire ( C/OpenPTC) :

http://netabarons.chez.tiscali.fr/downloads/oldschool.ace

( le rotozoom, ´tention c´est du fixed point)

Ah oui merci i_am_the_law

Sinon, pour votre problème de console, il y a une autre méthode encore plus simple :

depuis el ocde de la console, c´est très facile de récuperer son hwnd.

alors un petit :
ShowWindow ( ConsoleHWND,SW_HIDE);

et on en parle plus. Mais la console existe toujours, donc du code peut être exécuté dessus --> la facilité de débogage est conservée.

merci LGV tu pourrais stp faire un code ou on pivote un bitmapavec commentaire merci

ben regarde dans le lien que je donne 3 posts avant, y´a exactement ce que tu cherches, un(e ? ) rotozoom, donc rotation entre autre, plus zoom parceque sinon ça ne serait pas un(e ? ) rotozoom LOOOOL :D

ok j´ai vu mais ou telecharger le add-on pour avoir rotozoom

les " addons" ? . .. j´ai pas du tout saisir :/
y´a tout dans l´archive en théorie, le code du rotozoom, la lib openPTC, les headers, l´image utilisée et ça compile ; y´a meme le binaire, donc c´est *autonome*