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.


Messages - Lasconik

Pages: [1]
1
Graphique / Re : Vertex
« le: Juin 20, 2013, 11:53:38 pm »
Citer
nicox11, ton utilisation de VertexArray est bonne.

Lui dit pas ça. Avec cette méthode il n'affiche qu'un quad. 
Il veut faire un afficheur de niveaux, ce n'est clairement pas l'objectif. il faut à absolument qu'il passe par quelque chose du type pointeur (suivant les coordonnées par exemple). Il va quand même pas faire
m_vertices[8].position = ...
m_vertices[44].position = ...
m_vertices [480].position = ...

2
Fenêtrage / Re : Ma fenêtre ne s'ouvre pas chez tout le monde
« le: Juin 20, 2013, 06:39:04 pm »
Peut-être un soucis de résolution ? Windows n'aime pas les fenêtres plus grandes que le bureau.

3
Graphique / Re : Vertex
« le: Juin 20, 2013, 06:36:47 pm »
Citer
m_vertices.setPrimitiveType(sf::Quads);
    m_vertices.resize(4);

    m_vertices[0].position = sf::Vector2f(0, 0);
    m_vertices[1].position = sf::Vector2f(32, 0);
...

C'est quoi m_vertices ? vu que tu appelles setPrimitiveType, c'est probablement un sf::VertexArray.
du coup tu dis ensuite que m_vertices est un ensemble de 4 quads.
ainsi avec
m_vertices[0].position = x;
tu dis que la position du premier point du quad est x.

Ce n'est pas comme ça que ça marche : pour chaque quad, il faut définir les 4 coordonnées.

tu devrais changer les positions depuis un
Vertex * v = &(m_vertices[n]*4)

Relis bien le tuto sur les VertexArray, il me semble qu'il y a un exemple tout fait sur justement les tilemaps.

4
Graphique / Re : Connaitre la couleur d'un pixel?
« le: Juin 20, 2013, 06:31:17 pm »
Peut-être par exemple si on a une image avec plein de couleurs, pouvant éventuellement varier vite, et que
-si l'utilisateur clique sur du rouge, faire quelque chose
-si on clique sur du bleu, faire autre chose....

En tous cas, la méthode getPixel(x, y) de sf::Image permet de faire ça. Après tu n'as pas forcément une sf::Image.
Si tu as une sf::Texture, il y a directement la méthode copyToImage().
Si tu veux prendre directement depuis la RenderWindow :
texture.update(RenderWindow);
sf::Image i = copyToImage();
sf::Color px = i.getPixel(666, 42);

5
Graphique / Re : Faires revenir les fonctions setX et setY !!
« le: Juin 20, 2013, 06:24:40 pm »
Comme tu l'as détaillé, tu connais la méthode. Pourquoi ne pas faire une fonction type statique :

Citer
void setX(const Transformable& cible, const unsigned short& valeur){
cible.setPosition( valeur, cible.getPosition().y );
}

Avec éventuellement un remplacement de "cible" par un pointeur. Ça marche pas ?

Citer
dès qu'on veut changer que le X ou Y c'est assez relou, en plus de rendre le code moins lisible.
A partir du moment ou tu dois réécrire très souvent quelque chose de "relou", c'est qu'il y a un problème. Il faut toujours réutiliser au maximum le code, les fonctions sont justement là pour ça.

6
Général / Problème makefile et linkage SFML
« le: Juin 17, 2013, 07:09:18 pm »
Bonjour,
mon "problème" n'est pas en rapport direct avec SFML mais j'espère que vous pourrez m'aider quand même !  ;D

Voici mon makefile, je signale au passage que tout ce qui concerne SFML est dans le répertoire $HOME/.SFML-2.0
Citer
PROGRAM=app
SOURCES=$(wildcard *.cpp)
OBJECTS=$(patsubst %.cpp,%.o,$(SOURCES))
LIBREP=$(HOME)/.SFML-2.0
CC=g++
CPPFLAGS=
CFLAGS=-Wall
IFLAGS= -I$(LIBREP)/include
LDFLAGS=-L$(LIBREP)/lib -lsfml-graphics -lsfml-window -lsfml-system

all: show $(PROGRAM)

show:
   @echo "librep : "$(LIBREP);
   @echo "include : "$(IFLAGS);
   @echo "ld : "$(LDFLAGS);
   @echo "sources : "$(SOURCES);
   @echo "objects : "$(OBJECTS);

$(PROGRAM):$(OBJECTS)
   $(CC) $(CFLAGS) $(OBJECTS) -o $@ $(LDFLAGS)

%.o:%.d
   $(CC) $(CFLAGS) -c $< $(IFLAGS) $(LDFLAGS)

%.d:%.cpp
   $(CC) $(CFLAGS) -MM $< $(IFLAGS)

clean:
   rm -f $(PROGRAM) $(OBJECTS) *.d *~

et l'output donne :
Citer
g++    -c -o app.o app.cpp
In file included from app.hpp:4:0,
                 from app.cpp:1:
Resources.hpp:7:29: erreur fatale: SFML/Graphics.hpp : Aucun fichier ou dossier de ce type
compilation terminée.
make: *** [app.o] Erreur 1

