1

j aurais voulu savoir comment vous voyez ce system là dans le cadre d un jeu de combat.

en clair quand ton perso dans un coup et qu il n est pas parer par l adversaire

le coup doit enlever des points d energie et impliquer une animation (sprite de colision)

mais pour faire cela il faut une gestion de colision et je ne vois pas concrétement comment faire ??

j ai penser a deux solutions et je voudrais avoir votre avis

1°) faire une feuille transparant qui englobe le perso et qui servirais de zone de colision

2°) ou lors de la création du perso coder les zones de transparence comme zone de colision

ou si vous avais une autre idée merci de me la soumettre..... confus

2

regarde ici: http://mugen.elecbyte.com/docs/tutorial/tutorial2.html

c'est un tutorial pour mugen, tu peux sauter tout ce qui est specifique à ce moteur, mais les images avec les collision boxes sont tres interessantes. apres tu n'as plus qu'a appliquer ce principe, la detection des collisions pixel par pixel sont inutiles, et les algos pour detecter une collision entre deux box ne sont pas tres compliqués à pondre.

3

pas mal comme principe

4

Pour les détections de collisions par rectangles en C, c'est très simple. Voilà des macros tirés de ExtGraph de Thomas Nussbaumer, une librairie graphique pour les calculatrices TI-89/92+/V200:
// macro which returns the absolute value of a given short
#define EXT_SHORTABS(a)  ({register short ta=(a); (ta>=0) ? ta : -ta;})
 
// macro which checks two bounding rectangles starting at (x0/y0) and (x1/y1) for
// collision. w is the width in pixels and h the height of the two bounding rectangles
#define BOUNDS_COLLIDE(x0,y0,x1,y1,w,h) \
   ((EXT_SHORTABS((x1)-(x0))<(w))&&(EXT_SHORTABS((y1)-(y0))<(h)))
 
// handy aliases for standard tile sizes (8x8 / 16x16 / 32x32)
#define BOUNDS_COLLIDE8(x0,y0,x1,y1)  BOUNDS_COLLIDE(x0,y0,x1,y1,8,8)
#define BOUNDS_COLLIDE16(x0,y0,x1,y1) BOUNDS_COLLIDE(x0,y0,x1,y1,16,16)
#define BOUNDS_COLLIDE32(x0,y0,x1,y1) BOUNDS_COLLIDE(x0,y0,x1,y1,32,32)

Ces macros devraient être compilables sans problème avec n'importe quelle version de GCC, y compris la version pour GP32. La seule chose qui est demandée (mais pas exigée à ce qu'il me semble) si tu utilises ces macros est un merci à Thomas Nussbaumer avec un lien vers http://tict.ticalc.org quelque part dans les crédits.

Documentation:
BOUNDS_COLLIDE(x0,y0,x1,y1,w,h)
Checks if two rectangle areas of width w and height h starting at (x0,y0) and (x1,y1) overlaps. Returns 0 if areas won't overlap.
BOUNDS_COLLIDE8(x0,y0,x1,y1)
Checks if two square areas of width 8 and height 8 starting at (x0,y0) and (x1,y1) overlaps. Returns 0 if areas won't overlap.
BOUNDS_COLLIDE16(x0,y0,x1,y1)
Checks if two square areas of width 16 and height 16 starting at (x0,y0) and (x1,y1) overlaps. Returns 0 if areas won't overlap.
BOUNDS_COLLIDE32(x0,y0,x1,y1) Checks if two square areas of width 32 and height 32 starting at (x0,y0) and (x1,y1) overlaps. Returns 0 if areas won't overlap.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

merci et pour le petit remerciment dans les credits cela va de soit. je n ais pas été éduquer à la methode de bilou$.
Et je n'oublier pas tous ceux qui m'aiderons dans notres creations
top

6

Bon j'ai l'impression que je vais mettre du tutoriel en ligne ....

Je vais peut être écrire 2 ou 3 chose sur unplugandplay, sans trop dévoilé ce qui sortira dans le numéro 2 de Alternatif Pocket....

Patience Patience...
avatar
:*)

7

cool

Par contre bille2 tes tutoriels s'adresseront j espére aux niewbies comme aux confirmer.

j ai hate de savoir les themes que tu vas abordé.

nous on est toujours au stade du gratage de papier pour mettre en place le pseudo moteur 2d mais on a encore des points sombrent...

on peut pas tous savoir en 3-4 jours.....

8

Tes tutoriels utilisent les biblio de GamePark seront appliqués à un exemple ou bien ce seront des tutoriels sur la théorie des moteur2D (gestion de sprite, de collistions etc...) ?

9

smile merci d'ailleur,

hier soir j ai vue cela dans le work_en, on est train de potasser justement les bibliothéques ( au fait se sont bien les GPDRAW() GPlcdsurfaceget().... etc, les bibliotheques).

Mais il n y a pas inventaires de toutes les fonctions avec la syntaxe leurs definitions
(enfin la résultante) et leur domain d'application ..???

10

ici tu trouvera la doc de tt les fct gp smile
et la le mec il le pécho par le bras et il lui dit '

11

cool merci bien

12

kel boss ce noferov happy)))

13

rotfl

je suis pas un boss lol je suis juste un 26.gif

le boss c yenaphe qui ma donné la doc wink
et la le mec il le pécho par le bras et il lui dit '

