Forum de la communauté SFML
Général => Suggestions de nouvelles fonctionnalités => Discussion démarrée par: Timidouveg le Mars 19, 2013, 04:03:05 pm
-
Bonjour à tous :)
En ce moment, j'ai besoin de récupérer l'identifiant de texture côté OpenGL d'une image ou une texture de SFML pour le lier avec un framebuffer object et ainsi afficher un cube 3D et texturé en rotation dans la couche 2D qui sert à l'interface graphique de mon jeu 3D. D'autres choses du même type auront besoin du même procédé et de plus cela permet d'utiliser les fonctionnalités de SFML (comme la simplicité d'utilisation entre autres) pour gérer les textures sans perdre l'accès à l'identifiant pour tout travail qui se fait côté OpenGL.
J'ai été surpris de constater que la méthode GetId() pour un sf::Image ou un sf::Texture n'existait pas. en me renseignant j'ai vu aussi qu'il n'est pas possible de l'ajouter par héritage car l'ID est private. Un sujet à ce propos a été écrit par quelqu'un d'autre sur l'ancien forum : http://www.sfml-dev.org/old-forum-fr/viewtopic.php?t=1709
En lisant la réponse de Laurent, je comprends que ce type d'accès soit interdit dans un sf::Image, étant donné l'existence maintenant de sf::Texture. Par contre, sf::Texture pourrait tout à fait, à mon sens, permettre cette liberté.
Je sais bien que c'est une porte ouverte à des manipulations non-sécurisées de la texture interne, mais dans le cas d'un sf::Texture, ce que j'attends de ses méthodes c'est de me simplifier la vie, pas forcément de trop restreindre mes possibilités.
Je ne suggère pas nécessairement de rendre l'ID public, mais plus tôt protected pour permettre d'ajouter des méthodes supplémentaires par héritage, non pas dans sf::Image, mais au moins dans sf::Texture. Au programmeur d'être assez rigoureux pour éviter de faire n'importe quoi et ainsi profiter de cette liberté. Se passer par exemple de l'attachement d'une texture SFML du plan 2D avec un framebuffer par exemple, c'est assez dommage, je trouve. Autrement, il faudrait recopier les pixels, ce qui est un peu plus lent et contraire au principe du FBO (oui je donne l'exemple pour mon cas).
J'espère ne pas avoir ouvert un sujet déjà traité ici, j'ai cherché avant, mais bon :)
Qu'en pensez-vous et qu'en penses-tu Laurent ?
-
Ton cas est le seul qui requiert d'accéder à l'identificateur de la texture. Pour tout le reste, l'accès à la texture se fait de manière indirecte, en l'ayant au préalable bindée -- chose qu'il est déjà possible de faire avec sf::Texture::bind. Du coup ça me gêne d'ajouter une fonction dans l'API pour un cas aussi particulier.
-
Justement, je propose juste de baisser le niveau de protection de l'identifiant pour laisser le programmeur ajouter ses propres fonctionnalités plus spécifiques par héritage. Un utilisateur qui n'a pas ce type de besoin, se contentera d'utiliser sf::texture tel quel et l'identifiant étant protected ne pourra pas être extrait puisque sf::texture n'a pas de méthode pour ça. Dans mon cas, je ne compte pas nécessairement ajouter par héritage ce genre de méthode mais plus tôt une méthode qui prend en argument le FBO et laisse ma texture attacher son identifiant en interne. Bien sûr, ça n'empêche pas un autre programmeur d’opter pour l'extraction de l'id à l'extérieur, mais bon.
-
Je comprends. J'essayerai d'y penser une fois que les trucs urgents seront bouclés, promis. Par contre si je le fais ce sera plutôt une fonction publique qu'un truc protégé. Faire des trucs protégés dans une classe qui n'a pas vocation à être héritée, c'est un peu bizarre.
-
Merci beaucoup :)
En attendant, je vais modifier ma version de SFML pour ajouter une méthode à sf::texture, puisque tu propose plus tôt cette voie :) Je songe à ajouter simplement à sf::texture une méthode AttachFramebuffer(). En interne, il utilisera la fonction OpenGL glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, this->m_texture, 0).
-
Je précise juste que j'ai déjà moi aussi rencontré ce soucis et c'était pas pour faire de la 3d, alors je pense que oui, cette méthode peut être utile car on est pas les premiers et sûrement pas les derniers à avoir ce soucis. ;D