Messages

1

Général / [SFML 2.1, Linux] ".so n'est pas un lien symbolique" avec ldconfig

« le: Avril 10, 2014, 03:16:53 pm »

Bonjour,

Tout d'abord, pour préciser, ce topic sert plus à annoncer un warning qu'une erreur puisque le problème soulevé ne m'empêche pas d'avancer !

C'est à propos d'un programme comprenant des dépendances SFML que j'avais créé sur une VM Linux (Ubuntu je-sais-plus-quelle-version) et que je devais lancé sur mon serveur sous Ubuntu 12.04 LTS.

J'ai sans problème pu installer les autres dépendances qui m'étaient nécessaires en passant par apt-get directement (par exemple Boost). Mais ayant compris qu'à priori les dépôts ne comprennent que la version 1.6 de SFML j'ai préféré faire l'autre solution pour ce SDK : télécharger la version GCC Linux pour 64bit, rajouter le lien du dossier lib dans ld.so.conf et effectuer un ldconfig pour que le système puisse reconnaître le SDK correctement. (solution qui a aussi été utilisé au moment de la création du programme sur ma VM, sans souci)

Mais lors du ldconfig j'obtiens ces retours sur mon serveur :

/sbin/ldconfig.real: /home/SFML-2.1/lib/libsfml-window.so.2 n'est pas un lien symbolique

/sbin/ldconfig.real: /home/SFML-2.1/lib/libsfml-audio.so.2 n'est pas un lien symbolique

/sbin/ldconfig.real: /home/SFML-2.1/lib/libsfml-system.so.2 n'est pas un lien symbolique

/sbin/ldconfig.real: /home/SFML-2.1/lib/libsfml-graphics.so.2 n'est pas un lien symbolique

/sbin/ldconfig.real: /home/SFML-2.1/lib/libsfml-network.so.2 n'est pas un lien symbolique
 

Pour information cela n'empêche pas à mon programme de maintenant retrouver le SDK et de fonctionner.

ldd sur le programme :

 
...
libsfml-system.so.2 => /home/SFML-2.1/lib/libsfml-system.so.2 (0x00007f637ef23000)
libsfml-network.so.2 => /home/SFML-2.1/lib/libsfml-network.so.2 (0x00007f637ed0a000)
...
 

Néanmoins je pose donc la question par curiosité étant donné que j'avais installé de la même façon SFML sur ma VM et que je n'avais pas eu ce genre de retour avec ldconfig, et que ces derniers semblent annoncer une erreur.

Y a t-il quelquechose à faire pour corriger ça ?

2

Fenêtrage / Re : [RESOLU][SFML 2.0] Souci de FBO avec sf::style::Default

« le: Février 12, 2014, 05:18:44 pm »

Bon, finalement c'était un petit problème de configuration du FBO qui venait poser souci ^^ ! Un "glDrawBuffers(1, gl_draw_buffers);" de trop ! C'est en écrivant le code minimal que je me suis rendu compte que j'avais même plus le FBO en Fullscreen ><, et que je suis remonté petit à petit à cette ligne problématique !

Néanmoins il me reste une bizarrerie !

Je donne le code minimal suivant (utilise SFML 2.0 et GLEW 1.9.0)

#include <GL/glew.h>
#include <SFML/Window.hpp>
#include <SFML/OpenGL.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>
#include <vector>

GLuint sizeX=800;
GLuint sizeY=600;

GLuint oculusFBO;
GLuint oculusFBODepth;
GLuint oculusFBOTexture;

typedef unsigned char UINT8;

GLint setupFBO();

