Calendrier des nouvelles fonctions

Coucou 4ian,
voilà, je voudrais savoir si tu comptais bientôt ajouter la fonction de masque pour les images
(on en avait parlé, mais c’est vrai que ça fait longtemps) car je commence un peu à coincer sur certaines
parties cruciales de mon jeu à cause de ça… :cry:
Il commence aussi à y avoir de gros problèmes de framerate qui son dûs à plusieurs systèmes de particules
intégrés dans mes évènements tels que la traînée lumineuse du vaisseau, les éclats d’astéroïdes, les tirs, les impacts…
Voici donc ma question : comptes-tu aussi ajouter prochainement (dans le mois à venir par exemple)
des systèmes de particules ainsi que les formes (ou tracés) dynamiques ?

Ce n’est peut-être pas la première fois que je t’ennuie avec ça, et je m’en excuse à l’avance,
surtout que je sais que tu n’aimes pas avancer de dates, mais j’ai peur de ne pas pouvoir présenter
mon jeu à cause de la puissance qu’il requiert (pour sa catégorie); et j’ai beau rogner de tous les côtés,
dès que je suis dans une phase de combat intensif mon framerate descend en chute libre à 20 images secondes
(je précise que j’ai une machine très correcte).

Ce que tu demande c’est une bonne idée :smiley:
Je peut comprendre que ton jeu(tout comme le miens d’ailleurs) prends beaucoup de ram enfin peut être ralentit par la machine(il est trop lourd quoi) :frowning:
D’ailleurs je propose suite a tes idées que gd ai un truc pour s’occuper uniquement de la zone sur laquelle on joue et qu’il permette de nous dire quel évènements sont joués et lesquels ralentissent le plus :smiley:
Merci

Normalement, ça ne devrait pas être trop dur à ajouter, je pourrais le faire assez vite après avoir ajouté le système d’extension.

J’ai vu une bibliothèque pour les systèmes de particules qui s’intègre facilement à SFML/OpenGL, et qui pourrait permettre de créer pourquoi pas des objets émetteurs de particules, mais ce serait moins trivial à faire.

Pour les dates, je peux pas vraiment m’avancer… Disons qu’il faut que le système d’extension soit arrivé à un certain point avant que je puisse envisager une nouvelle version et des nouvelles fonctionnalités. Justement, ça avance plutôt bien, il faut que je règle encore un problème lors de la copie d’objets provenant d’extensions, puis que je sépare les fonctionnalités actuelles en extensions, et que j’intègre enfin la possibilité d’utiliser des extensions externes.
Pour ce dernier point, je pourrais toujours le rajouter plus tard, en mettant en ligne une version de Game Develop qui introduira le concept d’extensions et d’objets de différents types sans pour autant permettre encore l’utilisation de nouvelles extensions.

J’espère quand même arriver donc au système d’extension + des extensions basiques ( objet “texte”, “image animée”, fonctions de dessins ) d’ici un mois.

D’ailleurs, tu as une idée sur comment tu utiliserait les fonctions de dessins ? Car je rappelle qu’elles seront du style de la fonction de dessin de texte actuelle.

cool :smiley:

Merci beaucoup de ces réponses, je retrouve l’espoir !
Pour ce qui est des fonctions de dessin, je pense notamment à celles de Scirra Construct ou Game Maker :
ronds polygones, traits, remplis avec une couleur pleine ou dégradé (avec transparence si possible ?)
C’est bien cela que tu me demandais ?
Sinon, je me demande aussi comment on fera pour les tests de collision avec ces tracés (détection de la couleur?).

Ronds, lignes, rectangles sans problème.
Polygone, ça nécessitera un paquet de paramètre, mais je verrais.

Normalement, il sera possible de spécifier la couleur de remplissage, la couleur de la bordure, la taille de celle ci, la transparence de l’ensemble. Degradé, je crains que ce ne soit pas possible.

Là par contre, je ne sais pas trop non plus, surtout que vu que si tu dessine manuellement à l’écran, tu est supposé “savoir” ce que tu fait.

Je me demandais comment tu comptais utiliser concrètement ces futures fonctionnalités. Il faut bien prendre en compte qu’il faudrait les redessiner manuellement à chaque tour de boucle, vu que c’est des fonctions de dessins primitives, ce ne sont pas des objets “Formes personnalisables”…

Eh bien justement, vu que les tirs, les effets de feu (des systèmes de particules plus ou moins complexes qui ralentissent bien le jeu)
et les éclats d’astéroïdes (qui peuvent blesser les joueur et les ennemis) sont très nombreux dans mon jeu, je comptais les remplacer…
Histoire qu’ils n’aient pas le statut d’objet, afin d’optimiser les performances. Dans ma tête, cela ferait moins d’objets à gérer, d’où gain de performance.
En fait, je pensais surtout à des systèmes de particules qui emploieraient ces formes…
Mais si tu ne peux pas effectuer de test de collisions avec, je crois que leur utilité sera du coup très réduite…
Et pour le système de masque ? Pour son utilisation, je pourrai par exemple creuser les astéroïdes de manière très précise et ainsi effectuer des tests
de collisions bien plus précis que dans le cas de ton exemple “destruction”, sans compter qu’il n’y aurait ainsi pas de milliers d’objets qui serviraient de “trous”
en même temps à l’écran. D’ailleurs, voilà aussi un exemple d’utilisation des formes dynamiques : je ne sais pas si ce que je dis est trop abstrait ou irréalisable,
mais on pourrait effectuer de opérations booléennes de soustraction de ces formes sur l’image même.
Je sais, je pars loin, mais je voulais au moins que tu comprennes mieux ce que je voulais dire… :blush:

