Ah oui c'est bien possible que la SDL casse les pieds dans son cas. J'évoquais juste la technique, je ne prétendais pas qu'elle était applicable ici (désolé si ce n'était pas clair).
Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D
Oui on est d'accord ce n'est pas l'approche la plus simple dans l'absolu. Si tu te fais suer à faire un moteur 2D basé sur des quads 3D, c'est pour atteindre des super performances avec des sprites de haute résolution (genre les derniers Rayman) ; donc tu ne vas pas gréver tes performances pour 10 lignes de code :)
Je ne pense pas que l'écriture d'un tel moteur soit hyper simple non plus (mais en libre il doit y avoir celui d'Aquaria), mais quand tu auras fait de l'OpenGL, tu verras que ce que je dis est bateau.
Pour suivre ton approche objet, je dirais que tu passes la grosse image (128x512 pour continuer mon exemple) au constructeur de ta classe AnimatedSprite, qui va :
créer une texture ; mon openGL est loin, mais ça doit être un appel de fonction pour créer l'identifiant de texture, et un autre pour passer les pixels à OpenGL (qui les mettre si possible dans la carte graphique).
Créer un quad avec comme coordonnées de texture : (0, 0),(0, 0.25),(1, 0.25),(1, 0). Les 0.25 c'est bien sûr 1/4 puisqu'il y a 4 frames. Là encore une poignée de lignes de code.
Ta méthode display sera elle aussi assez simple :
calcul de l'index 'i' de la frame en fonction du temps, avec le modulo, tout comme toi.
activer la matrice de texture (un appel), faire la translation selon l'axe V de '0.25 * i' (un appel).
affichage du quad (un ou deux appel j'ai un doute).
la c'est vraiment loin mais il doit falloir réinitialiser la matrice de texture au moins.
Ça me semble relativement simple. Bon après il commence à y avoir pas mal de moteur 2D libres qui ont l'air très sympa. En discutant avec un pote hier, j'ai découvert IndieLib et Polycode.
[^] # Re: Tuxfamily
Posté par GuieA_7 (site web personnel) . En réponse au journal Un planet francophone pour Blender. Évalué à 2.
Ah oui c'est bien possible que la SDL casse les pieds dans son cas. J'évoquais juste la technique, je ne prétendais pas qu'elle était applicable ici (désolé si ce n'était pas clair).
Oui on est d'accord ce n'est pas l'approche la plus simple dans l'absolu. Si tu te fais suer à faire un moteur 2D basé sur des quads 3D, c'est pour atteindre des super performances avec des sprites de haute résolution (genre les derniers Rayman) ; donc tu ne vas pas gréver tes performances pour 10 lignes de code :)
Je ne pense pas que l'écriture d'un tel moteur soit hyper simple non plus (mais en libre il doit y avoir celui d'Aquaria), mais quand tu auras fait de l'OpenGL, tu verras que ce que je dis est bateau.
Pour suivre ton approche objet, je dirais que tu passes la grosse image (128x512 pour continuer mon exemple) au constructeur de ta classe AnimatedSprite, qui va :
Ta méthode display sera elle aussi assez simple :
Ça me semble relativement simple. Bon après il commence à y avoir pas mal de moteur 2D libres qui ont l'air très sympa. En discutant avec un pote hier, j'ai découvert IndieLib et Polycode.