int main()
{
    sf::RenderWindow window;
    window.create(sf::VideoMode(sizeX, sizeY), "testFBO", sf::Style::Default, sf::ContextSettings(32));
    window.setVerticalSyncEnabled(true);

    GLenum initialisationGLEW( glewInit() );
    if(initialisationGLEW != GLEW_OK)
    {
        std::cout << "Erreur d'initialisation de GLEW : " << glewGetErrorString(initialisationGLEW) << std::endl;
        return 1;
    }

        glDisable(GL_DEPTH_TEST);
        glDisable(GL_CULL_FACE);

    if(setupFBO() != 0)//erreur
    {
        return 2;
    }

        sf::CircleShape shape(50);
        shape.setFillColor(sf::Color(100, 250, 50));

        bool running = true;
    while (running)
    {
        // gestion des évènements
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            {
                // on stoppe le programme
                running = false;
            }
            else if (event.type == sf::Event::Resized)
            {
                // on ajuste le viewport lorsque la fenêtre est redimensionnée
                glViewport(0, 0, event.size.width, event.size.height);
            }
            else if (event.type == sf::Event::KeyPressed)
            {
                if(sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
                {
                        running = false;
                }
                if(sf::Keyboard::isKeyPressed(sf::Keyboard::F))//permet d'enregistrer le contenu du FBO (pour debug)
                {
                    std::vector<UINT8> pixels(sizeX*sizeY*4);

                                        glBindFramebuffer(GL_FRAMEBUFFER, oculusFBO);
                                        glReadBuffer(GL_COLOR_ATTACHMENT0);
                                        glReadPixels(0, 0, GLsizei(sizeX), GLsizei(sizeY), GL_RGBA, GL_UNSIGNED_BYTE, &pixels[0]);
                                        glBindFramebuffer(GL_FRAMEBUFFER, 0);

                                        sf::Texture texture;
                                        texture.create(sizeX, sizeY);
                                        texture.update(&pixels[0]);
                                        texture.copyToImage().saveToFile("testFBO.jpg");
                }
            }
        }

        //rendu dans le FBO
        glBindFramebuffer(GL_FRAMEBUFFER, oculusFBO);

                glViewport(0,0, sizeX, sizeY);

                glClearColor(0,0,0,0);
                glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

                //un rond SFML
        window.pushGLStates();
        window.draw(shape);
                window.popGLStates();

                //et un triangle OpenGL
                glBegin(GL_TRIANGLES);
        glColor3f(1, 0, 0);
        glVertex3f(0, 0, 0);
        glVertex3f(1, 0, 0);
        glVertex3f(0, 1, 0);
        glEnd();

                glBindFramebuffer(GL_FRAMEBUFFER, 0);

                //maintenant on va afficher le FBO à l'écran

        // effacement les tampons de couleur/profondeur
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

        glEnable(GL_TEXTURE_2D);
                glBindTexture(GL_TEXTURE_2D, oculusFBOTexture);

                float quad[][5]=
                {
                        {-1, -1, -1,  0,  0},
                        { 1, -1, -1,  1,  0},
                        { 1,  1, -1,  1,  1},
                        {-1,  1, -1,  0,  1},
                };
                unsigned int faces[]=
                {
                        0, 1, 2, 3
                };

                glEnableClientState(GL_VERTEX_ARRAY);
                glEnableClientState(GL_TEXTURE_COORD_ARRAY);

                glVertexPointer(3, GL_FLOAT, 5*sizeof(float), &quad[0][0]);
                glTexCoordPointer(2, GL_FLOAT, 5*sizeof(float), &quad[0][3]);

                glDrawElements(GL_QUADS, 4, GL_UNSIGNED_INT, faces);

                glDisableClientState(GL_VERTEX_ARRAY);
                glDisableClientState(GL_TEXTURE_COORD_ARRAY);

                glBindTexture(GL_TEXTURE_2D, 0);
                glDisable(GL_TEXTURE_2D);

        // termine la trame courante (en interne, échange les deux tampons de rendu)
        window.display();
    }

    // libération des ressources...
    // mais je suis un gros flemmard :p

}

