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

Commentaire de xarier le 15/06/2004 00:49:53

10/10 bravo amigos

Commentaire de Kirua le 15/06/2004 08:43:21

viens d'avr une idée, je la poste ici pour que je m'en souvienne parce que là je peux pas coder. Pour faire une trainée derrière le centre de l'objet, il faut déplacer le point Lieu du moteur de particules, et pas effectuer une translation supplémentaire. Comme ça, les particules ne se déplacent pas avec la translation. (faites pas attention, je me parle tout seul, c'est un post-it ;-))

Commentaire de Cyberboy2054 le 15/06/2004 10:37:17

Trop fort, j adore l effet de trainée :)
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 :)

Commentaire de Funto66 le 15/06/2004 10:54:04

L'effet est magnifique même sur ma carte graphique, même envoûtant des fois lol, bravo ;)

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

Commentaire de Funto66 le 15/06/2004 11:58:45

Moi aussi j'adore ce vert ;)
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...

Commentaire de Kirua le 15/06/2004 14:25:01

je savais pas pour le f après un nombre, je pensais que c'était facultatif, mais sans incidence.
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...

Commentaire de Funto66 le 15/06/2004 14:58:56

Bah de toutes façons ils utilisent bien ça dans Final Fantaisy non?
Bon c'est sûr je pense pas que ton RPG ressemblera niveaux graphismes à Final mais bon ça sera un 1er pas :p

Commentaire de xarier le 15/06/2004 15:30:33

pense tu pas creé un jeu like street fighter et utiliser les particule comme des bull ( Hadouken) ca serait super :)

Commentaire de xarier le 15/06/2004 16:19:28

Alors  tekken Vs Street :) :)

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

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 ca va rester

Commentaire de xarier le 15/06/2004 17:10:25

Bh ca na rien donner He j'ai mi la un 10/10 il ca n a fait aucun effet

Commentaire de Kirua le 15/06/2004 17:41:25

Salut Wett, thx pr le commentaire élaboré ^^

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

Commentaire de gagah1 le 15/06/2004 20:49:08

Salut!
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!

Commentaire de djl le 15/06/2004 20:55:09

exelent ! 10/10

Commentaire de Funto66 le 15/06/2004 23:47:16

Tous les CParticuleEngine utilisent la même texture; ça serait pas mieux de créer son ID en static?
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.

Commentaire de xarier le 16/06/2004 00:24:42

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 Kirua le 16/06/2004 07:59:44

Funto, ton postulat de départ est erroné: tous les CParticleEngine's n'utilisent pas la même texture, et c'est bien pour ça que j'ai opté pour ce système. Ce qui est vrai, c'est que je pourrais avoir un flag qui détermine si la texture a déjà été générée, et j'y ai pensé. Mais on ne veut pas forcément créer la texture! Donc je laisse ça au gestionnaire de CParticleEngine's (je dois lui trouver un nom ;-))

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

Commentaire de Kirua le 16/06/2004 10:59:24

la 3D serait pas plus dure à coder (effectuer la modif mtnt est lourd, mais si depuis le début j'avais tout orienté 3D, ça n'aurait pas été sensiblement plus compliqué). je l'ai fait en 2D parce que mon moteur de jeu est en 2D et que donc, ben pas besoin de 3D ^^

Commentaire de Wett le 16/06/2004 11:18:35

Ici il n'est pas du tout question de HDD ou de sacrifier de la vitesse pour conserver de la mémoire (c'est fini l'époque des 512Ko de ram... On en est conscient t'inquiete!), simplement d'optimisations et d'éviter de bouffer trop de ram pour un simple moteur de particules, qui n'est qu'un supplément dans un moteur et non un programme à lui tout seul... Donc plus il est léger (autant en mémoire qu'en temps machine) mieux c'est!

Commentaire de Xs le 16/06/2004 11:23:43

Arg :D

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

Commentaire de Xs le 16/06/2004 11:30:57

Spa bien de se moquer :'(
Jtaurai toi à la première gaffe  :D

Commentaire de Kirua le 16/06/2004 11:49:47

malheureusement avec Wett on risque de chercher longtemps parce qu'il s'enferme à Lyon. Il sait qu'il dit bcp de bêtises alors il se met ds un endroit où y a que des daubes comme connexions internet, et comme ça il risque pas de se dévoiler... naaah, c bientôt les vacances, tu vas retourner chez toi, pas vrai? on t'aura plus svt :)

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

Commentaire de StanOfSky le 16/06/2004 14:12:03

ouai la fonction la plus rapide est bien triangle_strip donc faire des carré. a noter que les objets 3d sont tres souvent exporté sont un format triangle_strip pour l'optimisation du rendu.
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 ;)

Commentaire de Xs le 16/06/2004 14:22:31

euh chez moi aucuns problémes avec 6500*2 + 2000 particules sur une G4 Ti4200 128Mo, 512 DDR et un 1.1Ghz (AMD TBird)

