PARTICLE ENGINE 2D OPENGL DEV-C++ - EFFETS DE FEU ETC [ MOTEUR DE PARTICULES ]

Commentaire de BumpMANN le 14/06/2004 23:39:45

10/10! sans contestes ! Bravo!

Commentaire de BruNews le 15/06/2004 00:54:16 administrateur CS

Kirua, c'est joli tout plein et pour une fois voila un opengl qui daigne tourner chez moi.

Commentaire de Kirua le 15/06/2004 08:50:19

Désolé pour le mail supplémentaire, je viens de coder ça et ça marche! Suis content ^^, ça prend quasi rien comme lignes!

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!

Commentaire de Cyberboy2054 le 15/06/2004 10:53:56

Au passage, si tu code un moteur 2D, on va problablement avoir plein de trucs a se raconter :)
Meme si le mien utilise SDL pour le rendu a la place d opengl, les concepts restent les memes ...

Commentaire de Kirua le 15/06/2004 11:02:27

CyberBoy: C'est une bonne idée, et je fais ça assez souvent quand je code une classe. Si j'en ai l'utilité, je le coderai (faudra juste rajouter une méthode pour savoir si le système est mort). Pas compliqué, mais je pense pas le coder ici. Dans mon moteur de RPG plus tard oui ;)

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 :( :( :(

Commentaire de LordBob le 15/06/2004 11:59:20

c'est tres jolie !!! :)

Commentaire de gagah1 le 15/06/2004 14:44:21

Magnifique effet! 10/10.
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!!!!!!!

Commentaire de Kirua le 15/06/2004 15:03:10

ils utilisent ça dans les final fantasy en 3D, qui n'ont rien de rétro depuis 6 ans ^^ regarde FF7, c'est une pure bombe, et ça date de ...

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 ...

Commentaire de Kirua le 15/06/2004 15:37:02

à part Tekken 3 et DOA 3 j'aime bof les jeux de combat, et puis, c'est pas parce que j'ai l'anim que je vais faire le jeu, ça me paraît rapide comme saut^^ Mais le code source est à toi, tu es libres d'en faire ce que tu veux ;-)

Commentaire de BumpMANN le 15/06/2004 16:49:09

Qui a osé mettre 9? O_o

Commentaire de xarier le 15/06/2004 17:03:53

il ont pas posé 9 mais oui
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

Commentaire de Wett le 15/06/2004 17:22:29

Salut! Comme d'hab, excellente source ;)
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!

Commentaire de neo_00110010101 le 15/06/2004 20:35:26

excellent, magnifique, beau ... comme la note :)

tu n'as pas mis longtemps à sortir ta "petite" source que j'attendais :]

Commentaire de Kirua le 15/06/2004 20:55:06

le rayon des particules, tu suggères qu'une particule ait un rayon fixe généré aléatoirement, ou que le rayon de la particule soit redéfini à chaque frame? parce que dans le premier cas, c'est la même réponse qu'à Wett pr les couleurs: il faut minimiser les données nécessitées par les particules parce qu'il y en a bcp! faut être raisonnable dans la paramétrisation ^^

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.

Commentaire de Kirua le 15/06/2004 21:03:41

Voici le code pour des textures plus petites (j'ai juste dû apporter qq modifs pour qu'il ne faille (mtnt) plus que changer les deux premières lignes pour changer la définition de la texture:

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;
}
//-------------------------------------------------------------

Commentaire de Xs le 16/06/2004 00:10:43

Salut !

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

Commentaire de xarier le 16/06/2004 00:25:31

bh jj'ai pas vue mais la plus part des fois en utilise des carré la aussi je pense qu'il utilisé des carré

Commentaire de Wett le 16/06/2004 10:53:11

Kirua pour les couleurs, il ne faudrait pas conserver les couleurs pour chaque particule, simplement conserver par ex 255 couleurs differentes max et de conserver uniquement l'indice de la couleur dans chaque particule... ça reduit à un octet.. et on se reduit à meme pas 10Ko en plus, ça se tiens je trouve...
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 ^^

Commentaire de Xs le 16/06/2004 11:12:52

Merci pour l'info Kirua mais : 4 triangles pour un carré ? Un carré moi je le divise en 2 triangles non :S ?

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

Commentaire de Kirua le 16/06/2004 11:20:24

les 120 Ko ils vont ds les gencives de la RAM, et c'est pas parce que t'as 1024 Mo de RAM que 120 Ko ça ne représente rien. La fonction new d'allocation mémoire est très lente, elle doit chercher des plages mémoire continues dans la mémoire vive. Si tu cherches un tronçon continu de 120Ko tu risque de plus t'amuser que si tu cherches 4 octets pour stocker ton int. Le résultat il est clair: vitesse d'exécution en chûte. Puis je vois pas le rapport avec un disque dur ^^ si tu stockes ces données ds le DD t'es parti pour la gloire avec ta vitesse d'exécution ;-)

Commentaire de Wett le 16/06/2004 11:24:22

LOOL j'imagine trop le concept : Pour optimiser l'acces à la ram et eviter de trop en bouffer... Privilégiez la mémoire virtuelle!!! ARGGG ou mieux : ils vont nous sortir de la HDDR à debit maxi de.... 50Mo/s!!! la galere... Pardon private joke ^^

Commentaire de Wett le 16/06/2004 11:33:42

je me moquais pas de toi promis ^^ Juste je reprennais le concept parce qu'il se defandait ^^ Et t'inquiete si tu veux m'avoir à la 1ere gaffe tu va pas chercher longtemps ;o)

Commentaire de Kirua le 16/06/2004 11:54:25

L'extrait qui nous intéresse: (url du document, commentaire précédent). ça parle de malloc et free en fait, pas de new et delete, mais je suppose que c'est le même genre de fonctionnement (?)

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.

Commentaire de xarier le 16/06/2004 14:19:58

hi bh la chez moii ca marche vraimment tres lent avec 6500 alors si quelqu'un peu l'optimizer :

j'ai un p4 1.60 GHz 520 mo ram .

Merci

Commentaire de xarier le 16/06/2004 14:43:00

bh ca peut que ca soit ma carte graphique car j'ai une de  32 Mo

Commentaire de Kirua le 16/06/2004 15:18:35

hmm, l'exe du zip est compilé avec la texture à 256*256 pixels. si vous recompilez avec le code que j'ai mis plus haut (je me souviens plus si j'ai modifé le zip avec la màj...) pour passer à une texture 64*64 (32*32 c'est pas très beau), vous aurez des meilleures perf!

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 ;-)

Commentaire de Funto66 le 16/06/2004 18:16:56

J'admet mon erreur (quelques dizaines de posts plus haut lol), je savais pas que tu voulais laisser au programmeur la possibilité d'utiliser une autre texture que celle que produit GenerateTexture().

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().

Commentaire de Kirua le 16/06/2004 18:51:45

les types embarqués du C++ n'ont pas de constructeur, donc si je n'utilise pas GLuint mais unsigned int, je peux utiliser les new[] et delete[] sans perte de performance.

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?

Commentaire de Kirua le 16/06/2004 20:32:42

ok, merci pr l'info.
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 ^^.

Commentaire de Funto66 le 17/06/2004 23:50:15

Pour glPushAttrib()/glPopAttrib() , d'après ce que je me rappelle de "OpenGL 1.2", ça permet de mettre dans une pile des "attributs", en gros une partie de l'état actuel d'OpenGL : des informations relatives à l'éclairage, à la couleur...etc, presque tout quoi.
Mais exactement, comment l'utiliser, ben j'ai pas le bouquin sur moi et j'ai la flemme