Question sur setOrigin () et les floats

[Timidouveg]

Bonjour à tous

J'espère que ce sujet est dans la bonne section, je n'étais pas sûr, j'ai donc préféré tenté ici pour ne pas polluer des sections plus spécifiques.

Plusieurs variables de sf::transformable sont des floats comme la position, l'origine, ... Il me semble que c'est pour être plus en phase avec la carte graphique, non ? J'ai souhaité faire mes propres class Font et Text car j'avais des critères très précis pour mes jeux-vidéo, et sans entrer dans les détails, j'ai eu un bug graphique que j'ai rapidement résolu sans modifier SFML. Ceci dit, je trouvais que la correction que j'ai apporté n'étais pas élégante. Ce problème est lié à la méthode setOrigin (float x, float y) dans transformable qui peut accepter certes des floats, mais donc des nombres qui n'ont pas que des zéros derrière la virgule. Si vous jugez que les détails du soucis rencontré est intéressant, je vous les fournirais volontiers

Ce que je souhaite savoir, avant tout et essentiellement, c'est est-ce qu'il y a des situations dans lesquelles la présence de chiffres après la virgule dans les x et y de l'origine d'un transformable est utile ? Même question pour la position, même si ça ne pose aucun problème dans le cas que j'ai rencontré, mais c'est par curiosité.

[Laurent]

J'espère que ce sujet est dans la bonne section, je n'étais pas sûr, j'ai donc préféré tenté ici pour ne pas polluer des sections plus spécifiques.

Mauvaise pioche... c'est en postant ici justement que tu "pollues" (-> je déplace le post)

Ce que je souhaite savoir, avant tout et essentiellement, c'est est-ce qu'il y a des situations dans lesquelles la présence de chiffres après la virgule dans les x et y de l'origine d'un transformable est utile ? Même question pour la position, même si ça ne pose aucun problème dans le cas que j'ai rencontré, mais c'est par curiosité.

Les coordonnées "scène", qui sont des unités auxquelles toi seul donne un sens particulier, et les coordonnées "fenêtre" qui sont des pixels, n'ont rien en commun si ce n'est le fait que SFML les cale l'un sur l'autre à la création de la fenêtre. Mais si je fais ensuite ça :

window.setView(sf::View(sf::FloatRect(0, 0, 1, 1));

... j'aurais bien du mal à faire quoique ce soit avec des coordonnées uniquement entières

[Timidouveg]

Désolé pour la mauvaise section, je n'ai plus l'habitude du forum depuis le temps :s

Pour l'exemple que tu as donné, effectivement, les valeurs sont plus tôt des ratios, c'est à dire que 1 est en fait 100%, donc il faut nécessairement des chiffres après la virgule. Mais, concernant les transformables, peut-il y avoir des utilisateurs qui ont intérêt à ce que les floats entrés dans setOrigin (x,y) ne soient pas converti en floats contenant que la valeur entière et le reste à zéro ?

J'ai testé un sf::Text de SFML 2.2 en mettant dans setOrigin, un x = 40.f et comparé avec un autre dont x = 40.5f et dans le premier cas le dessin du texte est net, alors que dans le deuxième il est légèrement lissé, ce qui se voit un peu qu'en-même. C'est comme un très léger flou.
Je ne te parle pas de ce que ma classe de texte maison faisait, c'était pire, mais je m'étais inspiré d'une version antérieur de SFML donc bref

Ma parade a consisté à écrire une surcouche de setOrigin pour enregistrer le x et le y en passant par floorf () pour forcer la retenu que d'une valeur entière sans remettre en question le choix des floats. Mais je me demandais donc si ce genre de modif aurait sa place directement dans la SFML ?

[Laurent]

Le problème c'est que pour avoir un rendu net, il ne suffit pas d'avoir des coordonnées entières pour l'origine. C'est en fait une combinaison de plein de paramètres dont le résultat doit tomber juste : la taille de la fenêtre, la taille et la position de la vue, la position et la taille du viewport, la position et l'origine des entités, ... et là je ne parle pas des rotations.

La plupart du temps les gens ne jouent que sur l'un de ces paramètres, les autres restant fixes (ou entiers), donc il est facile de retomber sur un rendu net en arrondissant une seule paire de coordonnées.

Du coup ce que tu proposes ne s'appliquerait qu'à un cas particulier. En fait pour être sûr d'avoir un rendu toujours net, ce sont les coordonnées finales (après toutes les transformations possibles) qu'il faut arrondir. C'est ce que faisait SFML 1. Et cela a été retiré car on s'est rendu compte qu'un rendu net n'était pas toujours souhaitable : lorsque des objets bougeaient ou tournaient, leur déplacement apparaissait saccadé alors qu'en gardant du "flou" pour les pixels à coordonnées décimales, c'était parfaitement fluide.

[Timidouveg]

Ah d'accord
Moi qui croyais que j'avais enfin trouver un truc pour contribuer à la SFML, zut

Il y aurait un bug ou une fonctionnalité que je pourrais tenter de voir au cas où ?

[Laurent]

Tout est sur le bug tracker