Sujets

1

Général / GCC 4.8.1 64 bits

« le: Octobre 16, 2013, 05:10:20 am »

Bonjour à tous et à toutes

J'ai réussi (finalement) à installer correctement mingw64 avec code blocks et tout fonctionne à merveille si je me limite à la STL.

Lorsque je veux utiliser la SFML (32 bits) que j'avais compilé pour 4.8.1... On dirait que ça ne fonctionne pas (toujours des erreurs du type undefined reference to...). J'imagine donc que les libs.a doivent être recompilé en 64 bits (logique sinon je ne vois pas pourquoi on peut télécharger SFML en 32 ou 64 bits...)

Or, la version 64 bits dans les download est seulement avec GCC 4.7. J'aimerais donc savoir comment je dois faire pour compiler la lib en 64 bits.

Merci et bonne journée !

Ps. avec CMake, j'ai essayé de choisir Specify a native compilers au lieu de la détection automatique, mais quand j'entre les mingw64.....g++.exe, CMake me dit que c'est pas un compilateur valide. Pourtant, c'est bien ces exécutables qui sont dans mon toolchain dans code blocks.

2

Général / Thread plutôt lent

« le: Juillet 14, 2013, 07:50:14 pm »

Bonjour à tous et à toutes

J'ai fait un petit code simple qui démarre un thread et je mesure le temps avec un sf::Clock en attendant thread.wait();

Comment se fait-il que pour la même charge de travail (ex. une boucle qui tourne 100 millions de fois et affecte i à une variable) un thread créé prend toujours environ 3 fois plus de temps pour exécuter le même code que le thread "principal" du processus ?

L'intérêt du multithreading est totalement perdu si ces derniers ne s'exécutent pas aussi vite que le processus même... (y a-t-il un problème dans le scheduler de windows face à ça ?)

Merci et bonne journée !

3

Fenêtrage / Faire du rendu 3D pour produire des sprites

« le: Avril 08, 2013, 02:01:22 am »

Bonjour à tous et à toutes

Je fais un moteur un peu spécial qui me demande de faire du rendu 3D (pour du réalisme et des problèmes de consommation mémoire monstrueuse si c'était en image) pour ensuite afficher les modèles 3D les uns par dessus les autres comme des sprites.

On m'a donc fortement conseillé l'utilisation des FrameBuffer Object étant donné que j'utilise OpenGL 3.

En fouillant un peu dans les classes de la SFML, j'ai aperçu un RenderTexture qui permet de faire exactement ce que j'ai besoin.

Ma question est donc la suivante : est-ce que la classe renderTexture est équivalente au FBOs en performance ou suis-je mieux de faire ma propre implémentation ?

Je sais que la SFML est faite principalement pour OpenGL 2, et l'extension des FBO n'était pas prise entièrement en charge via l'extension. Je me demande donc s'il procède directement sur la carte graphique ou s'il s'agit d'une ancienne méthode moins optimisé (transfert CPU/GPU), mais qui permet de garder une compatibilité.

Merci et bonne journée

4

Général / [OpenGL] bug lorsque deux carrés superposés

« le: Novembre 19, 2012, 02:49:30 am »

Bonjour à tous et à toutes

Lorsque deux carrés sont superposés (x,y,z identique) les FPS chute rapidement. Y a-t-il une raison à cela ?

Je peux dessiner 100 000 carrés (200 000 triangles) à des endroits différents et je vais tourner à 100 FPS. Si je met aucun offset à aucun carré, là je tourne à 3 FPS...

Merci et bonne journée !

5

Général / OpenGl 3.1 Comment mieux optimiser ?

« le: Novembre 18, 2012, 04:50:46 am »

Bonjour à tous et à toutes

J'ai un modèle 3D entièrement stocké sur le buffer de la carte graphique (GL_ARRAY_BUFFER,GL_ELEMENT_ARRAY_BUFFER,GL_TEXTURE_BUFFER). J'utilise glDrawElements puisque mes triangles sont indexés.

Existe-t-il une méthode plus rapide pour dessiner quelque chose à l'écran ou ce que j'utilise est le plus rapide pour faire le rendu d'un objet ?

De plus, comment fait-t-on pour optimiser la vitesse de rendu si on veut afficher par exemple 100 fois le même objets ? La seule façon que je connaisse consiste à changer la matrice de transformation et d'appeler glDrawElements entre chaque objet, mais je crois que ce n'est pas très optimisé puisque je ferais appel 100 fois à glDrawElements alors qu'il s'agit du même objet, mais avec une matrice de transformation différente.

Merci de votre aide et bonne journée !

6

Général / Moteur 3D avec la SFML

« le: Novembre 04, 2012, 06:25:20 pm »

Bonjour à tous et à toutes

Je développe un jeu en 2D isométrique et j'arrive à un problème assez conséquent : un manque de mémoire VRAM. Je voulais faire en sorte que tous les vaisseaux spatiaux aient une image pour chaque degré afin qu'il tourne fluidement. Or, cela engendre une consommation de la mémoire très élevée.

Je me suis donc tourné vers une solution 3D afin de permettre l'affichage fluide en 2D isométrique. Je me suis dit que la façon la plus simple serait de coder un simple moteur 3D basic (affichage d'objet, gestion de la caméra, gestion des textures, gestion des shaders de base (obligatoire avec OpenGL 3.x) ainsi qu'un système de particule pour les réacteurs et effets de fumée (traînée des roquettes par exemple).

Quand je viens poser ma question sur le SdZ, tout le monde me dit que ça serait quasiment mieux d'utiliser un moteur existant parce que ce que je vais faire ça va être de la marde (enfin ils ne le disent pas comme ça bien entendu ). Je comprends très bien que je ne serai jamais capable de recoder un moteur 3D comme CryEngine, Unreal Engine, etc., mais comme je viens de le spécifier, je n'ai pas besoin de toutes les fonctionnalitées que ces moteurs offrent.

De plus, j'ai déjà créé une GUI complète et personnalisable avec la SFML. Ça serait donc beaucou pde travail que je jetterais puisque les moteurs 3D offrent normalement une GUI.

J'aimerais donc avoir ton opinion (Laurent) à ce sujet. Vaut-il mieux pour moi de recoder un petit moteur 3D ou partir sur un moteur 3D existant et abandonner la SFML ? (sans compter que mon serveur utilisent la SFML pour le transfert de données. Je serai tout de même obligé d'inclure certaines parties de la SFML...)

