1
Graphique / Re : [SFML2] sens trigo ?
« le: Juillet 30, 2012, 10:24:38 am »
En effet ... je n'avais pas vu ça comme ça .... Merci pour vos réponses ! Je vais méditer là dessus profondément !
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.
Pages: [1]
2
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) ?
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) ?
3
Fenêtrage / Re : [SFML 1.6] MA chere manette Xbox 360 ....
« le: Juillet 26, 2012, 12:02:37 am »
J'y songe sérieusement ....
Peut être demain !
Peut être demain !
4
Suggestions de nouvelles fonctionnalités / Re : Changer le titre d'une fenêtre ?
« le: Juillet 25, 2012, 11:58:36 pm »
Alors :
Mon erreur est due au fait que dans la doc de la 1.6, sur la page de RenderWindow
http://www.sfml-dev.org/documentation/1.6/classsf_1_1RenderWindow.php
La fonction SetTitle n'est pas présente ....
Et ensuite, je bosse en 1.6 ^^ Pas précisé en effet, je m'en excuse ....
EDIT : en fait ce n'est pas non plus dans la page pour Window ...
Donc ce n'est pas disponible en 1.6 ...
Mais ça y est dans la doc de la 2.0 ...
Je vous présente mes humbles excuses, la prochaine fois, j'irai voir si ce n'est pas déjà corrigé dans la 2.0 ...
Mon erreur est due au fait que dans la doc de la 1.6, sur la page de RenderWindow
http://www.sfml-dev.org/documentation/1.6/classsf_1_1RenderWindow.php
La fonction SetTitle n'est pas présente ....
Et ensuite, je bosse en 1.6 ^^ Pas précisé en effet, je m'en excuse ....
EDIT : en fait ce n'est pas non plus dans la page pour Window ...
Donc ce n'est pas disponible en 1.6 ...
Mais ça y est dans la doc de la 2.0 ...
Je vous présente mes humbles excuses, la prochaine fois, j'irai voir si ce n'est pas déjà corrigé dans la 2.0 ...
5
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 ?
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 ?
6
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 :
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 ....
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
}
{
// ################# 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 ....
7
Graphique / Re : [SFML 1.6 Bug ?] Subrect
« le: Juin 10, 2012, 11:07:34 am »
Parfait ! La preuve que la SFML s'améliore de jours en jours !
8
Graphique / Re : [SFML 1.6 Bug ?] Subrect
« le: Juin 09, 2012, 05:11:20 pm »
Ok d'accord 
Je m'en suis aperçu hier et je ne connaissais pas ce bug, donc je préfère poster inutilement que garder ça pour moi ^^
En tout cas, ce bug est réglé avec cette définition du Rect, si on fait attention à ce qui suit :
On affiche les pixel de rect.X à rect.X+rect.W-1 !! (X position du Rect, et W sa largeur, évidence ?)
Sinon, on affiche 1 pixel de trop cette fois ci !
(x=10, w=10 -> on affiche jusqu'à 19 pour avoir 10 pixels !!)
Je m'en suis aperçu hier et je ne connaissais pas ce bug, donc je préfère poster inutilement que garder ça pour moi ^^
En tout cas, ce bug est réglé avec cette définition du Rect, si on fait attention à ce qui suit :
On affiche les pixel de rect.X à rect.X+rect.W-1 !! (X position du Rect, et W sa largeur, évidence ?)
Sinon, on affiche 1 pixel de trop cette fois ci !
(x=10, w=10 -> on affiche jusqu'à 19 pour avoir 10 pixels !!)
9
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 !
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 !
10
Général / Re : [WIP] Casse Brique C++
« le: Mai 16, 2012, 12:57:23 pm »
C'est fait, et ça marche !!! 
La moyenne des vecteurs normaux me semble moins intéressante, puisque qu'on retrouve des cas moches, avec une seule brique (j'avais déjà écarté la réflexion sur les angles) :
vitesse verticale -> vitesse horizontale (la balle redescends pas)
si la balle arrive comme la vitesse orange du premier dessins, ça donne une réflexion bizarre (la balle tourne autour de la brique)
Voilà donc un problème résolu, jusqu'au suivant !
EDIT : petite subtilité :
vérifiez que la somme des vitesse réfléchies n'est pas nulle :
ça arrive dans le cas des trois briques, si la balle ne choque qu'avec celle du haut et celle de gauche.
Dans ce cas, on détruit bien les briques, et la balle repart avec une vitesse simplement opposées à sa vitesse d'arrivée ! (Si jamais cette remarque sert à quelqu'un un jour
)
Et il faut aussi donner une valeur minimale à la vitesse verticale, en valeur absolue -> il arrive que par cette méthode, la balle ait une vitesse quasi-horizontale.
La moyenne des vecteurs normaux me semble moins intéressante, puisque qu'on retrouve des cas moches, avec une seule brique (j'avais déjà écarté la réflexion sur les angles) :
vitesse verticale -> vitesse horizontale (la balle redescends pas)
si la balle arrive comme la vitesse orange du premier dessins, ça donne une réflexion bizarre (la balle tourne autour de la brique)
Voilà donc un problème résolu, jusqu'au suivant !
EDIT : petite subtilité :
vérifiez que la somme des vitesse réfléchies n'est pas nulle :
ça arrive dans le cas des trois briques, si la balle ne choque qu'avec celle du haut et celle de gauche.
Dans ce cas, on détruit bien les briques, et la balle repart avec une vitesse simplement opposées à sa vitesse d'arrivée ! (Si jamais cette remarque sert à quelqu'un un jour
)Et il faut aussi donner une valeur minimale à la vitesse verticale, en valeur absolue -> il arrive que par cette méthode, la balle ait une vitesse quasi-horizontale.
11
Général / Re : [WIP] Casse Brique C++
« le: Mai 15, 2012, 10:41:28 am »
Et bien, je détecte une collision avec la methode décrite ici :
http://www.siteduzero.com/tutoriel-3-254490-formes-plus-complexes.html#ss_part_4
J'ai essayé plusieurs trucs : la balle ne choque pas avec 2 briques sans se déplacer un peu, ou alors elle doit attendre un petit laps de temps avant de pouvoir rechoquer ..... mais c'est pas top !
Je vais regarder ton lien !
EDIT : Et transformer le vecteur bleu en (0,1) enlève le cas limite ou la balle arrive avec une vitesse de (-1, -1) -> elle doit être réfléchie dans ce cas, et ce ne serait plus le cas avec (0,1) ....
EDIT 2 : Possible solution :
Je vais tester quelque chose (mais ça nécessite pas mal de modifications donc ça va prendre un moment) ...
Je vais trouver toutes les briques à proximité de la balle, calculer la vitesse qu'elle aurait en choquant contre chacune d'elle, et en faire la moyenne !
ça semble résoudre pas mal de cas tordus ! à voir ...
En tout cas je vais essayer ça !
http://www.siteduzero.com/tutoriel-3-254490-formes-plus-complexes.html#ss_part_4
J'ai essayé plusieurs trucs : la balle ne choque pas avec 2 briques sans se déplacer un peu, ou alors elle doit attendre un petit laps de temps avant de pouvoir rechoquer ..... mais c'est pas top !
Je vais regarder ton lien !
EDIT 2 : Possible solution :
Je vais tester quelque chose (mais ça nécessite pas mal de modifications donc ça va prendre un moment) ...
Je vais trouver toutes les briques à proximité de la balle, calculer la vitesse qu'elle aurait en choquant contre chacune d'elle, et en faire la moyenne !
ça semble résoudre pas mal de cas tordus ! à voir ...
En tout cas je vais essayer ça !
12
Général / Re : [WIP] Casse Brique C++
« le: Mai 14, 2012, 07:18:02 pm »
En fait de manière plus ou moins aléatoire, quand je casse une brique, une autre disparaît et réapparait de suite après, elle scintille une seule fois...
Et j'ai beau chercher dans le code, il y a toujours quelque chose d'afficher, les fonctions de chocs et d'affichage sont totalement indépendantes ... De plus, chaque brique gère son propre affichage, donc si j'en casse une, il n'y a aucun effet sur les autres !
Pour ce qui est des rebonds, j'avais pensé à ça aussi, mais je trouve pas ma façon super réaliste, ça rebondis bizarrement parfois ... Il y a une meilleur manière de gérer ces rebonds spéciaux ?
(Merci pour la réponse rapide au passage !)
Est-il utile de poster une release ?
(Désolé pour mon délai de réponse, ma connexion internet est vacillante ...)
EDIT : Oulah, je crois connaitre l'origine du problème d'affichage, après plusieurs dizaines de test ...
En fait, quand je détruit ma brique, je l'enlève du tableau contenant toutes les briques, et c'est toujours celle qui prends sa place qui scintille ... c'est moche ....
EDIT2 : scintillement, morale de l'histoire :
Ne jamais interférer dans les affaires d'autrui :
la brique agissait sur le jeu pour qu'il la supprime -> immense bordel inomable, après réflexion ...
-> correction : la brique indique au jeu qu'elle doit être supprimée, et celui le fait quand c'est le moment !
-> pas de bordel ! Reste encore un problème : la collision mystère !
-> c'est une brique qui par une série de rebords originaux, est purement et simplement détruite par la balle, mais celle-ci ne semble pas rebondir !
-> En bref, ce problème est réglé !
Mais si quelqu'un a une idée pour une collision sur les angles plus réaliste, je suis preneur !
EDIT3 : Les colisions avec plusieurs briques : cas pathologiques :
Le problème viens des deux images :
la 1ère, avec 2 briques :
la balle arrive : vitesse rouge, rebondis sur la brique de gauche -> vitesse verte
MAIS : elle n'as pas le temps de partir, et l'algo la fait choquer avec la 2ème brique.
J'ai eu une collision sur la face inférieure comme ça -> vitesse verticale inversée -> bleue
Et avec 3 briques, j'ose même pas imaginer le bazar que ça peut engendrer ....
J'avoue, je sèche complètement ... Aucunes idée de comment gérer le truc, même en supposant que je connaisse toutes les briques proches (en collision avec une balle plus grosse par exemple) ...
Je suis prêt à tout essayer, dès demain !
[attachment deleted by admin]
Et j'ai beau chercher dans le code, il y a toujours quelque chose d'afficher, les fonctions de chocs et d'affichage sont totalement indépendantes ... De plus, chaque brique gère son propre affichage, donc si j'en casse une, il n'y a aucun effet sur les autres !
Pour ce qui est des rebonds, j'avais pensé à ça aussi, mais je trouve pas ma façon super réaliste, ça rebondis bizarrement parfois ... Il y a une meilleur manière de gérer ces rebonds spéciaux ?
(Merci pour la réponse rapide au passage !)
Est-il utile de poster une release ?
(Désolé pour mon délai de réponse, ma connexion internet est vacillante ...)
EDIT : Oulah, je crois connaitre l'origine du problème d'affichage, après plusieurs dizaines de test ...
En fait, quand je détruit ma brique, je l'enlève du tableau contenant toutes les briques, et c'est toujours celle qui prends sa place qui scintille ... c'est moche ....
EDIT2 : scintillement, morale de l'histoire :
Ne jamais interférer dans les affaires d'autrui :
la brique agissait sur le jeu pour qu'il la supprime -> immense bordel inomable, après réflexion ...
-> correction : la brique indique au jeu qu'elle doit être supprimée, et celui le fait quand c'est le moment !
-> pas de bordel ! Reste encore un problème : la collision mystère !
-> c'est une brique qui par une série de rebords originaux, est purement et simplement détruite par la balle, mais celle-ci ne semble pas rebondir !
-> En bref, ce problème est réglé !
Mais si quelqu'un a une idée pour une collision sur les angles plus réaliste, je suis preneur !
EDIT3 : Les colisions avec plusieurs briques : cas pathologiques :
Le problème viens des deux images :
la 1ère, avec 2 briques :
la balle arrive : vitesse rouge, rebondis sur la brique de gauche -> vitesse verte
MAIS : elle n'as pas le temps de partir, et l'algo la fait choquer avec la 2ème brique.
J'ai eu une collision sur la face inférieure comme ça -> vitesse verticale inversée -> bleue
Et avec 3 briques, j'ose même pas imaginer le bazar que ça peut engendrer ....
J'avoue, je sèche complètement ... Aucunes idée de comment gérer le truc, même en supposant que je connaisse toutes les briques proches (en collision avec une balle plus grosse par exemple) ...
Je suis prêt à tout essayer, dès demain !
[attachment deleted by admin]
13
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]
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]
Pages: [1]