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
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 !
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 ! Merci !
Je trouve aussi que ces idée sont bonnes
Donc si l’ordinateur a moins de surface a calculer il y aura un jeu plus fluide
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
Oui se sera bien
Bonne chance et merci pour ce futur développement
Et 30 Mo ce doit être déjà un beau jeu(ça doit prendre du temps)
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 ?
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.
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
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
40 images par seconde, c’est plus fluide que 20
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.