Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

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.


Messages - coco

Pages: [1] 2 Suivante »
1
Fenêtrage / Re : SFML, coordonnées, draw et glClipPlanes
« le: Février 05, 2013, 07:32:17 pm »
Ca semble fonctionner correctement avec un resetGLStates sur le RenderTarget avant d'activer les clip planes.

Pour le glScissor, on doit utiliser les coordonnées du RenderTarget ou celles de la RenderWindow ? Le "Windows coordinates" dans la doc me fais douter...

2
Fenêtrage / Re : SFML, coordonnées, draw et glClipPlanes
« le: Février 05, 2013, 04:44:17 pm »
Pour glScissors, probablement parce que je ne connais pas ^^. Je vais y jeter un coup d'oeil !

Pour glClipPlanes, d'après la doc :

Citer
When glClipPlane is called, equation is transformed by the inverse of the modelview matrix and stored in the resulting eye coordinates. Subsequent changes to the modelview matrix have no effect on the stored plane-equation components.

Si je comprends bien, à l'appel il convertit en "global" a partir de la vue courante. Du coup, a quel moment le transform des RenderStates est appliqué à openGL ? Lors du RenderTarget::draw ?

3
Fenêtrage / SFML, coordonnées, draw et glClipPlanes
« le: Février 05, 2013, 04:22:27 pm »
Bonjour !

J'utilise les clipPlanes d'openGL pour masquer des éléments qui dépassent de leur conteneurs ( GUI ). J'ai réussi a les faire fonctionner, mais dans certains cas cela ne fonctionne pas, ou très mal.

A noter : Chaque élément de GUI est positionné en local par rapport à son parent pour l'affichage. les draw successifs déplacent la "zone de rendu" au coin supérieur gauche du conteneur, et ainsi de suite...

Je suppose que mes équations de plan sont fausses. Je me demande donc ce que j'ai mal fait.

1- Pour délimiter un objet de taille (w,h) et de position (x,y), c'est bien les équations suivantes que je dois utiliser ?

        GLdouble eq1[] = {1, 0, 0, -x};
        GLdouble eq2[] = {-1, 0, 0, x+w};
        GLdouble eq3[] = {0, 1, 0, -y};
        GLdouble eq4[] = {0, -1, 0, y+h};
 

2- Est-ce que le fait de modifier le transform des RenderStates influe sur les équations des clipPlanes ?

Merci d'avance =)


4
Général / Re : Probleme situé au niveau des events
« le: Août 27, 2012, 12:02:18 pm »
Il faudrait que tu indentes mieux ton code parce que c'est dur a lire, mais tu retournerais pas EXIT_SUCCESS a la fin de ta boucle ou tu teste app.IsOpenned ? du coup oui, ton programme doit se fermer après la premiere boucle...

int main()
{
    [...]

    if (!image.LoadFromFile("cat.png"))
    {
        cout<<"Erreur durant le chargement de l'image"<<endl;
        return EXIT_FAILURE;
    }
    else
    {
       [...]
        while (app.IsOpened())
        {
            while (app.GetEvent(event))
            {
                switch (event.Type)
                {
                    [...]
                }
                if(marche == false)
                {
                   [...]
                }
                personnage.SetPosition(Vector2f(x, y));
                marche = false;

                app.Clear();
                app.Draw(personnage);


                app.Display();
                personnage.SetImage(image);
                sf::Sleep(0.5f);

                std::cout << 1 << std::endl;
            }
            return EXIT_SUCCESS;// La ligne fatale =)
        }
    }
}
 

5
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Août 21, 2012, 04:42:37 pm »
MAJ

J'ai fait quelques tests supplémentaires au niveau de l'utilisation de la mémoire graphique. J'ai utilisé le programme GPU-Z de TechPowerUp pour tracer la quantité de mémoire graphique utilisée par notre jeu.

