Colisions 2d

j'avais quitté le forum de panoramic par ce que je n'avais plus de temps maintenant je l'ai retrouver le temps biensur à l'époque j'avais demander comment gérer des collisions 2d mais on avait répondu qui fallait les tester soit même oui mais comment je suis débutant en panoramic basic alors je comprend pas trop comment faire ?

En fait pour une collision, tu regardes si les coordonnées de 2 sprites où images se chevauchent.
Je vais essayer de faire simple
Tu as un sprite qui fait un largeur: La1 et une longuer lo1.
Il a une position de départ x1,y1
Tu as un autres sprites La2, lo2, x2,Y2
S'il y a collision entre les 2, tu as
x1+La1 > x2 et x1 <x2+La2
y1+lo1 > y2 et y1 < y2+lo2

Fais toi un schéma si tu veux. J'espère ne pas me tromper, je fais ça de tête au boulot, mais normalement, c'est ça.

je suis désolé je ne comprend pas tout pourrais tu si tu as le temps et l'envie bien sur de me l’expliquer un peu mieux

encore une fois désolé pour le dérangement et merci

En fait il faut que le coin droit de ton sprite 1 dépace le coin gauche de ton sprite 2 qu'il soit après
d'où le x1+La1 > x2 , mais il faut aussi que le sprite 1 n'ait pas dépacé le sprite 2 (qu'il ne soit pas plus loin que le sprite 2) du coup tu vérifies que x1 <x2+La2, c'est à dire que le coin gauche du sprite 1 soit bien à l'interieur ou avant le bord droit de ton sprite 2
Essaye de voir avec le petit schéma, le principe en faisant tourner progressivement les cas

Houla je trouve cela pas pratique du tout il n y a que cette solution ? par ce que si j'ai beaucoup de collisions à faire je vais perdre du temps a gérer ça non ? en plus je trouve pas cela très facile à mettre en œuvre ! mais bon faut que j’asseye de bien comprendre le principe

Ta as, depuis aujourd'hui, la possibilité d'utiliser une des fonctions de ma dll MouseOperations.dll: c'est la fonction IsPointInRectangle ! On s'en sert de la manière suivante:

Code:

i% = dll_call6("IsPointInRectangle",xp%,yp%,xr%,yr%,wr%,hr%)
if i%=1 then (... le point est dans le rectangle - donc collision...)

Les paramètres sont les suivants:
- le point est déterminé par (xp%,yp%)
- le rectangle est déterminé par son coin en haut à gauche (xr%,yr%) et sa largeur wr% et sa hauteur hr%

Tous les paramètres sont en pixels.

mdr, oui mais là tu triches Klaus
Non sérieux, c'est génial.
Par contre, je remets ça sur le tapis, mais il va falloir que tu refasses une grosse DLL complémentaire à panoramic pour que l'on ajoute les fonctions en attendant que certaines soient intégrées à Panoramic.
Il faudrait les fonction de Printscreen / MouseOperation / strings / WindowsVersion / GetMouse / Form / Bench et j'en oublie surement des utiles ...
Toutes les fonctions ne serviront pas à chaque fois, mais bon ce serait plus simple que de jongler avec toutes ces DLL.

Euh... C'était mon idée initiale, d'où KGF.dll.

Or, des voix du forum se sont élevées pour suggérer des DLLs individuelles, afin de ne pas avoir à trimballer la grosse KGF.dll alors que juste une fonction n'est utilisée. J'ai donc changé d'orientation et fait des DLLs individuelles.

Maintenant, je pense aussi qu'une seule DLL serait une vraie simplification. Alors, si d'autres parmi vous votez pour une seule DLL unifiée, je vais tout réintégrer en une seule. Mais je ne maintiendrai pas les deux versions en parallèle - trop complexe.

En fait, les deux sont bien selon l'usage. La DLL séparée pour certains usage et la mise à jour de ta KGF.DLL pour les programmes qui font appels à plusieurs fonction (ça évite d'avoir à utiliser la DLL pour en charger plusieurs ... )

SVP les gars votez pour la MAJ de KGF

Wir sollten prüfen welche Funktionen in einer DLL sinnvoll zusammen passen.