Merci et bonne journée !

7

Général / OpenGL 3.1 et GLSL 140 (ou 310 ?). Impossible de compiler

« le: Septembre 27, 2012, 03:39:59 am »

Bonjour à tous et à toutes

J'ai deux tutoriels pour openGL 3.1. Dans l'un, on écrit 140 pour la version de GLSL (tuto du SdZ) et dans un autre, on écrit 310 (comme pour la version 3.10).

Dans les deux cas, ça refuse de compiler. Même avec un main vide et aucune variable... Impossible de compiler le Vertex et Fragment Shader. Toujours sur la ligne 1 (#version xxx).

J'ai essayé d'envoyer l'utilisation d'openGL 3.1 à RenderWindow dans un ContextSettings, mais quand je fais getSettings, ça m'affiche toujours OpenGL 3.2. À savoir pourquoi (ma carte supporte en mode de compatibilité jusqu'à 3.3).

Que suis-je sensé faire exactement ? Est-ce que ce problème vient de moi ? d'ATI ? de Windows ? (7 64 bits)

Merci de votre aide et bonne journée !

8

Général / compatibilité SFML et GCC 4.7.0 ??

« le: Septembre 19, 2012, 02:41:51 am »

Bonjour à tous et à toutes

EDIT

Petite erreur de ma part. Je devais recompiler entièrement mon projet.

Merci et bonne journée !

9

Général / int64_t compatibilité ?

« le: Septembre 05, 2012, 11:41:25 pm »

Bonjour à tous et à toutes

Je suis passé au c++11 afin de pouvoir utiliser les entiers atomiques et j'aimerais savoir ce qu'il en est des nouveaux types telles que int64_t. La SFML déclare les entier sur 64 bits grâce à un double long. Cela signifie-t-il que je ne peux pas utiliser les int64_t avec la SFML ?

Enfin, j'aimerais savoir comment surcharger un int64_t dans un sf::Packet pour communiquer grâce à ces entiers. J'aimerais aussi savoir s'il y a une différence entre les long long de la SFML et les int64_t.

merci et bonne journée !

10

Système / Système de boîte aux lettres pour client et Mutex pour serveur

« le: Septembre 04, 2012, 03:08:22 am »

Bonjour à tous et à toutes

J'utilise massivement les Mutex sur mon application serveur afin de locker des données partagées à travers 3 threads. Pour mon application client, on m'a conseillé d'utiliser autre chose tel que Boos.Asio pour obtenir un système de boîte aux lettres entre le moteur réseau et le moteur de jeu :

Avantages de l'IOCP : plus simple car pas de synchronisation, lock, deadlock ; plus scalable car en grande partie pris en charge par le Kernel ; plus performant ; Boost.Asio a bénéficié du Design de personnes bien plus compétentes que vous et surtout que moi, etc...

