PARTICLE ENGINE 2D OPENGL DEV-C++ - EFFETS DE FEU ETC [ MOTEUR DE PARTICULES ]
BumpMANN
Messages postés
330
Date d'inscription
jeudi 22 mai 2003
Statut
Membre
Dernière intervention
26 janvier 2009
-
14 juin 2004 à 23:39
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008 - 1 sept. 2005 à 19:44
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008 - 1 sept. 2005 à 19:44
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/23693-particle-engine-2d-opengl-dev-c-effets-de-feu-etc-moteur-de-particules
https://codes-sources.commentcamarche.net/source/23693-particle-engine-2d-opengl-dev-c-effets-de-feu-etc-moteur-de-particules
1 sept. 2005 à 19:44
21 oct. 2004 à 16:41
20 oct. 2004 à 23:41
merci bcp pr la petite discu ;)
je vais me coucher
20 oct. 2004 à 23:34
pour repprendre :
oubli le static_cast, ca permet uniquement de de verifier la plausibilité pour deux types de la meme hierarchie de classe
dynamic_cast fais de meme mais dynamiquement lorsque la veridication statique n'est pas possible (pointeur) ==> controle retour necessaire
reinterpret_cast, equivalent au cast c
l'interet par exemple du reinterpret_cast, c'est (en plus de faire partie du langage) de pouvoir etre retrouvé facilement dans le source (contrairement aux cast c (Type) )
donc dans ton cas il est conseillé d'utiliser un reinterpret_cast
20 oct. 2004 à 23:26
En fait il ne fais que la verification statique (on appel ca le downcast)
20 oct. 2004 à 23:19
tout les types sont des objets en c++
"alors on a bien qu'effectuer un cast demande une conversion au run-time, c'est logique."
non, tu demandes un transtypage, il ne pourra se faire qu'au cour de l'execution, vu qu'il ne connais pas la valeur de la variable
meme float n = 1; genere un cast en c (pas en c++)
l'absence de controle static, c'est tout ce pourquoi le c peu compiler un programme qui plante lamentablement à l'execution (declaration implicite, nombres d'arguments variables, indirections,... )
20 oct. 2004 à 23:02
float f = ...;
int i = int(f);
parce que je trouve ça plus clair: ça fait référence à un constructeur du type d'objet int pour importer un float. si l'analogie est complète, alors on a bien qu'effectuer un cast demande une conversion au run-time, c'est logique.
qu'est-ce que tu appelles l'absence de contrôles statiques ?
20 oct. 2004 à 22:58
pour les cast, oui la conversion se fais au cours de l'execution, pour certains types de bases le processeur possede meme l'instruction (int -> float par exemple)
et puis c'est connu, la faiblesse du c c'est l'absence de controles statiques
20 oct. 2004 à 22:48
pour les const est, je les utilise à outrance depuis un certain temps. qd j'ai écrit ce code-ci, je n'avais pas encore tt à fait conscience de l'importance que ça avait: mtnt c'est chose faite ;)
les tableaux statiques c'est génial pour les concours d'algo (c'est super rapide), pour le reste, je préfère perdre un peu de temps et avoir une allocation vraiment propre. mais je suis bien conscient que c'est lent, aussi je m'arrange tt le tps pr minimiser le nombre d'appels à ces fonctions.
tu veux dire que les cast c-like ne sont pas effectués à la compilation? je ne vois pas qd il peut le faire sans ça ... enfin, va pour les static_cast, même si je trouve ça profondément ... moche et lourd :D
je comprends ce que tu veux dire pr les cas où il n'y a qu'une seule texture, mais un moteur c'est qd même sensé se plugger dans une carrosserie ;) mais je note que c'est couteux, je n'imaginais pas... je pensais que ça changeait juste un int dans la mémoire quoi... c'est pas le cas apparament ^^
merci bcp pr ces détails. tu auras remarqué que bcp de choses que tu as énoncées, je les ai acquises depuis lors; c'est rassurant: ça veut dire que j'ai un peu évolué ^^
pour le reste, j'essayerai de m'y attacher et de m'y contraindre (juste ton histoire de cast qui m'embête :p).
je continue mtnt ma lecture du tuto que tu linkais plus haut.
20 oct. 2004 à 21:25
par exemple
struct SRVB
{
float R,V,B;
SRVB() : R(0), V(0), B(0) {}
SRVB(float r, float v, float b): R(r), V(v), B(b) {}
};
fais toujours comme ca, c'est pareil et c'est plus rapide, surtout sur les objets autres que les types de bases (ou l'appel du constructeur par copie est tres penalisant)
abuse aussi tant que possible de const, private & co, de methodes static egalement quand c'est possible (mais ca j'ai vu que tu le faisais deja ;) )
prefere les tableaux statique aux zones allouée (d'une maniere generale)
pour les cast (transtypage), pour les types de bases, prefere l'operateur static_cast, qui en plus d'etre plus propre en c++ (que les c-style cast), sera resolu statiquement, c'est à dire à la compilation
p[0] = static_cast<char>(color);
pour les commandes opengl :
c'est une machine etat, donc si tu fais un glEnable( truc ); à l'initialisation, t'aura plus besoins de le faire au cour de l'execution, sauf si pendant le rendu tu dois desactiver ce truc, dans ce cas tu as pas le chois, mais travail le design de la partie rendu de facon a ne desactiver/reactiver qu'une seul fois par rendu
pour le glBinTexture c'est pareil, et surtout la c'est couteux, ca permet juste de dire à opengl quel est l'id de la texture courante, donc si tu utilise qu'une seule texture (qu'un seul id), un seul glbindTexture suffit (au debut, apres le glGenTextures)
pour les glTexParameteri et autres appliqua de texture, c'est encore mieux, tant que tu changes pas, tu le fais une fois pour la textures selectionnée et c'est bon
utilise aussi les filtres (GL_LINEAR = bilinear filtering), ca engendre aucune pertes, la cg gere ca en pur hardware, et pour ma part, j'ai deja observer que GL_NEAREST est meme legerement moins performant
donc en gros, le maximum de commandes à l'initialisation pour un minimum de commandes au cours du rendu :)
20 oct. 2004 à 20:35
bye !
20 oct. 2004 à 20:20
pour les index j'ai lu je sais plus ou que pour la cartes graphique, un tableau de points ca devais etre sous la forme d'un dico (d'abord les différents points, puis leur arrangement sequentiel)
comme seul article francais j'ai trouvé celui de prografix
http://prografix.games-creators.org/document/122
ca reste minimal, mais c'est deja un bon debut, surtout que ca te permettra d'adapter le design de ton code dans cette voie
pour voir ca en profondeur, doit y avoir de bon tutos sur les site gamedev (anglophone)
regarde les sources de q2/q3, je sais pas si j'avais bien chercher mais ils me semble pas avoir vu un seul glvertex !
je suis d'accord avec toi, y a rien de plus enervant que de tomber dans le pieges des extension et de se retrouver avec un programmes qui ne fonctionne qu'avec les dernieres cartes graphiques, mais c'est pas le cas de toutes les extensions, beaucoup sont aujourd'hui acquis pour la majorité des carte graphiques (comme le multi texturing et au moins 2 unités de rendu par gpu)
20 oct. 2004 à 19:38
20 oct. 2004 à 19:33
Bon courage pour la suite ;-)
20 oct. 2004 à 19:32
PIV 2.8Ghz
1,3 DDR
20 oct. 2004 à 19:26
djl << si il y a bien un truc que je ne fais pas, c'est optimiser en OpenGL :p:p j'ai déjà franchement du mal à comprendre comment ça marche simplement, alors plus loin je me lance pas encore ;) Cependant, tout ce qui appartient à la liste des réflexes simples, si je les apprends, je les utiliserai parce que je me poserai plus la question, donc balance tt ce que tu peux ;)
j'utilise en effet les glvertex... c'est quoi des vertesx buffer? et est-ce que si j'utilise des display lists ça sera encore nécessaire?
les extensions, c'est même pas la peine ;) je suis contre parce que ça tue dans l'oeuf la portabilité (au sens distribuabilité plutôt).
20 oct. 2004 à 18:29
donc si tu dessines à coup de glvertex, la ca casse tout
faudrais passer par des vertex buffer avec des tables d'index, je sais pas comment ca marche en opengl mais ca passe par les extensions
d'une manieres générale quand on veut faire du serieux en opengl, on doit passer par les extensions, et ca je trouve que c'est un gros defauts par rapport a dx, ou au moins tu es sur de n'avoir aucun probleme si la carte est compatible avec la version de dx que tu utilise
20 oct. 2004 à 16:58
Mais tu sais je disais ca en rigolant; de toute facon moi je vais en faire un (moteur de particules) incessamment pour Sniper.
Ya un bout de tps une source la-dessus avait été postée par..euh ben je sé plus en plus je l'ai jetée :( mais qques recherches et ca sera bon
Tu as PainKiller? réponds moi ca m'intéresse (si,si)
Et ,enfin,je te dirais que je me serais douté, sans que tu me le dises, que tu n'as pas de classe camera dans un jeu 2d :))
Suis en train de télécharger la src...les 140Ko, sur le T1 du lycée, je les avait pas vu passer ;) pourquoi le screenshot ne correspond pas aux progs?
En tout cas, ca rame meme sur mon PC (1.4GHz), c'est dire...
++
20 oct. 2004 à 16:10
Si j'ai le vecteur, c'est juste un peu de géométrie analytique / vectorielle, je pense que ça ira aisément, mais il me faut ce vecteur ... et ça j'ai pas ^^
(bon, en même temps, je travaille le plus souvent en 2D, à cause de mon RPG, donc forcément je n'ai jamais réellement réfléchi à une classe Caméra. J'imagine que si j'en écrivais une bien fichue, elle permettrais de récupérer ce vecteur crucial)
Pour la lenteur, suis bien d'accord avec toi que c'est pas glorieux.... j'imagine qu'il serait bien senti de créer une display list pour les particules. (en fait, ça devrait accélérer monstrueusement, ^^)
Je vais profiter du message pour rajouter quelques petites choses (je mets au pluriel, on verra si je dis plusieurs choses ^^)
- J'avais initialement désiré coder l'Engine de sorte que l'origine du repère Ecran soti en bas à gauche, et que dès lors l'axe Y monte au lieu de descendre, ce que je pensais être habituel (car j'avais tjs vu ça, et j'utilise ça pr mon rpg justement). J'ai appris plus tard, lors d'un concours de Coder-Studio.com (puub ^^) que sous OpenGL, en 2D, bcp de gens demandent à OpenGL directement d'avoir un repère avec origine en bas à gauche... du coup mon système inversait ça aussi, et c'est profondément idiot, d'autant plus que si on code un jeu on connaît les coordonnées écran des sprites etc... et on ne devrait pas avoir besoin d'inverser les coordonnées verticales pour retomber sur la correspondance avec l'autre repère! Ce que je veux dire en définitive, c'est qu'il faudrait que je récrive une partie du code de sorte que le système d'axes pris en compte soit celui du programme hôte. De cette façon, des gens intéressés (et moi le premier ^^) pourront l'implémenter selon leur bonne volonté dans leur programme.
- autre chose: mais c'est bourré de fautes ma description! lol, je vais en corriger qq unes (= je vais en oublier, dc je ne prétend pas tt corriger :p)
20 oct. 2004 à 09:15
PS:l'ordi du lycée rame un peu..genre...10FPS?!!pour un petit truc comme ca, doit y avoir un sacré nbre de particule.
Bon, maintenant tu nous fait la meme chose en 3D, comme dans painkiller (^^)
13 sept. 2004 à 01:08
en effet dans ma petite tête,une texture était toujours associée a un fichier image,voir un fichier vidéo (qui n'est c'est vrai qu'une suite d'images) et non a une formule mathématique.
C'est plus clair maintenant.
J'ai mis aussi 10/10,même si pour l'instant je n'arrive pas a compiler.
12 sept. 2004 à 10:56
quant à la texture, il s'agit d'un disque dont les bords sont plus transparents que le centre. comme c'est une forme géométrique simple, il est plus facile (et plus efficace même) de générer la texture grâce à une formule que de stocker la dite formule dans un fichier qu'il faut trimbaler avec la classe! si tu préfères utiliser une étoile complexe, tu peux tt aussi bien attacher une texture bien à toi à la classe, aucun problème.
une texture, c'est simplement (comme une image d'ailleurs) un tableau de données. si tu simules une image en couleurs réelles avec couche alpha, ça te fait 4 octets par pixel. si tu veux générer une texture de 16*16 pixels, ça te fait un tableau de 16*16*4 pixels à allouer, et puis grâce à la formule tu donne la couleur et l'alpha désiré à chaque pixel correspondant à l'image finale dans le tableau. une fois que c'est fait, tu envoies le tableau à OpenGL qui t'en fait une texture.
12 sept. 2004 à 10:07
De plus j'ai toujours un problème avec l'include windows.h
chez moi il ne compile pas directement.
31 août 2004 à 19:35
31 août 2004 à 18:12
24 août 2004 à 14:51
- voitures qui fument
- poussière
et ça c'est que les 2 1ères idées qui me viennent.
bon boulot, TRES UTILE, et sur devcpp, que demander de plus ?
5 juil. 2004 à 21:00
moi je voulait te faire plaisir et la .... oki pas grave
5 juil. 2004 à 20:49
5 juil. 2004 à 16:27
see you
5 juil. 2004 à 02:03
27 juin 2004 à 12:31
27 juin 2004 à 12:30
27 juin 2004 à 00:19
26 juin 2004 à 23:27
26 juin 2004 à 22:47
je reviend j'etait partie a une fete et la je vein pour rammener quelque CD lol :
See you
N 105 lol
26 juin 2004 à 21:21
fin remarque, je dis qu'il passe jamais... c'est surtout parce qu'il est adepte des techno microsoft.
26 juin 2004 à 20:32
26 juin 2004 à 19:27
26 juin 2004 à 19:21
26 juin 2004 à 19:16
Et non msn n'est pas chiant il suffit d'eviter les contacts un peu boulets... Perso j'ai rarement plus de 10 gars connectés en meme tps! Et (presque) pas de mec lourd :)
26 juin 2004 à 19:14
26 juin 2004 à 19:13
26 juin 2004 à 17:48
note: discussions de deux grands bavard (et ouééé) Kirua et xarier ;)
26 juin 2004 à 17:30
sinon t'm vraiment les couleurs flash ? le BG devient bleu !
J'dois avoué que lorsque tu as sorti ta source, je pensais que www.winmfx.fr.fm était un site professionnel ! en tout cas il est réussi !
26 juin 2004 à 17:13
dit les mec vous avez vue mon site que j'ai creé hier pour mon prog WinMFX www.winmfx.fr.fm ( un peu de pun )
26 juin 2004 à 17:10
26 juin 2004 à 17:06
voila ce forum va devenir le plus visité par le monde des programmeur lol
aller les mec en continu : (pour faire de ce forum le plus visité par cppfrance :) ) HE kIRUA C KOI TON avi
Lol
26 juin 2004 à 16:58
Pour Kirua, j'pense qu'il n'aime pas écrire "com sa" chose fréquente sur les chats ...
26 juin 2004 à 16:53
Kirua --> par amour pour la langue française ?
26 juin 2004 à 16:48
26 juin 2004 à 16:47
26 juin 2004 à 16:42
26 juin 2004 à 16:22
26 juin 2004 à 00:55
25 juin 2004 à 17:57
25 juin 2004 à 17:52
25 juin 2004 à 17:32
(J'aime bien jouer les mecs chiants :p surtout que mon post n'a pas plus de rapport avec ta source que le tien ^^)
25 juin 2004 à 17:22
25 juin 2004 à 13:33
allez 10/10 !
23 juin 2004 à 00:37
23 juin 2004 à 00:34
Mais à part Particule2D_trainee.exe, ça rame bien sur mon PC :'(
22 juin 2004 à 15:09
Zouli ton screen :) Je m'occupe des couleurs, mais ce soir je fait un réseau donc si j'ai pas le tps de te le finir ça attendra demain :)
22 juin 2004 à 14:37
Si dans le zip l'exe principal (Particle2D.exe) n'affiche pas la même chose que dans le screenshot de mon commentaire précédent, c'est que vous n'avez pas le nouveau zip. Vous pouvez aussi le voir au code source si vous n'être pas sous win: dans CParticle.h, les deux constructeurs doivent être devenus ceux-ci:
CParticle(float MinMort, float MaxMort);
CParticle(float MinMort, float MaxMort, int AngleMin, int AngleMax, int VMin, int VMax, CVecteur2D Pos);
22 juin 2004 à 14:29
- mortalité paramétrable
- accélération paramétrable
on voit en effet l'apparition de lignes sur lesquelles les particules ne passent jamais, c'est embêtant :(
laissez-moi 4 min pr mettre le zip à jour
22 juin 2004 à 13:34
le facteur vitesse est à 1.0f par défaut, comme ça, aucun effet. le mettre à plus que 1 accélère la particule (effet contraire aux frottements cinétiques) et le mettre à moins de 1 (mais plus que 0) crée un effet de frottement cinétique justement.
c'est quoi l'histoire de flux? pr la mortalité, je suis bien d'accord qu'il faut la rendre paramétrable. je vais coder l'accélération mtnt, occupe toi des couleurs plutôt ;) tu vas créer une palette 256?
eh, l'effet de facteur vitesse, il est activé depuis le premier post de la source, t'avais pas vu?
22 juin 2004 à 13:29
Pour le facteur vitesse c'est pas idiot faut voir les resultats... En tout cas le laisser en option!
En tout cas bravo pour tes exams ;) Et content de te voir libre ;)
22 juin 2004 à 13:10
j'ai un secret à vous confier ...
<whisper>
je suis en vacances
</whisper>
J'ai passé mon examen de français avec brio ^^ (mention Très Bien), et mtnt je suis libre.
J'ai lu tous tes comments Wett, merci de t'être intéressé à mon code, ça me donne l'impression qu'il était assez propre :p L'idée de l'accélération est bienvenue, c'est d'ailleurs un grand classique des moteurs de particules. Les particules n'ayant pas de masse, je m'étais dit qu'une simulation de gravitation serait une insulte à Newton, mais il est mort: l'effet sur tes screens est franchement chouette! La manière dont tu l'as implémenté ne me satisfait paaaas tout à fait, comme j'ai déjà dit: hors de question de rajouter des propriétés à CParticle, pas de place pour ça. Je préfère de loin donner soit un vecteur Acceleration à CParticleEngine. Le générer aléatoirement entre deux bornes n'est pas une option, puisqu'il faut que le vecteur soit le même pour une particule à chaque instant (aaah, dé-rîves enchantées (suis allé à la mer hier)). Le mouvement de la particule sera de tte façon bien différent en fct de sa vitesse (vectorielle) de départ, pas de panique.
En fait, le "facteur vitesse" devait rendre un effet de frottement dans l'air (réduction/croissance du module de la vitesse, mais conservation de la direction), avec l'accélération, ça va faire de plus en plus vrai ^^
j'ai un peu de temps dans une heure ou deux, et après j'vais m'hydrater toute la nuit.
21 juin 2004 à 16:53
21 juin 2004 à 15:30
21 juin 2004 à 14:45
21 juin 2004 à 03:24
un autre rendu style jet d'eau que j'aime bien, toujours rien d'extraordinaire mais bon :)
Engine3.SetFourchetteAngles(40, 60);
Engine3.Accely = -2;
Engine3.SetFourchetteVitesse(15, 20);
Engine3.Rayon = 8;
Engine3.Lieu.Type = liPoint;
Engine3.Lieu.SetPoint(400, 335);
Engine3.Couleur = CParticleEngine::clrEnergieBleue;
Engine3.CreerParticules(NbPart3);
Pour un petit apercu, http://perso.wanadoo.fr/wett/images/screen2.jpg
21 juin 2004 à 03:07
Alors j'ai commencé à rajouter (c'est sale mais ça marche) une gestion d'accélération (gravité...) Et franchement ça rend bien! :)
Néanmoins quelques limitations : Il faudrait prévoir de laisser choisir la marge de mortalité des particules (hyper important pour une fontaine, moi comme j'ai fait il faut attendre qlq secondes avant d'avoir qlq chose de fluide et bien réparti) ou alors de ne pas toutes les créer au meme moment (genre donner un nombre max à ne pas depasser et un flux = le nb de particules lancées par seconde)
Encore autre chose : pour ta classe vecteur, passer en float au lieu de int, c'est vraiment trop visible, perso je vois des rangées de particules... Bon qlq part en tout cas y'a des int à passer en float, pas forcément dans la classe vecteur à bien y réfléchir...
Bref voila ce que ça donne :
http://perso.wanadoo.fr/wett/images/screen1.jpg
Les modifs sont simples, que des ajouts ou qlq modifs:
*CParticle.h
CParticle(int AngleMin, int AngleMax, int VMin, int VMax, int Accelx, int Accely, CVecteur2D Pos);
CVecteur2D Acceleration;
*CParticle.cpp
Dans CParticle::CParticle( etc )
Acceleration.X = Accelx;
Acceleration.Y = Accely;
Dans void CParticle::Deplacer()
Vitesse += Acceleration;
*CParticleEngine.h
int Accelx, Accely;
*CParticuleEngine.cpp
Dans void CParticleEngine::CreerParticules(int nb)
Particules[i] = CParticle(AngleMin, AngleMax, VMin, VMax, Accelx, Accely, Lieu.GetCouple());
Et bien sur dans main.cpp, on désactive les 2 premiers engine et le 3e:
Engine3.SetFourchetteAngles(-10, 10);
Engine3.Accely = -1;
Engine3.SetFourchetteVitesse(-10, 10);
Engine3.Rayon = 8;
Engine3.Lieu.Type = liPlaquette;
Engine3.Lieu.SetCoinsRect(350, 250, 100, 0);
Engine3.Couleur = CParticleEngine::clrEnergieBleue;
Engine3.CreerParticules(NbPart3);
Sans oublier les qlq modifs pour pas lagguer ;)
Voila je crois n'avoir rien oublié, sinon bah vous voyez surement ou je veux en venir et vous modifiez en conséquence :)
Encore merci kirua pour cette source! A+ et bonne prog
21 juin 2004 à 01:23
Alors maintenant je sais pourquoi tu laissais la texture en 256x256...
CParticleEngine.cpp ligne 108 tu mettais
GLuint dist = (unsigned)hypot(float(i - (texHeight / 2)),float(j - (texWidth / 2)));
Alors forcément qd la texture était pas en 256x256 ben le calcul était faux...
On remplace par
GLuint dist = (unsigned)hypot(float(i - (texHeight / 2))*256.0f/texHeight,float(j - (texWidth / 2))*256.0f/texWidth);
Et hop, on met la texture en 16x16, on a strictement le meme resultat graphique, et des perfs... 10x supérieures??? Je sais pas j'ai pas d'affichage du fps mais c'est bien plus que flagrant... Ce que je sais c'est qu'en mettant 20 000 à chaque systeme, sur ma geforce4Mx, ben je dois tourner dans les 20fps...
lool pardon je me fait plaisir mais ça me troublait depuis un bout de temps que pour un dessin si petit, une texture si grosse soit necessaire, alors maintenant que je peux compiler...
19 juin 2004 à 09:39
18 juin 2004 à 22:56
...
à 30 FPS ça fait bcp de fois par 2 secondes :/
18 juin 2004 à 22:52
j'ai pu exactement le graphique de fonctionnement du moteur graphique OpenGL mais changer les etats sans arret ralenti le fonctionnement donc vau mieux les changer qu'au bon moment et pas toutes les 2sec...
18 juin 2004 à 20:43
18 juin 2004 à 19:50
là j'ai codé mon premier algo pour n reines, temps de programmation < 1h.
18 juin 2004 à 19:33
Mais le truc de Funto marche aussi très bien, c est dailleurs ce qu il est conseillé de faire dans la plupart des cas, cad ceux ou tu sais ce que tu modifie. GL_ALL_ATTRIB_BITS, c est la solution du flemmand (Oui je l utilise ? et alors ?) car ca evite davoir a chercher quels etats tu modifie pour ne pas les alterer.
Ca evite de modifier definitivement les etats d opengl, alors que tu n en as besoin que pour une portion de ton code.
Chuis sur que j ai du dire plusieurs fois la meme chose, mais j ai un peu la flemme de relire la ... =)
17 juin 2004 à 23:57
examen de latin demain (enfin, presque ajd), je go :/
17 juin 2004 à 23:50
Mais exactement, comment l'utiliser, ben j'ai pas le bouquin sur moi et j'ai la flemme de le chercher lol.
Pour les appels à glEnable()/glDisable(), je ne pense pas que ça soit vraiment coûteux (comme tu dis, à mon avis ce sont des flags) mais je n'en suis pas sûr du tout.
En fait, plutôt que d'utiliser push/pop attrib, tu pourrais aussi faire un truc du genre :
GLboolean texture_enabled = glIsEnabled(GL_TEXTURE_2D);
glDisable(GL_TEXTURE_2D);
if(texture_enabled) glEnable(GL_TEXTURE_2D);
(je sais pas du tout si ce que je viens d'écrire est compilable).
17 juin 2004 à 12:19
ya
* utiliser des listes d'affichage (bon la ct po possible bien que...)
* utiliser des tableau de points (pareil encore pour faire un carré c po nécessaire bien que...)
* penser à changer les états une fois pour toutes, ou tout du moins un minimum de fois : cad a dire eviter de les mettres dans une boucle
* générer les textures de facon aproprié : ici gl8linear sert pas a grand chose, fau mettre gl_nearest
* utiliser push et pop au lieu de faire des rotation ou translation supplémentaires, et surtout utiliser les opérations matricielle de opengl (gltranslate etc...) car elles seront bcp plus optimisées que toutes celle que tu pourras faire
parce que la faut qd meme une grosse carte graphique pour des effets qui sont pourtant tres basiques ;)
pour ce qui est des new et delete, ca n'apelle pa de constructeur pour les types de base comme les int, double etc....
par contre apres fau savoir ce qu'on veut...si on fait du C++ on utilise des new et delete po malloc (a part dans certain constructeur pour des utilisations bien particulieres) ou alors on fait du C
16 juin 2004 à 20:32
j'ai jamais mis de glEnable dans une boucle, c'est déjà ça :p quoiqu'au final, le programme étant une boucle, ça revient à ça aussi, mais en moins con ^^.
16 juin 2004 à 19:57
for (....)
{
glBegin (...)
}
et mettre plutot
glBegin (..);
for (...)
{
}
car a chaque fois que tu passe dans ta boucle tu demande de faire qqch qui ne sert a rien (sil te plait la CG, mets moi les blending dans son état actuel ...), ce qui est forcément couteux.
16 juin 2004 à 18:51
Pour les glPushAttrib tu as parfaitement raison. J'ai compris à quoi ça servait en lisant quelques codes, mais comme je n'étais pas absolument certain du fonctionnement, je ne l'ai pas implémenté. D'ailleurs je devrais généraliser l'usage de cette fonction! Est-ce que tu pourrais me donner un mot d'explication sur ces fonctions, et aussi (si tu sais) me dire si ces appels répétés à glEnable/glDisable sont couteux, où si ils ne font que modifier des flags (bool) ?
Xarier, tu as su compiler alors?
16 juin 2004 à 18:35
Mais apres que je l'ai lue j'ai changer l'image 256/256 par 32/32
et ca merche meiux :)
16 juin 2004 à 18:16
Au sujet de malloc()/free() vs new[]/delete[] en fait la principale différence c'est que new[]/delete[] appellent le constructeur de chaque objet alloué, C++ oblige.
Donc, quand on alloue des GLubyte comme dans ce cas, en toute logique new[] les initialisera à 0 (c'est ce que fait le constructeur par défaut non?) alors qu'on n'en a pas besoin -> garde les malloc()/free().
Arrêtez-moi si j'ai (encore...) dit une connerie, je ne suis pas sûr du tout de ce que j'avance mais c'est ce il me semble que c'est ça...
Ah oui aussi; y'a un glDisable(GL_TEXTURE_2D); à la fin de CParticleEngine::Dessiner() ; ça pourra conduire un gars qui veut utiliser le moteur de particules et qui n'aura pas lu le code à se demander pourquoi sa *** de texture ne veut pas s'afficher...
Le mieux dans ce cas-là c'est d'utiliser glPushAttrib()/glPopAttrib().
16 juin 2004 à 16:03
ta mon mail ta msn alors ..fill le moi please :)
16 juin 2004 à 15:18
ts vos ordinateurs st excellents, si mon moteur est lent sur ces ordis, c'est la faute du programmeur qui est un incapable, ça c'est du certain ;-)
16 juin 2004 à 14:53
16 juin 2004 à 14:43
16 juin 2004 à 14:22
16 juin 2004 à 14:19
j'ai un p4 1.60 GHz 520 mo ram .
Merci
16 juin 2004 à 14:12
bien entendu 2 triangles = un carré (ou rectangle ou paralelogramme)
pour ce qui est de allocation en effet c assez lent c pourquoi fau faire ses allocation au tout début quitte à prevoir l'espace que tu devras allouer
de maniere générales tous les calculs lourds qui n'ont pas besoin d'etre dynamique ou qui peuvent etre précalculé doivent etre fait au debut quitte a perdre un peu d'espace ram pour plus de rapidité dans l'exécution.
sinon c vrai que le moteur est assez bleuffant, le rendu est vraiment tres beau.
mais chez moi c po tres rapide donc reste à optimisez tout ca.
parce qu'avec 6500 particules pour les 2 premiers et 2000 pour le 3e ca rame un peu
et pourtant j'ai une GF2 1600+ qui supporte parfaitement UT2004 ou warcraft iii ;)
16 juin 2004 à 11:54
That opens another whole can of worms: memory allocators. Do you know how malloc works? The nature of malloc is that it has a long linked list of available blocks of memory called the free chain. When you call malloc, it walks the linked list looking for a block of memory that is big enough for your request. Then it cuts that block into two blocks -- one the size you asked for, the other with the extra bytes, and gives you the block you asked for, and puts the leftover block (if any) back into the linked list. When you call free, it adds the block you freed onto the free chain. Eventually, the free chain gets chopped up into little pieces and you ask for a big piece and there are no big pieces available the size you want. So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. The end result of all this mess is that the performance characteristic of malloc is that it's never very fast (it always walks the free chain), and sometimes, unpredictably, it's shockingly slow while it cleans up. (This is, incidentally, the same performance characteristic of garbage collected systems, surprise surprise, so all the claims people make about how garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)
Smart programmers minimize the potential distruption of malloc by always allocating blocks of memory that are powers of 2 in size. You know, 4 bytes, 8 bytes, 16 bytes, 18446744073709551616 bytes, etc. For reasons that should be intuitive to anyone who plays with Lego, this minimizes the amount of weird fragmentation that goes on in the free chain. Although it may seem like this wastes space, it is also easy to see how it never wastes more than 50% of the space. So your program uses no more than twice as much memory as it needs to, which is not that big a deal.
16 juin 2004 à 11:49
le truc de l'opéro new qui est lent, j'ai pas trouvé ça tout seul, c'était dans un document sur les optimisations à prendre en compte en C++, tout spécialement en ce qui concerne les chaînes de caractères (qui sont dég. en C/C++ ;))
http://www.joelonsoftware.com/articles/fog0000000319.html
ça vaut vrmnt le coup de le lire en entier
16 juin 2004 à 11:33
16 juin 2004 à 11:30
Jtaurai toi à la première gaffe :D
16 juin 2004 à 11:24
16 juin 2004 à 11:23
Vous avez tout les deux raisons et Kirua a un excellent argument que je ne connaissais pas :D Pour le HDD, je me suis emmelé les pinceaux et pensais à la RAM (mais une fois que j'ai dis HDD je suis partis dedans :'( )
merci, je m'en vais, tête baissée, programmer un moteur en DX :D
cordialement
16 juin 2004 à 11:20
16 juin 2004 à 11:18
16 juin 2004 à 11:12
Sinon, je vois pas trop pourquoi vous vous prenez la tête avec des 120Ko, 10Ko, etc... : je vous rappel qu'un jeu (2D qui plus est) doit être 100% orienté vitesse : donc vaut mieux stocker quelques données pour gagner quelques fps (multipliés par le nombre de particules) que quelques kilo.. A moins que vous soyez restés à l'époque des HDD de 3Mo : Ce ne sont pas quelques centaines de kilo qui vont surcharger un HDD d'une 50aine de gigas (Les nouveaux jeux se fichent de leur consommation en place : ils veulent juste aller vite : quake3, ut2k4..) !
cordialement
16 juin 2004 à 10:59
16 juin 2004 à 10:53
Sinon c'est dommage que tout soit en 2D pure meme si je comprends que ça te simplifie grandement la tache... Je verrais si je peux pas trafiquer un peu ça des que j'aurais à nouveau acces à internet depuis mon pc ;) idem pour les couleurs ^^
16 juin 2004 à 07:59
Salut Xs. Ton effet esxt OK pour un petit flambeau ou qqch du genre, en effet, faudra que je pense à le mettre dans les donjons :p
Si tu veux convertir le code pour DirectX, c'est vraiment, vraiment easy. Tu ne dois changer que la méthode de Dessiner de CParticleEngine ainsi que la fonction GenerateTexte. C'est tout!
Je dessine en fait 4 triangles qui forment un carré. J'ai lu que c'était "mieux", et en général je fais confiance ;-)
16 juin 2004 à 00:25
16 juin 2004 à 00:24
16 juin 2004 à 00:10
Si tu veux t'en servir dans un ptit rpg 2D, j'ai trouvé ca (c'est a peu prêt comme ca que je m'en servirai dans le mien) :
Engine3.SetFourchetteAngles(80, 100);
Engine3.SetFourchetteVitesse(4, 15);
Engine3.Rayon = 8;
Engine3.Lieu.Type = liPoint;
Engine3.Lieu.SetPoint(400, 335);
Engine3.FacteurVitesse = 0.95;
Engine3.Couleur = CParticleEngine::clrFeu;
Engine3.CreerParticules(50);
50 particules seulement pour un truc assez sympa.
Sinon, je suis pas habitué à l'openGL (je fais du DX9) donc je me pose une qustion : tes particules, ce sont bien des triangles ? Je veux dire, qu'est ce que tu dessines ? Un carré ou un triangle ? ou autre chose ?
merci
15 juin 2004 à 23:47
Je veux dire, plutôt que de donner un ID de texture arbitraire à chaque CParticuleEngine, d'autant plus que cet ID est le même pour tous, je verrai la chose comme ça :
- un membre de CParticleEngine : static GLuint IdTexture;
- à l'appel du constructeur de CParticuleEngine :
static bool PremierPassage= true;
if(PremierPassage)
{
glGenTextures(1, &IdTexture); // Evite d'utiliser un ID arbitraire; par contre dans tout le programme faudra utiliser des glGenTextures au lieu d'IDs arbitraires, ce qui est beaucoup plus clair et fiable.
// ICI : génération de la texture...
PremierPassage = false;
}
- la méthode CParticuleEngine::Dessiner() utilise IdTexture.
15 juin 2004 à 21:03
j'ai changé ça:
float color = 255-(dist*1.8);
en ça:
float color = 255-(dist*1.8*(256./texWidth));
//---------------------------------------------------------------
void CParticleEngine::GenerateTexture(int id)
{
int texWidth = 64;
int texHeight = 64;
GLubyte *texPixels, *p;
int texSize;
int i, j;
int radius;
texSize = texWidth*texHeight*4*sizeof(GLubyte);
texPixels = (GLubyte *) malloc(texSize);
if (texPixels == NULL)
return;
p = texPixels;
for (i=0; i<texHeight; ++i)
{
for (j=0; j<texWidth; ++j)
{
GLuint dist = (unsigned)hypot(float(i - (texHeight / 2)),float(j - (texWidth / 2)));
float color = 255-(dist*1.8*(256./texWidth));
if (color < 0) color = 0;
p[0] = (char)color;
p[1] = (char)color;
p[2] = (char)color;
p[3] = (char)color;
p+=4;
}
}
glBindTexture (GL_TEXTURE_2D, id);
//glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
//glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glTexImage2D(GL_TEXTURE_2D, 0, 3, texWidth, texHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, texPixels);
free(texPixels);
TextureID = id;
}
//-------------------------------------------------------------
15 juin 2004 à 20:55
15 juin 2004 à 20:55
pour le timer, je l'ai vrmnt écrit en 4 secondes ;) c'était seulement pour l'application de démo (et de test). dans mon rpg, ce sera le timer du jeu qui fera la loi, et dans vos applications (éventuellement), ce sera le vôtre, pas de souci.
pour les triangles, j'ai suivi un conseil sur un site qui disait que les triangles étaient plus rapides à dessiner qu'un rectangle (même 4 triangles dans ce cas-ci! étonnant non?).
quant à la texture, c'est un des points à changer en effet.
15 juin 2004 à 20:49
J'ai regardé la source. Si tu mets le rayon (taille de particule) en valeur aléatoire comprise dans une fourchette et si la texture au lieu de rond , tu mets en ovale comme suit:
GLuint dist = (unsigned)hypot(float(i-(texHeight/2)),float(j-(texWidth)/2))*2.0); l'effet sera plus réel.
Aussi, gère independamment le timer.
Dans la texture un 64x64 sera suffit ,meme 32x32 ,car le particule est petit, là tu perds quelque ms en utilisant 256x256.
A part celà c'est très bien.
J'ai remarqué aussi la presence de glBegin(GL_TRIANGLE_STRIP) dans le boucle for(...), tu peut mettre cela en dehors du boucle en remplaçant par (gl_Begin(GL_QUADS)) et changer le 4e glTexCoord en 3e. On gagne aussi quelque ms. Voilà , bonne prog!
15 juin 2004 à 20:35
tu n'as pas mis longtemps à sortir ta "petite" source que j'attendais :]
15 juin 2004 à 17:41
Le moteur est 2D complètement, donc pour l'adapter à de la 3D, faudrait du travail, à commencer par récrire une classe CVecteur3D et à remplacer tous les calculs de position (récrire Lieu et ses paramètres aussi...).
C'est vrai que la mortalité c'est le seul truc que j'ai pas rendu paramétrable, je devrais changer ça (juste quelques lignes mais dans plusieurs classes). Faut d'ailleurs aussi récrire la génération de texture.
Le mouvement de caméra, ben c'est en 2D, y a pas moyen ;-) mais si tu déplaces le lieu du système, les particules mortes renaissent toujours dans le nouveau lieu, ce qui permet les effets de trainées, puisque les particules en vie continuent de se mouvoir selon leur mvmt originel, indépendemment du déplacement du système. Tu pourras aussi simplement faire des transitions d'un point à un cercle puis d'un cercle à une droite, le tout en changeant les couleurs, ce serait simple à coder.
Pour les variations de couleurs d'ailleurs, c'est une idée... pas long à coder non plus mais il y a un problème: une particule ponctuelle doit garder la même couleur tout le temps, donc il faudrait donner une propriété Couleur à chaque particule (SRVB = 3*4 octets). Pour 10 000 particules ça fait 120 Ko de plus... c'est trop coûteux je trouve. A nouveau, c'est vrmt trivial à coder, donc si ça amuse qq un :)
Quant au mvmt des particules, m'étais demandé d'abord: est-ce que je dois gérer la gravitation? -> c'est tt léger, ça n'a "pas" de masse, donc non. Donc, il s'agira d'un mvmt rectiligne uniforme? pas vrmnt, elles sont quand même freinées par leur milieu... donc j'ai opté (sur conseil d'un tuto ;-)) pour l'option suivante: à chaque déplacement, je me contente de multiplier le vecteur vitesse (pas accélération!) par le scalaire FacteurVitesse (ce qui aura pour effet de modifier le module de la vitesse et donc la valeur scalaire de la vitesse) et ensuite j'additionne le vecteur vitesse au vecteur position de la particule, ce qui a pour effet de bien déplacer la particule dans le sens et la direction du vecteur vitesse.
Les composantes du vecteur, par trigonométrie élémentaire, sont calculées selon les sinus et cosinus de l'angle (cf. Cercle Trigonométrique) et le module, ben c'est du Pythagore :)
PS: si vous avez la possibilité de compielr chez vous, essayez de remplacer dans le code "main_trainee.cpp" le code d'initialisation de l'engine3 (la boule qui se déplace) par ça:
Engine3.SetFourchetteAngles(360-40, 0+40);
Engine3.SetFourchetteVitesse(4, 25);
Engine3.Rayon = 8;
Engine3.Lieu.Type = liPoint;
Engine3.Lieu.SetPoint(100, 335);
Engine3.FacteurVitesse = 0.95;
Engine3.Couleur = CParticleEngine::clrFeu; //CParticleEngine::clrNauseabond;
Engine3.CreerParticules(NbPart3);
ça fait un jet amusant ^^
15 juin 2004 à 17:22
Je viens de voir qu'une particule est gérée à l'aide de vecteurs, mais dans ta classe moteur c'est avec des angles... O_o plutot space comme truc... encore que non c'est pas idiot tu peux donner une fourchette et c'est bien mieux!
Simple question (pas trop le temps d'étudier ta source) le moteur est 2D ou 3D? On peut gérer un mouvement de caméra? Je pense à un exemple simple : une chute d'eau (vitesse initiale horizontale, acceleration verticale, couleur bleue-blanche (tu devrais mettre aussi des plages de couleur, genre possibilité de melanger selon des proportions + ou - alétoires plusieurs couleurs) ) ensuite on pourrait tourner autour, etc. Et donc l'intégrer dans un vrai moteur 3D! Meme en 2D ça peut toujours servir...
Tu devrais aussir permettre de gérer la mortalité de tes particules de differentes manières : pourcentage de mort à chaque secondes (genre la radioactivité), distance du point initial, temps etc... Que le tout soit paramétrable et bien sur soit tout de meme plus ou moins aléatoire comme tu t'es attaché à la faire jusqu'à présent...
Bon voila un peu à court d'idée là mais j'espere que ça t'aidera... Et en fait meme apres avoir regardé ta source je comprends pas bien comment tu gere la vitesse et l'accéleration d'une particule... Un mélange d'angles et de vecteurs ok je comprends mais... La vitesse ET l'accélération ont un angle bien distinct? Je repense toujours à mon exemple de chute d'eau : c'est réalisable? Désolé de poser des questions bêtes je peux pas compiler d'ici sinon j'aurais bien essayé voir ce que je pouvais faire ;)
a+ et encore bravo!
15 juin 2004 à 17:10
15 juin 2004 à 17:03
car il avait deja 10 + 8 / 2 = 9 mais c pas grave je vais faire en sorte que sa augmente regarde now
Kiruna mirite un 10/10 et je vais faire en sorte qu'il a
15 juin 2004 à 17:03
car il avait deja 10 + 8 / 2 = 9 mais c pas grave je vais faire en sorte que sa augmente regarde now
Kiruna mirite un 10/10 et ca va rester
15 juin 2004 à 16:49
15 juin 2004 à 16:19
15 juin 2004 à 15:37
15 juin 2004 à 15:30
15 juin 2004 à 15:03
je me demande juste ce que ça va faire ces grosses boules d'énergies dans les mains de mes sprites en 2D bien plate sur fond 2D bien plat ...
15 juin 2004 à 14:58
Bon c'est sûr je pense pas que ton RPG ressemblera niveaux graphismes à Final mais bon ça sera un 1er pas :p
15 juin 2004 à 14:44
J'ai recompilé la source en changeant la valeur du timer en 15ms et même avec des nombres de particules 3000, l'effet est plus naturel. Bravo!!!!!!!
15 juin 2004 à 14:25
je savais pas non plus que les libraires <c___> faisaient partie de l'espace de nom std, faudra que je modifie ça.
ben oui je fais référence en RPG Engine, bien entendu ^^ c'est pour ça que je l'ai créé ce moteur de particules, pour faire les effets des combats. Mais ça va faire bizarre ce truc "moderne" avec les graphismes rétro (vieillot? :p) du rpg...
15 juin 2004 à 11:59
15 juin 2004 à 11:58
Pour les casts, en fait, c'est surtout avec l'usage de constantes; 1.0 est un double et 1.0f et un float.
Y'avait aussi des erreurs dûes à l'inclusion de GL/gl.h sans inclusion de windows.h avant (je sais c'est stupide mais Visual C++ veut ça...), et aussi M_PI n'était pas défini dans math.h.
Y'a aussi un truc qui est bizarre, c'est que ça compile impec sur les 2 compilos alors que tu fais des #include <cmath>, #include <cstdio>...etc sans aucun using namespace std...
Je t'envoie le mail avec la version VC++ée.
PS : à un moment dans un commentaire tu fais référence au RPG Engine, je sais pas si c volontaire ou si c un oubli...
15 juin 2004 à 11:02
Funto: pourtant moi Dev m'embête déjà bcp pr que j'exprime les cast littéralement, comprends pas où il t'en a trouvé d'autres ton VC :(
La partie du code de génération de la texture n'est pas de moi, je l'ai extrait d'un code, d'ailleurs je dois encore rajouter les crédits de l'auteur. J'ai juste cherché à l'inclure dans ma classe sans chercher plus loin, je vais modifier ça, en effet c'est un peu idiot. Quant au malloc/free, je trouve ça moche :p je devrasi récrire la fct en fait.
j'adore ce vert ^^ autant que le bleu et le rouge/jaune en fait. Mais si l'animation n'est pas sur un fond noir, ça tue tout l'effet :( :( :(
15 juin 2004 à 10:54
J'ai recompilé sous Visual C++ en supprimant tous lles errors et warnings (y'en avait un paquet :(, mais c'était surtout des histoires de conversions de types implicites ) je t'enverrai ça.
J'ai vu aussi dans ta génération de textures que tu utilisais un filtre GL_LINEAR; vu que les particules sont toutes petites on ne voit aucune différence lorsque l'on filtre en GL_NEAREST, et, chez moi en tous cas, les performances sont bien meilleures.
Extrait de ton code : "texPixels = (GLubyte *) malloc(texSize);" -> et toi qui me reprochais d'utiliser malloc() au lieu de new[]....d'ailleurs dans ce cas l'allocation dynamique n'est pas obligatoire vu que la taille de la texture allouée ne change pas...
Euh...d'ailleurs je viens de m'en rendre compte : si j'ai bien compris, ta texture est appliquée à chaque particule, chacune toute petite. Et ta texture fait 256x256??? C'est énorme !
PS : "//quelques couleurs remarquables qui seront souvent utilisées
static SRVB clrFeu, clrEnergieBleue, clrNauseabond;"
Mdr la couleur clrNauseabond :p
15 juin 2004 à 10:53
Meme si le mien utilise SDL pour le rendu a la place d opengl, les concepts restent les memes ...
15 juin 2004 à 10:37
On peut par dessus ton systeme de gestionnaire de particules imaginer un gestionnaire des gestionnaires. Pour quoi faire ? ben au lieu d avoir
Engine1.Deplacer();
Engine2.Deplacer();
Engine3.Deplacer();
dans ta boucle principale, tu cree un gestionnaire qui n est ni plus ni pour qu une liste des moteur de particules, et qui se chargerait de mettre a jour et afficher les systemes de particules, puis supprimer ceux qui sont morts. Chais pas si je suis clair, mais ca fait un truc comme ca
class PartManager
{
std::list <CParticleEngine*> m_List;
public:
void AddSystem (CParticleEngine* pEngine)
{
m_List.push_back(pEngine);
}
void Update ()
{
// met a jour les systemes, supprime ceux qui sont usagés
}
void Draw ()
{
// dessine les systemes presents
}
};
comme ca tu peut initialiser le manager
PartManager g_Manager;
g_Manager.AddSystem (&Engine1); g_Manager.AddSystem (&Engine2); g_Manager.AddSystem (&Engine3);
puis dans la boucle principale
g_Manager.Update ();
g_Manager.Draw();
Voili voulou :)
15 juin 2004 à 08:50
J'ai rajouté dans le zip un exécutable Win32 Particle2D_trainee.exe pour vous montrer l'effet, et un fichier main_trainee.cpp par lequel il faut remplacer main.cpp si vous voulez compiler cet exemple-là. Les seules modifs apportée au flambeau:
//les particules vont vers l'arrière
Engine3.SetFourchetteAngles(180-40, 180+40);
//le centre du jet commence plus à gauche (100px)
Engine3.Lieu.SetPoint(100, 335);
et dans la boucle principale:
Engine3.Lieu.Param1+=15;
Ce qui déplace le centre du jet de 15 px vers la droite 30 fois par seconde!
15 juin 2004 à 08:43
15 juin 2004 à 00:54
15 juin 2004 à 00:49
14 juin 2004 à 23:39