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.


Sujets - janf

Pages: [1]
1
Graphique / Question généraliste de compréhension sur les VertexArray
« le: Septembre 05, 2017, 07:52:42 pm »
Bonjour !

A force d'utiliser la SFML (bien que cela fasse maintenant un moment que je n'ai pas trop touché au C++), j'ai fini par comprendre certaines choses sur son fonctionnement, notamment le fait qu'une des clefs de la performance se trouve dans la limitation des appels à la fonction draw().

Ainsi j'ai compris le tuto qui explique comment créer un niveau sous forme de tilemap en utilisant un sf::VertexArray plutôt qu'un sf::Sprite par tile.

Maintenant, j'aimerais savoir si je dois rechercher toujours au maximum le passage par les VertexArray ? Exemple : prenons le cas farfelu où je voudrais me lancer dans la création d'une bibliothèque d'UI basée sur SFML, une collection de "widgets" tels des boutons et zones de textes éditables ou non, des "fenêtres" affichées à l'intérieur de la RenderWindow, avec du drag & drop à la souris.

Est-ce qu'il est réaliste de vouloir "assembler" tout ça, ou une grande partie de tout ça, en un VertexArray, en sachant que certains éléments peuvent bouger ?

Dans un autre cas, qui pourrait être inclus dans ce premier exemple, celui où je voudrais faire des boîtes de textes dont les retours à la ligne s'adaptent au redimensionnement de la taille de la boîte. Est-ce que là, je devrais créer ma propre classe plutôt que de passer par sf::Text, et ainsi finir avec un VertexArray ?

Est-ce que tout ça est mélangeable ? Est-ce que je peux avoir des éléments qui bougent, qui font des rotations, mais sont au final toujours inclus dans un VertexArray général qui gère l'affichage ?

Finalement la réponse peut simplement se résumer à "oui ou non". Comme il reste un flou dans ma compréhension, je voudrais seulement savoir si ma recherche est orientée dors et déjà vers une impasse, ou une solution over-compliquée, ou bien si c'est raisonnable.

Je vous remercie pour votre lecture !

Ren.

2
Général / [Résolu] Compilation sous Linux
« le: Février 16, 2017, 02:33:05 pm »
Bonjour !

Ça fait un bon moment que je suis passé au monde Linux, que j'apprécie beaucoup. Je commence à parler shell plus ou moins couramment, enfin, je me débrouille disons.

Mais je suis resté en dual boot sous Windows notamment car j'ai des soucis pour compiler / faire tourner mes programmes construits avec la SFML.

Après des heures de lectures afin de tenter de comprendre globalement comment tout cela fonctionne, je me tourne vers vous car vous allez voir, je crois que je ne suis pas loin de toucher au but. Il doit manquer un petit détail ou deux pour tout faire fonctionner correctement.