Es gibt, wenn ich richtig gezählt habe, 32 DLL von Klaus.
Weiter benutze ich eine FORM.DLL von Nardo26.
Weiter benutze ich eine Format.DLL von papydall.
Weiter benutze ich eine EVAL.DLL von Jean_debord.

Da ich die Variablen dem Prgramm anpasse, gibt es sprechende Variable.
Wie alle Druckvariablen - Druck......




Nous devrions envisager quelles sont les caractéristiques s'inscrivent dans une DLL est logique ensemble.
Il est, si j'ai bien compté correctement, 32 DLL de Klaus.
Ensuite, j'ai utiliser un FORM.DLL de Nardo26.
Ensuite, j'ai utiliser un Format.DLL de papydall.
Ensuite, j'ai utiliser un EVAL.DLL de Jean_debord.
Comme je l'ai ajuster les variables à l'Prgramm il parle variable.
Comme tous les pression variable - la pression ......

Absolument si Nardo, Jean debord et papydall sont d'accord, il faudrait intégrer aussi leurs fonctions interessantes. La DLL de Nardo est très pratique aussi pour les form, la fonction pour les chiffres aléatoires de Jean apporte un plus aussi, et en effet les fonctions de format facilite la vie dans certains cas.

Personnellement, je vois difficilement comment intégrer dans une seule DLL, les DLLs de diffférents auteurs. Non seulement il y aura à l'évidence des problèmes de maintenance et de mise à jour, mais en plus, il y a des DLLs en Delphi, d'autres en FreeBasic, ...

Ce qui est envisageable, c'est de faire une seule DLL par auteur, regroupant toutes ses fonctions. Après tout, même avec plusieurs dizaines de fonctions, une DLL ne sera pas si énorme que ça, et si l'on compare aux DLLs qui sont dans Windows\System32...

Je suis assez tenté de tout réintégrer dans une seule DLL, mais je ne veux pas faire une autre fois les aller-retour de ce genre.

Perso, je pense que c'est plus pratique et ça doit te faire moins de maintenance aussi...
Mais bon c'est mon point de vue.

Dans l'idéal absolut, il faudrait que chacun puisse créer une dll
adaptée à son programme et contenant toutes les fonctions nécessaires
à son bon fonctionnement.

Malheureusement, si on est tous des adeptes du partage de source,
et bénit soit la communauté panoramique pour cela, nous ne sommes
pas égaux devant la compilation. Perso, je peux compiler du freebasic
mais pas du Delphi, j'ai pu installer delphi6 sous W7 mais à part ses librairies
le reste bug.

Donc, à choisir entre une grosse ou des petites, entre les deux mon coeur balance.
Klaus doit en être à sa deux millième fonction entre toutes ses dll ,
peut être que certaines (celles du début ) ont trouvé un pendant dans les fonctions Panoramic.
Du coup, KGF.dll serait peut être moins lourde.
Dans le cas d'une seule dll, la doc va être costaud, et pour retrouver une fonction
parmis un tel ensemble...

Par conséquent, je vote blanc et je m'en remets à l'avis général.

Si toutefois chacun venait à faire qu'une seule dll (KGF.dll , Nardo.dll,Jicehel.dll)
il serait bien de laisser les sources libres de façon à ce que,
dans la mesure où les prog restent ouvert à tout le monde,
chacun puisse compiler en fonction de ses possibilités le morceaux dont il a besoin
pour son programme. A ce moment là la dll devient "Mon_prog.dll".

Bon je pense qu'après ce long post tout le monde

Noch ein Aspekt:

Die "LoadProgram.dll" gibt Handle auf Form.
Wenn Jack diese Funktion programmiert, dann ist diese DLL überflüssig.

Das könnte mit jeder DLL passieren.
Ich hatte das schon angesprochen, das Jack auch mal auf die verschiedenen DLL schaut.

Ich glaube wir sollten es so lassen, wie es ist.


Un autre aspect:

Le "LoadProgram.dll" donne forme à manipuler.
Si Jack programmé cette fonction, puis cette DLL n'est pas nécessaire.

Cela pourrait se produire avec n'importe quelle DLL.
J'avais déjà mentionné que Jack se penche également sur la DLL différents moments.