GLint setupFBO()
{
        glGenFramebuffers(1, &oculusFBO);
    glGenTextures(1, &oculusFBOTexture);
    glGenRenderbuffers(1, &oculusFBODepth);

    glBindFramebuffer(GL_FRAMEBUFFER, oculusFBO);

    glBindTexture(GL_TEXTURE_2D, oculusFBOTexture);

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, sizeX, sizeY, 0,GL_RGBA, GL_UNSIGNED_BYTE, 0);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

    glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, oculusFBOTexture, 0);

    glBindRenderbuffer(GL_RENDERBUFFER, oculusFBODepth);
    glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, sizeX, sizeY);
    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, oculusFBODepth);

    //glDrawBuffers(1, gl_draw_buffers);

        if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
    {
        glBindFramebuffer(GL_FRAMEBUFFER, 0);
                std::cout<<"[FRAMEBUFFER] error."<<std::endl;
                return 1;
    }

        glBindFramebuffer(GL_FRAMEBUFFER, 0);

    return 0;
}

Ce code va donc faire le rendu d'un rond vert SFML et d'un triangle rouge OpenGL dans le FBO, et ensuite on affichera le FBO à l'écran ! Voici le contenu du FBO (lu via la petite partie de code dispo en appuyant sur F) :



Mais voici le résultat une fois l'affichage du FBO à l'écran :



Je sais pas d'où me viens cette transformation du rond vert en marron xD ! (l'inversion est normale par contre)

Bon, je peux aucunement mettre en cause je pense un problème avec la SFML puisque le contenu du FBO est correct ^^ ! Ça doit venir d'un paramètre OpenGL manquant je suppose !

Enfin bref, je passe ça en Résolu !

3

Fenêtrage / [Résolu][SFML 2.0] Souci de FBO avec sf::style::Default

« le: Février 12, 2014, 11:57:52 am »

Bonjour,

J'essayais de rechercher une erreur équivalente mais sans succès, c'est pour cela que j'ouvre ce topic !

J'ai un programme assez costaud OpenGL+SFML (+ quelques tonnes d'autres libs ^^) auquel je devais implémenter récemment une fonctionnalité qui me demandait d'utiliser un FBO (1ère fois que j'en utilise,  et je sais que je vais dans le futur m'en servir pour bcp d'autres choses ^^) ! Je fais donc quelques rendus dans le FBO, que j'utilise ensuite pour faire un rendu à l'écran !

Enfin bref, tout se passe bien en sf::style::Fullscreen, mais avec sf::style::Default pour me retrouver en mode fenêtré impossible de mettre à jour le contenu de mon FBO, ce dernier reste vide ! C'est la seule chose que j'ai changé, et ça me produit donc un bel écran noir !
Pour info, si je fais un rendu directement à l'écran plutôt que dans le FBO tout fonctionne bien, en Fullscreen comme en Default !

Je vais m'arrêter là pour ce 1er post, si ça se trouve ces premières informations seront suffisantes pour comprendre le problème (problème connu de 2.0 et corrigé en 2.1 ? Je n'ai pas d'autres pistes)  !

Sinon je peux essayer d'écrire un code minimal en cas de besoin ! Il suffit de me demander (se basera sur SFML 2.0 avec utilisation de GLEW par contre) !

4

Graphique / Re : Re : [Curiosité] Performance/BestPractice sf::Quads comparé à sf::Triangles

« le: Septembre 05, 2013, 04:06:53 pm »

La différence est très minime en effet.

Mais utilise des sf::Triangles, sf::Quad sera déclaré obsolète dans la prochaine version car il n'est pas supporté sur OpenGL ES (plateformes mobiles).

Excellent, merci pour la réponse rapide !

5

Graphique / [Curiosité] Performance/BestPractice sf::Quads comparé à sf::Triangles

« le: Septembre 05, 2013, 03:55:26 pm »

Salut salut,

Je me posais une petite question face à l'utilisation des sf::VertexArray. Cela fait déjà longtemps que j'avais remarqué qu'il fallait privilégié l'utilisation des Triangles avec OpenGL que le rendu de Quads, puisque le GPU gère plus simplement les triangles.

Mais qu'en est-il lorsqu'on utilise sf::Quads ou sf::Triangles ?
Je n'ai pas fait de test de performance, je suppose que dans tous les cas la différence reste minime, à moins que la SFML découpe automatiquement le sf::Quads en sf::Triangles pour le rendu !?