Commentaire de Wett le 16/06/2004 14:53:02

Là c'est sur, le seul facteur c'est la vitesse brute de la carte graphique qui joue, les effets sont simples et ne demandent pas je pense plus de 16 Mo de ram... Et c'est pas le proco qui prend donc --> CG

Commentaire de xarier le 16/06/2004 16:03:40

non mais please moi j'ai pas le devc++ alors la je ne peut avoir L'image. peut tu le recompiler pour Moi
ta mon mail ta msn alors ..fill le moi please :)

Commentaire de xarier le 16/06/2004 18:35:31

Hoola pardon pour tout a heur car j'avait pas lue la  source.
Mais apres que je l'ai lue  j'ai changer l'image 256/256 par 32/32
et ca merche meiux :)

Commentaire de Cyberboy2054 le 16/06/2004 19:57:05

Ben Opengl c est une machine a état. Ca veut dire qu elle fait toujours la meme chose tant que son etat ne change pas. Et comme ces états sont sur la CG, lui faire appel coute cher ... C est pour quoi vaut mieux eviter
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.

Commentaire de StanOfSky le 17/06/2004 12:19:49

ouai ya des petites techniques pour optimiser un peu les rendu opengl....
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

Commentaire de Kirua le 17/06/2004 23:57:17

l'idée y est. mtnt, je trouverais étonnant si c t tellement couteux que ça que OpenGL n'ai pas ce système "built-in"

examen de latin demain (enfin, presque ajd), je go :/

Commentaire de Kirua le 18/06/2004 19:50:38

c'est très clair, pas de souci, je devrai penser à l'implémenter.
là j'ai codé mon premier algo pour n reines, temps de programmation < 1h.

Commentaire de StanOfSky le 18/06/2004 22:52:19

en fait je parlais pas de glPush/PopAttrib mais de glPush/PopMatrix() puisque je parlai des matrices de transformation 3D (rtanslate, rotate etc...) de meme vau mieux utilisser les opérations matricielle d'OpenGL
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...

Commentaire de eldered le 19/06/2004 09:39:06

Très sympas, beau travail Kirua.

Commentaire de Wett le 21/06/2004 03:07:01

Bon décidemment j'ai décidé de faire mumuse avec ton programme :)
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

Commentaire de Funto66 le 21/06/2004 14:45:45

Yeah, j'attends avec impatience l'update :)

Commentaire de Wett le 21/06/2004 16:53:24

Ben le kirua ça fait qlq jours que je le vois plus du tout... Kirua mon ami ou es-tu? :p

Commentaire de Wett le 22/06/2004 13:29:32

Ouais c'est vrai c'etait idiot de mettre le vecteur acceleration dans CPArticle puisque c'est tjs le meme j'avais pas fait attention... Le mettre dans CParticleEngine suffit puis on update directement à partir de là... Ca se fait aisément ;) Des que j'ai un peu de temps je modifie ça si tu l'as pas fait et je m'occupe de la gestion des couleurs (promis je rajoute que 1 octet par particule, je peux pas faire moins ^^) et de la gestion de flux (qui va permettre un rendu carrément chouette et plus simple d'utilisation dès qu'on gere des particules à longue vie)
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 ;)

Commentaire de Kirua le 22/06/2004 14:29:16

http://nboumal.free.fr/ParticleEngine2DAccelerationRouge.png

- 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

Commentaire de Wett le 22/06/2004 15:09:59

L'histoire de flux, c'est pour eviter un effet que j'ai eu lorsque tu met une mortalité trop faible, tu te retrouve avec 6500 Particules lancées d'un seul coup et puis apres plus rien jusqu'à ce quelle meurent toutes et apres 10 sec à peu près elles sont bien réparties... C'est assez moche au début :) donc en mettant un flux, plutot que de lancer 6500 d'un coup tu en lance par ex 1000 en 1 seconde, mais bien réparties (tu en lance 1000/fps par frame) et là des le debut c'est bien repartit :)
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 :)

Commentaire de xarier le 23/06/2004 00:37:17

meme avi que mon cher ami funto ;-)

Commentaire de Kirua le 25/06/2004 17:22:31

ouééééé, amk t'es pas mort :-D tu vas en france alors ette année??

Commentaire de neo_00110010101 le 25/06/2004 17:52:55

rien qu'à voir le nombre de commentaires ! "seulement" 86 avec celui-là ! c'est énorme !

Commentaire de Funto66 le 26/06/2004 00:55:35

Je pense qu'il l'était déjà avant qd même...;)

Commentaire de xarier le 26/06/2004 16:42:14

DIT Kirua pourquoi tu lance j'ammais ton msn :)

Commentaire de neo_00110010101 le 26/06/2004 16:48:10

xarier >> ben c'est quand même lourd MSN (surtout quand on a 53 contacts...) meu bon (non je ne vais quand même pas les bloquer !)

