Sujets

1

Général / Encodage des fichiers du code sur github

« le: Mai 06, 2013, 04:09:10 pm »

Bonjour,

Je voudrais savoir quel est l'encodage utilisé par les fichiers de code source situés sur github, car en modifiant une ligne dans un fichier de mon fork, il détecte que la totalité des lignes du fichier ont été remplacées... ce qui est un peu problématique

2

Audio / Trop de threads tue le thread.

« le: Avril 19, 2013, 02:32:02 am »

Quand le module Audio est initialisé, il crée au moins 10 threads o_O !
Y-a-t-il une raison à cela ?

Dans le code je n'ai pas vu de launch en dehors des endroits où la musique est jouée (c'est d'ailleurs bien piquant le stop+launch dans le setPlayingOffset x) ).

D'autant que sur les 10 threads, 2 d'entre eux se suppriment et se relancent en permanence... ce qui n'est pas pour arranger les choses.

Est-ce OpenAL qui crée tous ces threads ?

3

Suggestions de nouvelles fonctionnalités / sf::Packet proposer une 2e interface non modifiante

« le: Août 27, 2012, 12:42:36 pm »

Actuellement, lorsqu'on souhaite extraire une donnée de sf::Packet, il n'est plus possible de lire cette donnée déjà extraite. La seule façon de le faire est d'utiliser getData et de faire quelques casts horribles qui ne devraient pas avoir lieu d'être puisqu'il faut pour cela connaître la construction interne de sf::Packet pour s'assurer de son fonctionnement. Si je veux récupérer le premier char :

char data = *reinterpret_cast<const char*>(packet.getData());

C'est juste moche .

Je propose d'ajouter une fonction template :

template <class T>
void Packet::get(T &data)
{
    *this >> data;
      m_readPos -= sizeof(data);
}

 

Ou alors mieux : proposer des fonctions pour sauvegarder une position dans un sf::Packet pour l'y faire revenir plus tard (en clair on sauvegarde m_readPos). Ainsi que les positions statiques définies à l'avance : begin et end.

La 1e solution n'est qu'une solution vite fait, tandis que la 2e s'inscrit plus dans la logique des flux (voir std::fstream et compagnie).

4

Suggestions de nouvelles fonctionnalités / utilisation de C++11 pour la classe Group sur le wiki

« le: Mai 17, 2012, 12:12:36 pm »

Bonjour, je lis sur le wiki https://github.com/SFML/SFML/wiki/TutorialDrawableGroup une suggestion fort intéressante de classe Group, et sa raison principale de ne pas figurer dans la SFML :
The SFML doesn't implement a Group class for ownership reasons: should the Group destroy its elements when it is destroyed?
L'utilisation de std::shared_ptr (c++11) dans cette page wiki, ou du moins sa suggestion, pourrait être fort utile pour régler cette question...

#include <SFML/Graphics.hpp>
#include <memory>

class Group : public sf::Drawable, public std::vector<std::shared_ptr<sf::Drawable>> {
    public:
        Group();
        ~Group();

        void render(sf::RenderTarget&) const;
};

#include "group.hpp"

Group::Group() :
    sf::Drawable(),
    std::vector<std::shared_ptr<sf::Drawable>>() {
}
Group::~Group() {
//nada rien, ça marche tout seul.
}

//This is what ables you to do Group.Draw() to draw all the Drawable inside of a Group, and to apply common settings such as position, color, ... to its elements.
void Group::render(sf::RenderTarget& Tar) const {
    for(std::vector<std::shared_ptr<sf::Drawable>>::iterator i = begin(); i != end(); ++i) {
        Tar.draw(*i);
    }
}