Je pense que nous devrions, comme il peut, comme il est.

En ce qui concerne le partage des sources, je n'y suis pas opposé. J'ai d'ailleurs déjà publié les sources partielles de certaines DLLs, et même une DLL entière. Mais ce n'est pas aussi simple que de poster un seul source Panoramic ! Par contre, je suis prêt à placer les sources sur mon WebDav, avec les projets Delphi complets.

@ Klaus,

Je ne doute pas de ta volonté de partage, loin de là.
Tu es celui qui nous permet avec quelques autres, je ne veux blesser personne,
d' avancer dans nos délirs "programmiques".
Mais je mets aussi en avant la simplicité d'utilisation, la complexité de la doc.
J'ai mis sur mon webdav, dans "projet helpNDoc", un début d'aide chm
pour retrouver plus facilement les dlls et leurs fonctions avec pour pouvoir
le visualiser un chm compilé mais si tu jettes un oeil, c'est déjà pas simple...

Severin a écrit:

Il est, si j'ai bien compté correctement, 32 DLL de Klaus.
Ensuite, j'ai utiliser un FORM.DLL de Nardo26.
Ensuite, j'ai utiliser un Format.DLL de papydall.
Ensuite, j'ai utiliser un EVAL.DLL de Jean_debord.

Redde Caesari quae sunt Caesaris
rendre à César ce qui est à César

La DLL FORMAT.DLL n’est pas de moi mais de jean debord que je salue.

Jicehel a écrit:

En fait, les deux sont bien selon l'usage. La DLL séparée pour certains usage et la mise à jour de ta KGF.DLL pour les programmes qui font appels à plusieurs fonction (ça évite d'avoir à utiliser la DLL pour en charger plusieurs ... )

SVP les gars votez pour la MAJ de KGF

Je vote POUR

Merci

@Jean_debord

Entschuldigung das ich den Erfinder verwechselt habe
und Dank an Papydall für die Compilierung der DLL.
Severin

Désolé que j'ai confondu l'inventeur
et grâce à Papydall pour la compilation de la DLL.
Severin

Alors je suis désolé mais je ne toujours pas compris je m'excuse par avance
mais je 'est toujours rien compris à ce calcul pour les collisions


peut etre que comme il y a une gestion des colisions pour la 3d je devrait faire de la 3d et attendre qu'un jour peut être jack nous fasse une fonction pour la la colisions 2d

ce n'est pas grave je verrais cela plus tard j'ai décider de m'attaquer à un truc plus simple un logiciel basic de traitement de texte

j'ai déjà implanter la fenêtre et ces menu principaux

A thermes dans quelques mois le but étant de fournir un éditeur de traitement de texte avec coloration syntaxique .


je mettrais a disposition les sources au fur et à mesure



ps: désolée pour la gêne occasionné par ce sujet

Il n'y a aucune gène à ce que tu poses des questions. C'est juste dommage que nous n'ayons pas réussi à expliquer clairement comment faire.
Si tu retrouve dans les source le petit space invanders que j'avais fais quand j'ai commencé Panoramic, dedans il y a un test de collision entre le sprite du tir et les 'aliens' mais je ne sais pas si ça sera plus clair pour autant. A toi de voir si un code est plus parlant que la théorie.

e regarderais jicelel mais après tout je ne suis pas si pressé et puis je sens que que mon traitement de texte vas me prendre du temps

en tout cas merci beaucoup


ps : j'adore notre petite communauté de panoramiciens ^^

il m'arrive que des galeres mon pc est mort du coup je suis rester quelques mois sans ordis

et pour couronner le tout j'ai un pc moins puissant et j'ai oublié plein de choses sur ce langage merveilleux panoramic

mais j'ai toujours ce probleme de colisions et comme mon objectif est faire des jeu en panoramic je ne lache pas l'idée

est ce quelqu"un pourrais s'il vous plait me donner une fonction de colisions avec son mode d'emploi j'en demande peut etre trop mais je suis sur que cela me m'aider à comprendre comment faire des colisions à l'avenir

je vous en serais très reconnaissant de me donné la solution encore désolé pour le dérangement