7
votes

Libgdx trop fps. Comment limiter?

Je fais un jeu et j'ai un problème sur des dispositifs Android bas de gamme (étrange) (Galaxy S Mini, Galaxy Ace), avec un mauvais matériel. Le FPS est sur les deux appareils 85+ et sur d'autres périphériques (HTC Desire, Sony Xperia Arc S, Samsung Galaxy S, HTC Wildfire) Le FPS est "normal" (environ 60fps). Aussi 60 FPS s'affiche également sur l'ordinateur. Évidemment, plus de 85 fps est trop important, car l'expérience de jeu est différente et peut causer un avantage injuste pour les joueurs qui jouent sur 85fps +.

Je veux limiter le FPS au maximum 60.

i J'ai déjà fouillé ce forum et j'ai trouvé la question exacte que je pose en ce moment. limite FPS au jeu libgdx avec fil.sleep () 't fonctionne

la solution (acceptée) de l'utilisateur @Daniel était la suivante: xxx

mais la chose est que cela ne fonctionne pas pour moi. Si j'utilise ce code (30 remplacé par 60), je reçois 30-33 fps ou si j'utilise juste le code de Daniel, je reçois environ 15-17 FPS. Pourquoi est-ce et pourquoi ne travaille-t-il pas pour moi? Comment limiter les FPS sur tous les appareils à max 60? J'ai testé ce code sur ordinateur et sur des périphériques également.

Toute aide hautement appréciée. Merci.


9 commentaires

Comment mesurez-vous les FPS? Êtes-vous chronométrant chaque image au début et à la fin de la méthode de rendu ou comparez-vous d'une image à la suivante?


Je doute sérieusement d'avoir un FPS plus élevé donnera "avantage" ..... comme un gars qui soutient l'idée de "course de maître de jeu PC", limitant le FPS est ce que je déteste le plus. Les FPS ne doivent affecter que la douceur du gameplay et rien d'autre, si on pouvait dire que 85fps est un "avantage" de plus de 60 ans, alors pourquoi 60 ans n'est-il pas un avantage sur le matériel qui donne 30? Cela signifiait sûrement que vous devez limiter les FPS à 10 afin d'être "juste". Les FPS ne devraient pas être limités sauf si elle est liée à la vitesse de jeu elle-même (comme une vitesse de déplacement de l'unité = 3 pixels par cadre E.T.C.) qui est un design extrêmement mauvais en premier lieu.


Cela dit, il semble que votre FPS soit la moitié de la valeur cible? Peut-être que changer la valeur dans l'équation de sommeil à 120 vous donnera 60fps? De plus, je remarque que vous avez dit que les gèvements «bas de bout» 85fps et le périphérique «plus haut» donnent 60? Êtes-vous sûr de regarder FPS mais pas le temps de Delta? Delta Time signifie le temps entre 2 Cadre Mise à jour, un 60fps vous donnera 16,6 millyseconde de temps de delta.


Dernier point mais non le moindre, faites très attention à la méthode de sommeil que vous utilisez, il existe de fortes chances que l'équation revienne une valeur négative et que vous écrasez votre programme.


@ Tenfour04. Je mesure FPS avec la méthode libgdx nommée "gdx.graphics.getframesPersecond ()". J'imprime cela dans la méthode de rendu. Jackycheng. Merci pour votre anwser. J'ai essayé de jouer à nouveau sur 85+ fps. J'ai dit que le joueur aura un avantage injuste mais comme vous l'avez dit que ce n'est pas vrai. Un avantage injuste aura ceux qui fonctionnent sur des FPS inférieurs. Parce que les plates-formes se déplacent (au moins visuellement) vraiment très vite sur des périphériques FPS élevés, il est donc difficile de sauter de la plate-forme à la plate-forme. (Mais je n'ai pas remarqué que du début parce que le jeu est facile, une fois que vous commencez).


"Évidemment 85+ FPS, c'est trop, car l'expérience de jeu est différente". Ce n'est pas évident du tout. Vous ne pouvez jamais assumer des fps constants. Il y aura toujours des appareils comptant moins de 60fps par exemple. Vous devez normaliser votre jeu en multipliant avec le cadrage pour obtenir un comportement constant sur tous les appareils.


@noone hein. Donc, par exemple, toutes les plates-formes mobiles, les personnages, etc., j'ai besoin de multiplier avec le framerate? Ou le temps delta? Pouvez-vous me donner un exemple s'il vous plaît? Dans mon exemple, j'ai défini la vitesse linéaire de la plate-forme comme celle-ci "SetLineArvelocity (2.15F, 0);". Mais le comportement est différent sur 60 ou 85 fps. Comment changer la vitesse linéaire de la chose mobile afin qu'il aura le même effet sur tous les appareils?


Avec Box2D, il devient plus compliqué. Vous devriez lire ce iForce2D.net/b2dTut/CONSTANT-Speed ​​. Et comment votre monde de physique se comporte fortement dépend de la manière dont vous faites world.step (...) .


