Forum de la communauté SFML

Aide => Général => Discussion démarrée par: Olibrius le Mars 28, 2012, 07:06:29 pm

Titre: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 28, 2012, 07:06:29 pm
Bonjour à tous,

Je code actuellement un logiciel Qt 4.7 + SFML 1.6 sous Windows et il marche à merveille :) !
Le code étant 100% multi-plateforme, je le compile donc sous mon Mac OS X (Lion).

Le problème est, lorsque je lance mon application, la fenêtre reste blanche et je reçois plein de messages dans la sortie de l'application : 2012-03-17 21:22:47.733 level_editor[827:107] NSOpenGLPixelFormat creation failed! (invalid video settings ?)
2012-03-17 21:22:48.413 level_editor[827:107] NSOpenGLPixelFormat creation failed! (invalid video settings ?)
2012-03-17 21:22:48.420 level_editor[827:107] invalid context
2012-03-17 21:22:48.467 level_editor[827:107] invalid context
2012-03-17 21:22:48.527 level_editor[827:107] invalid context
2012-03-17 21:22:48.552 level_editor[827:107] invalid context
2012-03-17 21:22:48.572 level_editor[827:107] invalid context
2012-03-17 21:22:48.592 level_editor[827:107] invalid context
2012-03-17 21:22:48.611 level_editor[827:107] invalid context
2012-03-17 21:22:48.629 level_editor[827:107] invalid context
Et des "invalid context" jusqu'à ce que je ferme le logiciel.

Apparemment, il faudrait changer le contexte, et j'ai trouvé la structure ContextSettings (http://www.sfml-dev.org/documentation/2.0/structsf_1_1ContextSettings.php), cependant uniquement disponible sous SFML 2.0.

Je me demande alors :
- Y a-t-il un moyen de résoudre ce problème avec SFML 1.6 ?
- Ou alors ferais-je mieux d'attendre la version 2.0 ? Si oui, c'est pour quand, environ ?

Je vous remercie d'avance  ;) !
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: victorlevasseur le Mars 28, 2012, 09:21:52 pm
Salut,

Sinon, tu peux déjà utiliser la version dev de la SFML 2.0 (qui est très stable).
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 28, 2012, 09:44:55 pm
Je sais, mais dans ce cas je dois tout réécrire le code pour mac pour qu'il soit compatible SFML 2.0.
Bien sûr je peux aussi utiliser la 2.0 sur Windows.

Mais je ne suis pas pressé, alors je préfère continuer en 1.6 sur Windows en attendant la 2.0 pour le réécrire et compiler sous mac.
Dans ce cas, pourrait-on connaître la date de sortie officielle pour la 2.0 ?

Ou existe-t-il un moyen pour régler ces "création failed" en 1.6 ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Hiura le Mars 29, 2012, 09:12:06 am
Ou existe-t-il un moyen pour régler ces "création failed" en 1.6 ?

J'aurais tendance à dire que non, mais peut-être que je me trompe.

Maintenant, en ce qui concerne la version 2.0, le seul moyen de savoir si ça fonctionne c'est de tester. Je n'ai personnellement pas le temps de tester SFML+Qt (du moins pas avant cet été vu comme le semestre se déroule en ce moment...).

D'instinct uniquement, je dirais que ça fonctionne : je ne vois pas pourquoi ça ne marcherait pas alors que JSFML fonctionne qui est, elle, une integration plus complexe il me semble.
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 29, 2012, 09:47:53 pm
Bon j'ai tester avec la 2.0, et ça marche :D !!

Juste un dernier problème.
Chez un copain, certain caractère d'un sf::Text ont une sorte de cadre.

A gauche chez moi, à droite chez mon copain.
(http://img76.xooimage.com/files/0/a/4/temp-33083fb.png)

Et encore, à quand la sortie de la SFML 2.0 officielle ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 29, 2012, 10:39:00 pm
Citer
Chez un copain, certain caractère d'un sf::Text ont une sorte de cadre.
C'est un bug connu.

Citer
Et encore, à quand la sortie de la SFML 2.0 officielle ?
Quand elle sera prête.
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 30, 2012, 06:07:49 pm
Donc ce bug sera corrigé dans la version finale si j'ai bien compris ?

Sinon, autre problème, comme je passe aussi à la 2.0 sur Windows, j'obtiens toujours des erreurs dans cmake :
...
Check size of void*
Check size of void* - failed
CMake Warning at cmake/Config.cmake:9 (if):
  given arguments:

    "EQUAL" "4"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)


CMake Warning at cmake/Config.cmake:11 (elseif):
  given arguments:

    "EQUAL" "8"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)


CMake Error at cmake/Config.cmake:14 (message):
  Unsupported architecture
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)


Configuring incomplete, errors occurred!

Apparemment ça viendrait du fichier cmake/Config.cmake ?

EDIT: J'ai réussi à obtenir mon makefile en utilisant une ancienne version de Config.cmake.
Cependant lorsque je compile (sous Code::Blocks), j'ai plein de undefined reference to `_Unwind_Resume'

