1
Graphique / Re : [RenderTexture] méthode create lente
« le: Février 19, 2013, 04:52:04 pm »
Ok, je vais faire ça alors
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 Suivante »
2
Graphique / Re : [RenderTexture] méthode create lente
« le: Février 19, 2013, 04:37:12 pm »
C'est que, passe de 1500 fps à 2/3 fps, pour un petit redimensionnement à la souris, ça fait peur...
Mais bon, tu as raison... Je vais laisser ça de coté pour plus tard...
Mais bon, tu as raison... Je vais laisser ça de coté pour plus tard...
3
Graphique / Re : Re : [RenderTexture] méthode create lente
« le: Février 19, 2013, 04:02:19 pm »Disons, que j'ai pas vraiment mesuré les performances mais simplement, réfléchie par logique...Citerce qui est un sacré gain rentableApparemment pas tant que ça... as-tu réellement mesuré les performances avec l'approche "naïve" ?
Afficher une texture de 600*500 (la texture qui contient le conteneur et les enfants)
C'est bien plus rentable, que d'afficher une texture de 600*500 (celle du conteneur) puis les divers textures des enfants
Mais sinon, que penses-tu de l'idée de procéder avec une sorte de cache-mémoire
En résumer, si le cache est à jour, on se contente d'afficher simplement l'image du cache
Sinon, s'il est pas à jour, on affiche le conteneur et les enfants
Et un petit thread qui s'occupe de mettre à jour le cache, (ex: si le cache du Conteneur n'est pas à jour et n'a pas été modifier depuis 2sec, hop on calcule et on crée le nouveau cache)
4
Graphique / Re : [RenderTexture] méthode create lente
« le: Février 19, 2013, 03:51:33 pm »
Args, je ne savais pas que les Context était lourd à créer =s
Enfaîte, c'est simplement pour des Widget conteneur, (ex: ScrollArea, Window, Layout, ...)
Donc quand un enfant est modifier, je clear puis draw tous les enfants et display...
Donc au final, on n'affiche que le Widget conteneur, au lieu d'afficher ses enfants par dessus (ce qui est un sacré gain rentable)
J'ai pensé à créer un sf::Image au lieu de sf::RenderTexture, mais les get/setPixel, je pense que ça peut être lourd
Edit:
@G.: Oui, c'est ce que m'avait proposer Laurent
Enfaîte, c'est simplement pour des Widget conteneur, (ex: ScrollArea, Window, Layout, ...)
Donc quand un enfant est modifier, je clear puis draw tous les enfants et display...
Donc au final, on n'affiche que le Widget conteneur, au lieu d'afficher ses enfants par dessus (ce qui est un sacré gain rentable)
J'ai pensé à créer un sf::Image au lieu de sf::RenderTexture, mais les get/setPixel, je pense que ça peut être lourd
Edit:
@G.: Oui, c'est ce que m'avait proposer Laurent
5
Graphique / Re : [RenderTexture] méthode create lente
« le: Février 19, 2013, 03:09:22 pm »
Quand j'ai dit refresh, je voulais parler du changement de taille
Sinon pour te répondre, oui c'est vraiment trop lent dans ce cas (j'arrive à constaté à l'oeil nu le temps que ça prend pour se redimensionner)
Dans mon exemple d'utilisation, c'est dans un cas ou un Window extensible contient un layout extensible, qui lui même contient plain de sous layout extensible et ...
Du coup, quand on s'amuse à redimensionner le Window à la souris, on remarque la lenteur de create =s
Voici un exemple, qui me donne comme résultat :
Ce qui fait, quand même une bonne seconde ^^
Et je ne crois pas que c'est mon pc qui foire, vu que je n'ai encore eu aucun soucis avec sf::Image, sf::Texture, draw() et ...
Si vous pouviez faire des testes de vos cotés (au cas où) ça serait bien.
Sinon je vais faire comme tu me le conseille Laurent (créer une taille de base, puis doublé celle-ci s'il faut plus et ainsi de suite)
Edit: Laurent, aurais-tu une idée pourquoi cette fonction est si lourde ? Et une petite explication à ce sujet en même temps. (cela doit surement venir de GlContext::create())
Sinon pour te répondre, oui c'est vraiment trop lent dans ce cas (j'arrive à constaté à l'oeil nu le temps que ça prend pour se redimensionner)
Dans mon exemple d'utilisation, c'est dans un cas ou un Window extensible contient un layout extensible, qui lui même contient plain de sous layout extensible et ...
Du coup, quand on s'amuse à redimensionner le Window à la souris, on remarque la lenteur de create =s
Voici un exemple, qui me donne comme résultat :
int main()
{
std::cout << "sf::RenderTexture test... ";
sf::RenderTexture rts[16];
sf::Clock clock;
for(sf::RenderTexture& rt : rts)
{
rt.create(100, 25);
}
sf::Int32 time = clock.getElapsedTime().asMilliseconds();
std::cout << time << " milliseconds" << std::endl;
}
sf::RenderTexture test... 1144 milliseconds{
std::cout << "sf::RenderTexture test... ";
sf::RenderTexture rts[16];
sf::Clock clock;
for(sf::RenderTexture& rt : rts)
{
rt.create(100, 25);
}
sf::Int32 time = clock.getElapsedTime().asMilliseconds();
std::cout << time << " milliseconds" << std::endl;
}
Ce qui fait, quand même une bonne seconde ^^
Et je ne crois pas que c'est mon pc qui foire, vu que je n'ai encore eu aucun soucis avec sf::Image, sf::Texture, draw() et ...
Si vous pouviez faire des testes de vos cotés (au cas où) ça serait bien.
Sinon je vais faire comme tu me le conseille Laurent (créer une taille de base, puis doublé celle-ci s'il faut plus et ainsi de suite)
Edit: Laurent, aurais-tu une idée pourquoi cette fonction est si lourde ? Et une petite explication à ce sujet en même temps. (cela doit surement venir de GlContext::create())
6
Graphique / [résolu] [RenderTexture] méthode create lente
« le: Février 19, 2013, 10:58:52 am »
Salut, j'ai un élément graphique qui contient d'autre élément graphique
On peut résumer ce-ci, par ce-ci :
Le problème, est que l'appel de create est vraiment lourd... alors que celui de image/texture est léger
Donc, je voudrais vous demander, qu'elle solution me conseiller vous ?
Utiliser GLEW me rendra t'il create plus rapide ?
Créer des rendertexture de grande taille et jouer avec sf::View ?
Utiliser Image/Texture (au risque d'avoir mon propre draw faible et lent? par ce que franchement, je doute que passer par des getPixel/setPixel soit une bonne idée... sauf pour tuer mon processeur =D) ?
On peut résumer ce-ci, par ce-ci :
// Fonction d'initialisation
sf::RenderTexture rendertexture;
sf::Sprite sprite;
// Fonction de refresh (taille)
rendertexture.create(geometry.width, geometry.height);
sprite.setTexture(rendertexture.getTexture(), true);
ps: j'ai tapé le code à la main (des erreurs sont possible)sf::RenderTexture rendertexture;
sf::Sprite sprite;
// Fonction de refresh (taille)
rendertexture.create(geometry.width, geometry.height);
sprite.setTexture(rendertexture.getTexture(), true);
Le problème, est que l'appel de create est vraiment lourd... alors que celui de image/texture est léger
Donc, je voudrais vous demander, qu'elle solution me conseiller vous ?
Utiliser GLEW me rendra t'il create plus rapide ?
Créer des rendertexture de grande taille et jouer avec sf::View ?
Utiliser Image/Texture (au risque d'avoir mon propre draw faible et lent? par ce que franchement, je doute que passer par des getPixel/setPixel soit une bonne idée... sauf pour tuer mon processeur =D) ?
7
Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"
« le: Janvier 24, 2013, 03:47:48 pm »Bon, j'ai installé la dernière version de code::blocks qui du coup a mis à jour gcc. J'ai ensuite installé d'une façon plus propre (oui je m'y prenais mal avant) les librairies comme SFML 2.0, etc...N'utilise que des libs en 32 bits pour MinGW, même si ton windows est en 64Bits, ça devrait régler les problèmes
Je rencontre un problème pour installer FreeType. Je ne trouve que la librairie pour du Win32, sauf que je suis en 64 bits, donc le programme sensé faciliter l'installation m'envoie balader. J'ai eu pareil avec zlib, mais j'ai trouvé une version pré-compilé pour Win64 sur le net. Donc, je pourrais bien me lancer dans une compilation de la lib si seulement je savais comment faire ça sans passer par le petit programme intitulé "vms-make.com" (si c'est bien ce truc là qu'il faut lancer). A part ça, il me reste encore lpng à télécharger et installer.
Autre chose, pour zlib, le fichier dans le répertoire lib s'appelle zlib et dans ton projet tu l'as appelé z, du coup mon compilo a râler lol J'ai donc changé z par zlib, c'est bien ce qu'il fallait faire ?
Il faut installer beaucoup de choses, c'est un peu dommage je trouve :s
EDIT: C'est pareil avec lpng, erf !
8
Discussions générales / Re : SFML Gui (des questions pour tous, même aux débutants)
« le: Janvier 23, 2013, 07:09:51 pm »
Il n'y a pas de soucis Laurent, le mail a été envoyé à "laurent (arobas) sfml-dev (point) org"
C'est un mail avec 11 questions
Je vais t'en faire une copie en MP sur le forum
C'est un mail avec 11 questions
Je vais t'en faire une copie en MP sur le forum
9
Discussions générales / SFML Gui (des questions pour tous, même aux débutants)
« le: Janvier 23, 2013, 06:52:10 pm »
Salut, après avoir envoyé un mail à Laurent (qui est sans réponse), je pense qu'il doit être occuper pour ne pas y répondre. C'est pour quoi, je me redirige vers vous !
Voilà, j'ai du temps libre devant moi et j'aimerais me consacré à un projet qui puisse être utiles aux autres.
Et je me lance donc dans une Gui pour SFML (en reprenant comme base, ma Gui personnel)
J'aimerais terminer et mettre au point mon prototype (pour enfin, commencé à ma focaliser sur l'optimisation de celle-ci).
Donc voici la liste des questions (vous pouvez vous contenter de répondre à celles, dont vous avez envie) :
1) Cela vous dérangerait-il, si je passe à la norme C++11 ? (voir exemple)
2) Qu'elle syntaxe désirez vous pour les signaux/slots ? Qu'elle syntaxe de signaux préférez-vous ? (voici les 2 syntaxe actuelle)
Énumération (avantages)
==> Si on ne connaît pas le nom du signal, il suffis simplement de tapez le nom du widget:: et votre IDE affichera la liste des énumérations
==> Ne pèse qu'un simple std::size_t, donc plus performant qu'un string
String (avantages)
==> Rend le codage plus court
ps: je prévois déjà de renommer connect et de le rendre private, et de créer un nouveau connect qui sera templaté (je sais pas si ça se dit...?) et qui s'occupera d'appeler l'ancien connect
En résumer, on garde l'ancien avantage que connect ne soit pas templaté, mais juste la fonction d'appel et on gagne l'avantage de ne plus utiliser slot()
Ainsi on passe à :
ps2: le 2éme paramètre est soit une référence ou un pointeur de l'objet qui doit être exécuter
Voilà, donc si vous avez une idée pour rendre l'utilisation de signaux/slots plus simple et agréable, n'hésitez pas !
3) Préféreriez-vous que les signaux/slots soit automatiquement threadé ?
Je ne sais pas comment vous comptez utiliser vos signaux/slots, si la plus par du temps vous les utiliser pour des fonctions bloquante, il serait surement plus sage de les avoirs threadé par défaut.
4) Ce module de gui, risque d'avoir une dépendance en dehors de SFML, c'est l'utilisation d'une lib XML pour charger vos stylesheet où encore vos gui pré-crée. Donc la qu'elle préféreriez-vous ?
J'ai pensez à coder ma propre lecteur XML, ce qui devrait être assez rapide grâce aux regex...
Mais bon... c'est quand même perdre du temps et je doute que ce soit une sage idée
5) Qu'elle syntaxe/structure utiliser pour le stylesheet ? Pouvez-vous m'aidez à en réaliser un qui soit Simple and Fast ? (c'est mon principal problème)
L'affichage de chaque widget doit impérativement être entièrement éditable depuis le stylesheet
Là tous à été simplifié, mais la création de style complet me paraît long avec ce système
Si vous avez des amélioration à proposer pour la syntaxe, j'attends avec impatience =)
Voici un exemple de ce que je vise pour mon prototype :
ps: je prévois de publier les sources une fois le stylesheet mis en place, (mais si vous avez besoin de consulter les sources ou juste de certaines class, vous pouvez me mp)
Voilà, j'ai du temps libre devant moi et j'aimerais me consacré à un projet qui puisse être utiles aux autres.
Et je me lance donc dans une Gui pour SFML (en reprenant comme base, ma Gui personnel)
J'aimerais terminer et mettre au point mon prototype (pour enfin, commencé à ma focaliser sur l'optimisation de celle-ci).
Donc voici la liste des questions (vous pouvez vous contenter de répondre à celles, dont vous avez envie) :
1) Cela vous dérangerait-il, si je passe à la norme C++11 ? (voir exemple)
// Constructeur
Button::Button() : Button("default text")
{
}
// Énumération
Policy::Expanding;
// ...
Button::Button() : Button("default text")
{
}
// Énumération
Policy::Expanding;
// ...
2) Qu'elle syntaxe désirez vous pour les signaux/slots ? Qu'elle syntaxe de signaux préférez-vous ? (voici les 2 syntaxe actuelle)
// Connexion (signal via énumération, converti en std::size_t)
button.connect(Button::Clicked, window, slot(&RenderWindow::close));
// Connexion (signal via std::string)
button.connect("clicked", window, slot(&RenderWindow::close));
// Émission de signal (exemple, depuis l'intérieur de la class Slider)
transmit(ValueChanged, m_value, valueOld);
transmit("valueChanged", m_value, valueOld); // valueOld, n'existe pas, et est là juste dans le but de montrer qu'on peut mettre plusieurs paramètre
button.connect(Button::Clicked, window, slot(&RenderWindow::close));
// Connexion (signal via std::string)
button.connect("clicked", window, slot(&RenderWindow::close));
// Émission de signal (exemple, depuis l'intérieur de la class Slider)
transmit(ValueChanged, m_value, valueOld);
transmit("valueChanged", m_value, valueOld); // valueOld, n'existe pas, et est là juste dans le but de montrer qu'on peut mettre plusieurs paramètre
Énumération (avantages)
==> Si on ne connaît pas le nom du signal, il suffis simplement de tapez le nom du widget:: et votre IDE affichera la liste des énumérations
==> Ne pèse qu'un simple std::size_t, donc plus performant qu'un string
String (avantages)
==> Rend le codage plus court
ps: je prévois déjà de renommer connect et de le rendre private, et de créer un nouveau connect qui sera templaté (je sais pas si ça se dit...?) et qui s'occupera d'appeler l'ancien connect
En résumer, on garde l'ancien avantage que connect ne soit pas templaté, mais juste la fonction d'appel et on gagne l'avantage de ne plus utiliser slot()
Ainsi on passe à :
button.connect("clicked", game, &Game::start);
ps2: le 2éme paramètre est soit une référence ou un pointeur de l'objet qui doit être exécuter
Voilà, donc si vous avez une idée pour rendre l'utilisation de signaux/slots plus simple et agréable, n'hésitez pas !
3) Préféreriez-vous que les signaux/slots soit automatiquement threadé ?
Je ne sais pas comment vous comptez utiliser vos signaux/slots, si la plus par du temps vous les utiliser pour des fonctions bloquante, il serait surement plus sage de les avoirs threadé par défaut.
4) Ce module de gui, risque d'avoir une dépendance en dehors de SFML, c'est l'utilisation d'une lib XML pour charger vos stylesheet où encore vos gui pré-crée. Donc la qu'elle préféreriez-vous ?
J'ai pensez à coder ma propre lecteur XML, ce qui devrait être assez rapide grâce aux regex...
Mais bon... c'est quand même perdre du temps et je doute que ce soit une sage idée
5) Qu'elle syntaxe/structure utiliser pour le stylesheet ? Pouvez-vous m'aidez à en réaliser un qui soit Simple and Fast ? (c'est mon principal problème)
<?xml version="1.0" encoding="UTF-8"?>
<StyleSheet>
<Widget name="CheckBox|RadioButton" width="125" height="25">
<Style name="Normal|NormalActive|NormalDisabled|Pressed|PressedActive|PressedDisabled">
<Couche> <!-- La couche utilise par défaut un layout="honrizontal" -->
<LayoutV policyWidth="fixed">
<Image path="gui/frameLeftTop.png" />
<Image path="gui/frameLeftMiddle.png" />
<Image path="gui/frameLeftBottom.png" />
</LayoutV>
<LayoutV policyWidth="fixed">
<Image path="gui/frameMiddleTop.png" />
<Image path="gui/frameMiddleMiddle.png" />
<Image path="gui/frameMiddleBottom.png" />
</LayoutV>
<LayoutV policyWidth="fixed">
<Image path="gui/frameRightTop.png" />
<Image path="gui/frameRightMiddle.png" />
<Image path="gui/frameRightBottom.png" />
</LayoutV>
<Text>Case à cocher (le texte par défaut)</Text> <!-- Text du widget -->
</Couche>
<Couche name="Check" layout="float"> <!-- Cette couche n'est afficher que si on demande à afficher Check -->
<Image path="gui/check.png" size="25" policy="fixed" x="0" /> <!-- Centrer verticalement, en commencent à gauche -->
</Couche>
</Style>
</Widget>
<!-- Ce qui nous donne un cadre extensible en hauteur...
avec le check centrer dans le cadre...
et un texte à droite du cadre qui est extensible -->
</StyleSheet>
<StyleSheet>
<Widget name="CheckBox|RadioButton" width="125" height="25">
<Style name="Normal|NormalActive|NormalDisabled|Pressed|PressedActive|PressedDisabled">
<Couche> <!-- La couche utilise par défaut un layout="honrizontal" -->
<LayoutV policyWidth="fixed">
<Image path="gui/frameLeftTop.png" />
<Image path="gui/frameLeftMiddle.png" />
<Image path="gui/frameLeftBottom.png" />
</LayoutV>
<LayoutV policyWidth="fixed">
<Image path="gui/frameMiddleTop.png" />
<Image path="gui/frameMiddleMiddle.png" />
<Image path="gui/frameMiddleBottom.png" />
</LayoutV>
<LayoutV policyWidth="fixed">
<Image path="gui/frameRightTop.png" />
<Image path="gui/frameRightMiddle.png" />
<Image path="gui/frameRightBottom.png" />
</LayoutV>
<Text>Case à cocher (le texte par défaut)</Text> <!-- Text du widget -->
</Couche>
<Couche name="Check" layout="float"> <!-- Cette couche n'est afficher que si on demande à afficher Check -->
<Image path="gui/check.png" size="25" policy="fixed" x="0" /> <!-- Centrer verticalement, en commencent à gauche -->
</Couche>
</Style>
</Widget>
<!-- Ce qui nous donne un cadre extensible en hauteur...
avec le check centrer dans le cadre...
et un texte à droite du cadre qui est extensible -->
</StyleSheet>
L'affichage de chaque widget doit impérativement être entièrement éditable depuis le stylesheet
Là tous à été simplifié, mais la création de style complet me paraît long avec ce système
Si vous avez des amélioration à proposer pour la syntaxe, j'attends avec impatience =)
Voici un exemple de ce que je vise pour mon prototype :
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML Gui");
// Création du Gui Manager
sf::GuiManager gui;
// Chargement des stylesheet (via le constructeur)
sf::StyleSheet ssr("red.xml"), ssg("green.xml"), ssb("blue.xml");
ssg.becomeDefault(); // green devient le style par défaut (jusqu'à sa destruction)
// Chargement de l'interface graphique
gui.loadFromFile("ui.xml");
gui.getButton("red").setStyleSheet(ssr); // On définie un style obligatoire
gui.getButton("green").setStyleSheet(ssg); // Si le bouton n'existe pas, GuiManager renvoie un faux
gui.getButton("blue").setStyleSheet(ssb); // Et signal l'erreur sur le stream err
// Connexion des signaux/slots
gui.getButton("red").connect(sf::Button::Clicked, ssr, &sf::StyleSheet::becomeDefault); // On change le style d'affichage
gui.getButton("green").connect(sf::Button::Clicked, ssg, &sf::StyleSheet::becomeDefault); // Au clic du bouton
gui.getButton("blue").connect(sf::Button::Clicked, ssb, &sf::StyleSheet::becomeDefault);
// Attention, le changement de style peut être plus ou moins long en fonction du nombre de widget
// Il est donc préférable de faire cela dans un thread
gui.getButton("exit").connect(sf::Button::Clicked, window, &sf::RenderWindow::close);
gui.getSlider("slider").connect(sf::Slider::ValueChanged, gui.getProgressBar("progress"), &sf::ProgressBar::setValue);
// Boucle d'affichage
while (window.isOpen())
{
// Événement
sf::Event event;
while (window.pollEvent(event))
{
// Exit
if (event.type == sf::Event::Closed)
window.close();
if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))
window.close();
// Gui
gui.event(event);
}
// Affichage
window.clear(sf::Color::Black);
window.draw(gui);
window.display();
}
// Création du Gui Manager
sf::GuiManager gui;
// Chargement des stylesheet (via le constructeur)
sf::StyleSheet ssr("red.xml"), ssg("green.xml"), ssb("blue.xml");
ssg.becomeDefault(); // green devient le style par défaut (jusqu'à sa destruction)
// Chargement de l'interface graphique
gui.loadFromFile("ui.xml");
gui.getButton("red").setStyleSheet(ssr); // On définie un style obligatoire
gui.getButton("green").setStyleSheet(ssg); // Si le bouton n'existe pas, GuiManager renvoie un faux
gui.getButton("blue").setStyleSheet(ssb); // Et signal l'erreur sur le stream err
// Connexion des signaux/slots
gui.getButton("red").connect(sf::Button::Clicked, ssr, &sf::StyleSheet::becomeDefault); // On change le style d'affichage
gui.getButton("green").connect(sf::Button::Clicked, ssg, &sf::StyleSheet::becomeDefault); // Au clic du bouton
gui.getButton("blue").connect(sf::Button::Clicked, ssb, &sf::StyleSheet::becomeDefault);
// Attention, le changement de style peut être plus ou moins long en fonction du nombre de widget
// Il est donc préférable de faire cela dans un thread
gui.getButton("exit").connect(sf::Button::Clicked, window, &sf::RenderWindow::close);
gui.getSlider("slider").connect(sf::Slider::ValueChanged, gui.getProgressBar("progress"), &sf::ProgressBar::setValue);
// Boucle d'affichage
while (window.isOpen())
{
// Événement
sf::Event event;
while (window.pollEvent(event))
{
// Exit
if (event.type == sf::Event::Closed)
window.close();
if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))
window.close();
// Gui
gui.event(event);
}
// Affichage
window.clear(sf::Color::Black);
window.draw(gui);
window.display();
}
ps: je prévois de publier les sources une fois le stylesheet mis en place, (mais si vous avez besoin de consulter les sources ou juste de certaines class, vous pouvez me mp)
10
Discussions générales / Re : Un livre sur SFML -- recherche d'auteur(s) !
« le: Janvier 23, 2013, 04:34:14 pm »
Es-ce toujours d'actualité ? Moi je veux bien contribuer ou donner quelques coup de main par-ci par là... (sachant que j'ai énormément de temps en ce moment).
Pour ce qui est d'être auteur, non merci, j'ai pas l'orthographe et mon anglais est trop technique...
Mais sinon, je trouve que ce livre est une très bonne idée. Et je souhaite un bon courage aux auteurs (s'ils y'en a qui se proposent) !
Pour ce qui est d'être auteur, non merci, j'ai pas l'orthographe et mon anglais est trop technique...
Mais sinon, je trouve que ce livre est une très bonne idée. Et je souhaite un bon courage aux auteurs (s'ils y'en a qui se proposent) !
11
Suggestions de nouvelles fonctionnalités / sf::Text plus personalisable (couleur / gras / ...)
« le: Novembre 21, 2012, 06:55:54 pm »
Salut, es-ce possible de proposer une meilleur personnalisation de sf::Text pour la prochaine version ?
Du genre rendre gras et rouge du caractère 12 à 18
Je sus pose qu'il n'y a rien de compliquer et qu'il faut juste ajouté un nouvelle attribut à la classe
Par exemple, un tableau trier dans l'ordre croissant et qui contienne le numéro du caractère et la modification a faire, exemple :
12 | Style(Gras + Color:Red)
18 | Style(Normal + Color:Black)
18 | Style(Italique)
Et la fonction qui va avec pour ajouté des styles, et une autre pour vider tous les styles =)
Et dans la fonction updateGeometry(), il suffirait d'ajouter dans la boucle, un if qui s'occupe d'apporter les modifications des styles si on est arrivé à un caractère ou il faut modifier
Bref, j'espère m'être fait comprendre, c'est simple et ça peut être pratique =)
Du genre rendre gras et rouge du caractère 12 à 18
Je sus pose qu'il n'y a rien de compliquer et qu'il faut juste ajouté un nouvelle attribut à la classe
Par exemple, un tableau trier dans l'ordre croissant et qui contienne le numéro du caractère et la modification a faire, exemple :
12 | Style(Gras + Color:Red)
18 | Style(Normal + Color:Black)
18 | Style(Italique)
Et la fonction qui va avec pour ajouté des styles, et une autre pour vider tous les styles =)
Et dans la fonction updateGeometry(), il suffirait d'ajouter dans la boucle, un if qui s'occupe d'apporter les modifications des styles si on est arrivé à un caractère ou il faut modifier
Bref, j'espère m'être fait comprendre, c'est simple et ça peut être pratique =)
12
Graphique / Re : Largeur des caractères spéciaux (é, ã, ...)
« le: Mai 15, 2012, 08:48:31 am »
Effectivement Laurent, sa va beaucoup mieux ainsi
ps: Ne serait t'il pas mieux que getGlyph récupère un Int32 au lieu d'un Uint32 ? (pour une plus grande compatibilité) ? Ou alors une seconde fonction qui s'occupe de récupérer un Int8 et le converti en Uint8, et puis finalement en Uint32 pour appeler la fonction principal
ps: Ne serait t'il pas mieux que getGlyph récupère un Int32 au lieu d'un Uint32 ? (pour une plus grande compatibilité) ? Ou alors une seconde fonction qui s'occupe de récupérer un Int8 et le converti en Uint8, et puis finalement en Uint32 pour appeler la fonction principal
13
Graphique / [Résolu] Largeur des caractères spéciaux (é, ã, ...)
« le: Mai 14, 2012, 09:39:14 pm »
Bonjour, voilà, je n'arrive pas à récupérer la largeur des caractères spéciaux (j'entends par là, les lettres accentué) du genre " ã, ä, ë, ... "
Je dois surement mal m'y prendre... mais en faisant ainsi, je me prend un jolie décalage du curseur pour mon text edit quand je tape des accents...
cout << sf::Font::getDefaultFont().getGlyph('a', 30, false).advance << endl; // Résultat: 16
cout << sf::Font::getDefaultFont().getGlyph('ã', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ä', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('e', 30, false).advance << endl; // Résultat: 16
cout << sf::Font::getDefaultFont().getGlyph('é', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ê', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ë', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ã', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ä', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('e', 30, false).advance << endl; // Résultat: 16
cout << sf::Font::getDefaultFont().getGlyph('é', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ê', 30, false).advance << endl; // Résultat: 23
cout << sf::Font::getDefaultFont().getGlyph('ë', 30, false).advance << endl; // Résultat: 23
Je dois surement mal m'y prendre... mais en faisant ainsi, je me prend un jolie décalage du curseur pour mon text edit quand je tape des accents...
14
Discussions générales / Re : SFML 2.0 RC
« le: Mai 08, 2012, 11:35:13 am »
aille aille aille... la RC (méthode qui passe en minuscule ). Il a fallu rechanger tous les nommages, bon mais vais pas me plaindre, c'est beaucoup mieux ainsi !
Si je trouve quelque chose, je tacherais de le signaler :p
). Il a fallu rechanger tous les nommages, bon mais vais pas me plaindre, c'est beaucoup mieux ainsi !Si je trouve quelque chose, je tacherais de le signaler :p
15
Graphique / Re : Zone d'affichage (pour sf::Text)
« le: Avril 12, 2012, 11:59:19 pm »
Ah oui tien, les viewport, je l'avais zapper 
Sinon j'ai un soucis avec RenderTexture
Et je me retrouve avec le Haut en Bas, et le Bas en Haut
Et ce, même si je fais rw.Create(230,230,true); (au lieu de false)
Si la gauche et la droite étais inversé aussi, j'aurais pu faire une rotation, mais là, sa va être un peu dur
Edit: J'ai trouver, la solution (un peu simple, mais fallait y pensé ^^)
Sinon, merci Laurent !
Sinon j'ai un soucis avec RenderTexture
sf::RenderTexture rw;
rw.Create(230,230,false);
rw.Clear(sf::Color::Red);
sf::Texture at;
at.LoadFromFile("nature.png");
sf::Sprite as;
as.SetTexture(at);
as.SetTextureRect(sf::IntRect(0,0,200,200));
rw.Draw(as);
sf::Sprite TS(rw.GetTexture());
window.Draw(TS);
rw.Create(230,230,false);
rw.Clear(sf::Color::Red);
sf::Texture at;
at.LoadFromFile("nature.png");
sf::Sprite as;
as.SetTexture(at);
as.SetTextureRect(sf::IntRect(0,0,200,200));
rw.Draw(as);
sf::Sprite TS(rw.GetTexture());
window.Draw(TS);
Et je me retrouve avec le Haut en Bas, et le Bas en Haut
Et ce, même si je fais rw.Create(230,230,true); (au lieu de false)
Si la gauche et la droite étais inversé aussi, j'aurais pu faire une rotation, mais là, sa va être un peu dur
Edit: J'ai trouver, la solution (un peu simple, mais fallait y pensé ^^)
rw.Display();
Sinon, merci Laurent !
Pages: [1] 2 Suivante »