Sujets

1

Graphique / [SFML2] sens trigo ? [RESOLU]

« le: Juillet 26, 2012, 05:59:57 pm »

Je viens de passer en SFML 2 et je suis soudains surpris de voir que le sens de rotation des objets a changé !

Une rotation positive le fait tourner dans le sens horaire, et pas dans le sens trigo !

C'est fait exprès ? pourquoi avoir fait ce choix (si choix il y a eu) ?

2

Suggestions de nouvelles fonctionnalités / [1.6] Changer le titre d'une fenêtre ?

« le: Juillet 25, 2012, 11:13:03 pm »

C'est pas super violent, je sais ...

Mais je constate que l'on ne peut pas changer facilement le titre d'une fenêtre, sans en créer une autre !
L'idée est de faire comme certains programmes windows, qui indiquent par exemple l'avancement d'un traitement dans le titre de la fenêtre (on peut le voir quand la fenêtre est réduite ...)
Ce serait intéressant aussi pour afficher les FPS, ce genre de choses ...

Rien de bien violent en somme, mais ça peut être sympa !

Est-ce possible, et simple ?

3

Fenêtrage / [SFML 1.6] [RESOLU]MA chere manette Xbox 360 ....

« le: Juillet 24, 2012, 08:03:55 pm »

Tout est dans le titre, je m'amuse avec ma manette de jeu xbox 360 ....

Voici un petit code tout mignon pour voir comment ça marche là dedans :

while (continuer) // tant que je veux continuer
   {
      // ################# parcourt de la liste d'évènements ################
      while (App->GetEvent(event)) // tant kil reste des évènements dans la pile
      {
         if(event.Type==sf::Event::Closed) // si on veut fermer : on ferme
         {
            return 0;
         }
         
         if(event.Type==sf::Event::JoyButtonPressed) //affiche les infos sur la pression d'un bouton
         {
            std::cout<<"JoyButtonPressed"<<" ";
            std::cout<<"id : "<<event.JoyButton.JoystickId<<" ";
            std::cout<<"bouton : "<<event.JoyButton.Button<<std::endl;
         }

         if(event.Type==sf::Event::JoyMoved) //idem pour le mouvement d'un joystick
         {
            if(fabs(event.JoyMove.Position)>30) //on ignore les petits déplacements parasites
            {
               std::cout<<"JoyMoved"<<" ";
               std::cout<<"id : "<<event.JoyMove.JoystickId<<" ";
               std::cout<<"axe : "<<event.JoyMove.Axis<<" ";
               std::cout<<"val : "<<event.JoyMove.Position<<std::endl;
            }
         }
      } // fin boucle évênements
}

Comme mis en remarque, la manette a tendance à "inventer" de faibles déplacement des joysticks, donc je les ai tout simplement ignorés ....

Bref, voici les conclusions de ce test :

A,B,X,Y -> boutons 0,1,2,3
LB,RB -> 4,5
SELECT/START -> 6,7
click sur le joystick gauche/droit -> boutons 8 et 9.

Pour les Axes :
Joystick Gauche X/Y -> 0,1
Gachettes : axe 2 (position négative pour RT, positive pour LT)
Joystick Droit : X/Y -> 4,3

Et les flèches alors ?
-> c'est le joystick 6 (où est passé le 5 ??  )
ça donne des valeurs correspondant à l'angle entre la verticale et la touche d'appui
touche de droite -> 90
bas -> 180 etc ...

MAIS : la touche du HAUT n'est PAS détectée !

Serai-ce un bug dans la SFML ? Et l’absence de ce joystick 5 est bien étrange ....

Manifestement, ça correspond au POV, mais les valeur 0/360 sont ignorées ....

EDIT : Je pense bien que c'est ça, la position doit être dans ]0;360[, or ici les valeurs limites ont leur importance .... Je ne suis pas parvenu à trouver la ligne de code correspondante ... A vérifier à l'occasion ....

4

Graphique / [SFML 1.6 Bug -> Réglé !] Subrect

« le: Juin 09, 2012, 04:15:50 pm »

Bonjour,

