Messages

1

Discussions générales / Re : Recherche de site pour trouver des assets graphiques

« le: Janvier 08, 2014, 07:12:42 pm »

Un bon annuaire de liens : http://jeux.developpez.com/medias/

2

Général / Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions

« le: Juillet 24, 2012, 03:07:04 pm »

Ok. Si on a les avantages de la composition tout en conservant l'aisance syntaxique offert par l'héritage, c'est tout bon je trouve.

3

Général / Re : Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions

« le: Juillet 24, 2012, 02:27:02 pm »

struct T { void foo(); };
class U1 {
    T myT;
public:
    void foo() { myT.foo(); }
};

class U2 : private T {
public:
    using T::foo;
};

U1 et U2 sont strictement équivalent pour l'utilisateur.

Merci ! Je ne connaissais pas cet usage de using. Très pratique pour exposer uniquement certaines méthodes de sf::Sprite, et ainsi ne pas surcharger l'interface publique des mes classes d'entité.
Mais on parle toujours d'héritage, et non de composition 

Tu peux aussi hériter de sf::Transformable pour manipuler ton sprite à ta guise, sf::Sprite héritant lui-même de sf::Transformable.

Justement, puisque sf::Sprite hérite de sf::Transformable, je ne vois pas l'intérêt d'hériter de sf::Transformable si j'ai déjà un attribut sprite, ce serait redondant d'avoir 2 fois la matrice de transformation, et d'appliquer 2 fois les transformations (il faut bien transmettre l'info dans les sf::RenderStates au moment de dessiner le sprite).

Donc ça permet, comme le disait Laurent, de supprimer des méthodes auxquelles l'utilisateur ne doit pas avoir accès.

L'héritage privé m'a l'air la solution la plus adéquate pour ça (+ l'astuce de Hiura pour autoriser certaines méthodes uniquement), et celle qui requiert le moins de code également.

(Je n'ai pas lu toute la discussion, cette technique générale ne s'applique donc pas forcement à ton cas!)

Rien à voir avec le problème de l'OP, j'ai juste rebondi sur une citation de Laurent

4

Général / Re : Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions

« le: Juillet 24, 2012, 12:22:04 pm »

Je ne veux pas que les gens dérivent de ces classes car dans 99% des cas leur solution est incorrecte (du point de vue du design). J'essaye de les orienter vers les bons choix, qui est de les utiliser par aggrégation.

Après, on peut bien sûr discuter de chaque cas, et je me ferai un plaisir de revenir sur mes choix si quelqu'un me donne un excellent contre-exemple.

J'ai toujours eu pour habitude de faire hériter mes entitiés graphiques de sf::Sprite dans mes jeux. Je peux ainsi les dessiner directement — target.draw(entity) — et réutiliser les méthodes de sf::Sprite.

Si j'utilise l'aggrégation, je dois :
- soit mettre un getter non constant sur le sprite (crade...)
- soit recoder les méthodes nécessaires et les rediriger vers l'attribut sprite (redondance de code)

Quel intérêt aurais-je à utiliser l'aggrégation plutôt que l'héritage ?

5

Site web SFML / Re : Nouveau forum

« le: Mars 25, 2012, 04:39:09 pm »

Petit détail : il manque la favicon !

6

Site web SFML / Re : Nouveau forum

« le: Mars 25, 2012, 12:57:18 pm »

Qu'est-ce qui a motivé le choix de migrer le forum, outre le hack pour faire deux forums en/fr ?
L'ancien semblait faire très bien l'affaire, non ?

Tant que tu travailles sur le thème, mieux vaut le dire avant qu'après: Est-ce qu'il est prévu d'avoir un thème dont le cadre est de taille variable?

Je ne pense pas que le thème que j'ai choisi comme base puisse être à taille variable.
Mais personnellement, je trouve que ça devient pénible de lire du texte lorsque les lignent s'étendent trop. Ca me semble plus ergonomique comme ça.

Si c'est prévu par SMF, peut-être les utilisateurs pourraient choisir eux-mêmes un thème dans les options de leur compte ?

C'est quand même un peu abusé toutes les infos qu'on peut avoir dans les profils des gens, temps passé sur le site (même quand on est "invisible"), graphique des heures de tous les posts, ...

Et c'est pas bien ?

Ah, je comprends que ça ne plaise pas à tout le monde ! Mais bon ce ne n'est pas bien méchant.