Messages

31

Général / Re : Fonction d'affichage de texture

« le: Novembre 09, 2016, 02:43:59 am »

La signature de ta fonction

sfSprite* Charger_images(char* _sNom)

montre qu'elle renvoie un pointeur vers un sfSprite, c'est à dire l'adresse d'un sfSprite

Dans ta fonction tu crées un pointeur vers un sfSprite, tu lui appliques une texture et tu renvoies ce pointeur, c'est-à-dire une adresse vers un sfSprite. Ta fonction renvoie bien un sfSprite* (l'adresse d'un sfSprite).

Après je ne connais pas le binding CSFML, donc je sais pas s'il faut que tu fasses une allocation mémoire avec malloc pour renvoyer une adresse qui n'a pas été désallouée à la fin de ta fonction (et qui peut donc contenir n'importe quoi et faire planter ton programme), ou si c'est la fonction sfSprite_create() qui s'en charge.

32

Général / Re : Besoin d'aide pour un jeu

« le: Novembre 09, 2016, 02:22:45 am »

La structure squelettique d'un jeu vidéo, tu te lances dans tout un sujet
Des mots clefs pour tes recherches sont : states manager.
Chaque "moment" du jeu (intro, menu principale, gameplay, menu pause, etc.) peut être un "état", et ces état s'empilent les uns sur les autres. L'état tout en haut de la pile est l'état actif.
Par exemple tu es dans le jeu, tu appuies sur échap, ça ajoute l'état "menu pause" par dessus l'état "gameplay", ce qui fait que la boucle principale de ton programme maintenant s'occupe uniquement du menu pause, le jeu lui-même n'est plus calculé, il est en pause.

Pour les "freeze" de ton personnage : utilises-tu bien le temps comme mesure pour les déplacements de ton personnages, ou bien les tours de boucle? C'est à dire, par exemple quand tu laisses la touche pour aller vers la gauche enfoncée, se déplace-t-il de x pixels par secondes ou bien de x pixel par tour de boucle (ou frame) ? Si c'est le deuxième cas, sa vitesse de déplacement sera différente selon la puissance de la machine, et sera saccadé à chaque baisse de fps.
Autrement, tu peux régler le maximum de frame par seconde directement avec une fonction de la RenderWindow de la SFML (60 fps est une valeur suffisante), ou choisir la synchronisation verticale (le fps est synchronisé au taux de rafraîchissement de ton écran). Consulte la doc de sf::Window ou sf::RenderWindow.

33

Graphique / Re : Carré blanc et changement d'adresse?

« le: Novembre 09, 2016, 02:16:16 am »

Hum.. je suis pas sûr de comprendre.

Tu as une classe qui possède un membre sf::Texture ?

Dans ce cas dans le constructeur tu peux charger la texture. Et l'adresse de ce membre n'est pas censée changer. Vérifie que tu ne la passe pas à tes fonctions par copie. Passe un pointeur ou une référence.

Le mieux bien sûr, si tu peux avoir plusieurs objets de la même classe qui utilise la même texture, c'est que le membre soit un pointeur sur sf::Texture*. Comme ça la texture n'est chargée qu'une seule fois.

34

Réseau / Re : TcpSocket::send, arrivée garantie ?

« le: Mai 08, 2016, 09:20:32 pm »

Je te remercie beaucoup pour ta réponse très détaillée.

Lorsque je parlais de paquet arrivé au destinataire, je voulais dire arrivé jusqu'à sa machine, pas forcément déjà lu avec la fonction receive.

Je lis que le protocole TCP garanti la réception et l'ordre des paquets, mais disons que je ne sais pas à quel point je dois lui faire confiance. Je ne sais pas à quel point il est intriqué avec les fonctions de la SFML, et si un statut 'Done' lors de l'envoi signifie que TCP a reçu son accusé de réception. J'imagine que ça veut dire seulement que la fonction s'est bien déroulée en ce qui concerne l'envoi. Le code source pourrait peut-être m'en dire plus, mais j'imagine qu'il faudrait que j'aille voir jusque dans les sources des API de sockets utilisées par SFML.

35

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 ?

36

Graphique / Re : Aligner des textes

« le: Février 15, 2016, 07:07:49 pm »

Merci Laurent, tu m'as sauvé de justesse d'une dépression nerveuse là.

37

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.

38

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!

39

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;
 

40

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.

41

Graphique / Re : Performances draw(sf::VertexArray)

« le: Décembre 23, 2015, 05:23:43 pm »

Oui tout à fait, je ne fais que m'exercer pour le moment. Effectivement vu comme ça il est plus raisonnable d'utiliser un quad. J'avais pas percuté le concept de transformation appliqué à chaque élément du tableau.

42

Graphique / Re : Performances draw(sf::VertexArray)

« le: Décembre 23, 2015, 01:37:30 am »

Ah bah oui, tout à fait! Ma fenêtre et ma map sont en 800x600. Le 2ème array ne contient que la baraque, donc le 1er qui affiche le reste est chargé de pas mal de points oui. Bon, même 800x600 ça fait pas des millions. Je me disais que peut-être un quad texturé coutait autant que son équivalent en points.

La bonne stratégie serait donc d'utiliser un autre type de primitive, c'est ça ?

43

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 :