Voilà, je voulais simplement me renseigner sur ça, car tant qu'à faire, vu que je gère des triangles du côté d'OpenGL, il serait peut être mieux finalement que je gère tout aussi bien mon interface 2D (affichée en utilisant donc des sf::VertexArray) avec des sf::Triangles plutôt que des sf::Quads !

6

Fenêtrage / Re : caractères non reçus par TextEntered, et gestion clavier QWERTY

« le: Août 26, 2013, 06:25:14 pm »

Ok, merci ! je ne savais pas ^^ !

7

Fenêtrage / Re : caractères non reçus par TextEntered, et gestion clavier QWERTY

« le: Août 26, 2013, 05:09:05 pm »

J'aurais besoin de toi finalement Laurent pour comprendre un dernier point sur le TextEntered et mes caractères accentués.

Me basant sur la table ascii étendue, je pensais déjà donc géré l'event jusqu'à "event.text.unicode < 169" !

En me basant donc sur ça :


Mais voilà, les caractères accentués ne retournent pas du tout ces valeurs, le 'è' retourne 232, le 'é' retourne 233, le 'ê" 234, le 'ô' 244.

Ce n'est donc même pas un décalage avec la table ascii étendue !

Je peux sans souci gérer les caractères dont j'ai besoin de façon "manuelle", mais j'amerais savoir comment ça fonctionne pour ces caractères étendus. Et si je peux donc filtrer les caractères que je veux par un simple encadrement de "event.text.unicode" ou si je dois les traiter un par un !?

8

Réseau / Re : Re : [SFML2.0] Souci TcpListener.accept avec SocketSelector

« le: Août 24, 2013, 10:32:24 pm »

C'est assez vicelar (et tu ne pouvais pas deviner) : en fait la socket interne est créée non pas dans le constructeur de TcpListener, mais dans la fonction listen. Du coup tu ajoutes ton listener trop tôt au sélecteur, la socket interne n'existe pas encore.

Haha, en effet j'aurais eu du mal à deviner ^^ ! Je m'en vais tester ça de suite ^^ !

EDIT : c'est parfait, ça fonctionne bien ^^ ! Merci d'avoir répondu si rapidement, ça va me permettre de continuer un peu à coder ce soir l'esprit tranquille ^^ !

9

Réseau / [Résolu] [SFML2.0] Souci TcpListener.accept avec SocketSelector

« le: Août 24, 2013, 10:14:59 pm »

Bonjour,

Je crée tranquillement le nécessaire pour un serveur gérant plusieurs clients. Mais j'ai un souci car le SocketSelector (dans lequel j'ai donc enregistré mon TcpListener), ne répond jamais lorsqu'un client fait un "connect". Le client reçoit bien la comfirmation de la connexion dit en passant !

voici le code concerné :

GLvoid Net_BasicServer::listenConnectTCP_Thread()
{
        sf::SocketSelector selector;
        selector.add(m_TCPlistener);

        m_b_stopThreads = false;

        // lie l'écouteur à un port
        if (m_TCPlistener.listen(m_portEcoute) != sf::Socket::Done)
        {
                std::cout<<"port déjà utilisé"<<std::endl;
        }

        std::cout<<"Début thread écoute TCP Serveur"<<std::endl;

        while(!m_b_stopThreads)
        {
                // socket TCP d'écoute:
                if (selector.wait(sf::milliseconds(60)))
                {
                        if (selector.isReady(m_TCPlistener))
                        {
                                std::cout<<"test nouveau client"<<std::endl;

                                sf::TcpSocket* socket=new sf::TcpSocket();

                                if (m_TCPlistener.accept(*socket) == sf::Socket::Done)
                                {
                                        std::cout<<"nouveau client connecté"<<std::endl;

                                        m_clients.push_back(new Net_ConnectedClient(socket));
                                }
                        }
                }
        }

        std::cout<<"Fin thread écoute TCP Serveur"<<std::endl;

        m_TCPlistener.close();
}

Et voici donc les résultats de mes tests :

