Texture emplacement fichier

[FatihLD]

Salut!

Ça serait pratique si la classe Texture avait une fonction qui retournait l'emplacement du texture dans un string, par exemple: texture.getDirectory(), et pareil avec les sons, musiques et les polices. Juste question pratique hein :p

[Laurent]

Ca me paraît un peu farfelu. Si tu as besoin de ces informations, pourquoi ne pas les stocker toi-même ?

[FatihLD]

Oui c'est ce que j'ai fais, mais autant supprimer tous les getter puisque qu'on peut les stocker nous même
Mais ça serait bien pratique quand même quand on a besoin de l'emplacement de beaucoup de textures ^^

[Laurent]

mais autant supprimer tous les getter puisque qu'on peut les stocker nous même

La différence avec les autres getters, c'est que ceux-ci renvoient des informations qui sont de toute façon déjà présentes, et qui sont nécessaires au bon fonctionnement interne, et dans 90% des cas externe, de la texture (ou autre). Alors que le nom du fichier qui a servi à charger la texture... une fois le chargement terminé, c'est une information dont plus personne n'a besoin : ni la texture, ni l'appelant (à part toi ). Et aussi, les autres getters renvoient des informations qui ont été déduites, ce n'est pas toi qui les a données -- donc difficile de les stocker toi-même

Et du coup on fait quoi quand on a chargé la texture depuis la mémoire, ou depuis un flux ? On les stocke et on ajoute un getter aussi ? Et si je charge la texture depuis un fichier, mais qu'ensuite je change son contenu via Texture::update ? On garde l'info ou on la supprime ?

Bref, c'est peut-être pratique pour toi dans ton code en particulier, mais si on prend un peu de recul je ne pense pas que ce soit une "fonctionnalité" qui vaille le coup.

Mais ça serait bien pratique quand même quand on a besoin de l'emplacement de beaucoup de textures ^^

Je suis curieux de savoir pourquoi tu as besoin de cette information.

[FatihLD]

(à part toi ).

Si y'a que moi qui en a besoin j'veux bien que vous ne l'ajoutez pas ^^^

Et aussi, les autres getters renvoient des informations qui ont été déduites, ce n'est pas toi qui les a données -- donc difficile de les stocker toi-même

Oui c'est sûre pour la plupart, mais par exemple pour un sf::Text, son String il sort pas de nul part, c'est l’appelant qui le change, donc il peut très bien le stocker quelque part, mais on est tous d'accord que le getString() est très pratique.

Et si je charge la texture depuis un fichier, mais qu'ensuite je change son contenu via Texture::update ? On garde l'info ou on la supprime ?

Bah faudrait mieux la supprimer, c'est pas une question à se poser ça, par exemple; Si je change la position d'un sprite, on garde l'ancienne position on on la supprime?

Bref, c'est peut-être pratique pour toi dans ton code en particulier, mais si on prend un peu de recul je ne pense pas que ce soit une "fonctionnalité" qui vaille le coup.

Oui bon tu as raison mdr, on peut s'en passer

Je suis curieux de savoir pourquoi tu as besoin de cette information.

J'ai fais un menu où le joueur choisit la texture de sa tête et de son corps, je traverse un vector de plusieurs textures avec un boucle, et j'ai besoin de l'emplacement de la texture qu'il va choisir ^^, pour ça j'ai du faire deux autres vector de string avec les emplacements

[Laurent]

Si y'a que moi qui en a besoin j'veux bien que vous ne l'ajoutez pas ^^^

Pour l'instant c'est le cas

Oui c'est sûre pour la plupart, mais par exemple pour un sf::Text, son String il sort pas de nul part, c'est l’appelant qui le change, donc il peut très bien le stocker quelque part, mais on est tous d'accord que le getString() est très pratique.

Parce que getString() renvoie l'information essentielle de l'objet sf::Text, à savoir la chaîne qu'il affiche. Donc sf::Text la stocke, l'utilisateur la voit à l'écran, ... ce serait bête de ne pas donner un accès publique au développeur.
C'est complètement différent pour le chemin d'une texture : l'info n'existe nulle part, elle n'est ni stockée ni utilisée ; en d'autres termes c'est uniquement toi qui a besoin de la garder, et c'est pour cela que c'est toi qui devrait adapter ton code pour combler ce besoin, pas SFML.

Bah faudrait mieux la supprimer, c'est pas une question à se poser ça, par exemple; Si je change la position d'un sprite, on garde l'ancienne position on on la supprime?

Texture::update modifie des pixels de la texture, mais ça ne change pas le fait qu'à la base elle ait été chargée depuis un fichier ; imagine que dans ton programme tu aies besoin d'effectuer une transformation de couleur (noir et blanc) ou d'opacité (appliquer un masque de transparence) ; ça ne changera rien au fait que tu auras toujours besoin de savoir de quel fichier la texture provenait.

Bref c'est juste pour dire que lorsqu'on pousse la réflexion, les choses ne sont pas si évidentes...

Et imagine ces exemples très simples :

sf::Image image;
image.loadFromFile("...");

sf::Texture texture;
texture.loadFromImage(image); // oups on a perdu le "filename"...

// --------------------------

std::ifstream file("...");

sf::Texture texture;
texture.loadFromStream(file); // oups on a perdu le "filename"...

Tu vois bien que sf::Texture a très facile de perdre l'information, alors que toi de ton côté, tu l'as toujours à disposition si tu veux la garder.

pour ça j'ai du faire deux autres vector de string avec les emplacements

Mauvaise solution. Fais plutôt un seul vector d'une structure qui aggrège la texture + son chemin.

[FatihLD]

Oui bon tu as raison J'vais pas essayer d'argumenter plus, tu es le boss dans le domaine. Sinon pour mon "problème" je m'en suis sorti sans aucun vector, mais j'avoue que je pense jamais aux structs, merci ^^