Messages

16

Discussions générales / Re : Bon zanniversaire

« le: Mai 29, 2012, 01:43:32 pm »

Joyeux Anniversaire 


Encore merci pour ton travail

17

Général / Re : Déplacement de "Frame" trop lente par rapport à la souris.

« le: Mai 26, 2012, 01:33:16 pm »

Je pense qu'il y a toujours trop de code inutile, et le code qui pourrait nous permmetre de t'aider est encore absent.

                                sf::Vector2i oldMousePos = getEventManager()->getOldMousePosition();
                                sf::Vector2i mousePos = getEventManager()->getMousePosition();
                                move(mousePos.x - oldMousePos.x, mousePos.y - oldMousePos.y);

Dans Frame::Update, tu appelles les méthodes getEventManager et move. Elle ne sont pas déclarer dans le header de la classe Frame. Et tu n'a pas mis le .cpp

Met juste la fonction où tu captures les événement SFML et là où la fenêtre est déplacée.

ps:: Je n'ai pas la possibilité de mettre des balises de code 

18

Général / Re : Déplacement de "Frame" trop lente par rapport à la souris.

« le: Mai 25, 2012, 11:37:50 pm »

je ne vous met que les fonctions appelé pour faire ce déplacement

Non, tu as mis les classes utiliser pour faire le déplacement. Malheureusement, cela représente énormément de code. Personne ne vas le lire, bien que ton code est bien mis en forme.

Met juste la fonction où tu captures les événement SFML et là où la fenêtre est déplacée.

19

Graphique / Re : Position d'un sprite

« le: Mai 25, 2012, 11:27:36 pm »

Peut-tu mettre le code complet de ton bouton(.h et .cpp)

20

Graphique / Re : Shape::getTexture() return NULL

« le: Mai 25, 2012, 11:22:47 pm »

En passant par un RenderTexture. Plus de renseignement sur la documentation 

21

Graphique / Re : VertexArray et RenderTexture ???

« le: Mai 24, 2012, 08:41:50 pm »

Je voulais faire une fonction qui remplie un VectexArray depuis une Texture. Je pensais parcourir le tableau de pixel pour remplir le VectexArray 

Mais vu que le VectexArray est stocké au niveau de la mémoire centrale, et la Texture sur la carte vidéo, ce n'est pas possible. Je pense qu'il faut passé par l’intermédiaire d'une image.

Bien sur, il n'a pas de réel intérêt, c'était juste pour effectuer des tests.

22

Graphique / Re : VertexArray et RenderTexture ???

« le: Mai 24, 2012, 08:19:35 pm »

VertexArray a une approche géométrique, tu as une bouillie de points.
RenderTexture a une approche par image, tu as une bouillie de pixels.
Je te laisse tirer les conclusions que tu trouveras de ces deux points

Juste parfait l'explication 

Mémoire centrale, et transféré sur le GPU au moment du dessin (mais pas de manière permanente).

Donc je perds mon temps à vouloir afficher une texture avec VertexArray, faut je passe par une image.

23

Graphique / Re : VertexArray et RenderTexture ???

« le: Mai 24, 2012, 06:15:19 pm »

Ce sont deux utilisations très différentes.

Justement, je ne vois pas différence pour l'utilisation. La seule différence que je remarque avec RenderTexture est la création de l'objet et la manière de la dessiner. RenderTexture nécessite un autre objet(Sprite...).

VertexArray permet d'aggréger une géometrie perso en une seule entité dessinable. Ca fait gagner considérablement en performances, par rapport au cas d'utilisation typique où on dessine X * Y sprites, car il n'y a qu'un seul appel OpenGL pour tout dessiner.

Comme pour un RenderTexture. Je vois quand même une utilisation avantageuse pour les dessins vectoriels.

Par exemple, si j'ai un personnage découper dans une texture, je peux le reconstituer dans un VertexArray depuis une texture(ou image).

VertexArray permet d'aggréger une géométrie perso en une seule entité dessinable.

Je pense que je vais attendre les tutoriels. J'ai fais plusieurs test et c'est plutôt amusant mais je ne vois pas comment dessiner une texture par exemple. Un indice...ou j'irai voir la classe Sprite.

RenderTexture permet de faire du dessin sur quelque chose de réutilisable ultérieurement, c'est donc utilisé par exemple pour faire des post-effects, ou bien pour précalculer des images statiques composées.

Pré-calculer des images statistiques n'est pas l'utilisation énoncé plus haut dans ton message. Si ce n'est pas le cas, c'est à ce niveau que se porte ma confusion.


Où est charger le VertexArray, mémoire ou carte vidéo???

24

Graphique / VertexArray et RenderTexture ???

« le: Mai 24, 2012, 02:43:26 pm »

Bonjour,

j’entends souvent que les VertexArray permettent de meilleurs performances, mais surtout de mieux concevoir sont application.

Un VertexArray n'est jamais qu'un tableau de point. Ces points peuvent en fonction de la primitive représentaient un pixel.

RenderTexture est un tableau de pixel. On peut dessiner dessus notre Background où tous autres éléments composées de plusieurs texture fixe. De plus cette classe héritant de Render a des méthodes pour l'utiliser simplement.

