Questions sur un menu d'options

Hep !

Mon jeu progresse et je réfléchis à faire un menu d’option comme on en voit dans tous les jeux… Se pose la question de la faisabilité… Après je ne sais pas ce qu’exploite le moteur de rendu, et on est sur de la 2d, néanmoins je note que forcer certaines choses sur le drivers nvidia a un impact non négliageable sur le rendu du jeu en termes de qualité et de fps.

J’ai déjà le choix de la résolution, plein écran/fenetré, voilà ce que j’ai besoin de savoir pour la suite :

  • V Sync : peut-on interagir avec pour activer/désactiver ingame ?
  • Triplage de mémoire tampon ? (pour la V Sync, si V sync activée) ?
  • Anti-aliasing : envisageable ? FXAA ? basique 2x 4x 2x 8x ? L’objet dessinateur notamment est très aliasé, de même que les sprites qui seraient mises à une échelle inférieures.
  • Anisotropie ? 2 à 16x
  • Détection de la carte graphique utilisée ? (pour switcher si apu ou integrated graphics + gpu dédié ; je note notamment des problèmes sur nvidia optimus où systématiquement il faut manuellement forcer l’usage de la carte nvidia)
  • Détection d’écrans pour le full screen ? (écran 1, écran 2, écran n)

Bon j’ai conscience que bien des jeux vont moins loin en termes d’options, surtout sur de la 2D, mais dans l’optique que j’ai actuellement je me pose juste la question de la faisabilité, sachant que je me vois mal expliquer dans le jeu d’aller bidouiller le panel nvidia ou le catalyst ati.

Salut,

Pas possible. D’ailleurs, je ne pense pas que tu vas gagner des masses en performances (surtout pour un jeu 2D).

Ce sont des fonctionnalités intéressantes mais elles dépendent plus de la bibliothèque utilisée pour le rendu (pour les jeux natifs = SFML) que de GDevelop.

  • Pour l’anti-aliasing et Anisotropie, il faut que je vérifie si c’est possible avant de te répondre si cela pourrait être ajouté à GDevelop
  • Pour la détection de la carte graphique (ou plutôt forcer le passage en Optimus), les dev de la SFML sont en train de développer une solution (qui sera disponible dans une prochaine itération de la SFML, il doit y avoir moyen de l’intégrer directement dans GDevelop néanmoins)
  • Pour tout ce qui est détection d’écran, la SFML ne possède encore pas beaucoup d’outils (ne gère pas vraiment le choix de l’écran pour le fullscreen et d’autres choses liées). Du coup, pas vraiment possible actuellement

OK et pour le fait de laisser le choix à l’utilisateur d’activer ou non la V sync (car en l’état on l’active dans Gdevelop en “dur” dans les propriétés du projet) ? Car l’impact avec et sans est assez énorme sur les tests que j’ai pu faire un notebook, on passe du simple au triple sur les perfs, du jeu super fluide sans au jeu qui rame à 15 fps avec. J’aimerais vraiment pouvoir laisser le choix aux joueurs de l’activer sans leur proposer 2 exécutables.

L’antialiasing serait vraiment top dans le cas cité plus haut d’objets générés à des échelles inférieures. L’anisotropie (ou un simple filtrage bilinéaire/trilénaire) se remarque apparemment aussi un peu sur le rendu des textures quand je le force sur le drivers nvidia.

Normalement, le V-sync devrait juste réduire les FPS jusqu’à un nombre proportionnel à la fréquence du moniteur (souvent 60 Hz). Donc, si les vrais FPS sont 40, ça ira à 30, si il ya 20 FPS, cela ira à 15 FPS. Il ne devrait pas y avoir de chute brutale.

Oui je sais bien comment ça marche à ce niveau là, mais sur mon net book je constate lors des séquences utilisant bcp de particules de grosse différences : sans la V sync ça tombe pas en dessous de 25/26 fps, avec la V-Sync j’ai une chute de 2 secondes sous 15 fps puis ça reste à 16/18 fps jusqu’à la disparition des particules… Bon je fais pleuvoir un déluge mais voilà si je peux permettre à mes effets pyrotechniques de passer sur des machines très légères c’est plutôt pas mal !