Hallo les gens.
Blady et moi rencontrons un problème de taille avec notre jeu Astral Masane…
En effet, alors qu’on vient de remettre la possibilité de mettre le jeu en plein écran, on s’est rendus compte que le jeu est super accéléré en mode plein écran, comme si la limite d’image par seconde disparaissait… et quand on repasse en mode fenêtre, la limite ne revient pas. En d’autres termes, en mettant le jeu en plein écran, le jeu devient injouable, si on le remet en fenêtré, il reste injouable, la seule solution est de redémarrer le jeu. Et curiosité pour rendre la chose encore plus inexplicable : sur Linux, il n’y a pas de problème, le jeu tourne parfaitement en plein écran.
J’ai essayé de modifier les limites d’images par seconde, de les supprimer, d’activer la synchronisation verticale, rien à faire…
Si l’une ou l’un d’autre vous pourrait nous aider…
La vitesse du jeu est indépendante du nombre d’images par seconde : même si le nombre d’images par seconde augmente, le jeu conservera la même vitesse.
Pourtant, lorsque j’avais tenté de réduire drastiquement le nombre d’images par seconde à cause du problème dont je parle, les “cinématiques” (si on peut appeler ça des cinématiques) sont plus lentes.
Au passage, j’ai un ordi portable avec deux processeurs graphiques, un Intel, et l’autre NVIDIA. J’ai testé sur les deux, et le problème que j’ai évoqué se produit lorsque j’utilise le processeur Intel, mais seulement en plein écran (puisque comme je l’ai déjà dit, c’est le fenêtré fonctionne sans problème, sauf quand je passe en plein écran pour repasser en fenêtré). Et sur NVIDIA, le problème ne se pose pas en plein écran, mais la “hyper-vitesse” se produit quand même lorsque je passe du plein écran au fenêtré.
Peut-être que la limitation de FPS ou la V-sync se désactive. Néanmoins, le jeu ne devrait pas dépendre du FPS.
Utilises tu des actions de positionnement (pas le force, les actions dans la catégorie Tous les objets > Position) ?
Je ne saurais le dire… je sais qu’on utilise l’effet de force pour faire bouger le personnage et les ennemis, idem pour l’interface. Mais le truc c’est que TOUT, absolument TOUT est accéléré : même les éléments qui apparaissent en fondu. Les animations au sein des sprites n’échappent pas à la règle, puisque l’écran de chargement est lui aussi accéléré.
Je pense qu’effectivement, c’est la limitation de FPS qui se désactive, reste à voir pourquoi, et c’est là que je sèche…
En désactivant la limitation de FPS et la synchronisation verticale, le jeu est hyper rapide depuis le début, et ce perpétuellement. Donc le problème vient bel et bien des FPS : selon toute vraisemblance, le passage en mode plein écran désactive la limitation de vitesse.
Sachant que quelque soit la façon dont les FPS se désactivent (que ce soit directement via GDevelop ou à cause du problème que nous avons), le jeu reprend une vitesse à peu près normale quand il y a beaucoup de sprites affichés en même temps… avant de redevenir hyper rapide une fois l’écran plus allégé. Les menus du jeu, quant à eux, sont rapides eux aussi, étant assez légers d’un point de vue du nombre de sprites.
Par ailleurs, ce n’est pas le seul problème du mode plein écran, puisque lorsqu’on met le jeu en mode plein écran, si on veut le remettre en fenêtré, il faut cliquer sur le bouton “mode fenêtré” (qui ne fait rien), remettre en mode plein écran (alors qu’on ne l’avait pas quitté), et recliquer sur “mode fenêtré”. Mais ceci est une autre histoire, ce n’est pas le problème principal…
Donc, il y a sûrement un bug dans GDevelop au niveau de la limite mais, j’insiste, ton jeu est mal codé : normalement, les mouvements ne doivent pas dépendre des FPS. Tu peux nous montrer un extrait de tes événements (qui gère des mouvements par exemple) ?
Voici, en guise d’exemple, l’évènement 19, qui fait animer les boutons du menu principal…
Je ne crois pas qu’il y ait une quelconque influence de l’échelle du temps dans les évènements. Après je me trompe peut-être.
Pour ce qui est de la liaison vitesse/FPS, il me paraît évident que les FPS aient une influence sur la vitesse du jeu : pour prendre un exemple assez connu, non pas sur PC, mais sur console : Sonic 91 sur Megadrive, qui est bien plus lent en 25 FPS qu’en 30 FPS…
Les forces ne dépendent pas des FPS : Si le jeu tourne deux fois plus vite sur un PC, alors la force “pousse” deux fois moins par frame pour conserver la même vitesse.
Dans ton exemple, tu utilises directement les actions de positionnement : si le jeu tourne à 60 fps, l’objet va par exemple bouger de 6010 pixels/secondes alors que si le jeu tourne à 120 fps, l’objet bougera de 12010 pixels par seconde (en admettant que l’on fait +10 à la position X de l’objet par exemple).
Il te suffit de multiplier le nombre de pixels par l’expression TimeDelta() (temps écoulé depuis la dernière image) pour que cela ne dépende plus du nombre de frames par seconde. Après, il faudra évidemment que tu adaptes les quantités de pixels (qui deviennent alors le nombre de pixels par secondes).
Je vois… après bon, c’est assez embêtant que la limitation des FPS saute lorsqu’on passe en plein écran, parce que lorsque celle-ci est présente, la technique qu’on a employé ici a fait ses preuves. Modifier la façon dont ça s’anime serait un contournement d’un bogue du logiciel, et je ne pense pas que ce soit la solution la plus pertinente.
Finalement, cette histoire aura permis de découvrir (ou redécouvrir, je ne sais pas) ce bogue de GDevelop : la limitation des FPS ne fonctionne plus lorsqu’on change de mode d’affichage.
Par contre, ce que je t’ai expliqué n’est pas un contournement, c’est la seule façon propre de faire : les forces utilisent ça en interne, tous les jeux utilisent ça aussi.
Imagine un PC qui ne peut faire tourner ton jeu qu’à 30 fps…
Si votre jeu tournait à 60 fps : Faire +1 à la position X d’un objet était équivalent à 60 pixels par seconde : donc 60 * TimeDelta(). Il faut juste multiplier par 60 les nombres initiaux en ajoutant TimeDelta() pour obtenir la même vitesse.
Sinon, on va voir pour corriger le bug de limitation de FPS.
Je remonte le topique parce qu’on a enfin préparé de quoi mettre le décor en place.
Et là, une interrogation : comment utiliser TimeDelta pour faire bouger le décor tout seul sans être dépendant du framerate ?
Même si j’ai bien compris quelques idées, je ne sais pas par quoi on pourrait commencer pour mettre en place cela… Comment faire ?
En utilisant les forces (de “Tous les objets > Mouvement / Force”), il n’y a pas ce problème (car il est bien marqué que la force est en pixels/secondes). Pour le reste, si tu effectues tes déplacements en utilisant les actions de positionnement (ce qui est quand même rare), là il faudra utiliser TimeDelta().