- avec ce code, si un client se connecte, il reçoit la confirmation de la connexion. Mais coté serveur, il ne passe jamais dans "if (selector.isReady(m_TCPlistener))". Et impossible ensuite de retenter une autre connexion

- testé sans le "if (selector.isReady(m_TCPlistener))", et bien entendu ça ne change rien. Donc en fait c'est qu'il ne parvient jamais à rentrer dans "if (selector.wait(sf::milliseconds(60)))". le selector ne semble pas réagir au connect du client.

- en supprimant le selecteur, tout fonctionne, le TcpListener.accept est pris en compte, d'autres clients peuvent rejoindre.

Voilà, je reste à disposition si il y a besoin d'autres infos. Au pire je peux toujours trouver un moyen de ne pas utiliser de selector, mais je les trouve bien utile pour justement stopper mes threads de façon bien contrôlé (dans ce cas j'ai juste à passé m_b_stopThreads à false dans le thread principal, et ça va me stopper l'écoute après 60 msec max).

10

Fenêtrage / Re : 2 soucis : caractères non reçus par TextEntered, et gestion clavier QWERTY

« le: Août 24, 2013, 09:50:15 pm »

Ok, je vais pas me compliquer la vie non plus. Après quelques recherches, je remarque que c'est loin d'être évident ^^ !

11

Fenêtrage / Re : Re : 2 soucis : caractères non reçus par TextEntered, et gestion clavier QWERTY

« le: Août 24, 2013, 12:35:21 am »

Premier problème : tu ne gardes que les caractères < 128, c'est-à-dire les caractères ASCII (donc pas d'accents).

Merci pour la précision, je n'avais pas assez fait attention à ce détail. En effet j'avais utilisé ton tuto sur les événements : http://www.sfml-dev.org/tutorials/2.0/window-events-fr.php
Celui-ci montrait un exemple de code sur "event.text.unicode < 128", et pas bien loin plus haut tu disais :
"Par exemple, appuyer sur '^' puis 'e' sur un clavier français produira deux évènements KeyPressed, mais un seul évènement TextEntered contenant le caractère 'ê'."
Résultat j'avais supposé, un peu trop vite, que les caractères accentués étaient déjà pris en compte avec ce code d'exemple ^^ !

Second problème : il est très peu probable que ça vienne de SFML. Il a essayé plusieurs fois ? Y compris après un redémarrage ?

Ok en fait j'ai redemandé et c'est moi qui a mal interprété ce que mon ami me disait je pense ^^ ! Il me disait que son clavier QWERTY se comportait comme un AZERTY, mais en fait c'est seulement que les touches de déplacement ZQSD dans le jeu ne sont evidement plus valides avec son clavier ^^ !

A ce propos, si je peux me permettre une nouvelle question, y a t-il un moyen de détecter le type de clavier utilisé, que je puisse paramétrer les touches par défaut du jeu pour des claviers AZERTY ou QWERTY ?

Merci en tout cas déjà pour cette réponse rapide ^^ !

12

Fenêtrage / [Résolu] caractères non reçus par TextEntered, et gestion clavier QWERTY

« le: Août 23, 2013, 07:44:45 pm »

EDIT: oups petite erreur de ma part, ce sujet devrait plus aller dans Système je suppose !?

Bonjour,

J'ai deux petites incompréhensions avec la SFML2.0. Loin d'être bloquants, ces deux problèmes impactent un peu quand même le gameplay de mon jeu ^^ !

Le premier souci vient de TextEntered (pour un module de tchat) qui ne me récupère pas certains caractères comme 'é', 'è', ... Bref tout ce qui semble avoir un accent (les combinaisons pour les majuscules ou autres sont bien récupérées).

