1
Fenêtrage / Re : De RenderWindow vers Window
« le: Décembre 08, 2014, 12:54:12 am »
Merci beaucoup 
!
!
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
Pages: [1]
2
Graphique / Re : Sf::Image et sf::Texture
« le: Décembre 08, 2014, 12:52:53 am »
C'est vrai que dans l'absolu; resize découle de scale. Très bien merci de vos réponses 
!
!
3
Graphique / Re : Sf::Image et sf::Texture
« le: Décembre 07, 2014, 04:12:15 pm »
Merci G. !
Laurent oui je me suis renseigné sur cette page:
http://sfml-dev.org/tutorials/2.0/graphics-sprite-fr.php
+ les documentations de classe.
http://sfml-dev.org/documentation/2.0/classsf_1_1Sprite.php
http://sfml-dev.org/documentation/2.0/classsf_1_1Texture.php
Cependant cet ancien projet avait développé uniquement avec des sf::Image, je ne voyais pas à l'époque l'utilité des textures. Désormais, j'ai le sentiment qu'il ne reste plus que les textures pour l'utilisation que j'en fais (j'ai des images.png dans un dossier, je les charge, les redimensionne en width et height et les affiche sur la window).
Si ce n'est que le nom qui change pas de problème, mais là je vois par exemple la disparition d'une fonction extrêmement utile : le resize d'un sprite en fonction d'un nombre de pixel donné :
Et l'appel à ces éléments :
Du coup je suis un peu perdu, je ne sais pas si je dois utiliser les sf::Image puisque je veux par exemple faire dessiner des Sprites avec une largeur et hauteur bien définie (par exemple du 40 par 60 en prenant à la base une image entière de 200 par 300) ou si je dois remplacer l'ancienne fonction resize par l'utilisation de scale de la classe Textures.
Je trouve dommage la disparition de cette implémentation. Ceci dit, la nouvelle est sans doute plus logique malheureusement j'ai appris avec l'ancienne
.
Laurent oui je me suis renseigné sur cette page:
http://sfml-dev.org/tutorials/2.0/graphics-sprite-fr.php
+ les documentations de classe.
http://sfml-dev.org/documentation/2.0/classsf_1_1Sprite.php
http://sfml-dev.org/documentation/2.0/classsf_1_1Texture.php
Cependant cet ancien projet avait développé uniquement avec des sf::Image, je ne voyais pas à l'époque l'utilité des textures. Désormais, j'ai le sentiment qu'il ne reste plus que les textures pour l'utilisation que j'en fais (j'ai des images.png dans un dossier, je les charge, les redimensionne en width et height et les affiche sur la window).
Si ce n'est que le nom qui change pas de problème, mais là je vois par exemple la disparition d'une fonction extrêmement utile : le resize d'un sprite en fonction d'un nombre de pixel donné :
Citer
GraphicElement::GraphicElement(Texture * texture, int x, int y, int w, int h)
: Sprite(*texture), _w(w), _h(h)
{
resize(w, h);
setPosition(x,y);
}
[...]
void GraphicElement::resize(int w, int h){
_w = w;
_h = h;
///Methode de classe sf::Sprite
resize(_w, _h);
}
Et l'appel à ces éléments :
Citer
if (!_background_image.loadFromFile("./sprites/planet.png"))
GraphicElement background_sprite(GraphicElement());
else
_background_sprite = GraphicElement(&_background_image,0,0,BACKGROUND_WIDTH,h);
Du coup je suis un peu perdu, je ne sais pas si je dois utiliser les sf::Image puisque je veux par exemple faire dessiner des Sprites avec une largeur et hauteur bien définie (par exemple du 40 par 60 en prenant à la base une image entière de 200 par 300) ou si je dois remplacer l'ancienne fonction resize par l'utilisation de scale de la classe Textures.
Je trouve dommage la disparition de cette implémentation. Ceci dit, la nouvelle est sans doute plus logique malheureusement j'ai appris avec l'ancienne
.
4
Graphique / [Résolu] Sf::Image et sf::Texture
« le: Décembre 07, 2014, 03:44:15 am »
Bonjour,bonsoir à tous,
Je reprends un projet en sfml 1.6 et essaie de le passer en 2.1 afin de profiter des évolutions effectuées sur la bibliothèque.
Certaines nouvelles implémentations me posent problème dans la mesure où pour seule solution je ne vois souvent qu'une profonde modification du code alors qu'il existe bien souvent des solutions plus simples.
Aujourd'hui, j'ai une petite erreur persistante à propos du constructeur des sprites qui sembles désormais ne se faire qu'avec des textures et plus avec des images.
Ainsi j'avais une classe GraphicElement dérivée de sf::Sprite dont le constructeur que voici :
Me donne l'erreur suivante :
En consultant la doc je vois que les constructeurs de sprites se font avec des textures, ainsi faut-il n'utiliser plus que des sf::textures pour manipuler des sf::sprites depuis des fichiers d'image ? Si oui, quelel est l'utilité de la classe sf::Image ? Sinon, comment faire passer mon sf::image au sf::Sprite ?
Merci de m'avoir lu !
Cordialement, Faya.
Je reprends un projet en sfml 1.6 et essaie de le passer en 2.1 afin de profiter des évolutions effectuées sur la bibliothèque.
Certaines nouvelles implémentations me posent problème dans la mesure où pour seule solution je ne vois souvent qu'une profonde modification du code alors qu'il existe bien souvent des solutions plus simples.
Aujourd'hui, j'ai une petite erreur persistante à propos du constructeur des sprites qui sembles désormais ne se faire qu'avec des textures et plus avec des images.
Ainsi j'avais une classe GraphicElement dérivée de sf::Sprite dont le constructeur que voici :
Citer
GraphicElement::GraphicElement(Image * image, int x, int y, int w, int h)
: Sprite(*image), _w(w), _h(h)
Me donne l'erreur suivante :
Citer
error: no matching function for call to 'sf::Sprite::Sprite(sf::Image&)'|
En consultant la doc je vois que les constructeurs de sprites se font avec des textures, ainsi faut-il n'utiliser plus que des sf::textures pour manipuler des sf::sprites depuis des fichiers d'image ? Si oui, quelel est l'utilité de la classe sf::Image ? Sinon, comment faire passer mon sf::image au sf::Sprite ?
Merci de m'avoir lu !
Cordialement, Faya.
5
Fenêtrage / [Résolu] De RenderWindow vers Window
« le: Décembre 06, 2014, 02:43:22 pm »
Bonjour tout le monde,
Je dois récupérer dans mon code la position de ma souris par rapport à la fenêtre de jeu. Cependant lorsque j'utilise :
sf::Vector2i localPosition = sf::Mouse::getPosition(_window);
où '_window' est ma sf::RenderWindow(RW), je reçois l'erreur suivante :
|710|error: no matching function for call to 'sf::Mouse::getPosition(sf::RenderWindow*&)'|
En effet la fonction de récupération a besoin d'une window et non d'une RW.
Je n'ai pas d'idée de comment implémenter cela, comment récuper un objet window depuis ma RW actuelle, ou comment (autre solution) peut-être le 'caster'.
Pouvez-vous m'aider ?
Merci de m'avoir lu.
Je dois récupérer dans mon code la position de ma souris par rapport à la fenêtre de jeu. Cependant lorsque j'utilise :
sf::Vector2i localPosition = sf::Mouse::getPosition(_window);
où '_window' est ma sf::RenderWindow(RW), je reçois l'erreur suivante :
|710|error: no matching function for call to 'sf::Mouse::getPosition(sf::RenderWindow*&)'|
En effet la fonction de récupération a besoin d'une window et non d'une RW.
Je n'ai pas d'idée de comment implémenter cela, comment récuper un objet window depuis ma RW actuelle, ou comment (autre solution) peut-être le 'caster'.
Pouvez-vous m'aider ?
Merci de m'avoir lu.
6
Suggestions de nouvelles fonctionnalités / Re : Un retour vers un sf::String ?
« le: Décembre 06, 2014, 10:54:47 am »
Je vous aurai un jour... je vous aurai !
Plus sérieusement, encore merci, je n'avais pas vu les choses sous cet angle.
Plus sérieusement, encore merci
, je n'avais pas vu les choses sous cet angle.
7
Suggestions de nouvelles fonctionnalités / Un retour vers un sf::String ?
« le: Décembre 06, 2014, 02:46:03 am »
Bonjour,
J'ai développé il y a de ça quelques temps un projet en SFML 1.6.
Reprenant ce dernier je me vois confronté à de nombreux changements assez faciles à utiliser(comme les fonctions ne commençant pas par des majuscules, ou les sf::clock.getElapsedTime directement inconvertibles en float il faut passer par une fonction du sf::Time (un pas en arrière ?? mais pourquoi !?!?)).
Cela dit voyant de nombreux problèmes avec la sf::String je comprend rapidement que de nombreuses choses concernant l'affichage de texte ont changé.
Tout d'abord, le tutoriel très clair en 1.6 pour afficher du texte n'est pas présent en 2.0 et supérieurs (ou est loin d'être complet, comme par exemple la gestion de la position de ce dernier).
Selon moi, sf::String aujourd'hui est plus pertinent, évite les mauvaises traductions entre encodages différents ce qui doit être bien utile pour l'utilisation de bases de données en ANSI (ceci n'est qu'un exemple).
Cela dit, la pauvre (et par extension toute la SFML) a pris un gros coup de régression. Il est désormais beaucoup plus compliqué d'afficher un simple texte !
Je trouvais que la SFML 1.6 avec sa puissante sf::String polyvalente supplée d'un excellent tutoriel allongeait les implémentations mais permettait de faire ce que l'on voulait. Désormais, il faut manipuler comme on le peut le sf::Text quitte à mettre une surcouche sur cette classe, cf :
http://fr.sfml-dev.org/forums/index.php?topic=9770.0
Selon moi, on va à l'encontre du principe d'une bibliothèque qui permet de rendre les actions les plus couramment utilisées facile et rapides d'utilisation ce qui n'est pas le cas ici. Ainsi, une version dite plus "avancée" fait un grand pas en arrière.
Je recommande donc l'existence de plus de contenu sur ce point (affichage de texte à l'écran), au moins un tutoriel complet en vue de l'étendue du changement.
J'ai développé il y a de ça quelques temps un projet en SFML 1.6.
Reprenant ce dernier je me vois confronté à de nombreux changements assez faciles à utiliser(comme les fonctions ne commençant pas par des majuscules, ou les sf::clock.getElapsedTime directement inconvertibles en float il faut passer par une fonction du sf::Time (un pas en arrière ?? mais pourquoi !?!?)).
Cela dit voyant de nombreux problèmes avec la sf::String je comprend rapidement que de nombreuses choses concernant l'affichage de texte ont changé.
Tout d'abord, le tutoriel très clair en 1.6 pour afficher du texte n'est pas présent en 2.0 et supérieurs (ou est loin d'être complet, comme par exemple la gestion de la position de ce dernier).
Selon moi, sf::String aujourd'hui est plus pertinent, évite les mauvaises traductions entre encodages différents ce qui doit être bien utile pour l'utilisation de bases de données en ANSI (ceci n'est qu'un exemple).
Cela dit, la pauvre (et par extension toute la SFML) a pris un gros coup de régression. Il est désormais beaucoup plus compliqué d'afficher un simple texte !
Je trouvais que la SFML 1.6 avec sa puissante sf::String polyvalente supplée d'un excellent tutoriel allongeait les implémentations mais permettait de faire ce que l'on voulait. Désormais, il faut manipuler comme on le peut le sf::Text quitte à mettre une surcouche sur cette classe, cf :
http://fr.sfml-dev.org/forums/index.php?topic=9770.0
Selon moi, on va à l'encontre du principe d'une bibliothèque qui permet de rendre les actions les plus couramment utilisées facile et rapides d'utilisation ce qui n'est pas le cas ici. Ainsi, une version dite plus "avancée" fait un grand pas en arrière.
Je recommande donc l'existence de plus de contenu sur ce point (affichage de texte à l'écran), au moins un tutoriel complet en vue de l'étendue du changement.
8
Général / Re : Compilation linux-->codeBlocks
« le: Décembre 05, 2014, 07:10:13 am »
Merci ! Je suis partagé entre le soulagement de voir que ce n'est pas plus compliqué comme solution et la déception de m'être fait avoir là-dessus 
.
Je pensais l'avoir originellement développé en 2.0mais non. Après les topics sur internet à ce sujet devraient me guide pour réparer ça sans problème
Encore merci,
Cordialement, Faya.
.Je pensais l'avoir originellement développé en 2.0mais non. Après les topics sur internet à ce sujet devraient me guide pour réparer ça sans problème
Encore merci,
Cordialement, Faya.
9
Général / [Résolu] Compilation linux-->codeBlocks
« le: Décembre 05, 2014, 01:11:52 am »
Bonjour à tous,
J'ai repris un vieux projet en SFML effectué à l'époque sur Linux. Souhaitant développer sur Windows j'ai donc installé codeblocks, téléchargé les sources de la SFML et recompilé cette dernière (l'exemple du tuto fonctionne à merveille).
Ainsi j'ai créé un nouveau projet, introduit l'ensemble de mes fichiers dedans (avec tous les sprites, fontes, et sons etc...) et lancé le build (après avoir bien sûr lié la SFML au projet).
Cependant lors de la compilation, une erreur arrive rapidement :
"myfile.cc|20|error: 'class sf::Clock' has no member named 'GetElapsedTime'|"
D'autres erreurs sur sf::sound, et je pense que cela aurait été pareil sur n'importe quel autre objet de la SFML.
Après avoir recherché et cogité je pense que cela vient du fait que la compilation ne suit pas le chemin du makefile fait sur Linux.
J'ai donc tenté d'indiquer à codeblocks d'utiliser ce makefile qui fonctionnait sous linux et j'ai une erreur :
mingw32-make.exe: *** No rule to make target `Debug'. Stop.
J'observe donc que les deux premiers fichiers (ou classe) compilés sont les deux premiers de la liste.
Ainsi est-il possible de résoudre ce problème de Makefile (le 'debug' qu'il ne trouve pas, et que je ne comprend malheureusement pas) ou bien l'ordre des fichiers compilés (afin qu'ils suivent la chaîne des liens vers la SFML depuis la classe principale) ?
Le plus étonnant est que même en ajoutant un #include <SFML\Graphics.gpp> dans la classe posant problème l'erreur persiste.
J'espère avoir été suffisamment clair, je vous remercie de m'avoir lu !
J'ai repris un vieux projet en SFML effectué à l'époque sur Linux. Souhaitant développer sur Windows j'ai donc installé codeblocks, téléchargé les sources de la SFML et recompilé cette dernière (l'exemple du tuto fonctionne à merveille).
Ainsi j'ai créé un nouveau projet, introduit l'ensemble de mes fichiers dedans (avec tous les sprites, fontes, et sons etc...) et lancé le build (après avoir bien sûr lié la SFML au projet).
Cependant lors de la compilation, une erreur arrive rapidement :
"myfile.cc|20|error: 'class sf::Clock' has no member named 'GetElapsedTime'|"
D'autres erreurs sur sf::sound, et je pense que cela aurait été pareil sur n'importe quel autre objet de la SFML.
Après avoir recherché et cogité je pense que cela vient du fait que la compilation ne suit pas le chemin du makefile fait sur Linux.
J'ai donc tenté d'indiquer à codeblocks d'utiliser ce makefile qui fonctionnait sous linux et j'ai une erreur :
mingw32-make.exe: *** No rule to make target `Debug'. Stop.
J'observe donc que les deux premiers fichiers (ou classe) compilés sont les deux premiers de la liste.
Ainsi est-il possible de résoudre ce problème de Makefile (le 'debug' qu'il ne trouve pas, et que je ne comprend malheureusement pas) ou bien l'ordre des fichiers compilés (afin qu'ils suivent la chaîne des liens vers la SFML depuis la classe principale) ?
Le plus étonnant est que même en ajoutant un #include <SFML\Graphics.gpp> dans la classe posant problème l'erreur persiste.
J'espère avoir été suffisamment clair, je vous remercie de m'avoir lu !
Pages: [1]