Forum de la communauté SFML
Aide => Fenêtrage => Discussion démarrée par: Neckara le Avril 04, 2012, 09:33:22 pm
-
Bonjour,
Je code actuellement une zone de texte en SFML.
J'ai presque fini mais je suis confronté à un petit problème : si le texte sf::String est trop long, il dépasse de la zone de texte.
J'aimerais donc le "couper" non pas au caractère près, mais au pixel près.
Auriez-vous une idée de comment procéder?
Cordialement,
Neckara
-
Tu utilises quelle version de SFML???
Idée en vrac. Tu dessines dans cette ordre:
-Cadre
-Text
-Bordure
Sinon, tu peux dessiner ton texte dans un sf::RenderTexture et couper les pixels qui dépassent. Après tu affiche cette texture à la place de ton objet sf::Text.
Peut-être qu'avec SFML2 il existe une solution plus efficace et propre ;D
-
Peut-être qu'avec SFML2 il existe une solution plus efficace et propre
Pas encore, mais ça arrivera bientôt.
En attendant il faut bidouiller :
- soit via une RenderTexture
- soit via une vue qui a le viewport qui va bien
Les deux sont plus ou moins des hacks, mais en attendant mieux ça fonctionne.
-
sf::RenderTexture?
Je n'en ai pas entendu parler dans le tutoriel de la 1.6 (version que j'utilise), qu'est-ce?
J'ai vu vite fait l'en-tête .hpp et j'ai l'impression que c'est un espace où on peut "blitter" dessus comme sur une sf::RenderWindow avec .Daw().
Si je veux mettre cette sf::RenderTexture sur une sf::RenderWindow, je fais
RenderWindow.Draw(RenderTexture.Display());
?
EDIT : C'est bon, j'ai trouvé comment l'utiliser (http://www.sfml-dev.org/documentation/2.0/classsf_1_1RenderTexture.php#details).
Ces sf::RenderTexture vont vraiment me simplifier mon code, il est vraiment très regrettable qu'on en parle pas dans le tutoriel de la SFML.
-
Ces sf::RenderTexture vont vraiment me simplifier mon code, il est vraiment très regrettable qu'on en parle pas dans le tutoriel de la SFML.
Ben, c'est un peu normal, c'est du SFML 2.0 ;)
Avec SFML 1.6, il y a un autre hack plus simple pour faire ce que tu veux : utiliser glScissors (fonction OpenGL) pour définir une zone rectangulaire de clipping.
-
Il me semble que la 2.0 n'est pas encore sortie, savez-vous quand elle sort?
Pour openGL, je ne sais pas du tout l'utiliser, que vais-je devoir faire exactement?
-
Il me semble que la 2.0 n'est pas encore sortie, savez-vous quand elle sort?
Elle est finalisée (tu peux déjà l'utiliser), elle sortira très très bientôt.
Pour openGL, je ne sais pas du tout l'utiliser, que vais-je devoir faire exactement?
Rien de bien compliqué :
- l'en-tête OpenGL est déjà inclus par <SFML/Window.hpp> dans SFML 1.6
- il faut lier à la bibliothèque OpenGL ("opengl32" sous Windows)
- il faut appeler glScissor(x, y, width, height) pour définir la zone de clipping
- il faut appeler glEnable(GL_SCISSOR_TEST) pour activer le clipping, glDisable(GL_SCISSOR_TEST) pour le désactiver
-
Je pense que je vais utiliser la 2.0 si j'y arrive.
Les sf::RenderTexture me semblent très pratique et plutôt que de faire des :
void getImage(sf::RenderWindow &app);
je pourrais faire :
sf::RenderTexture getImage();
Pour dessiner sur ma sf::RenderWindow.
Je vais donc essayer de voir comment installer la 2.0
-
Les sf::RenderTexture me semblent très pratique et plutôt que de faire des :
void getImage(sf::RenderWindow &app);
je pourrais faire :
sf::RenderTexture getImage();
Pour dessiner sur ma sf::RenderWindow.
Ce que tu proposes m'a l'air moins bien que ce que tu as.
Typiquement on demande à un truc de se dessiner dans une target, plutôt que de lui demander de retourner un truc graphique qu'on pourra dessiner. En d'autre terme, une classe doit fournir des services et non des données.
-
En fait j'ai une paquage (Event) qui sert d'interface homme / application qui gère le clavier et l'affichage.
Et j'ai à côté une classe fenêtre (Fenetre) qui représente une fenêtre à l'intérieur de la fenêtre principale.
Donc Event va chercher la Fenetre cible de chaque évènement clavier/souris ou autre et lui transmettre cet évènement.
A la classe Fenetre de gérer le reste.
Ensuite, à chaque "rechargement" de la page, Event va demander le sf::RenderTexture de la Fenetre pour la blitter sur la fentre principale (sf::RenderWindow).
Ceci permet de ne pas à avoir à tout dessiner sur la sf::RenderWindow toutes les 1/60 sec alors qu'il suffit de dessiner sur la sf::RenderTexture à chaque modification (pour les zones de textes) et toute les 1/60 sec de dessiner la sf::RenderTexture sur la sf::RenderWindow ce qui fait gagner énormément de ressources.
Fenetre rend donc bel et bien un service : celui de gérer totalement une "fenetre"
-
Déjà c'est bizarre qu'une classe nommée Event gère l'affichage :)
Ensuite ce serait plus logique que Fenetre se dessine toute seule lorsque "Event" lui demande. Comme ça les petits détails internes (passer par une RenderTexture, rafraîchir que lorsque c'est nécessaire, etc.) restent... internes.
Là tu as une approche hybride où Fenetre sait se dessiner, mais sur un truc intermédiaire qu'il faut lui-même encore dessiner ailleurs. Conceptuellement c'est pas bon :)
-
Je ne pense pas car une fenêtre sait de quoi elle est composée et sait faire une image d'elle-même.
Mais elle n'a pas à connaitre de qui la contient.
C'est à son contenant de prendre l'image de cette fenêtre et de l'afficher.
Si la fenêtre peut se dessiner elle-même, c'est comme mettre la sf::RenderWindow en attribut public.
Elle sera totalement libre de dessiner là où elle ne devrait pas dessiner.
-
En fait je pense que ce que veut dire laurent c'est que ta classe fenêtre doit être autonome. C'est la toute la puissance de l'encapsulation. admettons le petit bout de code suivant comme exemple:
class Event
{
//blabla
};
class fenetre
{
//blabla
public:
void Draw(sf::RenderWindow& app);
private:
Event monEvent;
};
int main()
{
//creation de la fenetre
sf::RenderWindow window(...);
sf::Event event;
//boucle d'event
while(...)
{
fenetre.Update(&event);
}
fenetre.Draw(&window);
}
En gros tu appelles la méthode draw() de ta classe fenêtre en lui passant en paramètre la renderwindow sur laquelle tu travailles. dans ta boucle d'évènement tu mets a jour les évènement de ta classe fenêtre.
Et la méthode draw() se débrouille pour dessiner la fenêtre en fonction des évènements associés.
De cette maniere quelle que soit la manière utilisée pour afficher ta fenêtre, c'est géré en interne et pour mettre a jour ton code c'est beaucoup plus facile.
-
Le principe de l'encapsulation est aussi de garantir une intégrité des données.
Si je donne accès à la sf::RenderWindow, je ne peux plus garantir son intégrité.
Pour les changements, cela se passe du côté de la classe Fenetre qui dessine dans une sf::RenderTexture.
Par ce que en fait ce qui change c'est juste ce petit bout de code :
Ma_renderWindow.Draw(Ma_Fenetre.getTexteture());
qui au lieu d'être dans Event se retrouvera (un peu modifié) dans Fenetre.
Mais quels que soit les modifications, ce bout de code sera inchangeable et elles se feront soit dans Fenetre
-
Le principe de l'encapsulation est aussi de garantir une intégrité des données.
Si je donne accès à la sf::RenderWindow, je ne peux plus garantir son intégrité.
Pour les changements, cela se passe du côté de la classe Fenetre qui dessine dans une sf::RenderTexture.
Je comprends, mais si tu la passes en reference constante le probleme de l'integrite n'est plus. Et de ce fait ca te permet de cacher le code de rendu dans fenetre.
void fenetre::Draw(const sf::RenderWindow &app) const
{}
De ce fait tout ce qui se trouve dans draw() ne pourra modifier ta reference.
-
fenetre::Draw(const sf::RenderWindow &app)
Il n'y as que moi que cela choque :o
On ne peut pas dessiner une target dans une target.
Je n'ai pas bien compris, pourquoi ceci ne respecte pas l'intégrité des données???
Ma_renderWindow.Draw(Ma_Fenetre.getTexture());
Puis cette ligne aussi est fausse ??? Il faut utiliser un sprite pour dessiner une texture(pas sur de moi).
Car sinon le fait d'afficher un sprite, un text ou un shape ne respecte pas l'intégrité des données ???
Question certainement superficiel, mais juste par curiosité ::)
edit:: une majuscule dans Draw, il s'agit donc de classe hors SFML. Désoler de la confusion :-[
-
ça me gène un peu de faire cela.
J'ai une feuille et je demande à chaque personne de coller un petit auto-collant dessus.
Tu propose de faire passer la feuille à chaque personne pour qu'elles puissent coller leur propre auto-collant.
Mais ne vaut-il pas mieux récupérer cet auto-collant pour être sûr qu'un et un seul auto-collant sera collé par personnes et pour éventuellement pouvoir mettre en place des contrôles sur la position et taille?
Donner la sf::RenderWindow, même en const reste tout de même une confiance non négligeable accordée à Fenetre.
EDIT : en effet, il faudra retourner un sf::Sprite.
-
J'ai entendu dire que la SFML 2.0 changeait pas mal de choses de la 1.6 et qu'il serait possible que j'ai à "tout recoder"
Est-ce que la SFML 2.0 gère bien la rétro-compatibilité avec la 1.6 ?
-
Est-ce que la SFML 2.0 gère bien la rétro-compatibilité avec la 1.6 ?
Non justement, c'est pour ça que c'est une 2.0 et non une 1.7 :)
Mais ce sont surtout des modifications cosmétiques et des ajouts, dans le fond les concepts qui marchaient avec 1.6 marchent toujours avec 2.0.
-
Est-ce qu'il y a une date de publication du tutoriel pour la 2.0 ?
Par modification cosmétique, auriez-vous un exemple?
Sinon, j'essaye de compiler la SFML 2.0 avec cmake et mingw-32make sous windows 7
Et j'ai ce message :
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>mingw32-make all
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj
Le chemin d'accès spécifié est introuvable.
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
mingw32-make: *** [all] Error 2
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>mingw32-make sfml-system
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
[ 7%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.
obj
Le chemin d'accès spécifié est introuvable.
mingw32-make[3]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/rule] Error 2
mingw32-make: *** [sfml-system] Error 2
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>
Est-ce que je me serais trompé sur les options?
-
Est-ce qu'il y a une date de publication du tutoriel pour la 2.0 ?
Oui : dès que j'aurai le temps de le faire.
Par modification cosmétique, auriez-vous un exemple?
J'ai renommé des classes, des fonctions, j'ai changé des conventions de nommage, etc. Beaucoup de modifs sur la forme, mais en fait très peu sur le fond.
Sinon, j'essaye de compiler la SFML 2.0 avec cmake et mingw-32make sous windows 7
Et j'ai ce message
T'as dû sauter une étape, ou mal faire un truc. Dis moi tout ce que tu as fait en détail.
-
Hormis la partie réseau, les sockets ont changés de sémantique.
-
C'est sûr qu'il y a tout de même des modifications sur le fond, mais ce que je voulais dire c'est que globalement on n'est pas dépaysé, ce n'est pas comme aborder une toute nouvelle API.
-
J'ai tout simplement suivi le tutoriel, j'ai presque tout coché dans les options de cmake.
D'après mon prof de C++, ceci pourrait venir du fait qu'on utilise cmake et mingw32-make qui sont logiciels de linux porté sous windows.
Il m'a aidé à installer la SFML 2.0 sur mon débian et les exemples semblent fonctionner sauf pour le son.
Il y a aussi quelques messages d'erreur (?)
window marche bien, lorsqu'on appuie sur Echap ou la croix on a un message d'erreur :
neckara@NeckDebian:~/local/sfml_build/examples/window$ ./window
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
sound_capture : n'entend pas le son enregistrer : sûrement une erreur de du config du micro
socket : aucun problème tcp et udp
pong : marche correctement mais messages :
./pong
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
DRM_IOCTL_GEM_CLOSE 4 failed (region): Bad file descriptor
X11 : deux carré jaunes au milieu de deux carrés verts/gris sur un fond noir.
Le carré de gauche semble s'incliner plus rapidement que le carré de droite mais cela reste assez long et très pixelisé.
./X11
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
//lorsqu'on quitte :
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 137 (DRI2)
Minor opcode of failed request: 7 ()
Resource id in failed request: 0x5a00002
Serial number of failed request: 224388
Current serial number in output stream: 224388
voip semble marcher mais toujours pas de sons.
sound : j'entends rien
shader : textes très mal affichés (fait exprès ?)
../shader
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
DRM_IOCTL_GEM_CLOSE 11 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 10 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 37 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 32 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 7 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 8 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 9 failed (region): Bad file descriptor
opengl : marche très bien mais juste quelques messages d'erreurs :
./opengl
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
DRM_IOCTL_GEM_CLOSE 6 failed (region): Bad file descriptor
DRM_IOCTL_GEM_CLOSE 59 failed (region): Bad file descriptor
EDIT : j'ai regardé le code source de certains exemples, dans aucun je n'ai vu l'utilisation de thread pour avoir deux processus : un pour l'affichage et un pour les évènements.
Je vais donc écrire un petit code pour tester parce qu'avec la 1.6 cela posait des problèmes.
EDIT 2 :
Je n'arrive même pas à compiler :
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ g++ main.cpp -o exe -lsfml-graphics
/tmp/ccCwaS3T.o: In function `lance_afficher(void*)':
main.cpp:(.text+0x1b): undefined reference to `sf::Window::setFramerateLimit(unsigned int)'
main.cpp:(.text+0x5d): undefined reference to `sf::RenderTarget::clear(sf::Color const&)'
main.cpp:(.text+0x68): undefined reference to `sf::Window::display()'
main.cpp:(.text+0x97): undefined reference to `sf::Window::isOpen() const'
/tmp/ccCwaS3T.o: In function `main':
main.cpp:(.text+0x185): undefined reference to `sf::RenderWindow::RenderWindow(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, sf::ContextSettings const&)'
main.cpp:(.text+0x209): undefined reference to `sf::Window::setActive(bool) const'
main.cpp:(.text+0x237): undefined reference to `sf::Thread::launch()'
main.cpp:(.text+0x28c): undefined reference to `sf::Window::close()'
main.cpp:(.text+0x2a5): undefined reference to `sf::Window::pollEvent(sf::Event&)'
main.cpp:(.text+0x2b5): undefined reference to `sf::Window::isOpen() const'
collect2: ld returned 1 exit status
Je pense qu'il doit me manquer une option pour la compilation, mais laquelle?
J'ai tenté de regarder dans les Makefile des exemples, mais je n'ai rien trouvé.
-
j'ai presque tout coché dans les options de cmake.
C'est-à-dire ?
D'après mon prof de C++, ceci pourrait venir du fait qu'on utilise cmake et mingw32-make qui sont logiciels de linux porté sous windows.
Aaaah... les profs de C++ ::)
Pour tes problèmes Linux, tu es sûr que tes drivers graphiques sont à jour ? Tu as essayé glxgears ?
Et sinon (pour les erreurs d'édition de liens) tu es sûr que tu n'as pas une 1.6 qui traîne et qui pourrait être utilisée à la place de la 2.0 (elles s'installent dans des endroits différents).
-
J'avais en effet une 1.6 qui traînait, je l'ai désinstallée et la compilation marche.
Pour ma carte graphique, c'est une intel, mon prof avait rapidement regardé les drivers et ça semblais être bon.
Je vais essayer de voir ce qu'est glxgears parce que je ne sais pas du tout ce que c'est^^
Pour window, il faudrait que je reboot pour voir les options que j'avais coché.
J'ai testé plusieurs fois mon code, mais dès que j'appuie sur une touche ou parfois quand je met la souris sur la fenêtre, celle-ci se ferme subitement avec ces messages d'erreurs :
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ g++ main.cpp -o exe -lsfml-window -lsfml-graphics -lsfml-audio -lsfml-system -lsfml-network
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exedo_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection)
Major opcode of failed request: 148 (XFIXES)
Minor opcode of failed request: 5 (XFixesCreateRegion)
Resource id in failed request: 0x6000018
Serial number of failed request: 111
Current serial number in output stream: 111
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection)
Major opcode of failed request: 148 (XFIXES)
Minor opcode of failed request: 5 (XFixesCreateRegion)
Resource id in failed request: 0x6000089
Serial number of failed request: 451
Current serial number in output stream: 451
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 493 requests (492 known processed) with 0 events remaining.
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 148 (XFIXES)
Minor opcode of failed request: 10 (XFixesDestroyRegion)
Serial number of failed request: 473
Current serial number in output stream: 472
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 505 requests (504 known processed) with 0 events remaining.
#include <iostream>
#include <SFML/Graphics.hpp>
const int IMGPROSEC = 60;
void lance_afficher(void *data)
{
sf::RenderWindow * window = static_cast<sf::RenderWindow*>(data);
window->setFramerateLimit(IMGPROSEC);
while (window->isOpen())
{
window->clear();
// dessine tout...
window->display();
}
}
int main()
{
sf::RenderWindow window(sf::VideoMode(500, 500, 32), "titre");
window.setActive(false);
sf::Thread thread(&lance_afficher, &window);
thread.launch();
sf::Event Event;
while (window.isOpen())
{
while (window.waitEvent(Event))
{
if(Event.type == sf::Event::Closed)
{
std::cout << "Fermeture" << std::endl;
window.close();
break;
}
}
}
}
Si jamais ceci peut vous aider :
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ valgrind ./exe
==4317== Memcheck, a memory error detector
==4317== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4317== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4317== Command: ./exe
==4317==
==4317== Syscall param ioctl(generic) points to uninitialised byte(s)
==4317== at 0x6DE3789: ioctl (syscall-template.S:82)
==4317== by 0x886F11C: ??? (in /usr/lib/dri/i965_dri.so)
==4317== by 0x886F20C: driDrawableInitVBlank (in /usr/lib/dri/i965_dri.so)
==4317== by 0x887C522: intelMakeCurrent (in /usr/lib/dri/i965_dri.so)
==4317== by 0x886FEC1: ??? (in /usr/lib/dri/i965_dri.so)
==4317== by 0x6EBC18B: ??? (in /usr/lib/libGL.so.1.2)
==4317== by 0x6E97DA1: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2)
==4317== by 0x6E97E72: glXMakeCurrent (in /usr/lib/libGL.so.1.2)
==4317== by 0x4907DC3: sf::priv::GlxContext::makeCurrent() (in /usr/local/lib/libsfml-window.so.2.0)
==4317== by 0x490244C: sf::priv::GlContext::setActive(bool) (in /usr/local/lib/libsfml-window.so.2.0)
==4317== by 0x4905188: sf::Window::setActive(bool) const (in /usr/local/lib/libsfml-window.so.2.0)
==4317== by 0x804911C: main (in /media/Acer/Users/Neckara/Desktop/Donnees/Test-Boucle_Lecture_ecriture/exe)
==4317== Address 0xfedafee8 is on thread 1's stack
==4317==
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 59
Current serial number in output stream: 60
==4317==
==4317== HEAP SUMMARY:
==4317== in use at exit: 25,522,439 bytes in 4,757 blocks
==4317== total heap usage: 9,565 allocs, 4,808 frees, 26,312,816 bytes allocated
==4317==
==4317== LEAK SUMMARY:
==4317== definitely lost: 0 bytes in 0 blocks
==4317== indirectly lost: 0 bytes in 0 blocks
==4317== possibly lost: 1,220 bytes in 27 blocks
==4317== still reachable: 25,521,219 bytes in 4,730 blocks
==4317== suppressed: 0 bytes in 0 blocks
==4317== Rerun with --leak-check=full to see details of leaked memory
==4317==
==4317== For counts of detected and suppressed errors, rerun with: -v
==4317== Use --track-origins=yes to see where uninitialised values come from
==4317== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 112 from 14)
Le prof avait aussi testé glxgears (je me souviens des engrenages^^)
Quand j'ai fermé, le message XIO c'est affiché
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ glxgears
2595 frames in 5.0 seconds = 518.781 FPS
2235 frames in 5.0 seconds = 446.572 FPS
2590 frames in 5.0 seconds = 517.616 FPS
2390 frames in 5.0 seconds = 477.659 FPS
2498 frames in 5.0 seconds = 499.217 FPS
2458 frames in 5.0 seconds = 491.246 FPS
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 45005 requests (45002 known processed) with 0 events remaining.
EDIT : glxgears n'affiche l'erreur XIO que lorsque je ferme en cliquant sur la croix, si j'appuie sur echap, je n'ai pas d'erreur.
-
Mais sans thread déjà, ça marche ? Faudrait pas s'éparpiller ;)
-
Sans thread, il marche, le problème vient, je pense, de l'utilisation de display() et de waitEvent() en même temps.
Vu que dans la 1.6 si je mettais des verrous pour que ces deux fonctions ne puissent s'exécuter en même temps, le code marchait.
Mais c'était vraiment du gaspillage vu que waitEvent va attendre un évènement donc il va bloquer l'affichage si aucun évènement ne survient.
Tandis que display() va quant à lui bloquer le processus de lecture d'évent puisque j'ai mis un setLimiteFrame(60)
./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
Fermeture
#include <iostream>
#include <SFML/Graphics.hpp>
const int IMGPROSEC = 60;
void lance_afficher(void *data)
{
sf::RenderWindow * window = static_cast<sf::RenderWindow*>(data);
window->setFramerateLimit(IMGPROSEC);
while (window->isOpen())
{
window->clear();
// dessine tout...
window->display();
}
}
int main()
{
sf::RenderWindow window(sf::VideoMode(500, 500, 32), "titre");
window.setActive(false);
sf::Thread thread(&lance_afficher, &window);
// thread.launch();
sf::Event Event;
while (window.isOpen())
{
while (window.waitEvent(Event))
{
if(Event.type == sf::Event::Closed)
{
std::cout << "Fermeture" << std::endl;
window.close();
break;
}
}
}
window.display();
}
NB : je suis en train d'installer ddd pour voir exactement ce qu'il se passe.
EDIT : lancé avec ddd, il n'y a aucune erreur. Mais on ne voit pas le deuxième thread, je pense que le deuxième thread n'est pas exécuté.
EDIT2 : je pourrais faire un pollevent, utiliser sf::Clock et sf::Mutex pour limiter le rechargement des images, mais avec :
#include <iostream>
#include <SFML/Graphics.hpp>
const int IMGPROSEC = 60;
sf::Mutex * Mutex;
void lance_afficher(void *data)
{
sf::RenderWindow * window = static_cast<sf::RenderWindow*>(data);
window->setFramerateLimit(IMGPROSEC);
while (window->isOpen())
{
//std::cout << "!!" << std::endl;
Mutex->lock();
window->clear();
// dessine tout...
window->display();
Mutex->unlock();
}
}
int main()
{
Mutex = new sf::Mutex();
sf::RenderWindow window(sf::VideoMode(500, 500, 32), "titre");
window.setActive(false);
sf::Thread thread(&lance_afficher, &window);
thread.launch();
sf::Event Event;
while (window.isOpen())
{
Mutex->lock();
while (window.pollEvent(Event))
{
std::cout << "???" << std::endl;
Mutex->unlock();
if(Event.type == sf::Event::Closed)
{
std::cout << "Fermeture" << std::endl;
window.close();
break;
}
Mutex->lock();
}
Mutex->unlock();
}
}
Il n'affichera à chaque fois au plus 3 fois "???"
Et sur quelques tests j'ai même eu :
./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
Fermeture
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 137 ()
Minor opcode of failed request: 6
Resource id in failed request: 0x5800001
Serial number of failed request: 749
Current serial number in output stream: 750
neckara@NeckDebian:~/Documents/Donnees/Test-Boucle_Lecture_ecriture$ ./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
Fermeture
pure virtual method called
terminate called without an active exception
Abandon
Par contre si je décommente l'affichage des "!!!" j'ai :
./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
Et tout fonctionne plutôt bien.
#include <iostream>
#include <SFML/Graphics.hpp>
const int IMGPROSEC = 60;
sf::Mutex * Mutex;
void lance_afficher(void *data)
{
sf::RenderWindow * window = static_cast<sf::RenderWindow*>(data);
window->setFramerateLimit(IMGPROSEC);
while (window->isOpen())
{
//std::cout << "!!" << std::endl;
Mutex->lock();
window->clear();
// dessine tout...
window->display();
Mutex->unlock();
}
}
int main()
{
Mutex = new sf::Mutex();
sf::RenderWindow window(sf::VideoMode(500, 500, 32), "titre");
window.setActive(false);
sf::Thread thread(&lance_afficher, &window);
thread.launch();
sf::Event Event;
while (window.isOpen())
{
Mutex->lock();
while (window.pollEvent(Event))
{
std::cout << "???" << std::endl;
Mutex->unlock();
if(Event.type == sf::Event::Closed)
{
std::cout << "Fermeture" << std::endl;
window.close();
break;
}
Mutex->lock();
}
Mutex->unlock();
}
}
-
Concrètement, le tout dernier code donne quoi comme résultat, avec et sans le mutex ?
-
Concrètement :
- Sans Mutex : erreur qui ferme la fenêtre dès que j'appuie sur le clavier ou parfois dès qu'un évènement souris survient.
- Avec Mutex : interblocage (?), mais marche parfaitement lorsque je met le "std::cout << "!!" << std::endl; juste avant le Mutex->lock() dans la boucle d'affichage
-
Chez moi, sous Windows, aucun problème.
Sous Linux j'ai remarqué qu'il fallait un appel à XInitThreads() pour que le fenêtrage multi-threadé fonctionne. Rien d'anormal donc :)
Il faudra que je règle ça prochainement (en fait ça se réglera tout seul quand j'aurai remplacé XLib par XCB pour implémenter le fenêtrage sous Linux).
-
Je l'avais déjà essayé sous Linux avec la 1.6 mais ça ne marchait pas.
Mais maintenant avec la 2.0 j'ai plus que ce petit message :
./exe
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
Fermeture
Mais sinon tout fonctionne bien. Merci beaucoup pour votre aide.
Demain j'essayerais de voir les options de cmake que j'ai utilisé pour window afin de voir pourquoi je n'arrive pas à compilé la 2.0 sous windows.
#include <iostream>
#include <SFML/Graphics.hpp>
#include <X11/Xlib.h>
const int IMGPROSEC = 60;
//sf::Mutex * Mutex;
void lance_afficher(void *data)
{
sf::RenderWindow * window = static_cast<sf::RenderWindow*>(data);
window->setFramerateLimit(IMGPROSEC);
while (window->isOpen())
{
//std::cout << "!!" << std::endl;
//Mutex->lock();
window->clear();
// dessine tout...
window->display();
//Mutex->unlock();
}
}
int main()
{
XInitThreads();
//Mutex = new sf::Mutex();
sf::RenderWindow window(sf::VideoMode(500, 500, 32), "titre");
window.setActive(false);
sf::Thread thread(&lance_afficher, &window);
thread.launch();
sf::Event Event;
while (window.isOpen())
{
//Mutex->lock();
while (window.pollEvent(Event))
{
//std::cout << "???" << std::endl;
//Mutex->unlock();
if(Event.type == sf::Event::Closed)
{
std::cout << "Fermeture" << std::endl;
window.close();
break;
}
//Mutex->lock();
}
//Mutex->unlock();
}
}
-
Pour cmake sous windows :
BUILD_DOC NON
BUILD_EXAMPLES OUI
BUILD_SHARED_LIBS OUI
CMAKE_BUILD_TYPE Release
CMAKE_INSTALL_PREFIX
C:/Program Files (x86)/SFML
GLEW_INCLUDE_PATH C:/Users/Neckara/Desktop/Bibliothèques/SFML/SFML-2.0/LaurentGomila-SFML-8d0da1d/extlibs/headers
GLEW_LIBRARY C:/Users/Neckara/Desktop/Bibliothèques/SFML/SFML-2.0/LaurentGomila-SFML-8d0da1d/extlibs/libs-mingw/libglew.a
STATIC_STD_LIBS NON
-
Ok, tout est bon.
Quel était le problème déjà sous Windows ? (désolé, je suis vite perdu quand il y a trop d'info mélangées dans un même topic)
-
Je savais que j'aurais mieux fait d'ouvrir plusieurs autres sujets plutôt que de continuer sur celui-ci :-[
Promis là prochaine fois, je diviserais les sujets en fonctions des problèmes (on a bien dérivé du problème initial tout de même^^)
Sous window 7 en essayant de compiler la SFML 2.0 avec CMAKE, j'ai eu :
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>mingw32-make all
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj
Le chemin d'accès spécifié est introuvable.
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
mingw32-make: *** [all] Error 2
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>mingw32-make sfml-system
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
[ 7%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.
obj
Le chemin d'accès spécifié est introuvable.
mingw32-make[3]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/rule] Error 2
mingw32-make: *** [sfml-system] Error 2
C:\Users\Neckara\Desktop\Bibliothèques\SFML\SFML_build>
Je dois aussi avouer que je n'ai pas désinstallé la 1.6 sous Windows (et je ne sais pas aussi comment faire^^) mais je doute que ce soit le problème ici.
-
Tu as essayé de tout effacer et recommencer depuis zéro ?
Sinon, peut-être que ton CMake ou ton MinGW est "cassé".
En tout cas, rien à voir avec SFML.
-
J'ai tenté de le faire en changeant le chemin de telle sorte qu'il n'y avait plus de 'é' dans le chemin mais même résultat.
Pour le mingw32, j'ai la dernière version et elle marche parfaitement.
Pour le cmake, j'ai utilisé celui du site officiel :
cmake-2.8.7-win32-x86.zip
-
Y a un truc qui est cassé chez toi, ou que tu as mal fait, mais je ne vois pas quoi, désolé :(
-
Peut-être qu'avec SFML2 il existe une solution plus efficace et propre
Pas encore, mais ça arrivera bientôt.
Désolé de ressortir ce vieux sujet....
Mais je voulais savoir si depuis, une classe pour les zones de textes avait été ajoutée ?
-
Ce qui arrive bientôt ce sont les masques, pas les zones de texte. Et pour suivre l'avancement, cf. le task tracker ;)
-
Bonjour tout le monde !
J'ai malheureusement le même problème que neckara, que je n'arrive pas à résoudre : error 1 sur clock.obj.
Donc réflex je suis allé voir dans les sources, et en effet le fichier n'y est pas.
:-1: erreur : [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj] Error 1
CMake n'a pas fait le fichier clock alors que dans le dossier originel, le clock.cpp est présent. Une idée s'il vous plait ?
J'utilise Qt, j'ai générer le tout avec la dernière version de CMake via Qt.
Cordialement
-
Peux-tu donner la sortie de compilation complète jusqu'à l'erreur, ainsi que le chemin complet de ton répertoire de build ?
Il n'y a rien eu de bizarre comme message lors de la configuration avec CMake ?
Quel est ton OS, et quelle est ta version de SFML ? (pourquoi la recompiles-tu d'ailleurs ?)
PS : mieux vaut ouvrir de nouveaux sujets que de venir se mélanger à un fil de discussion qui n'a déjà plus ni queue ni tête...
-
Alors vous allez être content :p
Le problème est simplement réglé en enlèvent tout les accents du répertoire !
En effet, je travaillais dans un dossier "Développement". C'était le 'é' qui faisait toute la merde ;)
A savoir et à mettre dans des truc et astuce ou quelque chose du genre :)
Je recompille les sources pour les intégrer à Qt5, MinGW 4.7. Il y a une autre manière ?
-
Le problème est simplement réglé en enlèvent tout les accents du répertoire !
C'est la première chose qui m'était venue à l'esprit, mais je pensais que tu avais déjà essayé, puisque c'est mentionné juste au-dessus :P
Je recompille les sources pour les intégrer à Qt5, MinGW 4.7. Il y a une autre manière ?
Oui : télécharger la version précompilée de SFML pour gcc 4.7.