SDL PollEvent против SDL WaitEvent
Итак, я читал эту статью, которая содержит "советы и рекомендации по многопоточному программированию в SDL" -https://vilimpoc.org/research/portmonitorg/sdl-tips-and-tricks.html
Он говорит о том, что SDL_PollEvent неэффективен, поскольку он может вызвать чрезмерное использование ЦП и поэтому рекомендует использовать SDL_WaitEvent вместо этого.
Он показывает пример обоих циклов, но я не вижу, как это будет работать с игровым циклом. Это так, что SDL_WaitEvent должен быть только используется вещами, которые не требуют постоянных обновлений, т. е. если бы у вас была игра, вы бы выполняли логику игры каждый кадр.
единственное, что я могу думать, что это может быть использовано для таких программ, как программа paint, где требуется только действие на ввод пользователя.
правильно ли я думаю, что я должен продолжать использовать SDL_PollEvent для общего программирования игр?
4 ответов
Если ваша игра обновляет / перекрашивает только пользовательский ввод, вы можете использовать SDL_WaitEvent. Тем не менее, большинство игр имеют анимацию/физику, даже когда нет пользовательского ввода. Поэтому я думаю, что SDL_PollEvent будет лучше для большинства игр.
один случай, в котором SDL_WaitEvent может быть полезен, если у вас есть в одном потоке и ваша анимация/логика в другом потоке. Таким образом, даже если SDL_WaitEvent ждет долгое время, ваша игра будет продолжать рисовать/обновлять. (EDIT: это может не фактически работать. См. комментарий Хенрика ниже)
Что касается SDL_PollEvent, использующего 100% CPU, как указано в статье, вы можете смягчить это, добавив сон в свой цикл, когда обнаружите, что ваша игра работает больше, чем требуемые кадры в секунду.
Если вам не нужна точность подкадра в вашем входе, и ваша игра постоянно анимируется, то SDL_PollEvent подходит.
точность подрамника может быть важна, например. игры, где игрок может хотеть очень маленькие приращения в движении-быстрое нажатие и освобождение ключа имеет непредсказуемое поведение, если вы используете классический ленивый метод keydown, чтобы означать " скорость = 1 "и keyup, чтобы означать" скорость = 0", а затем вы обновляете позицию только один раз за кадр. Если ваш кран случается перекрытие с кадром рендеринга, то вы получаете один кадр-продолжительность движения, если он не получает никакого движения, где то, что вы действительно хочу - это количество движения, меньшее длины кадра на основе временных меток, в которых произошли события.
к сожалению, события SDL не включают в себя фактические временные метки событий из операционной системы, только временную метку вызова PumpEvents и WaitEvent эффективно опрашивает с интервалом 10 мс, поэтому даже с WaitEvent работает в отдельном потоке, наибольшая точность, которую вы получите, - 10 мс (вы можете приблизиться к меньшему, сказав, что если вы получите keydown и keyup в том же цикле опроса, то это ~5 мс).
поэтому, если вы действительно хотите точного времени на входе, вам может потребоваться написать свою собственную версию SDL_WaitEventTimeout с меньшим SDL_Delay и запустить это в отдельном потоке от основного игрового цикла.
дальше, к сожалению, SDL_PumpEvents необходимо запустить в потоке, который инициализировал подсистему видео (per https://wiki.libsdl.org/SDL_PumpEvents), поэтому вся идея запуска вашего входного цикла в другом потоке, чтобы получить время подкадра, отменяется платформой SDL.
В заключение, для приложений SDL с анимацией нет причин использовать что-либо, кроме SDL_PollEvents. Лучшее, что вы можете сделать для точности ввода субфреймов, - это, если у вас есть время, чтобы записать между кадры, вы есть возможность быть точным в течение этого времени, но тогда вы получите странные окна продолжительности рендеринга каждый кадр, где ваш ввод теряет точность, поэтому вы в конечном итоге с другим видом несогласованности.
В общем, вы должны использовать SDL_WaitEvent, а не SDL_PollEvent для освобождения процессора в операционную систему для обработки других задач, таких как обработка пользовательского ввода. Это проявится для пользователей как медленная реакция на ввод данных пользователем, так как это может вызвать задержку между вводом команды и обработкой события приложением. Вместо этого с помощью SDL_WaitEvent ОС может быстрее отправлять события в приложение, что улучшает восприятие спектакль.
в качестве побочного преимущества пользователи на батарейных системах, таких как ноутбуки и портативные устройства, должны видеть немного меньше использования батареи, поскольку ОС имеет возможность уменьшить общее использование процессора, поскольку ваша игра не использует его 100% времени - он будет использовать его только тогда, когда событие действительно происходит.
Я пришел сюда, потому что мне было любопытно о SFML PollEventa против WaitEvent. И на самом деле обнаружил новую графическую библиотеку, которую я должен изучить.
Почему эти бесплатные библиотеки GPU так отсутствуют? из Windows.h в SFML в OpenGL и теперь SDL. Обычные программы так себя не ведут. Обычные программы, такие как Xilisoft Video Converter, VLC player, Microsoft Office For crying out loud, безусловно, используют больше ресурсов, чем наши любительские программы. Microsoft Office составляет более 30 Мб пространство жестких дисков наших программ едва доходит до 5mb. Тем не менее, они не используют около 100% CPU. Я могу запустить все три один раз и все еще иметь процессоры. Так почему же моя дерьмовая программа должна использовать 100% процессора сама по себе?
тогда я понял, что официальные программы действительно спят! Не имеет смысла делать постоянные ненужные петли и проверки! Это проблема с PollEvents. Вам никогда не нужно постоянно зацикливать свою программу или, по крайней мере, каждый ее дюйм. Я оставляю VLC играть видео, и это не Макс мой процессор.
этот драйвер меня к использованию события ожидания, которое привело меня к изучению многопоточности. Потому что по какой-то странной причине я не могу управлять несколькими событиями в потоке, если вы используете событие wait.
но потоковая передача вашей программы требует проб, проб и ошибок. Но я считаю, что преимущества CPU стоят того. У меня есть четыре окна, работающие на четырех потоках, и мой процессор едва достигает 20%. И помните об этом, если ваша программа делает 100% на вашем компьютере может не работать на другом компьютере. Небольшой опыт.
еще одна проблема с этими бесплатными библиотеками обработки событий. Программа зависает при удержании строки заголовка для события windowMove. Боже мой! Эти бесплатные библиотеки фактически не имеют события window Move.
и нет возможности изменять события вытягиваются, так что вы можете определить свои собственные события и важно решить, когда остановиться и начать цикл игры. Мои извинения за то, что я сказал открыть Gl I имел в виду перенасыщения.h.
в summaey . Эти дешевые библиотеки, кажется, хобби только стремление и ничего, чтобы поставить на вашем reaume, если вы не хотите дать вашему работодателю что-то смеяться. Direct X, Open Gl, unreal engine-профессиональный выбор. Однако я намерен дать SDL попробовать.