Discussion :

[piponux]

OK, je vais m esquinter la dessus. Si je trouve comment faire, je posterai le code ici.
Mais ceci ne me parait valable que pour des formes ayant des couleurs uniformes.

[Kannagi]

Mais ceci ne me parait valable que pour des formes ayant des couleurs uniformes.

Tout dépend de ce que tu veux faire, si tu veux mettre une texture c'est possible avec cette méthode ( faudra calculer ce qu'on appelle les coordonnés de texture sur chaque ligne , ça sera surtout appliquer la texture qui sera plus complexe) , mais le mieux c'est que tu réussi la première étape ça serait deja pas mal

[Obsidian]

Hello,

Merci pour les encouragements Si je comprends bien il faut que je laisse tomber l'interpolation bilinéaire. Soit. Je vais donc aller chercher des infos sur la rastérisation.

Pas forcément, mais il faut vraiment se souvenir que, d'une part, calculer sinus et cosinus prend beaucoup de temps, même si ce ne sont pas les pires. Pour autant que je sache, parce que je ne me suis pas penché récemment sur le sujet, ces fonctions sont toujours estimées à l'aide de séries de Taylor, et donc en itérant sur les calculs jusqu'à ce que la marge d'erreur devienne inférieure à la précision du format des nombres que l'on utilise.

Une bonne idée, en revanche, consisterait à ne calculer qu'une seule fois sin(α) et cos(α) puisque l'angle de rotation est identique pour tous les pixels de ta figure et qu'il reste constant tout au long de l'opération. Tu stockes le résultat dans des variables et tu impliques ensuite ces variables dans ton calcul. Rien qu'en faisant ça, tu multiplies au moins par 10 les performances de ton programme…

Ça nous ramène également à ce que tu disais au-dessus : la grande mode, ces derniers temps, a consisté à dire qu'il ne fallait pas faire d'optimisation trop précoce – ce qui est vrai ! Mais il arrive aussi un moment où il faut se souvenir qu'en programmation, il faut raisonner de manière algorithmique et pas seulement algébrique et que contrairement à une idée répandue, le compilateur n'est pas omnipotent. Le plus gros piège étant justement que le programmeur ne peut pas déterminer facilement quelles sont les limites de son compilateur, et peut encore moins le faire de manière universelle. A minima, il faudrait au moins pouvoir expliquer au compilo que sin et cos sont des fonctions pures, c'est-à-dire sans effet de bord, pour qu'il puisse lui-même bufferiser leurs résultats… à condition d'être capable de reconnaître que les paramètres sont eux-mêmes invariants sur un bloc donné (la boucle). Donc…

Certes tu n es pas tendre mais ça ne me dérange pas. "Entrainement difficile guerre facile" comme on dit, et puis, c'est constructif.
Sinon . Peut on par exemple calculer les coordonnées uniquement des sommets d une figure quelconque qu on veut faire pivoter, appliquer cos et sin uniquement sur ces sommets, puis calculer les scanlines à partir des nouvelles coordonnées des sommets ?

Absolument. C'est du tracé en « fil de fer » et ça se fait énormément. Et si tu remplis la surface délimitée par tes vertex en faisant de la rasterisation, et que regroupes ces vertex par trois pour avoir des triangles et, ainsi, être sûr que la surface formée est toujours plane, et bien tu réinventes la 3D à polygones. C'est toujours cette approche qui est utilisée dans tout ce qui demande un rendu rapide. Les raytracers, à l'inverse, ont le droit de prendre leur temps pour modéliser des solides avec des fonctions mathématiques exactes. Arriver à faire cela en assembleur, en commençant par rasteriser un triangle puis en faisant pivoter des sommets dans l'espace était d'ailleurs un rite initiatique (ou à tout le moins un exercice populaire auquel tout le monde s'est frotté, comme tu le fais aujourd'hui) dans les années 1990, du temps des démos.

Ceci dit, ce n'est pas forcément le problème qui t'intéresse ici : soit tu fais d'un coté un tracé de figure et, de l'autre, une routine de roto-zoom universelle en bitmap, ce qui donne le résultat que tu connais, soit tu veux vraiment faire une ellipse inclinée (ce qui est, comme on l'a dit, un problème assez récurrent) et là, l'idéal reste de trouver la formule mathématique optimisée exacte dès le départ. L'ennui, c'est qu'il est pratiquement certain qu'il soit impossible de le faire pour un angle arbitraire et dans le repère de la machine sans recourir aux fonctions trigonométriques (bien que je sois incapable de le démontrer).

En particulier, l'algorithme de Brehensam s'appuie au départ sur une fonction, monotone de surcroît. Donc, il s'agit toujours de voir si l'on passe au dessus ou au dessous de la courbe, mais le « dx » est justement donné par la largeur du pixel. Avec une ellipse inclinée, on se retrouve avec plusieurs pixels sur une même droite verticale ou horizontale, et il faut pouvoir se déplacer dans les quatre directions.

Maintenant, si l'on accepte de revenir un temps aux fonctions trigo, il y a un moyen plus simple de tracer une ellipse inclinée que la matrice de rotation : le Lissajous. Autrement dit, passer en paramétrique avec x=h⋅sin(α) et y=v⋅sin(α+ω) (ou cos pour obtenir un cercle lorsque le déphasage est nul). Mais ça demande un peu de calcul quand même pour déduire les bonnes constantes de l'angle initial en début de traitement.

[Obsidian]

Le reste de la discussion concernant la reprise du jeu « PV2000 » a été déplacé vers une discussion propre : Ré-écrire « PV2000 » en SDL.