Messages

1

Général / Re : Tile Mapping et structure de donnée

« le: Avril 23, 2013, 06:19:55 pm »

Je comprends mieux le problème maintenant un petit dessin aide beaucoup 

Perso j'utiliserai un vector de zone. Chaque zone connaitrait la(les) zone(s) qui lui sont accolé et les chargerait.
un petit schémas vite fait pour expliquer.

0   Z1 Z2
Z3 Z4  0
Z5  0   0

les Zx correspondent aux zone pleines et les 0 des zones vident.
Si mon perso se trouvent dans la zone Z1 je charge Z2 et Z4 mais ne dessine que Z1.
Si mon perso est en Z2 je ne charge que Z1 et dessine Z2.
Et ainsi de suite. Chaque zone connait sa ou ses voisines.

C'est primitif mais ça fonctionne. Ou alors j'utiliserais un tableau 2D de pointeurs vers des Zones et les zones vident je les mettrai à NULL.

Quelqu'un aura peut être une meilleur idée. Courage

2

Général / Re : Tile Mapping et structure de donnée

« le: Avril 23, 2013, 01:28:15 pm »

Pourquoi ne pas utiliser un tableau 2D de Zones ( ou un std::vector avec certains calculs cela revient au même) et définir une zone comme étant une tilemap.
Pour m'entrainer j'ai repris le tuto de la sdz que j'ai réadapté en c++. Ma zone est beaucoup plus grande que l'écran mais j'optimise en n'affichant que ce qui est sensé se trouver à l'écran. Ensuite arrivé au bord de ma zone je change de zone. Et ces zones sont stockées dans un tableau 2D et je n'est pas de perte de performances.

Pour résumer ce prendre la tête maintenant est une bonne chose mais pas forcément utile au vue de nos machines actuelles. Code comme tu le sens et si y a besoin d'optimiser regarde ce que tu peux faire à ce moment là.

3

Graphique / Re : L'origine d'un sprite

« le: Avril 22, 2013, 01:22:43 pm »

Je suis pas sur de comprendre l'intégralité du problème, mais ne serait il pas plus simple de placer le centre de l'explosion sur le centre des tes sprites ?

En gros :
- calculer le centre de l'explosion, une fois pour toute.
- calculer le centre des tes sprites, une fois pour toute.
- positionner le centre de l'explosion sur le centre des sprites.

4

Graphique / Re : [SFML 2] Surconsommation anormale du processeur

« le: Mars 30, 2013, 11:39:32 pm »