Je ne suis pas tout à fait sûr que cela aide votre question spécifique à la FPS, mais c'est comme ça que j'ai manipulé le temps à libgdx: Stackoverflow.com/questions/23995854/...


5 Réponses :


7
votes

Vous ne voulez pas faire cela.

Vous devez faire votre jeu pour n'importe quel téléphone. p>

Si vous avez un code comme P>

player.x+=Gdx.graphics.getDeltaTime()*300; // this would be ~5f if your device is running with 60 fps


7 commentaires

Pourquoi 5f? Ce sera exactement + 300 / s


Cette approche a effectivement fonctionné pour moi. Je me multiplie 2.15F (vitesse de la plate-forme) * Deltatime * 50. Sur la vitesse de la plate-forme de la plate-forme de 60 FPS environ environ 1,4-1,8 mais sur des périphériques de 85fps +, la vitesse de la plate-forme est réduite à 1,1-1.4F. Cela fonctionne un peu pour moi car toutes les plates-formes se déplacent avec la même vitesse (visuellement) sur tous les périphériques. Mais je suis curieux si c'est la bonne approche? Mais je pense toujours que c'est mieux que l'approche que j'avais à l'esprit en tête (limitant le FPS du jeu). Je laisserai cette réponse ouverte un peu et j'accepterai la réponse si personne ne peut me fournir une meilleure réponse ou confirmer si c'est le droit


@noone 1/60 * 300 = 5F, je veux dire que la valeur du joueur.x sera incrémentée de 5 dans une image sur un si le FPS est 60


@Paul Ah, vous vouliez dire que ce sera un changement de 5 par image, pas par seconde. D'accord, c'est correct. :)


@rootpanthera, vous ne devriez pas le faire de cette façon lorsque vous utilisez Box2D. La vélocité est déjà en m / s. Vous faites probablement world.step () de manière incorrecte, sinon Box2D normalisera la vélocité elle-même.


@noone merci d'avoir essayé de résoudre ce problème avec moi :). J'ai effectivement copié des paramètres pour une étape mondiale de certains didacticiels sur le Web. Time_step = 1/60f; Vélocity_itérations = 6; Position_itée = 2; Cela devrait être correct, non? Ou pensez-vous que quelque chose d'autre est faux?


C'est faux dans la mise en œuvre la plus simple. Vous définissez une horodatation constante (1/60) là-bas. Cela implique que vous devez également appeler le world.step (...) exactement 60 fois par seconde. Puisque vous l'appelez probablement dans chaque cadre, cela dépend du cadrage de l'appareil. Si le périphérique ne fonctionne que 30FPS, alors vous spartiez votre monde seulement 30 fois par seconde, ce qui signifie qu'il ne devient traité que pour 0,5 à 1s, comme prévu. Essayez soit Time_Step = Deltatime, ou voir Stackoverflow.com/Questtions/20848442/... pour la meilleure approche :)



2
votes

Au fur et à mesure que d'autres personnes ont dit, si vous codez votre jeu à droite, un FPS plus élevé ne devrait pas faire la différence. Jetez un coup d'œil à cet article ici pour une meilleure façon de le faire. Il ne traduira pas directement sur libgdx, mais les concepts de là sont tous corrects


0 commentaires

0
votes

Essayez ceci C:

 if (dt < (1f / max_frames)) {

        float sleepTime = (1f / max_frames) - dt;
        try {
            Thread.sleep((long) sleepTime);
        } catch (InterruptedException ex) {
            LogTool.logError(ex.getLocalizedMessage());
            ex.printStackTrace();
        }
    }


0 commentaires

13
votes

dans votre classe de lanceur;

x+= speed*Gdx.graphics.getDeltaTime();


0 commentaires

3
votes

Pourquoi voudriez-vous même suspendre le thread, lorsque vous pouvez simplement garder une trace du temps delta et omettre le dessin / la mise à jour quand il est trop tôt? Vous pouvez limiter le FPS par programme en sautant des mises à jour et des mises à jour logiques lorsque c'est trop tôt.

Essayez quelque chose comme ceci: p>

private static final float MIN_FRAME_LENGTH = 1f/60f;
private float timeSinceLastRender;

/** @param delta time since the last render call. */
public void render(float delta) {
      timeSinceLastRender += delta;
      if (timeSinceLastRender >= MIN_FRAME_LENGTH) {
           // Do the actual rendering, pass timeSinceLastRender as delta time.
           timeSinceLastRender = 0f;
      }
}


2 commentaires

Si votre jeu fonctionne à 67 FPS (15 ms Delta) au lieu de 60 FPS (16,6 MS Delta), 30 ms passeront entre chaque rendu et le jeu sera exécuté à 33 FPS. Même dormir le fil est une meilleure option.


Utilisez 1F / 120F et le fil de rendu exécutera la logique à 120fps mais ne tirez que 60 FPS.