J'ai remarqué que la mémoire graphique ne descendait presque jamais après la destruction d'une texture ( glDeleteTextures() dans le destructeur de Texture ). Après quelques recherches, je suis tombé sur un thread où ils conseillaient d'appeller glFlush() pour s'assurer que la mémoire opengl était correctement désallouée. J'ai donc rajouté des glFlush() juste après la destructions d'images, et, ô miracle, la mémoire graphique semble correcte ( augmente et diminue au fil des chargements/dechargements d'images ). En revanche, j'ai été obligé de placer le glFlush dans le même thread que le déchargement des images, sinon la mémoire n'était pas libérée ( problème de contexte openGL ? ).

Pour obtenir ces résultats, j'ai testé sur les deux pc ( Win 7 64, un avec une Nvidia, un avec une ATI ). J'ai le même comportement avec les deux configs au niveau de la mémoire graphique avec et sans glFlush(), même si le pc Nvidia semble "moins" affecté lorsque sa RAM graphique est blindée que l'ATI.

Est-ce correct d'appeller glFlush() manuellement ? Si quelqu'un a des infos...

6
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Août 20, 2012, 02:30:51 pm »
Bonjour !

Je reviens sur ce thread car j'ai toujours des soucis de compatibilité ATI et/ou 2.0 que j'ai absolument besoin de corriger.

J'ai testé un peu cette histoire de RAM graphique et normale. Il semble que le programme charge les nouvelles images en RAM normale lorsque la RAM graphique est pleine.

J'avais parlé plus tôt dans ce thread d'un bug sur les Threads avec les cartes ATI ( nécessité de déclarer un contexte explicitement, contrairement à Nvidia, sinon les images ne s'affichent pas ). J'ai l'impression que les images ne sont pas correctement déchargées au bout d'un moment. Sur un PC ATI ( Windows 7-64 ), la ram graphique augmente jusqu'a un point proche du max ( ~960/1024 ). Pendant un petit moment à charger/décharger des images, la RAM graphique oscille et la normale ne bouge pas. Au bout d'un moment, c'est la ram normale qui augmente, mais ne diminue plus lorsque les images sont détruites. lorsque la ram normale atteint un chiffre élevé ( ~1go ), le programme bloque dans la dll openGL d'ati ( pendant le rendu ou pendant un bind texture ).

Je n'ai pas réussi à reproduire ce comportement sur un pc Nvidia ( Windows 7 64 ).

Pour le moment je n'ai pas trouvé la source du problème ( et je galère un peu ). J'ai essayé de déclarer un contexte au moment de la destruction des textures ( et non plus uniquement à la création ), mais j'avais d'autres problèmes...

Petites questions au passage :
- Est-ce qu'une image chargée dans un thread doit être détruire dans le même thread ( même contexte )  ?
- J'ai vu dans les sources SFML qu'il y a une liste de internalContexts qui s'empilent pour chaque nouveau thread, et qui sont détruites uniquement dans la fonction de cleanUp global. C'est probablement de la que vient une partie de la fuite décrite dans ce bug : https://github.com/SFML/SFML/issues/120, et je me demandais si ça pouvait avoir un rapport avec mon problème.

je vais essayer de résumer le fonctionnement, au cas ou quelqu'un détecterait un problème potentiel :

on a un main thread qui fait quasiment tout ( affichage, physique... ). Lorsque le joueur change de map, on a un premier thread qui effectue l'initialisation des nouvelles maps, et qui envoie des requêtes de chargement de textures, effectuées par un troisième thread ( tout ça pendant que le jeu tourne dans le main ). Lorsqu'on s'éloigne d'une map, le premier thread désinitialise les maps et il détruit les textures.

Depuis le passage à la 2.0, on a aussi des chutes de framerate brutales ( localisées principalement dans l'affichage ), que nous n'avions pas sur la 1.6.

Je vais poursuivre mes investigations, et je mettrai a jour si je trouve quelque chose.

Je prends toute info ou suggestion pour essayer de localiser/corriger ce bug ( dans SFML si nécessaire ).

Merci de votre aide.

ps : Lorsque j'ai créé ce thread, j'ai pris le snapshot 2.0-rc-42-[...].
Actuellement c'est le 74 je crois. Serais-ce une bonne idée de mettre a jour au passage ?

ps2 : question "hors sujet" : Est ce qu'il y a déjà eu des jeux commerciaux sortis utilisant SFML ?

edit rapide : J'ai repris et modifié légèrement le code proposé par Ceylo ( https://github.com/SFML/SFML/issues/120 ) de la façon suivante :

#define TEX_SIZE 2048
sf::Image sharedImage;

void thread_func(void *data)
{
   // Reuse the same texture object
   sf::Texture** tex = ((sf::Texture **)data);
   (*tex) = new sf::Texture();

   //sf::Context ctx;

   // Should just erase the previous data
   (*tex)->loadFromImage(sharedImage);
}

int main()
{
   sf::Texture* tex = NULL;
   sharedImage.create(TEX_SIZE, TEX_SIZE, sf::Color::Red);
   sf::Thread th(thread_func, (void *)(&tex));

   sf::RenderWindow window;
   window.create(sf::VideoMode(256,256,32), "test");

   // Create one thread/sec
   while (true)
   {
          th.launch();
          th.wait();

          window.clear();
          sf::Sprite sprite;
          sprite.setTexture(*tex,true);

          window.draw(sprite);
          window.display();
          sprite.setTexture(sf::Texture(), true);
          delete tex;
   }

   return 0;
}
 

Résultat ( toujours sur mon pc win7 64 ATI ) : si je commente la déclaration du contexte dans le thread, j'ai une leak beaucoup plus importante ( ~16 Mo par itération ) contre beaucoup moins si je déclare le contexte dans le thread... C'est probablement lié a la nécessite de déclarer un contexte pour charger les images sur ATI. Si ça peut aider...

7
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 20, 2012, 05:10:29 pm »
1 - J'ai oublié de préciser un peu, désolé ^^
Là, J'ai fait des tests sur Windows 7, avec une ATI et avec une Nvidia. Ca fonctionne bien sur le pc Nvidia et pas sur l'ATI. Je pense que les drivers de l'ATI sont a jour ( de fin juin ).

nb : Je te laisse remplacer l'image chargée par celle de ton choix...

sf::Texture* texture = NULL;

void createTexture()
{
   //sf::Context glContext; //Fonctionne correctement sur ATI si cette ligne est décommentée
   
   texture = new sf::Texture();
   texture->loadFromFile("image.png");//Changer pour une image accessible
}

int _tmain(int argc, _TCHAR* argv[])
{
   sf::RenderWindow window;

   window.create(sf::VideoMode(500,500,32), "test app");

   sf::Thread createThread(createTexture);

   createThread.launch();
   createThread.wait();

        sf::Sprite sprite;
   sprite.setTexture(*texture);

   bool loop = true;
   while ( loop )
   {
      sf::Event sfEvent;
      while (window.pollEvent(sfEvent))
      {
         if (sfEvent.type == sf::Event::Closed )
            loop = false;
      }

      window.clear(sf::Color::Black);
      window.draw(sprite);
      window.display();
   }

   delete texture;
   texture = NULL;

   window.close();
   return 0;
}
 

Si tu as besoin de plus d'informations...

2 - J'avais pas vu ce paramètre... ça peut aider ^^

3 - Je pense aussi que ça va poser problème, d'où ma question. Ce que je voulais dire, c'est est-ce qu'il les chargera en RAM normale si la RAM graphique est pleine ? Parce que sinon selon la capacité de la carte graphique de l'utilisateur, ça risque de poser plein de problèmes... du coup, ça limite beaucoup la quantité d'image utilisables en même temps ( par rapport a la 1.6 ), non ? Parce que là j'ai pas les chiffres exacts, mais sur Exodus on arrivait bien a 900 MO de ram ( dont surement au moins les 2/3 d'images, estimation rapide ). Si on peux compter sur n'importe quel pc un minimum récent pour avoir au moins 2GO de ram software, c'est pas la même pour celle des cartes graphiques...

Je suis loin d'être expert, c'est pour cela que je me renseigne...


Merci =)

8
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 20, 2012, 01:47:11 pm »
Bonjour !

On a finalement réussi tant bien que mal a passer à la 2.0. Le moteur et les jeux tournent, j'ai du revoir certaines parties, mais ça c'est plutôt bien passé dans l'ensemble.

En revanche j'ai trouvé 2 problèmes ( je pense pouvoir fournir un code minimal si besoin )

- Spécifique ATI, apparement :
En parcourant le forum, j'ai cru comprendre qu'il n'y avait plus besoin de déclarer un sf::Context dans les threads pour charger les textures. Sur une nvidia ça fonctionne, par contre sur un pc avec une ATI, une texture chargée dans un thread, puis liée à un sprite lui même dessiné dans le main thread ne s'affiche pas. Déclarer un sf::Context dans le thread corrige le problème.

- Général
C'est peut-être "normal", mais si on associe une texture à un sprite de la façon suivante :
sf::Sprite sprite;
sprite.setTexture(sf::Texture());
 
Ensuite si on le dessine ( avec cette texture "vide" ), puis on change de texture pour une texture "valide", le sprite avec la nouvelle texture ne s'affiche pas a l'écran.

A part cela, j'aurais une petite question sur les sf::Texture. Si j'ai bien compris, elle sont chargées sur la RAM graphique. Que se passe t'il si on essaie de charger une image alors qu'il n'y a plus de RAM graphique ( a moins que ça ne puisse pas arriver ) ?

Merci,
Colin

9
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 09, 2012, 10:57:31 am »
Il "suffirait" donc de faire une fonction init/deinit pour les contextes openAL ?

Sinon pour la 2.1, il y aura des modifs niveau utilisateur par rapport à la 2.0 ? Et tu as une estimation du délai avant qu'elle soit prête ?

Merci pour ces réponses =)

10
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 09, 2012, 10:37:33 am »
Salut !

J'ai bien avancé sur le portage, sans que ce soit pour autant fini. J'ai pas trouvé la 2.0rc en recompilable ( j'ai surement mal cherché ), donc j'ai récup un snapshot du dépot. Pour l'instant j'ai modifié la lib en attendant d'avoir le temps de me pencher sur les suggestions que tu nous as fait. Ca nous embêtait un peu de contenir les objets sfml dans nos sprites, car ça nous oblige a faire des accesseurs d'accesseurs pour les données de sfml. C'est tout aussi perturbant de faire un getSprite sur un Sprite...

On essaiera de revoir le design lorsqu'on aura du temps pour ça =)

Sinon j'ai rencontré un autre problème :

En dynamic, J'ai un crash lorsque je quitte le progamme en ayant instancié un objet audio, je pense plus ou moins lié à ce bug (sur Trust ~= XP )

https://github.com/SFML/SFML/issues/30

La static corrige effectivement le problème, mais bon c'est pas l'idéal pour la dynamic. Si j'ai bien compris, ce bug ne sera pas corrigé pour la 2.0 mais la suivante ? C'est pas un peu le même genre de problème que pour l'ATI sur la 1.6 ?

Merci =)

Colin


11
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 04, 2012, 02:14:29 pm »
C'est donc bien intentionnel ^^. Du coup je vais essayer de récupérer les sources et faire cette modif' ( private => protected ), parce que j'en ai vraiment besoin ( impossible de revoir tout le design du moteur juste pour ça pour le moment ).

Je ne suis pas sur de pouvoir fournir un excellent contre exemple, ou encore d'affirmer que notre solution est valable du point de vue design. Nous héritions des classes sfml principalement pour les interfacer avec nos systèmes de load/save a partir de fichiers / flux, ainsi que pour la gestion du positionnement des objets une fois insérés dans nos "Maps" ( positionnement local par rapport a la map parente pour l'affichage, Global pour la physique et autres... ). Nous avions aussi besoin de redéfinir les draw pour appeler automatiquement une update dans ce dernier ( mise a jour des animations pour les sprites, lancement&mise a jour de scripts lua, etc...).

Par exemple, pour les Sprites, nous avons redéfini les draw pour qu'ils gèrent certains cas supplémentaires ( animations/spritesheets etc... ), mais comme on utilise directement openGL pour afficher ( ou le Renderer à l'époque ou il existait ), on n'a pas ce souci protected/private. Par contre pour les textes, ça nous arrange de ne pas refaire l'affichage, qui doit être un brin plus complexe que celui de Sprite =)