Juste par curiosité as tu pensé à mettre un limiteur de FPS. J'entends par la qu'il ne sert a rien d'utiliser toute la charge UC pour juste afficher un sprite. Un mécanisme qui permet de mettre ton programme en pause en fonction du FPS désiré. Ca sert a rien d'avoir 1200 fps pour juste afficher quelques sprites ou autre. (l’œil humain ne fait pas la différence au delà d'un certain nombre de FPS. Pour ma part en dessous de 30 fps je ressent la différence)

En gros dans la boucle de rendu faire un pause en fonction du fps désiré. ça consiste à :
- Mesurer le temps écoulé dans la boucle de rendu.
- Si le temps écoulé est inférieur à 1/(FPS désiré) : faire une pause
                                                                          sinon on affiche le rendu

Y a un sujet intéressant sur le forum même s'il ne traite pas du même problème. Ca peut etre une piste pour toi http://fr.sfml-dev.org/forums/index.php?topic=10989.msg76028#new.

En espérant t'avoir aidé un peu.

5

Général / Re : Animations via sprite sheets

« le: Mars 30, 2013, 11:17:38 pm »

Y a le système qu'utilise ragnarok online pour ses sprites. Un fichier .spr qui stocke si je ne me trompe pas le nombre de sprite par animation et leur rectangle englobant.

C'est du travail aussi mais c'est une autre solution. Il ne reste plus qu'a faire lecteur/parser de ce genre de fichier et le lier à la classe d'animation.

Bref ce ne sont pas les idées qui manquent

6

Graphique / Re : Normaliser un Vector2f

« le: Mars 18, 2013, 01:10:01 pm »

Salut, pour te répondre les sf::vector de SFML ne sont pas des vecteur mathématiques à proprement parler.
Il est cependant possible de rajouter des fonctions soit même.

Pour normaliser un vecteur, il faut connaitre sa norme (sa longueur) et ensuite diviser ses composantes par cette norme.

sf::vetor2f vecteur(3.f,2.f);
float norme = std::sqrt(vecteur.x*vecteur.x + vecteur.y*vecteur.y);
vecteur = vecteur / norme;
 

Dans les grande ligne c'est ce qu'il faut faire il y a surement des précautions à prendre. Peut être que quelqu'un d'autre saura amener plus de précisions la dessus.

7

Fenêtrage / Re : Code d'ouverture d'une fenêtre_test.exe a cessé de fonctionner

« le: Mars 01, 2013, 01:03:42 pm »

Perso dans les options du linker j'utilise l'option: -static-libgcc -static-libstdc++
Je n'aime pas avoir à copier/coller des dll dans mon dossier de travail. Peut être que ça peut te servir.

8

Graphique / Re : [SFML2] Optimisation déplacement

« le: Novembre 02, 2012, 07:39:44 am »

Non, tu affiches ton sf::vertexarray avec sa texture, et ensuite tu n'as plus qu'à déplacer ta sf::view.

9

Graphique / Re : [SFML2] Optimisation déplacement

« le: Octobre 30, 2012, 07:59:15 pm »

Pour plus de précisions  au lieu de déplacer tous tes sprites dans une direction ben tu déplace une sf::view dans la direction opposée   

10

Graphique / Re : [SFML 1.6] Tile mapping et collisions.

« le: Octobre 30, 2012, 01:04:32 pm »

Coucou, je pense qu'il y a un peu trop de code pour que l'on puisse le tester. (perso ca me donne pas envie  )

Ensuite une petite remarque, je suis pas trop fan de ton block switch dans la fonction afficher(). Pourquoi ne pas utiliser directement un tableau/vector de sprite et faire la manipe avec les switch une seule fois dans une fonction inti(). ça coute pas grand chose.

En tout cas je pense qu'il y a plus simple en utilisant la puissance du c++.
Bonne continuation

11

Graphique / Re : [SFML 2.0 RC] La RAM utilisée augmente sans cesse

« le: Septembre 30, 2012, 12:43:11 pm »

Bonjour, je n'ai pas testé ce bout de code, mais il me semble que c'est normal. Essaye de laisser tourner ton programme pendant un petit moment et normalement l'utilisation mémoire devrait se calmer et arréter d'augmenter.

12

Général / Re : [WIP] Casse Brique C++

« le: Mai 14, 2012, 06:32:18 pm »

Bonjour, pour le problème du rebond sur un coin je vois qu'une solution.
Si la balle tape un coin d'une brique, avant de la faire rebondir il faut tester si cette brique ne possède pas une voisine ( du coté du coin). 
Et donc si elle a une voisine on considère que la balle tape un segment et non un coin.

Le premier problème j'ai pas compris ce que tu voulais dire.

13

Général / Re : Fichier particulier

« le: Mai 04, 2012, 08:41:05 pm »

jettes un oeil sur l'ancien wiki, il y un tuto/code source pour intégrer nos ressources dans un fichier .dat
libre à toi de l'améliorer pour ajouter des fonctionnalités.

14

Discussions générales / Re : Un outil pour les animations 2D

« le: Mai 04, 2012, 08:11:24 pm »

Perso j'ai bossé sur une classe animation aussi  Mais plus dans l'optique de ragnarok online.
C'est a dire bouger un sprite dans 8 directions, avec les différentes animes de combat et autre dans un univers 3D, heightmap 3D avec caméra fixe ( il y a juste la map qui tourne selon un angle, mais la caméra est fixe style 2,5D )
J'utilise les sprites de ragnarok mais le problème c'est que les planches de sprite sont toutes différentes et je suis donc obligé d'utiliser un fichier pour configurer chaque sprite. ( comme fait ragnarok online)
Ce fichier défini les tailles des différents sprites, leur position, le nombre d'anime par sprite etc ...

Pour l'instant ça fonctionne pas mal, je ne gère pas encore les différentes têtes que peuvent avoir les personnages mais j'y travaille.

Si ça intéresse du monde je veux bien m'y remettre de manière plus poussée et le cas échéant partager mon code. Je ne fournirais pas mes sprites mais ils sont récupérables facilement de manière gratuite tant que votre projet n'est pas commercial.

edit: je peux donner le lien pour télécharger les sprites en questions. (mes animations marchent aussi avec des jeux pur 2D style "Zelda : a link to the past" sur super nintendo (une référence à mon gout) )

15

Site web SFML / Re : Nouveau forum

« le: Mai 03, 2012, 06:22:58 pm »

Mouarf, au temps pour moi, je pensais que le bouton vert été juste un indicateur et non pas un lien 
Du coup rien à dire c'est parfait . Merci