Ma question est qu'elle est l’intérêt de VertexArray???
A quoi sert la primitive???
(Je sais que c'est pas bien, je n'ai pas encore effectuer avant de poser cette question mais je suis vraiment dans le floue)

25

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

« le: Mai 17, 2012, 01:22:28 pm »

Comment est réglé le problème de l'overship???

La bonne solution(selon mon expertise) serait un attribut booléen ou 2 classe pour savoir si à l'élimination d'un élément on détruit le drawable ou pas 

26

Suggestions de nouvelles fonctionnalités / Re : sf::Image et constructeur par déplacement

« le: Mai 17, 2012, 01:19:06 pm »

Peux-tu expliquer au néophyte que je suis l’avantage que cela apporte???

Code: [Sélectionner]

sf::Image& sf::Image::operator=(sf::Image&& rhs)
Une référence d'une référence....Es-ce une nouvelle utilisation de l'opérateur = en C++11???
Sinon, peut-être rajouter un const si il s'agit bien de la copie d'un objet.

27

Graphique / Re : Position d'un sprite

« le: Mai 16, 2012, 07:48:38 pm »

On pourrait avoir des images...Je comprend mal le probléme

28

Suggestions de nouvelles fonctionnalités / Re : Déshériter Sprite et ses soeurs de Transformable

« le: Mai 12, 2012, 08:57:29 am »

En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience .

Citer

    Ca risque d'être lourd en mémoire, non ?

Bof, non. On n'est pas en train de parler de 1 000 000 d'entités à afficher sur un système embarqué avec 32 Mo de mémoire.

Ma fois, je ne saurais te répondre ici, ne connaissant que Box2D de nom et pas DebugDraw. Peux-tu préciser vite-fait ?

DebugDraw est une classe abstraite qui permet d'implémenter diverse fonction dessin comme un rectangle, une ligne, un cercle...

Le but étant de donner un objet de type Debug Draw à notre monde pour qui se dessine automatiquement dans une logique de debug. Généralement je rend mes objets graphiques transparents et je peux observer en dessous le monde physique.

j'ai ma propre classe Shape et mes propres Rectangle, Circle, etc.

(mes propos) Laurent souhaite que nous évoluons ainsi. Mais je suis incapable de faire de même 
Vivement les tutoriels qui vont bien 

Et au final, le bonheur de tout le monde. Le conservatisme est un frein à l'évolution. Le mieux aurait été de séparer dès le départ, pour éviter aux utilisateurs d'avoir à adapter leurs codes, car ils auraient bien démarré dès le début

Dés le départ??? Lors de la création de SFML1??? L'idée n'était pas encore envisagé. Actuellement tu peux coder à l'ancienne ou à la nouvelle méthode. Peut-être une fois la nouvelle méthode adapté dans plus de projet...

(Mon point de vue) Normalement tu ne fais pas hériter player de Drawable, mais GraphicPlayer qui sera un attribut de Player.

29

Suggestions de nouvelles fonctionnalités / Re : Re : Déshériter Sprite et ses soeurs de Transformable

« le: Mai 08, 2012, 03:26:57 pm »

Pourquoi le fait d'avoir plus d'attribut que nécessaire te rebut???

Qui peut le plus, peut le moins 

Puis si on fait ce que tu demande, mon système d'affichage de bounding boxes de Box2D s'appuyant sur DebugDraw ne fonctionne plus. Et là je vais devoir bricoler(rien de méchant, mais évitable).

Là on est vraiment dans la problématique :

Le malheur des uns, fait le bonheur des autres

De toute manière avec l'approche de la sortie de SFML2, ce genre de changement n'est pas envisageable(ce propos n'engage que moi).

30

Discussions générales / Re : SFML 2.0 RC

« le: Avril 19, 2012, 11:24:07 pm »

La première chose à faire est de choisir quel type de projet créer. Code::Blocks propose une grande variété de types de projets, dont l'un est "SFML project". Ne l'utilisez pas !

C'est bien de le préciser. J'en ai passé du temps et je n'ai jamais réussi à le configurer correctement

Même si cela ne fonctionne pas correctement(dans le cas du contraire, je suis preneur), cela montre une reconnaissance de SFML.

Ce tutoriel me semble plus complet que des tutoriels dédié à l'utilisation de Code::Block 

Citer

    Choisissez plutôt un projet vide (Empty project). Si vous voulez une application graphique sans console, dans les propriétés du projet onglet "Build targets", choisissez "GUI application" dans la liste déroulante au lieu de "Console application".


J'ai du relire deux fois ce passage pour le comprendre, je ne sais pas si c'est l'enchaînement de termes anglais ou le fait qu'il soit 23h15 

Après avoir créé un projet de type "Empty". Dans le menu(tous en haut)
Project=>Propertie=>Build Target
Dans la combo box "Type", tu mets la valeur "Gui Application"

Comme cela, au lancement de l'application la console ne se lancera pas. Par contre il est vrai que plus de précision sur cette manipulation ne serait pas trop