Normalement, réduire le nombre d’objets devrait effectivement améliorer les performances.

Je pense ajouter une fonction permettant de modifier une image en en collant une autre dessus.
Par contre, je ne peux rien garantir sur les performances…
D’autant plus que vu qu’il y aura modification d’une image, les astéroïdes ayant cette même image risque d’être modifiés. Il va falloir trouver une parade à ça…

Pour illustrer cette fonction, je pensais notamment à worms, où l’image du sol sur lequel se trouve les petits vers se fait détruire par des trous dans celle-ci.
Oui, je sais, c’est peut-être trop compliqué comme exemple… :blush:

Ok, je vois bien ce que tu veux dire.
Pour un terrain composé d’une seule image, il n’y aurait pas de problème, vu qu’il n’y qu’à coller une image comprenant du vide là ou il y a eu une collision par exemple.
Par contre, si il s’agit de multiple astéroïde, le problème est que si chaque asteroide utilise la même image, modifier l’image d’un asteroide risque de modifier l’image des autres aussi…

Ah oui, je vois bien le problème, mais ce genre d’action ne peut-il donc pas être localisé, comme les effets de couleur sur l’image ?

La couleur concerne juste le “Sprite” qui affiche l’image, et chaque objet a son propre “Sprite”, donc c’est localisé à chaque objet.
Pour les images, plusieurs objets peuvent avoir la même image, d’où le problème.

Je pense que je mettrai à disposition une première action modifiant donc une image, et une autre modifiant l’image actuelle d’un objet. Cette dernière copiera l’image de l’objet pour en créer une nouvelle spécifique à l’objet, ça devrait le faire ainsi.

Je vois ce que tu veux dire, ça a l’air bien sympa…
Je sais que je devrai attendre pour tout ça, ne t’inquiète pas, mais en tout cas un grand merci et bon courage !

Voilà un aperçu du nouvel exemple Destruction. Le terrain est composé d’objets “Balles de terres”, “Feuillage” et “Symbole”. Ils sont tous destructibles “réellement”. On peut librement modifier l’image d’un objet sans affecter celle d’un autre objet, d’où l’utilisation possible de plusieurs mêmes objets pour construire le terrain.
J’ai ajouté quelques particules qui volent quand on détruit un morceau de terre, ou de feuillages. On peut même tirer sur ces particules et les détruire, cependant elles disparaissent du terrain quand elle touchent le sol ( Vu qu’il peut y avoir pas mal de missiles, si il faut faire en plus des tests de collision avec plein de particules, ça peut vite ramer ).

J’ai aussi ajouté un type d’objet nommé “Dessinateur manuel”. Il est capable de dessiner des rectangles, lignes et cercles, avec la possibilité de modifier la couleur et l’opacité du remplissage et du contour, et l’épaisseur de ce contour. Au final, je sais pas si ça va t’être utile, mais ça peut être pratique pour d’autres utilisations.
Destruction.jpg

Waooouw !
C’est bientôt le nouvel an, mais j’ai l’impression que Noël revient !
Donc cela veut dire que tu as réussi à intégrer les masques d’images, particules et tracés dynamiques, incroyable !
J’imagine les efforts que tu as dû fournir pour faire tout ça, et je crois que les posts de remerciement
vont se multiplier sur ce topic. :smiley:

Peux-tu me dire si chaque groupe de particules fait partie d’un seul objet “émetteur de particules”
ou si chacune est unique (pour les collisions) ?
Aura-t-on des générateurs de particules avec les paramètres habituels, c’est-à-dire durée de vie,
nombre de particules, grossissement, vitesse, fade,… ?
Quant au masques d’images, y aura-t-il une perte de mémoire à un moment donné quand l’objet
aura été trop détruit, à cause du grand nombre de masques qui seront présents dessus ?
Et enfin, dans l’absolu, ces fonctions requièrent-elles beaucoup de mémoire ?
Je sais, c’est encore beaucoup de questions, mais c’est pour ronger mon frein en attendant
que tu mettes en ligne cette nouvelle et sublime version !

Et… MERCI ! ! !

EDIT : Et oui je pense que les rectangles dynamiques auront une très grande utilité : de la fausse 3D ! A suivre… :wink:

Sttooooopp !

Il n’y a pas de particules, désolé d’avoir utilisé ce mot, c’est toujours des objets normaux ( Enfin, des objets Sprites ) ! Désolé ! Bon maintenant, ce sera quelque chose à ajouter :slight_smile:

Lors de la première modification de l’image d’un objet, l’image doit être copiée pour que seul un objet la possède, donc un petit cout en performance à ce moment. ( Maintenant, quand je teste mon exemple Destruction, je ne le remarque pas quand un missile atteint un objet vierge de toute modification ).
Le deuxième moment qui peut pomper plus les performances, c’est lors de l’application d’une image sur une autre. ( Maintenant, dans mon exemple, j’applique 9 modifications à l’image de l’objet percuté, pour avoir l’apparence d’un trou rond, et ça le fait. Je suppose qu’il faut éviter quand même d’en faire 400 à la secondes :wink: )
Enfin, qu’il y est 0 ou 400 images collées sur une image, ça reste un tableau de pixel, donc il n’y a pas de modifications sur les performances. Un décor entièrement détruit garde les mêmes performances que son équivalent normal. C’est le gros avantage sur la technique des objets trous, en plus de pouvoir tester finement la collision et de pouvoir avoir un arrière plan.

( Et re désolé pour le faux espoir pour les particules, il va toujours falloir se coltiner les objets actuels ).

Bravo 4ian :laughing: