Augmenter la fluidité d'un jeu

Alors voilà déjà les caractéristiques de mon jeu “The Drill” jusqu’à maintenant :

  • plus de 300 évènements (bien remplis) rien que dans le moteur du jeu (19000 lignes de code dans bloc-notes)
  • Un total de 283 images pour l’instant dont la taille peut aller jusqu’à 1250*1250
  • Une résolution de base à 1024*768
  • Taille du jeu : 30 Mo

Tout cela tourne entre 23 et 40 images par secondes (selon l’action bien sûr) sur mon ordi (AMD Athlon Dual Core XP 3200+, ATI 3200HD 512Mo, 2Go de RAM).
C’est donc là le problème, parce je trouve ma config plutôt bonne et 23-40 images par seconde, c’est assez faible pour ce genre de petit jeu…
Et je suis sans arrêt en train d’optimiser les évènements pour améliorer la situation, de faire des conditions plus “intelligentes”, mais ça ne suffira plus je pense…

Donc voilà mes questions :

  • Serait-ce possible de faire en sorte (peut-être que c’est déjà le cas) que les images sortant de l’écran (non visibles) ne soient pas calculées par l’ordinateur ?
    Faire en sorte que le calcul de l’affichage ne se fasse que quand l’image approche de la surface utile du jeu ?
    Parce que je crains qu’essayer de programmer du “clipping” au seul niveau des évènements risque de ne pas avoir l’efficacité d’un travail en amont dans le moteur même de GD…
    Bon c’est peut-être beaucoup demander, mais je peux au moins essayer :stuck_out_tongue:
  • Est-ce que le fait de désactiver le lissage des images a un impact concret dans le gain de fluidité du jeu ?
  • Et quel format d’image demande le moins de ressources ?

PS : Je trouve ça super que tu aie fait deux onglets différents pour la prévisualisation du jeu et les évènements, c’est le genre de petit changement bien pratique !

Sur les cartes graphiques anciennes, les plus grandes risquent de ne pas s’afficher, car la texture sera trop grande pour la carte.

Ouais, je vais creuser de ce coté là.

Peut être, mais sans doute assez minime… Je vais me renseigner plus en détail.

Aucun, c’est stocké de la même manière pour tout les formats en mémoire.

Actuellement, j’améliore aussi l’éditeur de scène ( sélection multiple, grille vraiment utilisable… )

Oui, t’inquiète, j’avais eu ce problème avant (les images faisaient 20002000) et ça passe partout en dessous de 13001300,
même sur les configs les plus basiques (par contre, c’est 4-10 images seconde là-dessus…)

Vraiment génial ! ! !

Eh bien, tes réponses donnent de l’espoir ! :smiley: Merci !

Je trouve aussi que ces idée sont bonnes :smiley:
Donc si l’ordinateur a moins de surface a calculer il y aura un jeu plus fluide :exclamation:
Ce qui veut dire que mon pokemon pc en cour de développement prendra moins de memoire(ne fera pas sauter mon pc) et sera plus fluide :exclamation:

Oui se sera bien :exclamation:
Bonne chance et merci pour ce futur développement :exclamation:

Et 30 Mo ce doit être déjà un beau jeu(ça doit prendre du temps) :exclamation:

Attention, j’ai jamais dit que j’allais réussir à augmenter les performances, encore moins de manière significative.

Sinon, le fait d’activer ou non le lissage n’a absolument aucun impact sur les performances.

Dis donc Donut_prod, pour calculer les fps, qu’utilise tu ?
Et le fait tu dans l’éditeur ou dans un jeu compilé ?
Si c’est dans l’éditeur, le fait tu avec la version “bug fix” que j’ai mise en ligne ?

Heu… juste une opération simple genre “60/(temps écoulé depuis la dernière image)” je crois. Ca m’a l’air assez fiable, pourquoi ?

Je l’utilise à la fois dans l’éditeur et dans le jeu compilé, c’est une fonction texte toute bête…

Et oui, je le fais aussi avec la version “bug fix”(je n’ai pas vu de différence…)

Justement, c’est parfait :laughing:

Je pensais pourtant que ça allais changer quelque chose, car dans la version “bug fix”, j’ai supprimé une source potentielle de bugs, mais qui était là pour améliorer normalement les performances.

quand ont modifie les propriétés d’une scéne il y a une option
de méthode d’affichage d’objet:
“tri rapide” ou “stable”

cela serais t’il éfficace à l’echelle de The Drill?

Ca peut avoir un impact, mais le tri rapide est de toute façon coché par défaut.

Je ne crois pas avoir vu de grosse différence à ce propos…
Mais quel est le rôle du “tri” exactement ?

Au fait, je crois que le framerate de mon jeu, même s’il n’a pas vraiment augmenté, est devenu plus stable sur la version “bug fix”.

Je me permets de rajouter une petite question : je vois des jeux en pure 2D comme Cortex Command ou Worms,
qui intègrent même la physique dans chaque pixel, et qui ont un framerate incroyable; je sais qu’ils ont des mois de développement,
une équipe complète et beaucoup de moyens, mais quand même : comment font-ils la différence sur leur moteur de jeu ?
Est-ce le langage de programmation ?

Il s’agit de trier les objets dans l’ordre dans lequel il doivent être affichés, en fonction de leur plan.

Si deux objets ont le même plan, en tri rapide, l’un peut apparaitre au dessus de l’autre, puis la fois suivante en dessous. Il y a donc un petit risque de “clignotement”.
En tri stable, l’algorithme est censé éviter ce clignotement, mais il prend alors plus de temps.

Façon de parler, je ne pense pas qu’il y est un véritable moteur physique dans Worms, ou alors il intervient juste lorsqu’il s’agit de faire exploser une partie du terrain.

Je ne pense pas, sur le plan des performances pures, le C++ est déjà suffisamment efficace.

Déjà, avec de l’expérience et des connaissances de professionnels :laughing:

Au final ce serait possible d’améliorer la fluidité en demandant a gd de calculer que la zone ou l’on joue(zone visible de la camera) :question:

Plus précisement, avec les tests effectués, l’affichage ne prend qu’un temps très minime, la majorité du déroulement du programme s’effectuant dans les évènements.

Que faut fps je n’ai pas trop compris du coup moi je met tout au plus bas possible je trouve que ça marche bien
Sinon si vous me proposez mieux ou une méthode de calcul…
Voila

Mmm ? On parle des jeux Game Develop, qu’appelle tu mettre tout au plus bas possible ?

les fps

Plus tu “mettra” ( enfin limitera ) les fps bas, moins l’impression de fluidité sera bonne normalement. :wink:

donc si je les mets a 40 ça rendra mieux qu’a 20?

40 images par seconde, c’est plus fluide que 20 :wink:
Mettre une limite au nombre d’images par secondes permet de ne pas trop ralentir le reste de l’ordinateur, en lui disant que c’est pas la peine qu’il travaille vu qu’il est déjà assez rapide.
Mettre une limite minimum permet elle de ralentir le jeu si le nombre d’image par seconde est trop faible, ce qui pourrait entrainer par exemple des objets traversant des murs.