Je suis sous Mint (base Ubuntu donc). J'ai compilé GCC 5.4.0 et l'ai installé de façon globale (remplaçant donc GCC-4.8, je n'ai pas utilisé le système d'update-alternatives, j'ai complètement remplacé gcc-4.8 ).

J'ai compilé la SFML avec ce même compilateur. Et l'ai installé de manière globale sur le système.

J'ai configuré Code::Blocks et il compile les programmes SFML sans problème. L'auto-completion concernant la SFML fonctionne très bien également.

Par contre il ne lance pas les programmes SFML. Par exemple pour un programme de test tout simple il renvoie une erreur : "free(): invalid pointer".

Par contre j'ai exporté de manière globale les variables LD_LIBRARY_PATH et LD_RUN_PATH contenant le chemin vers /usr/local/include/SFML.
Ce qui me permet de lancer les programmes SFML en ligne de commande sans problème.
Alors que pour rappel, ils sont compilés avec C::B et je n'arrive pas à les compiler en ligne de commande (en ajoutant à tâtons -L /chemin/de/SFML).

Donc voilà, j'aimerais savoir ce que je dois faire :
- pour que CodeBlocks lance les programmes SFML
- optionnellement pouvoir compiler les programmes SFML en ligne de commande.

Si cela est possible, j'aimerais une solution globale, qui n'implique pas de rajouter des options sur la ligne de commande. Mais peut-être n'est-ce pas possible.

Je vous remercie pour votre lecture.

3
Réseau / Résolution du problème d'endianness
« le: Février 03, 2017, 12:59:16 pm »
Bonjour !

Je viens poser une question d'ordre totalement général pour combler mes lacunes. J'aurais pu le faire sur un autre forum éventuellement, mais comme j'ai été introduis à ce problème par le tuto sfml sur les socket et les sf::Packet et que j'utilise la SFML, je me permets de poster ici.

Dans le tuto sur l'envoie de sf::Packet il est dit que pour éviter les problèmes de différence d'endianness entre les machines, plutôt que d'utiliser les types numériques pré-inclus dans le C++ (int, long...) il valait mieux utiliser les types de la SFML tels que sf::Int8, sf::Uint16 etc. Mais il est dit dans la documentation que c'est types ne sont ni plus ni moins que des alias pour les types du C++. Comme le sont les types uint8_t etc. du header cstdint.h.

Du coup je me demandais par quel procédé le fait d'utiliser des alias réglait le problème d'endianness lors de la communication sur le réseau ?

J'espère vraiment que ma question a sa place ici et qu'elle trouvera quelque passionné de l'informatique bas niveau pour me répondre.

4
Réseau / TcpSocket::send, arrivée garantie ?
« le: Avril 28, 2016, 12:25:18 am »
Bonjour, j'ai une toute petite question sur le réseau.

Sur un sf::TcpSocket, quand la fonction send (surchargée avec sf::Packet) renvoi le statut "Done", cela veut dire que le paquet a bien été envoyé, mais ça ne garantie pas qu'il soit bien arrivé au destinataire, si ?


5
Graphique / [résolu] Aligner des textes
« le: Février 15, 2016, 05:05:17 pm »
Bonjour.

Je vous assure que c'est après maintes recherches que je me tourne vers vous, frustré de ne pas réussir à aligner des sf::Text entre eux. Le sujet a déjà été traité ici, mais malgré la lecture de topics même résolus je n'arrive pas à mes fins.

Je n'arrive peut-être pas bien à comprendre comment sont construits les rectangles englobants des sf::Text.

J'aimerais en fait connaître le calcul qui permet de trouver la ligne de base du texte. Parfois j'arrive à aligner deux textes, mais si dans l'un d'eux je rajoute une lettre qui descend plus bas que les autres, comme 'y' par exemple, le texte se décale. Donc mes calculs sont faux. J'ai essayé en tenant compte des bounds et des lineSpacing, et en mixant les deux, mais je n'y arrive pas.

Voilà donc je serais super content qu'on m'oriente vers la solution, svp.

6
Discussions générales / Saccades et f.lux
« le: Janvier 24, 2016, 05:44:13 am »
Bonjour,

Comme quelques personnes j'ai eu un petit problème de saccade. J'en ai trouvé l'origine : l'utilisation de f.lux, un petit programme qui modifie la température de couleur du moniteur histoire de moins fatiguer le système oculaire et nerveux.

Que ce programme pompe des performances, c'est tout à fait logique et normal. Quand je ferme le programme, je n'ai plus de problème de saccades. Ce que je trouve bizarre, c'est que quand le programme est lancé, j'ai une saccade extrêmement régulière : le jeu sous SFML tourne très bien, sauf que une frame toute les 2 seconde tombe sous la barre des 30fps (les autres sont largement au-dessus). Je ne remarque pas cette saccade régulière ailleurs, lorsque f.lux est lancé. Autant il fait ramer certains jeux qui nécessitent beaucoup de ressources, mais il ne saccade pas avec une régularité d'horloge les applications. Il produit exactement le même comportement quand il est lancé mais désactivé.

Voilà, je poste ça pour reporter le problème, bien que ce ne soit pas vraiment utile, mais surtout par curiosité, si quelqu'un a une idée de ce qui peut causer une saccade si régulière ???

Sinon, autre petite question : quand j'active la vsync je plafonne à 32fps. J'ai l'impression que c'est nouveau, depuis que j'ai mis mon driver à jour, mais pas sûr. Ça ne me gêne pas, je n'ai qu'à la désactiver, mais savez-vous si je peux agir là-dessus, avec un réglage par exemple ? Mon driver est donc à jour. J'utilise une GeForce 840M sous Windows 8.1.

Merci de votre lecture!

7
Discussions générales / Socket non bloquante pas de timeout
« le: Janvier 21, 2016, 09:21:48 pm »
Salut

En regardant le code de la fonction connect() de la classe TcpSocket, j'ai cru comprendre que si la socket est au départ en mode non-bloquant, passer un timeout à la fonction n'a aucun effet.

J'imagine que c'est tout à fait voulu mais perso j'aurais trouvé plutôt logique que si on précise un timeout, on s'attend à ce que la socket aille jusqu'au bout de ce timeout pour tenter de se connecter, même si elle est non-bloquante. M'enfin je vois bien aussi la logique inverse, on peut écrire des fonctions avec timeout et vouloir les outrepasser en mettant la socket en non-bloquante. Au final en fait je trouve que ça gagnerait en clarté de bien préciser ce comportement dans la doc. Mea culpa si ça l'est et que je suis passé à côté.

TcpSocket.cpp, l.160
// If we were in non-blocking mode, return immediately
        if (!blocking)
            return status;
 

8
Suggestions de nouvelles fonctionnalités / Packet::clear() virtual ?
« le: Janvier 18, 2016, 02:29:07 am »
Salut

Je me demandais, étant donné qu'il est pratique et encouragé de dériver de sf::Packet pour personnaliser nos échanges de données, est-ce qu'il ne serait pas judicieux de rendre virtuelle la fonction clear ?

C'est juste une question hein, peut-être y a -t-il des raisons de conception qui font que ce ne serait pas judicieux, au quel cas je suis curieux. Pour le moment je l'ai caché avec ma fonction dérivée, mais il parait que ce n'est pas très moral comme façon de faire.

9
Graphique / Performances draw(sf::VertexArray)
« le: Décembre 22, 2015, 06:52:17 pm »
Bonjour,

Je sais que le sujet des performances a déjà été abordé ici. La solution, pour dessiner des choses à l'écran sans trop perdre en images par seconde, c'est d'utiliser un nombre minimum de sf::VertexArray plutôt que d'afficher plein de sprites. Je cite : "les performances sont directement proportionnelles au nombre d'appels à draw..." J'avais déjà pu tester que d'afficher un sprite par tile dans une tilemap réduisait drastiquement les performances.

Aujourd'hui j'ai fais un petit test en affichant une image en deux tableaux de vertices. Elle représente le terrain, ou la map, c'est un simple dessin sous paint. Le premier tableau représente le sol, le deuxième ce qui pourra être affiché par-dessus le personnage. Entre les deux je dessine le sprite, donc.
Je voudrais savoir s'il est normal que chaque appel à draw pour un VertexArray divise mon fps par environ deux ?
Pour le coup j'ai fait un autre test en rajoutant une dizaine de sprites et ça a moins d'impact que l'ajout d'un seul VertexArray.

Loin de moi l'envie de dénigrer la SFML, c'est une bibliothèque que j'aime beaucoup, mais je voudrais savoir, n'étant pas du tout professionnel ni très expérimenté, si ce comportement est comparable avec celui des technologies utilisées dans les jeux 2d commerciaux, si les développeurs professionnels doivent composer avec les mêmes contraintes ? Outch la phrase à rallonge. Donc voilà, j'ai mis des petites images pour étayer mes propos et vous montrer mes talents de dessinateur Mspaint approved.

Merci d'avance à ceux qui pourront me répondre.

Voici mes tests (j'utilise une carte graphique récente avec accélération 3d) :


Ici je dessine tout. J'ai un FPS de 108ms.


J'enlève un VertexArray


J'enlève les deux.

Voici ce que contiennent les VertexArray, et comment je les rempli, au cas où ça puisse avoir un impact sur les perfs :






Pages: [1]