Sans chercher à faire un code minimal (me demander si vraiment c'est jugé nécessaire), voici comment j'utilise l'event dans mon code :

if (event.type == sf::Event::TextEntered && event.text.unicode < 128)
                {
                        if(event.text.unicode == 8)
                        {
                                if(getText().size()>0)
                                        setText(getText().substr(0, getText().size()-1));
                        }
                        else if(event.text.unicode != 9 && event.text.unicode != 13 && (GLint)getText().size()-1<m_nbrCharMax)
                                setText(getText()+static_cast<char>(event.text.unicode));
                }

Bref, j'applique à une chaîne le backSpace, et sinon rajoute le caractère tant c'est ni Entrée, ni Tab qui est tapé. Mais donc je ne parviens à saisir d'où viens le souci pour ne pas reconnaitre les lettres avec accents.


Et j'en profite pour remonter un autre problème. Un ami a qui j'ai fait tester mon programme avait un souci sur la reconnaissance de son clavier QWERTY (PC Win7). Par souci je veux simplement dire que tout était récupéré comme si c'était un clavier AZERTY. En tout cas, je ne peux que supposer que c'est à la SFML de détecter le type de clavier pour récupérer les bons event.

Quoi qu'il en soit, ces deux soucis semble concerner un unique problème : la reconnaissance du clavier utilisé, des touches présentes.

Je peux difficillement ajouter plus d'information. Je travaille et j'ai ce souci de TextEntered en tout cas avec mon laptop sous Windows7 x64.

13

Général / Re : Undefined ref sur sf::RenderWindow.create()

« le: Mai 13, 2013, 05:08:43 pm »

Ah mince oui simplement !

Désolé, je ne sais pas pourquoi je n'y ai pas pensé plus tôt ^^ !

14

Général / [Résolu] Undefined ref sur sf::RenderWindow.create()

« le: Mai 13, 2013, 01:39:35 pm »

Bonjour,

(je place ce topic ici dans le forum "Général" car le souci est lié je pense à un problème sur la dernière version de la lib directement)

Le problème est simple, j'avais compilé correctement la SFML 2.0 sur mon PC fixe il y a une semaine, et tout fonctionnait bien sur mon projet.

Et j'ai aujourd'hui retélécharger les sources depuis le site pour recompiler la lib sur mon PC portable, qui possède exactement le même projet et la même config au niveau de l'IDE (Eclipse Juno), et je me retrouve en cherchant à compiler le projet avec l'erreur suivante :

 undefined reference to `_imp___ZN2sf6Window6createENS_9VideoModeERKSsjRKNS_15ContextSettingsE'

et concerne qu'une seule ligne de code: le create(...) du RenderWindow (le projet compile sans faute en commentant la ligne)

 window.create(VideoMode(800, 600), m_titreFenetre, Style::Default, ContextSettings(32));

Pour vérifier, j'ai donc recompilé la toute dernière version aussi sur mon PC fixe, et même erreur désormais (alors que tout marchait bien avec la version d'il y a une semaine).

Je suppose donc qu'il y a une petite erreur au niveau de la lib elle même !

Pour info : GCC 4.6.2, compilé avec CMake 2.8.10.2 et Eclipse 4.2 Juno (Eclipse CDT MinGW Makefiles) en Target !


EDIT : besoin de refaire un test ce soir sur mon PC fixe car je doute un peu si j'avais bien utilisé la version compilée datant de la semaine dernière, ou si c'était pas carrément une version bien plus vieille de la lib. Dans tous les cas ça n'empêche pas que je ne sais pas comment corriger cette erreur pour la dernière version ^^ !
(aucune erreur de compilation avec une bien plus ancienne version de la lib en tout cas)

15

Graphique / Re : Re : [SFML 2.0] 9-slice scaling - souci de RenderTexture

« le: Mai 11, 2013, 03:52:00 pm »

en effet j'aurais du faire attention que les  push/popGLStates n'était pas là que pour les draw, car si j'entoure le getTextureFromRenderTexture de ces deux instructions le programme ne plante plus. Faut-il en retenir que strictement tous les éléments du module graphique SFML ne doivent être manipulés qu'à travers push/popGLStates à partir du moment où la RenderWindow est active ?

Ben, dans ta fonction, tu fais bien des draw non ?

Oui et non !

Oui en effet avec mes NinePatch je fais des draw ! Mais pour l'exemple de code minimal pour reproduire le problème je ne fais strictement rien de tel dans la fonction getTextureFromRenderTexture ^^ !