Je songe donc à un problème de linkage. En remplaçant "%.o:%.d" par "%.o:%.cpp", tout fonctionne (les répertoires étant bien spécifiés), mais du coup je perds tous les bénéfices du makefile, à savoir la bonne gestion des dépendances. Je dois tout recompiler à chaque fois ce qui n'est pas top.

Le soucis se situe selon moi soit au calcul du .d, soit au passage du .d au .o (la suppression ou l'ajout des IFLAGS ou LDFLAGS ne change rien).
J'avoue ne pas être très familier avec l'option -MM, aussi si quelqu'un pourrait m'éclairer je lui serais reconnaissant.

7
Général / Re : De SFML 2.0RC à SFML 2.0
« le: Juin 15, 2013, 06:05:04 pm »
tu copies uniquement les dll de SFML ou toutes celles nécessaires ?
Là il semblerait qu'il ne trouve pas la dll de libstdc++, ou alors elle est invalide.

8
Graphique / Re : Performances draw
« le: Juin 13, 2013, 12:13:00 pm »
Citer
D'ailleurs le second passage que tu cites fais plutôt référence au vertex array qu'au pré-rendu dans une grosse texture, si je ne m'abuse.

Tout à fait. Je vais donc me pencher vers ça. Merci d'une réponse si rapide !
Mais juste par curiosité, qu'est-ce qui aurait été le plus performant : plein de petits draw, ou 1 seul gros ?

9
Graphique / [Résolu] Performances draw
« le: Juin 12, 2013, 03:43:38 pm »
Bonjour,
j'avais déjà utilisé la sfml 1.6 auparavant, mais avec la nouvelle version et l'apparition des Textures, je me pose des questions !

Je cherche à un faire un truc plutôt simple : dessiner une map selon un tableau d'entiers. Ces entiers sont des indices disant où chercher la tile dans le tileset.
Il y a deux façons de faire assez différentes.

Citer
Les puces et les APIs graphiques modernes sont vraiment faites pour des cycles clear/draw/display répétés, où tout est complètement rafraîchi à chaque itération de la boucle de dessin. Ne soyez pas effrayés de dessiner 1000 sprites 60 fois par seconde, vous êtes encore loin des millions de triangles que votre machine peut gérer.

Option 1 --> très classique, on dessine (largeur*hauteur) tiles.
Ainsi pour une map de 20x20 avec des tiles de 32 pixels, on appelle 400 fois draw pour des affichages de 1024 pixels.
__________
MAIS
__________
Citer
Par exemple, vous atteindrez très rapidement les limites de votre carte graphique si vous dessinez un grand nombre de sprites. La raison est la suivante : les performances sont directement liées au nombre d'appels à la fonction draw.
Citer
De plus, utiliser une unique texture vous permettra si nécessaire de regrouper toute la géometrie statique en une seule entité (vous ne pouvez en effet utiliser qu'une seule texture par appel à la fonction draw), ce qui sera nettement plus performant que de dessiner un groupe de plusieurs entités.

Option 2 --> Créer une grosse texture (par exemple au chargement de la map) qui contiendra en fait toutes les tiles, en copiant les pixels uns par uns).
Ainsi pour la même map on fait 1 seul appel à draw, pour environ 410000 pixels. Et la gestion de la vue est plus facile.


Donc, qu'est-ce qui est le mieux ?
La première option fait plus d'appels à draw, mais sur des images plus petites.
La seconde ne fait qu'un appel, mais on dessine des chose hors-écran, c'est du gachis. EN plus j'ai vu sur le forum que les textures avaient une taille limite.

Sur une map de 20*20 je ne pense pas que ce soit significatif, mais sur une map de 500*500, le nombre d'appels à draw explose dans le cas 1, et la taille dans le cas 2 devient énorme.

(Une solution intermédiaire consiste à mixer les deux : faire une seule image, contenant uniquement ce qu'on peut voir, et la recalculer à chaque déplacement du personnage. )

Merci d'avance pour vos réponses et éclaircissements ! :)

10
Discussions générales / Re : Un jeux vidéo en 3 mois ?
« le: Juin 12, 2013, 03:32:30 pm »
J'avais développé, à l'époque où j'apprenais le C à la fac, un petit Space Invaders avec SDL en.... je dirais en compactant le temps, je dirais 1 semaine à temps complet (6h par jour).
J'en suis assez content même si il a quelques bugs. Et le plus beau c'est qu'il y a de l'aléatoire.

A toi de voir comment gérer les niveaux, mais il est essentiel de penser à tout dès le début.
Selon moi il y a deux façons de faire :
-une base de patterns, et à chaque fin de pattern on en tire un autre aléatoirement (à la Binding of Isaac).
-une génération vraiment aléatoire, qui peut donner des résultats bien meilleurs, mais bien sûr plus compliqués car il faut garder une cohérence.

Le jeu de shoot ne m'a pas l'air d'être le plus compliqué. Pense juste à faire des collisions intelligentes et des contrôles réactifs. Tu peux faire une I.A assez simpliste (viser - tirer - éviter), ce qui est toujours du temps gagné ;)

BON COURAGE ! Montre nous le résultat dans 3 mois :)

Pages: [1]