Est-ce qu'on pourrait m'expliquer réellement les avantages ? De plus, pourrait-on m'expliquer comment il est possible ajouter/supprimer/lire des données se trouvant dans une même boîte aux lettres sans effectuer de lock ? Pour moi, un lock est obligatoire sur un partage de données (Mutex ou entier atomique).

Ensuite, existe-t-il une meilleure méthode de faire sur une application serveur que d'utiliser massivement les sf::Mutex ? La boîte de réception ne sert absolument à rien ici. Sinon, il y aurait les entiers atomiques. Sont-ils réellement vraiment, mais beaucoup plus efficace que les Mutex pour protéger des variables ? Sinon, une autre solution ?

merci beaucoup et bonne journée !

11

Graphique / sf::Text saut de ligne

« le: Août 31, 2012, 12:37:09 am »

Bonjour à tous et à toutes

La classe sf::Text ne semble pas posséder de méthode afin de créer un retour à la ligne automatique dès que le GlobalBounds dépasse une certaine taille.

Existe-t-il une solution à se problème ou je dois mesurer la taille de X caractères et mettre un \n quand ça excède la taille désiré ?

Merci et bonne journée

12

Graphique / Slidebar avec des convexShape et du texte

« le: Août 29, 2012, 02:02:20 am »

Bonjour à tous et à toutes

Existe-t-il une solution afin de faire des subRect pour les convexShape et les Text comme les images afin de créer un effet de défilement parfaitement fluide avec des Slidebar ?

Merci et bonne journée

ps. bien évidemment, il s'agit de composants graphiques que j'ai fait afin d'avoir une GUI comme bon me semble en parlant de slidebar.

13

Graphique / [Text et ConvexShape] Impossible de centrer le texte

« le: Août 26, 2012, 09:31:30 pm »

Bonjour à tous et à toutes

J'ai, dans mes fenêtres faites de convexShape, des objets de type sf::Text servant à afficher le titre.

Voici les opérations que je fais :

m_title.setPosition(floor(m_titleShape.getPosition().x+m_titleShape.width/2-m_title.getGlobalBounds().width/2),
                        floor(m_titleShape.getPosition().y+m_titleShape.getGlobalBounds().height/2-m_title.getGlobalBounds().height/2));
 

Ce code mets le titre à (0,0) avec la barre, le mets ensuite à (x/2,x/2), ce qui a pour effet de centrer le (0,0) du titre avec le centre de la barre et finalement, on soustrait la moitié du globalBounds en x et y pour mettre le centre du titre avec le centre de la barre.

Le problème survient lorsque je change la taille du sf::Text. Les opérations ci-haut fonctionne très bien pour une taille de de 8 à 12 pixels (le texte est pas mal centré, des fois un pixel à côté, mais lié au floor pour avoir un texte clair et non flou). Lorsque je met par exemple 20, là le texte est toujours centré sur X, mais n'est pas du tout centré sur Y. J'ai remarqué que le globalBound ne fait pas toujours la taille de la taille des caractères...

Avez-vous une solution qui fonctionne pour centrer du texte ?

merci et bonne journée !

14

Fenêtrage / [sf::Event] touche unicode

« le: Août 26, 2012, 07:05:08 pm »

Bonjour à tous et à toutes

On peut obtenir la valeur unicode (UTF-32) du caractère qui a été saisie. Existe-t-il déjà une table faisant la conversion de cette valeur vers le caractère en le retournant via un sf::String (étant donné que les sf::String peuvent contenir n'importe quel valeur unicode (UTF-8)) ?

Merci et bonne journée !

15

Graphique / [GUI] garder les fenêtres en mémoire ou pas ?

« le: Août 25, 2012, 05:51:46 pm »

Bonjour à tous et à toutes

Je suis en train de créer une interface graphique pour une utilisation personnelle et je me demande s'il est mieux de supprimer la fenêtre de la mémoire (supprimer l'objet, donc une classe dérivant d'une classe Widget) et de la recréer lorsque l'utilisateur le demande (afficher ses statistiques par exemple) ou de simplement mettre un booléen toDraw; pour savoir si je dois la dessiner ou pas ?

L'avantage de la première solution est une consommation de mémoire réduite (dessiné à l'aide des ConvexShape). Par contre, je devrai garder en mémoire toutes les variables des statistiques par exemple.

L'autre solution a l'avantage de ne pas devoir stocker deux fois la même variable, mais devra garder en mémoire toutes les fenêtres du jeu...

Qu'en pensez-vous ?