Que faire ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 30, 2012, 08:36:05 pm
Tu utilises quelle version de CMake ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 30, 2012, 08:40:33 pm
Citer
CMake 2.8.7
Using Qt 4.6.2
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 30, 2012, 08:53:11 pm
Mince... J'ai fait un "fix" pour le message d'erreur mais je viens de voir que ça n'a rien à voir :
Citer
Check size of void* - failed
Ca c'est pas ma faute, et c'est pour ça que la suite foire :)

Tant pis...
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 30, 2012, 09:05:43 pm
Merci pour toutes ces réponses :) !

J'ai cependant toujours de la peine à transformer mon code pour qu'il soit compatible en 2.0.
Par exemple, avant pour avoir la position de la souris dans la fenêtre, j'utilisais ces quatre lignes :
event.MouseButton.X
event.MouseButton.Y

event.MouseMove.X
event.MouseMove.Y

Or en 2.0, il faudrait faire Mouse::getPosition(window).
Et comme je fait une application SFML + Qt, ma class SFMLView hérite de QSFMLCanvas (pris du tutoriel), qui elle-même hérite de RenderWindow.
Donc j'ai essayé Mouse::getPosition(this), mais sans succès :( ...
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 30, 2012, 09:31:17 pm
Les évènements n'ont pas changé dans SFML 2, tu peux toujours faire ce que tu faisais avant.

Quant à Mouse::getPosition(this), il manque juste une étoile puisque c'est un Window& et non un Window* qui est demandé.
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 30, 2012, 10:15:02 pm
Ah oui, je n'avais plus pensé que la SFML 2.0 n'avait plus de majuscule au début des membres.

Autre problèmes sinon, je créer un ConvexShape qui peut être de n'importe quel forme selon ce que l'utilisateur fait. Avant, lorsque l'utilisateur dessinait un cercle, je faisait :
myShape = Shape::Circle( ... ... );
Maintenant, j'ai essayé de faire :
CircleShape circle( ... ... );
myShape = circle; // myShape étant un ConvexShape

Mais le compilateur n'accepte pas et me dit :
erreur : no match for 'operator=' in '((SFMLView*)this)->SFMLView::p.std::vector<_Tp, _Alloc>::operator[] [with _Tp = sf::ConvexShape, _Alloc = std::allocator<sf::ConvexShape>](0u) = circle'
Y aurait-il une possibilité de convertir un CircleShape en ConvexShape ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 30, 2012, 11:03:16 pm
Citer
Y aurait-il une possibilité de convertir un CircleShape en ConvexShape ?
Non, mais pourquoi voudrais-tu faire ça ?

Et avant d'essayer des trucs et de rapporter que ça ne marche pas, tu peux aussi lire la doc pour voir si c'est censé le faire ou pas ;)
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 31, 2012, 09:09:14 am
Non, mais pourquoi voudrais-tu faire ça ?

En fait mon logiciel permet de créer des formes et de les modifier.
L'utilisateur à le choix entre rectangle, cercle et polygone.
Lorsque la forme est terminée, elle était stocké dans un std::vector<sf::Shape>.

Et lorsque j'ai transformé le code en SFML 2.0, le vector est devenu un vector de ConvexShape, et j'ai eu un peu de peine pour le cercle et le polygone.

Comme dit plus haut, je doit donc pouvoir mettre un CircleShape dans ce vecteur. Pour le moment, je le convertis point par point en un ConvexShape.

Et pour le polygone, à chaque clique de la souris je faisait un myShape.AddPoint( ... ... ). Pour le moment, je fais myShape.setPointCount(myShape.getPointCount()+1) et myShape.setPoint(myShape.getPointCount()-1, Vector2f(positionSouris).

C'est pourquoi je me demandais s'il n'y avait pas un moyen plus simple que cela, car ça m'étonnerais que la 2.0 ait une gestion des formes plus compliqué que la 1.6.

Sinon ce n'est pas trop grave ;) , mais merci quand-même pour toutes ces réponses rapides !
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 31, 2012, 10:09:54 am
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.
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Mars 31, 2012, 09:07:33 pm
Bon tout est réglé, plus qu'un problème à la compilation :
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 ?
Titre: Re : Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Mars 31, 2012, 09:27:33 pm
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.
Titre: Re: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Avril 01, 2012, 06:37:37 pm
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 :
2012-04-01 18:33:11.808 level_editor[308:107] invalid drawable
Pendant l’exécution, j'ai plein de :
Cannot process event from the view.
Cannot process event from the view.
Cannot process event from the view.
...

Et ça quand je ferme :
Cannot close the view.
Cannot close the view.

Alors je me suis demandé : SFML 2.0 est toujours compatible avec Qt ?
Titre: Re: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Hiura le Avril 01, 2012, 07:53:38 pm
Citer
Cannot process event from the view.
Citer
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é? ???
Titre: Re: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Laurent le Avril 01, 2012, 08:47:26 pm
Sous Windows et Linux il n'y a aucune contrainte de ce genre, non.
Titre: Re: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Olibrius le Avril 01, 2012, 09:12:46 pm
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 ?
Titre: Re: Sortie SFML 2.0 : meilleure compatibilité avec OS X ?
Posté par: Hiura le Avril 01, 2012, 09:33:41 pm
Sous Windows et Linux il n'y a aucune contrainte de ce genre, non.
Alors il va falloir que je corrige tout ça! :/