On pourrait aussi sortir l'activation / désactivation des clip planes du draw pour l’appeler avant/après chaque affichage de texte, mais c'est beaucoup plus pratique que ce soit directement intégré dans le draw ( surtout quand on a un moteur et 3 jeux qui tournent dessus à convertir )

En tout cas, merci pour les infos =)

12
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 04, 2012, 09:31:18 am »
Sur la version sfml que j'ai téléchargé ( 2.0 rc ), elle est effectivement protégée sur Drawable, mais privée sur sf::Text. Et ceci ne compile pas :

namespace cream
{
//...
void Text::draw(sf::RenderTarget& target, RenderStates states) const
{
    /*
    code
    */


    // on dessine l'objet en tant que sf::Text
    sf::Text::draw(target, states);

    /*
   code
    */

}
//...
}
 

( impossible d'accéder à private membre déclaré dans la classe 'sf::Text' )

Ce code est censé compiler ?

Par ailleurs, Je ne comprends pas bien pourquoi elle est protégée sur Drawable et privée sur Text, Shape, Sprite...

Du coup, dans les classes qui en héritent, on est censés mettre le draw en protected ou en private ?

13
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 03, 2012, 09:22:38 pm »
C'est ce que j'ai essayé de faire en premier, mais mon compilo n'aime pas trop l'appel a une fonction privée de la classe mère dans une classe fille ( en héritage public )...

Pour la fonction Render, c'est ce qu'on redéfinissait ( en tant que draw ) sur notre ancienne version de SFML. C’était peut être des modifs temporaires entre la 1.6 et la 2.0...

14
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juillet 03, 2012, 01:43:12 pm »
Le portage est en cours ( argh tous les noms ont changé ! )...

J'ai cru comprendre que la fonction draw remplace la fonction Render, mais elle est passée de protected à private, du coup impossible de l’appeler dans une classe fille ( a moins que mes connaissances en C++ ne soient un peu limitées ou que j'ai omis un détail... ).

