Ich habe gerade heute bemerkt, dass wenn ich ein neues XNA 4.0-Spiel kompiliere und laufe, einer der CPU-Threads mit 100% läuft und die Framerate auf 54 FPS fällt.
Das komische Ding ist, dass es manchmal bei 60 FPS funktioniert, aber dann fällt es einfach auf 54 FPS.
Ich habe dieses Verhalten vorher nicht bemerkt, also weiß ich nicht, ob das normal ist. Ich habe mein Antivirenprogramm deinstalliert und XNA Game Studio, XNA Redistributable und .NET Framework 4 neu installiert.
Wenn ich IsFixedTimeStep auf false setze, läuft das Spiel mit 60 FPS und die CPU-Auslastung ist minimal (1-2%). Aber soweit ich weiß, muss ich Velocity-Berechnungen mit ElapsedGameTime machen, aber ich weiß nicht, wie ich das machen soll, da ich mit XNA ziemlich neu bin. Aber einige sagen, dass die Einstellung false ruckartige Animationen reduziert.
Ich habe bereits diesen Forum-Thread überprüft, aber niemand hat eine gute Lösung gefunden.
Hat jemand dieses Problem erlebt?
BEARBEITEN: Ich recherchierte weiter und implementierte einen FPS-Counter (bis jetzt habe ich es mit Fraps gemessen), und mein Counter zeigt das Spiel mit 60 FPS (mit IsFixedTimeStep = true), so löst dies das FPS-Problem, aber die hohe CPU Nutzung bleibt. Ist es möglich, dass dies allen passiert?
Laut dieser Diskussion über Xbox Live Indie Games Forum , anscheinend auf einigen Prozessoren (und OS-s) XNA benötigt 100% CPU-Zeit für einen Kern, wenn der Standardwert Game.IsFixedTimeStep
verwendet wird .
Eine gemeinsame Lösung (eine, die auch für mich funktionierte) ist, dass Sie in Ihren Game
-Konstruktor folgendes einfügen:
Die Game.IsFixedTimeStep
Eigenschaft, wenn true
, stellt sicher, dass Ihr Frame ( Update()
, Draw()
, ...) in einem festen Zeitintervall aufgerufen in Game.TargetElapsedTime
aufgerufen wird. Dies ist standardmäßig 60 Aufrufe pro Sekunde .
Wenn Game.IsFixedTimeStep = false
, werden die Aufrufe zum nächsten Frame ausgeführt, wenn der vorherige beendet ist. Dies wird in der folgenden Zeitgrafik veranschaulicht:
Alle festen Zeitberechnungen ( Bewegungen , Timings usw.) müssen geändert werden, um variable Zeitschritte zu berücksichtigen. Zum Glück ist das sehr einfach .
Angenommen, Sie hatten
%Vor%für ein Objekt, und Sie aktualisieren die Position mit
%Vor% Standardmäßig bedeutet dies, dass die Geschwindigkeit Ihres Objekts 60 * velocity.Length()
Einheiten pro Sekunde ist. Sie fügen Geschwindigkeit 60 Mal pro Sekunde hinzu.
Wenn Sie diesen Satz in Code übersetzen, erhalten Sie diese einfache Modifikation :
%Vor%Um es ganz einfach zu sagen: Sie skalieren die hinzugefügten Werte basierend auf der verstrichenen Zeit .
Wenn Sie diese Änderungen an Orten vornehmen, an denen Sie sich bewegen (oder Timing usw.), stellen Sie sicher, dass sich Ihr Spiel so verhält, wie es bei einem bestimmten Zeitschritt der Fall wäre.
Hohe CPU-Auslastung (100% auf einem Kern) ist ein Nicht-Problem für Spiele. Mit anderen Worten, es wird erwartet. Die Art und Weise, wie Sie die CPU verwenden, wenn Sie ein Spiel schreiben, erfordert dies.
Öffnen Sie die Codeumgebung und schreiben Sie ein einfaches Programm
%Vor%Öffnen Sie den CPU-Monitor und sehen Sie, dass 100% eines Kerns verwendet wird.
Jetzt macht dein Spiel das:
%Vor% Du nennst also im Grunde update()
und draw()
, und das dauert die meisten der 16ms. Du musst einen Frame berechnen (den du am meisten aufnimmst, wenn dein Spiel viel hat von Sachen drin).
Jetzt, weil O / S-Schlafauflösung nicht genau ist ( Wenn Sie sleep( 1ms )
aufrufen, kann es tatsächlich für 20ms schlafen, bevor Ihre App wieder aufwacht. Was passiert, ist, dass Spiele die O / S-Systemfunktion Sleep
nicht aufrufen. Die Funktion Sleep
würde dazu führen, dass Ihr Spiel sozusagen "verschlafen" würde und das Spiel würde lückenhaft und langsam wirken.
Eine gute CPU-Nutzung lohnt sich nicht. Der Standard besteht also darin, "beschäftigt zu warten" und die Zeit wegzuzerren, während die CPU in die Mangel genommen wird.
Tags und Links c# windows xna frame-rate cpu