14

une autre petit question

on s est lancer donc avec une gestion de collision par boite

mais les boites de collision font parti du sprite du personnage ou font parti d un au sprite transparant sur un autre plan

nous on etait parti sur une gestion de boite de collision transparant sur le deuxiéme plan qui controle le personne sur le premier plan

quand on declanche la collision se fait par rupture de la surface ou par rupture du perimetre

je comprend pas


.........? mur (la theorie s est bien la realisation moins cool"

15

tu ma l'air un peu depassé lol :P

regarde la source que je t'avais envoyée, dedans g fait une gestion de collision par zones...
toi ca va etre encore + facile vu qu'il n'y a que 2 zones a tester (les 2 combatants)

pour expliquer ca simplement, chaque perso est ds un rectangle, qt ce rectangle est confondu avec un des autres, il y a collision

si tu veut gagner en precision, crés plusieurs rectangles par perso (1 pour le corp et un pour le bras par ex) ou detecte les collision par les pixels non transparent du rectangle au lieu du rectangle lui meme ...
et la le mec il le pécho par le bras et il lui dit '

16

j ai regarde projectx marrant mr neuilneuil je suis en train de decripter enfin apres le boulo. smile

17

chut c secret ^^'

'enfin apres le boulo' tu taffe a 4h du mat ?
et la le mec il le pécho par le bras et il lui dit '

18

et je traville en 5/8

on a penser a une autre solution soit delimitant un zone pixel (enumeration des coordonnée de chaque point (x,y))qui aurait les meme coordonner donc colision soit en mettant une zone virtuel (aire du carre)sur la derniere anim du coup qui ferait notre boite de col

19

en 5/8 ?

"enumeration des coordonnée de chaque point (x,y)" t pas ds la merde pour creer tes persos ...
fo que ca se fasse automatiquement ... a la limite pour faire un truc rapide, teste si les 2 rectangles se coupent (regarde ma source pour voir comment) et si sa se coupe, teste alors pixels par pixels les bouts d'images qui se touchent pour voir si les bonhommes se touchent vraiment... (si pour des mm coordonnées les 2 couleurs ne sont pas transparentes alors il y a impact)

"en mettant une zone virtuel (aire du carre)sur la derniere anim du coup qui ferait notre boite de col" euh cad ?
et la le mec il le pécho par le bras et il lui dit '

20

noferov: le 5/8 c'est comme un 3/8 + 2
Yenaphe point info

21

euh tu m'embrouille encore plus la ... triso

5/8 = 3/8 + 2/8 lol ca c en math mais au boulot ^^'

tu fait les trois 8 + 2 heures c ca ?
et la le mec il le pécho par le bras et il lui dit '

22

on tourne en 5 equipes et on fait a chaque fois 8h par poste sur une semaine samedi dimanche et jour ferié comprit

je vais potasser ça quand je me reveillerais tout à l heure

pour l aire s est un peu comme le principe des pixels sauf que cette on delimite une surface de contacte et non des points

arff un schemat serais plus explicite

23

je peux avoir cette sources, ca m'interresse ?!
TI-NSpire Pwned !

Thx ya all...thx ExtendeD.

...The rebirth of the community...

24

ta zone de contact, est composée de pixels qui viennent des spites de tes combatants (trouvée avec la collision par zone),
ces pixels vons êtres allumés ou transparents :
tu peut alors detecter si les 2 persos se touche reelement

soit tu compare pixel par pixel les 2 zones de contact des perso,
soit tu le fait par ligne en t'arrettant au 1 er pixel allumé (pour aller + vite) en partant de la droite pour le perso de gauche et vice versa

y aurais moyen aussi de gerer ces surface de contact par des matrices, il y a des formules pour les manipuler et comparer facilement ...

tu peut aussi aussi regarder le nombre de colision detectées sur la zone
pour faire une animation != ou mettre un coup + ou - violent selon si la droite est bien mise ou non :P

iceman : cf mini msg smile
et la le mec il le pécho par le bras et il lui dit '

25

sa serais pas mal pour gerer une gestion de domage ...

enfin pour l instant je galere toujours sur le c ton code na rien a voir avec se que j ai vue jusqu'a maintenant mais je te rassure j ai trouver la parti des colisions par point.

pour le reste un coup de bigo sera nécessaire, comme dirais l autre " la theorie s est bien la pratique ou la sa change quand meme". je vais voir sa avec mon pote qui code aussi et essayera de comprendre le tout a tete reposer "le taff du mat cela me tue le ciboulot". (s est un peu comme une platine ou il y a tout les composants mais j arrive a savoir comment ils sont relier mur)

maintenant se son les graphs qui taff plus vite que nous ......

annonce recherche prog pour enseigner a newbies moyennant monnaies lol

26

enfin nous avons trouver notre system de collision qui est du coup en cour de realisation

gestion tx rx

tx est un point de coordonnée (x,y)

rx est une dans repere orthonorme qui comprend ((-x,+x)(-y,+y))

tous les point qui est comprid dans la zone rx déclenche

par contre cela demande un traitement image par image....... smile

27

yep ca va etre + simple a codder ca smile

le traitement image par image lol c pas grave, c le boulot des graphistes :P
et la le mec il le pécho par le bras et il lui dit '

28

oui oui

maintenant on a meme vue de l attribution de nos var pour les col et les jonctions