Pour prendre un exemple, on a surchargé le draw du Text pour ajouter des appels openGL ( clip plane ) avant et après le draw, ce qui n'est plus trop possible apparement. De plus, il me semble impossible de refaire le draw du text "simplement" puisque tout est en private...

Aurais-je loupé une info ?

ps : C'est bien la classe ConvexShape qui propose les même possibilités que l'ancienne classe Shape ?

15
Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« le: Juin 29, 2012, 10:18:34 am »
Comme par hasard, on trouve toujours ce qu'on cherche après avoir posté :

http://en.sfml-dev.org/forums/index.php?topic=3438.0

On a toujours des soucis de framerate/freeze nvidia. Je suppose que ca vient de nous (moteur ou version de sfml ). On va donc essayer de passer sur la dernière 2.0

D'ailleurs il s'avère que nous n'avions pas fait de modifs internes a sfml, juste quelques const_cast pour pouvoir accéder a certains éléments. Mon ignorance me fait dire des bêtises ^^

Sinon pour le bug ATI sur la dynamic de la 1.6, effectivement il suffit de faire une fonction init et deinit et de passer les contextes réference et default en pointeurs. Je pourrais modifier les 3-4 fichiers nécessaires sur la 1.6 et les partager s'il y a encore des personnes qui rencontrent ce problème.

To be continued... =)

Pages: [1] 2 Suivante »
anything