Будет ли разблокировка частоты кадров в XNA / MonoGame сказать мне, насколько эффективен мой код?

12

Я разблокировал частоту кадров в 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

— тестовое задание
источник

1

В качестве примечания: на вашем пути разработки я бы посоветовал вам поддерживать целевой FPS как в отладочном, так и в выпускном варианте; что-то может работать хорошо в релизе, но может быть медленным, как ад, в отладке, что на самом деле бесполезно :)

— Vaillancourt

На самом деле, нет. Другие ответы на это хорошо отвечают, но суть в том, что большую часть тяжелой работы будет выполнять ваша видеокарта с использованием аппаратного ускорения. Если вы не выполняете работу в том же потоке, что и графика (вам не следует этого делать), то нет никаких причин для воздействия на FPS вашего кода - в пределах разумного - вообще.

— Дэн Пантри

30

Только грубо.

Во-первых, FPS не является линейной мерой . Разница между 11k FPS и 9k очень мала (0,0000201 секунды на кадр). Но разница между 60 и 2060 FPS (дельта 2k FPS, та же, что существует между 11k и 9k) составляет 0,0161 секунды ... намного больше. Таким образом, он может быть опасен как показатель производительности просто потому, что большие различия могут быть или не быть такими плохими.

Использование времени за кадром немного проще для размышления, но даже тогда это все еще очень широкий взгляд на ситуацию. Он просто говорит вам, сколько секунд занимает один кадр игры. Это не говорит вам, почему , если вы не посмотрите на значительное увеличение времени кадра сразу после добавления или включения одной конкретной функции.

Это может быть основным барометром для принятия решения о более глубоком профилировании. Особенно плохо использовать FPS, чтобы определить, привязаны ли вы к CPU или GPU; Профилирование GPU не так просто, как измерение времени на процессоре (где, вероятно, находится ваш тайминг и FPS-код).

Что касается того, когда вы должны быть обеспокоены ... ну, вы сами сказали, что игра нацелена на 60 FPS. Если вы начнете опускаться ниже или ниже этого уровня, то вам, вероятно, нужно начать более тщательно думать о проблемах с производительностью. До тех пор я бы сосредоточился на том, чтобы все работало, а затем беспокоился о том, чтобы сделать это быстро .

6

+1 за последнее предложение. Преждевременная оптимизация производительности, на мой взгляд, довольно плохая практика (если судить по опыту).

— sirdank

1

c2.com/cgi/wiki?PrematureOptimization - Рекомендуем прочитать на эту тему

— Machinarius

Не всегда, если у вас высокопроизводительная машина, и она получает около 80 FPS, тогда это будет достаточно для вашей машины, но если вы хотите использовать компьютеры более низкого уровня, они могут получить только 15 FPS, в идеале, было бы лучше провести тестирование на машине с минимальным набором спецификаций, на которые вы хотите ориентироваться, но, если это не удастся, оптимизация под ваш компьютер может также оптимизировать его для их. Конечно, если он работает достаточно быстро на ваших низкоуровневых компьютерах, то нет причин тратить дополнительные усилия на дальнейшую оптимизацию, особенно с риском увеличения количества ошибок.

— Программирование

5

Я не понимаю, почему ты не мог использовать это! Имейте в виду, что вам может потребоваться другой код для учета различий между фиксированным / переменным временным шагом, поэтому, если вы планируете исправить его при выпуске, вам нужно будет внести коррективы. Смотрите эту статью: http://rbwhitaker.wikidot.com/time-steps

Это хороший признак того, что мой код значительно замедляет работу графического процессора?

Может быть и процессор. Я бы рекомендовал периодически запускать встроенный в Visual Studio профилировщик (или всякий раз, когда вы видите большое падение частоты кадров), чтобы найти горячие точки в вашем коде.

я должен быть обеспокоен?

Это, очевидно, зависит от оборудования, на которое вы ориентируетесь. Вам нужно будет проверить свой код на соответствие минимальным требованиям машин, которые вы готовы поддерживать. Если там будет хотя бы 60, я бы не был слишком обеспокоен.

— tandersen
источник