Я разблокировал частоту кадров в MonoGame через:
this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;
И используя это как основу для того, насколько эффективно я обновляюсь и рисую в игре.
При разрешении 240 x 160 без прорисовки или обновления ничего, кроме счетчика кадров, я получаю значение FPS от 9 000 до 11 000 FPS.
Если я добавлю весь свой код обратно, он падает примерно до 1100 FPS.
Является ли это хорошим показателем того, что мой код значительно замедляет работу графического процессора (в 10 раз), и я должен быть обеспокоен? Игра будет работать на скорости 60 FPS, так что я все еще довольно далеко от этого, но в какой момент частоты разблокированных кадров я должен быть обеспокоен?
GPU: AMD FirePro W5000 (FireGL V)
monogame
frame-rate
тестовое задание
источник
источник
Ответы:
Только грубо.
Во-первых, FPS не является линейной мерой . Разница между 11k FPS и 9k очень мала (0,0000201 секунды на кадр). Но разница между 60 и 2060 FPS (дельта 2k FPS, та же, что существует между 11k и 9k) составляет 0,0161 секунды ... намного больше. Таким образом, он может быть опасен как показатель производительности просто потому, что большие различия могут быть или не быть такими плохими.
Использование времени за кадром немного проще для размышления, но даже тогда это все еще очень широкий взгляд на ситуацию. Он просто говорит вам, сколько секунд занимает один кадр игры. Это не говорит вам, почему , если вы не посмотрите на значительное увеличение времени кадра сразу после добавления или включения одной конкретной функции.
Это может быть основным барометром для принятия решения о более глубоком профилировании. Особенно плохо использовать FPS, чтобы определить, привязаны ли вы к CPU или GPU; Профилирование GPU не так просто, как измерение времени на процессоре (где, вероятно, находится ваш тайминг и FPS-код).
Что касается того, когда вы должны быть обеспокоены ... ну, вы сами сказали, что игра нацелена на 60 FPS. Если вы начнете опускаться ниже или ниже этого уровня, то вам, вероятно, нужно начать более тщательно думать о проблемах с производительностью. До тех пор я бы сосредоточился на том, чтобы все работало, а затем беспокоился о том, чтобы сделать это быстро .
источник
Я не понимаю, почему ты не мог использовать это! Имейте в виду, что вам может потребоваться другой код для учета различий между фиксированным / переменным временным шагом, поэтому, если вы планируете исправить его при выпуске, вам нужно будет внести коррективы. Смотрите эту статью: http://rbwhitaker.wikidot.com/time-steps
Может быть и процессор. Я бы рекомендовал периодически запускать встроенный в Visual Studio профилировщик (или всякий раз, когда вы видите большое падение частоты кадров), чтобы найти горячие точки в вашем коде.
Это, очевидно, зависит от оборудования, на которое вы ориентируетесь. Вам нужно будет проверить свой код на соответствие минимальным требованиям машин, которые вы готовы поддерживать. Если там будет хотя бы 60, я бы не был слишком обеспокоен.
источник