Sortie SFML 2.0 : meilleure compatibilité avec OS X ?

[Laurent]

Certaines choses sont plus faciles qu'avant, mais en effet certaines autres sont probablement un peu plus verbeuses.

A vrai dire je ne suis toujours pas satisfait de l'API des formes dans SFML 2, mais bon maintenant ça attendra SFML 3

Ce qui est bien maintenant c'est que tu n'es pas obligé de les utiliser, tu peux créer toi-même ta géometrie avec sf::Vertex. Les classes de forme ne sont là que pour faciliter la vie de l'utilisateur, donc si ça te la complique ne t'embête pas avec.

[Olibrius]

Bon tout est réglé, plus qu'un problème à la compilation :

Code: [Sélectionner]

mingw32-make.exe[1]: Leaving directory `C:/Users/Loris/Documents/Code-Blocks/level_editor_qt'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x33d6): undefined reference to `__chkstk_ms'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x4202): undefined reference to `__chkstk_ms'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x4b6e): undefined reference to `__chkstk_ms'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x4cb7): undefined reference to `__chkstk_ms'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x7343): undefined reference to `__chkstk_ms'
C:/Program Files (x86)/CodeBlocks/SMFL/SFML-2.0/lib/libsfml-graphics-s.a(ImageLoader.cpp.obj):ImageLoader.cpp:(.text+0x7383): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status
mingw32-make.exe[1]: *** [release\level_editor_qt.exe] Error 1
mingw32-make.exe: *** [release] Error 2
Il y aurait un problème dans libsfml-graphics-s.a ?

[Laurent]

Non. Ca c'est plutôt un problème de configuration/environnement/compilo de ton côté. Regarde du côté de Google, apparemment tu n'es pas le premier à rencontrer ce genre d'erreur.

[Olibrius]

Bon, j'ai recompilé la SFML 2.0 avec Qt, et ça marche parfait sur Windows et OS X.

Maintenant, le problème c'est SFML + Qt.

Sous Windows, je crois que RenderWindow::draw( ... ) ne fonction pas, car je peux faire un RenderWindow::clear( ... ) avec la couleur que je veux et les évènements fonctionnent.
Note : j'ai du changer le create(winId()); dans QSFMLCanvas, par sf::Window::create(winId()); pour éviter la confusion avec QWidget::create( ... ).
EDIT: Résolu, c'était une mauvaise gestion de sf::View.

Sous Mac, rien ne fonctionne. J'ai seulement la partie Qt. Dans la sortie de l'application, j'ai ça quand je lance l'application :

Code: [Sélectionner]

2012-04-01 18:33:11.808 level_editor[308:107] invalid drawable
Pendant l’exécution, j'ai plein de :

Code: [Sélectionner]

Cannot process event from the view.
Cannot process event from the view.
Cannot process event from the view.
...
Et ça quand je ferme :

Code: [Sélectionner]

Cannot close the view.
Cannot close the view.
Alors je me suis demandé : SFML 2.0 est toujours compatible avec Qt ?

[Hiura]

Cannot process event from the view.

Cannot close the view.

Ce qu'il se passe actuellement c'est que Qt crée une NSView pour accueillir SFML (et pas une NSWindow). Dans l'implémentation que j'ai écrite, il n'est pas possible de récupérer les évènements (claviers, souris, ...) si la sf::[Render]Window a été créée de manière à être intégrée dans une fenêtre (et pas en tant que fenêtre).

Si la zone de rendu SFML n'est pas une fenêtre à part entière mais uniquement une "sous-zone" d'une fenêtre, alors il faut utiliser le système d'évènement de l'outil qui te permet d'integrer SFML dans la fenêtre (ici : Qt, dans d'autres cas : Cocoa, Wx, ...).

J'ai le souvenir d'avoir fait ainsi car c'était comme ça que ça fonctionnait aussi sous Windows et Linux. Me serais-je trompé?

[Laurent]

Sous Windows et Linux il n'y a aucune contrainte de ce genre, non.

[Olibrius]

Donc si j'ai bien compris, sous Mac on ne peut pas recevoir les évènements avec pollEvent si le rendu SFML n'est pas une fenêtre à part entière ?
Donc il faudrait gérer les évènement avec la partie Qt et les envoyer par des slots à la classe qui contient le rendu SFML ?

Dans l'implémentation que j'ai écrite...

Ou alors est-ce qu'il existerait une implémentation capable de récupérer les évènements ?

[Hiura]

Sous Windows et Linux il n'y a aucune contrainte de ce genre, non.

Alors il va falloir que je corrige tout ça! :/