Commentaire de neo_00110010101 le 26/06/2004 16:58:42

mouais ... (idée méchante inside ! petits plissements des yeux, tête de diable ...) c'est interessant comme technique :]

Pour Kirua, j'pense qu'il n'aime pas écrire "com sa" chose fréquente sur les chats ...

Commentaire de neo_00110010101 le 26/06/2004 17:10:28

ben moi je pense que ........ et puis voilà quoi +1 post ^^

Commentaire de neo_00110010101 le 26/06/2004 17:30:41

"La sources" avec un "s" ?? ^^
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 !

Commentaire de Wett le 26/06/2004 19:13:47

et hop le 98e message... Pour qui le 100e?

Commentaire de Wett le 26/06/2004 19:16:31

POUR MOI LE 100e!! Désolé je suis un gamin mais je me lache un peu...
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 :)

Commentaire de Kirua le 26/06/2004 19:27:27

ça s'apparente quasiment à du mailbombing tout ça! savez que c'est punissable par la loi ;)

Commentaire de Kirua le 26/06/2004 21:21:57

Nix passe jamais par là, et puis y a assez de choses à corriger sur les sites pr qu'il commence à s'occuper du boulot des adminsen plus ;)
fin remarque, je dis qu'il passe jamais... c'est surtout parce qu'il est adepte des techno microsoft.

Commentaire de Wett le 26/06/2004 23:27:34

Heu... Soit.

Commentaire de Kirua le 27/06/2004 12:30:40

dis, exagère pas qd même, c'est pelant d'avoir un mail pour lire ça, on est tous très contents que tu te sois bien amusé, maintenant terminé. et c'est pas la peine de répondre "ok".

Commentaire de pyroflo le 05/07/2004 02:03:38

Je vois que tu ne te reposes toujours pas, très beau résultat, bravo ! :)

Commentaire de Kirua le 05/07/2004 20:49:52

c'est Wett, pas Weet, vala... et puis c'est Kirua, pas Kiruan, et c'est Aquanum.

Commentaire de _Thy_ le 24/08/2004 14:51:39

Un peu lent avec les miliers de particules par défaut sur une tnt2, sinon c'est très joli et je vais m'en servir comme un fou sur le jeu que j'écris (course de bagnoles) :
- 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 ?

Commentaire de Kirua le 31/08/2004 19:35:22

tu pourras pas l'utiliser pr le concours wett :p

Commentaire de Kirua le 12/09/2004 10:56:01

pour le windows.h, je ne sais pas. de tte manière, la fenêtre Win32 est la seulement pr offrir un support direct à la classe, ça marchera tt aussi bien avec glut, sdl, ...

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.

Commentaire de Arnaud16022 le 20/10/2004 09:15:54

bizarre...Kirua se met encore en débutant?

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

Commentaire de Arnaud16022 le 20/10/2004 16:58:05

nan c'est bon, l'orthographe ca va... :D
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...
++

Commentaire de Kirua le 20/10/2004 19:26:10

Arnaud << non, c'est quoi PainKiller? Quant au zip, il y a plusieurs exe normallement, parce que j'avais voulu illustrer plusieurs effets possibles (en déplaçant par exemple le lieu géométrique, ou bien en le modifiant, etc...). Ça me faisait des boules de feu projetées, des trainées de feu etc... c'est ça que tu devras avoir. Par contre pr le ramage... (c'est ds le dico, sisi :p:p) beeeeeh, faudra que je lui joue un sort oui... pas mtnt quoi ^^

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

Commentaire de pyroflo le 20/10/2004 19:33:54

Désolé, il faut lire 1,3Go DDR pour la mémoire vive.

Bon courage pour la suite ;-)

Commentaire de djl le 20/10/2004 20:20:12

les vertex buffers ce sont des tableaux de vertexs (de points 3d ), le fait de gerer les vertex par paquet permet pas mal d'optimisation, par exemple au niveau du transfer par le pont agp, mais surtout c'est comme ca que la carte graphique traite les points (acces sequentiel), ils peuvent etre compilés (non modifiable, ca permet sans doute de les laisser dans les caches du gpu?) mais ca reste tres souple (machine etat)

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)

Commentaire de djl le 20/10/2004 21:25:48

pour les constructeurs de tes objets, pense à initialiser les membres sytematiquement à leur construction, pour eviter les copies inutiles

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

Commentaire de djl le 20/10/2004 22:58:09

pas de probleme, et t'inquitte pas j'avais remarqué ;)

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

Commentaire de djl le 20/10/2004 23:19:51

int i = int(f); // oui, appel du constructeur

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

Commentaire de djl le 20/10/2004 23:34:16

ouai j'ai bien fais de me renseigné sur le coup

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

Commentaire de djl le 21/10/2004 16:41:00

finalement je reviens sur static_cast qui convient pour les types de base, mais pas de pointeur