je pense avoir découvert un bug :
Lorsqu'on change le subrect d'un sprite dans une image, mettons qu'on mette sf::IntRect rect={15, 15, 25, 25};
Seuls les pixels de (15,15) à (24,24) sont pris en compte, alors qu'on s'attendrait à avoir tout jusqu'à (25,25) ...

A mon avis, le problème se trouve dans la taille du rectangle :
Je suppose que pour charger le contenu, on calcule la taille width/height du rectangle, et que la faute se trouve ici :
il doit y avoir width=Right - Left .... Or la largeur du rectangle n'est pas Right - Left mais bien Right-Left+1 (ici : 11 et non pas 10 -> on veut afficher les 11 colonnes, de la 15 comprise à la 25 comprise !)

La faute que je propose ici donnerai bien le bug que j'ai constaté ...

Et en effet, en fouillant dans les fichiers, je trouve bien cette définition de width dans le fichier Rect.inl, ligne 60 (fonction GetWidth) qui se répercute donc bien dans l'affichage du sprite (Sprite::Render) pour ce que j'ai pu en comprendre ....
Idem pour la hauteur !

5

Général / [WIP] Casse Brique C++ [Résolu]

« le: Mai 14, 2012, 05:30:29 pm »

Bonjour !

Je me suis remis récemment à coder, et j'ai donc bien entamer la réalisation d'un casse brique, avec notre bibliothèque préférée. Jusque là, rien d'original ...

J'ai juste un petit soucis, et un problème d'ordre plus général, mais avant, quelques infos :

Organisation du programme :

La classe Jeu gère les évènements, provoque l'affichage régulier de toutes les briques, balle, etc ..
Le joueur est en fait juste un rectangle contrôlé par la souris (la classe jeu lui indique ou se placer)
La balle, bah voilà ... et idem pour les briques.

Le principe du truc : J'utilise des collisions cercle/rectangle entre balle et brique/joueur.
Le jeu test à chaque affichage les collisions balles/reste, et si il y  lieu, lance la fonction choc de la balle.
La balle rebondis, et c'est elle qui envoi le signal de choc à la brique.
Petite subtilité, j'ai fais en sorte que la balle ne puisse pas rebondir deux fois contre le même objets si elle n'a pas choqué contre autre chose avant (elle choquait, mais n'avait pas le temps de partir parfois, donc rechoquait). La détection des collisions et chocs fonctionne à merveille.

MAIS :

petit soucis : lorsque je casse une brique, certaines (aléatoire ?) scintillent une fois ! -> elle ne sont manifestement pas affichées pour une seule frame , mais là, bah je coince ...
-> problème connu ? (j'ai mis le frame limit à 400) ou alors j'ai vraiment un plantage quelque part ?

Mais on a aussi le problème : les rebonds !
Comment j'ai fais :
baballe choque sur brique -> on rebondis.
Si : le projeté du cendre de la balle est sur un segment horizontal (vertical), on inverse la vitesse horizontale (verticale respectivement) -> le point de choc est sur un segment.
Si ce n'est pas le cas, on est plus ou moins dans un angle :

(le schema est normalement en fichier joint, je ne sais pas trop comment ça marche  )

la balle arrive avec une vitesse rouge, de norme V. J'ajoute à ce vecteur le vecteur bleu (ici de coordonnées (1,1), de norme 2*V), on calcule le vecteur vert, vitesse finale de la balle, en lui redonnant une norme de V.
c'est pas trop mal, et ça règle le cas pathologique de la balle avec vitesse orange, mais qui tape dans le coin !

SAUF QUE : mettez deux briques à coté, et tapez dans le coin de l'une : la balle rebondis sur un angle, alors qu'elle est face à une droite  (comme ceci : _______|________ )

Comment faire pour avoir de jolis rebonds tout beaux ?? Voilà c'est mes deux problèmes du moments, j'ai nommé ce sujet WIP, car ce sera pas les derniers problèmes je pense, alors autant éviter le surnombre de sujets !

       
EDIT : les fichiers joins ne se voient pas à la prévisualisation, mais ça marche !

[attachment deleted by admin]