Comments 37
В ответ на коментарии «Delphi жив?» можно давать ссылку на эту статью.
p.s. Да, дочитал что компилируется через lazarus
p.s. Да, дочитал что компилируется через lazarus
С чего бы ему помирать-то? :) Мы игру тоже на делфи делаем и двиг на делфи пишем. пфф. предрассудки всё это.
С вероятность 146% у новостей про Delphi будет комментарий «А ей еще пользуются?\А она жива?»
Сам начинал и программировал 5 лет на ней, потом на C# перешел.
Когда D массово использовали — у людей был негатив от кода начинающих, из-за низкого порога вхождения. Например вся логика в в OnClick\GodClass-ы.
А теперь C# очень распространен и на нем такого полно.
Очередное подтверждение что не в инструменте проблемы, а в руках.
Сам начинал и программировал 5 лет на ней, потом на C# перешел.
Когда D массово использовали — у людей был негатив от кода начинающих, из-за низкого порога вхождения. Например вся логика в в OnClick\GodClass-ы.
А теперь C# очень распространен и на нем такого полно.
Очередное подтверждение что не в инструменте проблемы, а в руках.
Спасибо! Утащил к себе в игру самое простое решение с SetMaximumFrameLatency(1).
А ещё обработку ввода (опрос геймпада и всё такое) утаскивают в отдельный поток. Но пока у меня тупо опрос раз в кадр.
А ещё обработку ввода (опрос геймпада и всё такое) утаскивают в отдельный поток. Но пока у меня тупо опрос раз в кадр.
У меня SetMaximumFrameLatency практически не давало ощутимого результата, лучше всего через query
А ещё обработку ввода (опрос геймпада и всё такое) утаскивают в отдельный поток. Но пока у меня тупо опрос раз в кадр.Да, это будет полезно. Но только в случае с решением на Event/Текстуре, потому как после того, как кадр нарисован, нам нужно как можно быстрее загрузить видеокарту снова, и это сэкономит время на обработку ввода. Ведь свежие данные уже подготовил отдельный поток. В остальных случаях это мало поможет, если ботлнек GPU.
Чувствую себя креветкой понять всё это, но явно нужное дело.
Отличная статья, даже возникло на миг ощущение, что DirexctX — это не так уж сложно :)
Проблема эта в дх11, или в предыдущих тоже есть и решается подобным же методом?
Это проблема во всех графических api. И да, решается подобным же методом.
Только вот SetMaximumFrameLatency доступен только начиная с IDirect3D9Ex. Тоесть в ХР работать не будет такой подход.
Я об этом написал в статье. SetMaximumFrameLatency даже не на всех Win7 заведется, а только с определенными установленными апдейтами.
Я к тому, что работать будет только на интерфейсе IDirect3D9Ex, а на обнычном IDirect3D9 уже не сработает.
А я к тому, что на ID3D10Device тоже может не сработать, потому как требует IDXGIDevice1 интерфейс, который как сказано тут:
https://msdn.microsoft.com/en-us/library/windows/desktop/ff471331(v=vs.85).aspx
Ну и самой статье я писал: «и начиная с DX10.1 у нас появилась возможность задать это количество кадров через специальный метод IDXGIDevice1::SetMaximumFrameLatency.»
p.s. В комментарии выше про Win7 выше опечатался. Имел ввиду Win Vista.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff471331(v=vs.85).aspx
This interface is not supported by DXGI 1.0, which shipped in Windows Vista and Windows Server 2008. DXGI 1.1 support is required, which is available on Windows 7, Windows Server 2008 R2, and as an update to Windows Vista with Service Pack 2 (SP2) (KB 971644) and Windows Server 2008 (KB 971512).
Ну и самой статье я писал: «и начиная с DX10.1 у нас появилась возможность задать это количество кадров через специальный метод IDXGIDevice1::SetMaximumFrameLatency.»
p.s. В комментарии выше про Win7 выше опечатался. Имел ввиду Win Vista.
Опробовал. Результаты:
No lag reducing: 223-225 fps
SetMaximumFrameLatency: 224-226 fps
Query event: 218-220 fps
GenerateMips: 215-217 fps
P.S замеры проводились в течении минуты. В таблице выше указаны Минимум и максимум fps
No lag reducing: 223-225 fps
SetMaximumFrameLatency: 224-226 fps
Query event: 218-220 fps
GenerateMips: 215-217 fps
P.S замеры проводились в течении минуты. В таблице выше указаны Минимум и максимум fps
Вы рассмотрели самый не интересный случай. Когда игра тормозит настолько инпут лаг уже не важен. Также у вас тут решается не проблема инпут лага, а проблема неправильного построенного цикла отрисовки.
Вы рассмотрели самый не интересный случай. Когда игра тормозит настолько инпут лаг уже не важен
Ну например, 30 FPS — это игра настолько тормозит, что инпут лаг уже не важен? А при 60 FPS задержка на рекацию пользовательского ввода в 50 миллисекунд (вместо 17) — это не проблема?
Также у вас тут решается не проблема инпут лага, а проблема неправильного построенного цикла отрисовки.Пример не покажите, как делать правильно?
просто при нормальных фпс 30 -60 возникают другие проблемы. Тут уже нужно стараться считывать состояние контролера и задействовать его максимально близко по времени к vsync'у текущего кадра. Поскольку даже если сам процесс рендеринга нормальный и игра выдаёт 60 фпс, то вы получите при нормальной загрузке задержку 33 мс (16=1000/60мс построение кадра на CPU + 16мс рендер на GPU).
>Пример не покажите, как делать правильно?
Не понял вопроса, что делать правильно? Ваши решения для организации цикла рендеринга вполне приемлемы, но как я уже сказал выше, тут нет борьбы с инпут лагом, а идёт решение другой проблемы.
>Пример не покажите, как делать правильно?
Не понял вопроса, что делать правильно? Ваши решения для организации цикла рендеринга вполне приемлемы, но как я уже сказал выше, тут нет борьбы с инпут лагом, а идёт решение другой проблемы.
Тут уже нужно стараться считывать состояние контролера и задействовать его максимально близко по времени к vsync'у текущего кадра.В статье именно это и делается.
Поскольку даже если сам процесс рендеринга нормальный и игра выдаёт 60 фпс, то вы получите при нормальной загрузке задержку 33 мс (16=1000/60мс построение кадра на CPU + 16мс рендер на GPU).С самого начала статьи я рассказываю, и подробно на графиках показываю, как именно происходит рендеринг. Вы считаете совершенно не правильно. Во-первых, даже при 60FPS формирование кадра на GPU может занимать значительно меньше 16мс. Во-вторых, CPU и GPU работают параллельно. Пока CPU формирует кадр — GPU может его уже рисовать. Они работают одновременно. И по результатам GPUView это отлично видно. Нельзя просто складывать время CPU и GPU.
тут нет борьбы с инпут лагом, а идёт решение другой проблемы.Судя по предыдущему комментарию — я полагаю, что вы не поняли статьи.
>Во-первых, даже при 60FPS формирование кадра на GPU может занимать значительно меньше 16мс.
Это не имеет значения, так как всё равно будет ожидание vsync, GPU оставшееся время будет просто отдыхать и вы не увидите кадра раньше чем 16мс после начала отрисовки.
Либо в вашем случии поскольку цикл отрисовки не привязан к vsync, у вас GPU будет молотить избыточно кадры, которых вы даже не увидите и инпут лаг будет скакать в зависимости от того, куда как по времени совпали рендер и vsync.
>Пока CPU формирует кадр — GPU может его уже рисовать.
Обычно пока CPU формирует текущий кадр, в это время GPU рисует предыдущий кадр, поэтому время складывается. Вот как раз организация параллельного рендера текущего кадра без простоев на GPU и CPU достаточно интересная задача и про неё было бы интересно почитать.
Это не имеет значения, так как всё равно будет ожидание vsync, GPU оставшееся время будет просто отдыхать и вы не увидите кадра раньше чем 16мс после начала отрисовки.
Либо в вашем случии поскольку цикл отрисовки не привязан к vsync, у вас GPU будет молотить избыточно кадры, которых вы даже не увидите и инпут лаг будет скакать в зависимости от того, куда как по времени совпали рендер и vsync.
>Пока CPU формирует кадр — GPU может его уже рисовать.
Обычно пока CPU формирует текущий кадр, в это время GPU рисует предыдущий кадр, поэтому время складывается. Вот как раз организация параллельного рендера текущего кадра без простоев на GPU и CPU достаточно интересная задача и про неё было бы интересно почитать.
dell. не попал веткой, сори
Вот как раз организация параллельного рендера текущего кадра без простоев на GPU и CPU достаточно интересная задача и про неё было бы интересно почитать.В статье много интересных картинок из GPUView. Скажите честно, вы понимаете что на них вообще нарисовано? Если да, то покажите мне простои GPU на вот этом изображении:
Скрытый текст
Понимаю. На этой картинке у GPU нет простоев.
Если вы захотите сделать что-то сложнее демки с кубиками, вам нужно будет считать куллинг, филику, логику. И со своим подходом вы полюбому упрётесь в то, что проц ещё кулинг текущей группы объектов не досчитал, а GPU уже нарисовал всё что было и ждёт. Или на оборот, GPU делает долгий пост процессинг, а вы его сидите и ждёте на CPU и не начинаете считать следующий кадр.
Если вы захотите сделать что-то сложнее демки с кубиками, вам нужно будет считать куллинг, филику, логику. И со своим подходом вы полюбому упрётесь в то, что проц ещё кулинг текущей группы объектов не досчитал, а GPU уже нарисовал всё что было и ждёт. Или на оборот, GPU делает долгий пост процессинг, а вы его сидите и ждёте на CPU и не начинаете считать следующий кадр.
а GPU уже нарисовал всё что было и ждётТогда все замечательно. Проверка одного евента пракически никак не замедлит работу.
GPU делает долгий пост процессинг, а вы его сидите и ждёте на CPU и не начинаете считать следующий кадр.Считать следующий кадр никто не мешает. Сначала считаем, потом ждем. Еще раз, статья про рендеринг, и про то, что критичные к вводу данные (типа положения камеры, возможно положения игроков) нужно засылать на рендеринг как можно позже. Нет никакого смысла накидывать 3 кадра на GPU, потому что спустя 3 кадра вы все так же будете ждать, но уже в Present, в довесок имея Input Lag размером в 4 кадра.
Я надеюсь вы видите, где именно Input lag на картинке выше?
На всякий случай вот скриншоты с крайзисом и uningine:
Заголовок спойлера
на которых видны те же проблемы.
А еще бывают телевизоры с «улучшайзерами» картинки, которые легко добавят задержку в 2-3 кадра и вы с этим сделать не сможете ну просто ничего.
то бывает, когда вас в очередной раз убивают в компьютерной игре, и вы кричите: «Ну я же нажал блок/атаку/уворот». Ну а затем джойстик летит в стену.
Это уже скорее неудачный выбор автором игры слишком жестких игровых таймингов, где нажатия на плюс-минус пары кадров влияет на исход действия. Так сказать, чересчур хардкорная механика.
Интересно, эта проблема решена в популярных движках?
Я бы не советовал называть статью «Input lag», поскольку такое название вводит в заблуждение. «Input» это система ввода — джойстики, мыши, клавиатуры, и т.д. Соответственно, ожидается что «Input lag» — это проблема подсистемы ввода.
Статья же о том, что существует очередь рендера кадров, и о том, что её можно уменьшить до 1 кадра вместо 3-х по умолчанию. Безусловно, когда рендер не справляется и очередь вырастает, кадры будут отображены с задержкой (в т.ч. будут задержаны кадры с реакцией пользователя). Но это Render. Это не Input.
И если соблюдать точность — это не «Lag». Тут игра смысла в английском. Lag — задержка, запаздывание, отставание (между двумя событиями) происходящая незапланированно. Проблема обозначенная в статье называется Frame Latency, что отражено в соотв. названии функции. Казалось бы, пустая придирка? Но разница будет понятна когда вы попытаетесь искать…
Статья же о том, что существует очередь рендера кадров, и о том, что её можно уменьшить до 1 кадра вместо 3-х по умолчанию. Безусловно, когда рендер не справляется и очередь вырастает, кадры будут отображены с задержкой (в т.ч. будут задержаны кадры с реакцией пользователя). Но это Render. Это не Input.
И если соблюдать точность — это не «Lag». Тут игра смысла в английском. Lag — задержка, запаздывание, отставание (между двумя событиями) происходящая незапланированно. Проблема обозначенная в статье называется Frame Latency, что отражено в соотв. названии функции. Казалось бы, пустая придирка? Но разница будет понятна когда вы попытаетесь искать…
Я бы не советовал называть статью «Input lag», поскольку такое название вводит в заблуждение. «Input» это система ввода — джойстики, мыши, клавиатуры, и т.д. Соответственно, ожидается что «Input lag» — это проблема подсистемы ввода.Я с радостью пофилософствую с вами на эту тему, но сразу после того, как вы исправите статью на вики: en.wikipedia.org/wiki/Input_lag
Идет?
Еще, Frame Latency зависит таких параметров как полноэкранное приложение или нет (отключен ли DWM), включен ли в оконном режиме Aero на 7-ке, от флип-модели, VSync, и будет полезна IDXGISwapChain::GetFrameStatistics.
Sign up to leave a comment.
Input lag во время рендеринга и как его побеждать