Godot: Проблема с сильным заиканием в простой 2D-игре [Windows 10, Nvidia]

Привет, я обновил свой отчет, потому что я тестировал его на другом компьютере (домашнем), и проблема здесь в том же, что и при изменении анимации. Итак, проблема не в анимации. Думаю, я поверил этому, потому что, когда я увидел, что он был на моем ноутбуке, у него был маленький экран. Вот видео проблемы (видео с частотой 60 кадров в секунду):
GodotStutter.zip

Если видео является точным представлением того, что отображается на экране в реальном времени, то это намного более резкое заикание, чем я когда-либо видел, упомянутый здесь в любой проблеме, связанной с заиканием. Должно быть что-то серьезно не так с этой настройкой Windows 10 / GTX 1060 (я вижу довольно много статей в Интернете, в которых подробно описывается проблема производительности Windows 10 / Nvidia после крупных обновлений Windows, но не могу сказать, связана ли это).

Вот видео тестового проекта на моей системе, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX с последними проприетарными драйверами (390,59). Никаких заиканий (в Openbox - в KWin наборщик все портит, и каждые 10 секунд или около того возникает очень легкое заикание).
StutterTest_LinuxNvidia_OK.zip

Кстати, вот фиксированная версия демонстрационного проекта firstGame_fixed.zip , в исходной версии файлы каким-то образом разделены на три разные папки («firstgame», «firstGame» и «FirstGame»).

В игре у меня такое же заикание, как и на видео.
Однако отключение vsync полностью избавляет от заикания (но игра работает со скоростью 4000 кадров в секунду).
64-битная Windows 10 nVidia GTX 1060 тоже здесь.

Я также тестировал, как предложил здесь @Zylann, и получил те же результаты. У меня тоже Win10 x64 и nVidia GTX 1060.

Изменить: я использую эти драйверы от nVidia:
398,11-рабочий стол-Win10-64bit-международный-whql

Win 7 64-битные GLES2 и GLES3 протестированы, GeForce GTX 660 / PCIe / SSE2 ... никаких заиканий. Включение Aero с 2-м редактором godot, стоящим за игрой, приводит к небольшому заиканию (рендер редактора Godot мешает рендерингу игры).

Тем не менее, заикание Годо - это гигантский невидимый враг, мы все знаем, что он существует, но мы не хотим вглядываться очень внимательно, потому что знаем, что решение непростое.

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

Ваша проблема похожа на другую физику, фиксированный fps с частотой обновления монитора

В демонстрации не используется физика, только простой _process .

Верно ... я говорю, что вижу это сильное заикание только в этом случае, но это правда, что здесь нет никакого физического процесса. Я тестирую изменение Гц одного из мониторов и никаких отличий, 0 заиканий в моем оборудовании.

Изменить: я получил выигрыш 7, выиграл 8.1 и выиграл 10 на этом компьютере и не торопился, чтобы проверить все. Никаких заиканий в win 8.1. Сейчас я тестирую win 10 и все очень гладко ... без проблем с окнами. Годо зол на твою 1060?

Вот такой же тест с моим ноутбуком. Как видите, проблема тоже здесь. Но кажется, что это менее заметно, но оно здесь.

Технические характеристики ноутбука: Windows 10 - Geforce 940M

Вот видео с ноутбука (это видео со скоростью 60 кадров в секунду):
GodotStutterLap.zip

Может ли кто-нибудь с проблемой заикания попытаться выполнить замену демки в Player.gd _process с помощью _physics_process?

Я протестирую сегодня вечером на своем домашнем ПК, вот где у меня все время проблема. Но у меня есть странная вещь: сегодня утром я показал вам видео с проектом на моем ноутбуке, и, как вы можете видеть, у вас такое же заикание. Проблема в том, что теперь, если я запустил его снова, у меня больше не будет этого заикания, как будто оно случайное. А на ноуте ничего не менял, все утро на сеансе TSE работал.

Предупреждение: я говорю только для своего ноутбука. На моем домашнем ПК с GTX 1060 проблема всегда здесь. Но на моем ноутбуке проблема возникает случайно. Вот почему я думаю, что на данный момент я оставлю свой ноутбук на стороне для целей тестирования, и я буду тестировать только на своем домашнем ПК, на котором постоянно возникают проблемы, чтобы иметь возможность изолировать «ошибку».

@Ranoller Я тестировал и получил тот же результат. Заикание все еще присутствует, и выглядит почти так же.

@Ranoller Сделал тест и тот же @RaXaR, который ничего не меняет. Есть такая же проблема.

Это не очень хорошо ....

Чтобы точно указать ошибку, я бы сделал следующие тесты:

1) Полноэкранный режим включен - выключен
2) Если более 1 монитора:
Отключить - включить общий рабочий стол
3) Аэро вкл-выкл

Ваши карты хорошо работают в других играх? ...

Прочитав первый пост об анимации -> заикание / без анимации -> без заикания, я прочитал код и вижу кое-что, что мне не кажется правильным ... именно: изменение анимации каждый кадр. Я думаю, этот код должен проверять текущую анимацию. Скорее всего, это ничего не изменило, но если кто-то захочет test изменить Player.gd таким образом:

extends Area2D

# class member variables go here, for example:
# var a = 2
# var b = "textvar"
export (int) var SPEED #How fast the player will move (pixel/sec)
var screenSize #size of the game window
onready var AnimSprite = $AnimatedSprite


func _ready():
    # Called when the node is added to the scene for the first time.
    # Initialization here
    screenSize = get_viewport_rect().size
    #Engine.target_fps = 60
    pass

func _process(delta):
#   # Called every frame. Delta is time since last frame.
#   # Update game logic here.
    var velocity = Vector2() #Player movement vector
    if Input.is_action_pressed("ui_right") :
        velocity.x += 1
    if Input.is_action_pressed("ui_left") :
        velocity.x -= 1
    if Input.is_action_pressed("ui_down") :
        velocity.y += 1
    if Input.is_action_pressed("ui_up") :
        velocity.y -= 1
    if velocity.length() > 0 :
        velocity = velocity.normalized() * SPEED
        if !AnimSprite.is_playing():
            AnimSprite.play()
    else :
        if AnimSprite.is_playing():
            AnimSprite.stop()

    if velocity.x != 0 :
        if AnimSprite.animation != "right":
            AnimSprite.animation = "right"
        AnimSprite.flip_v = false
        AnimSprite.flip_h = velocity.x < 0
    elif velocity.y != 0 :
        if AnimSprite.animation != "up":
            AnimSprite.animation = "up"
        AnimSprite.flip_v = velocity.y > 0

    position += velocity * delta
    position.x = clamp(position.x, 0, screenSize.x)
    position.y = clamp(position.y, 0, screenSize.y)

Это последняя идея ... вероятно, не проблема, но ... ваша графическая карта очень часто встречается в плеерах, поэтому годо должен хорошо работать с ней.

@Ranoller

За :

• Первый момент: пробовал уже полноэкранный режим или нет, ничего не меняет

• 2: Уже пытался работать только с одним монитором (это моя обычная конфигурация, но иногда у меня тоже есть второй монитор, поэтому я пробовал оба), и это ничего не меняет.

• 3: Я должен проверить (должен быть в состоянии сделать это сегодня вечером (по французскому времени).

• 4: Мне нужно протестировать ваш код (я должен это сделать сегодня вечером (по французскому времени).

Просто протестировал свой код, и он ничего не меняет :(

Хотя эта проблема не может быть напрямую связана с Годо, Годот должен хорошо исправить проблемы с заиканием ... это неправда, что все игры заикаются, как было сказано в другой ветке. Сегодня я играл в n ++, в полноэкранном режиме, в оконном режиме, пытался увидеть какие-то заикания, и нет… никаких заиканий. То же самое с Ори и слепым лесом, чтобы иметь какое-либо заикание в этой игре, приходится делать много плохих вещей (оконные с другими программами в фоновом режиме и т.д .... и только 2 или 3 пропусков кадра в час ...). Годо, начиная выполнение, всегда заикается на x секунд, позже оно стабилизируется, но каждые X секунд вы будете пропускать кадры (если, конечно, у вас нет проблемы с gtx1060). Мы не должны относиться к этому вопросу как к мелкой проблеме.

Я стараюсь изо всех сил изолировать проблему, но на моем уровне это немного сложно. Я пробовал тестировать разные настройки, но безрезультатно. Я также пробовал использовать фоновое изображение вместо использования цвета с прозрачным экраном. Я уже видел (не помню, ведьма) движок с этой проблемой из-за того, что рендеринг 2D-спрайта на «пустом экране» вызывает эту проблему, но, похоже, здесь не так. Так что я пока понятия не имею.

Из любопытства попробуйте определить, сколько времени занимает SwapBuffers в context_gl_win.cpp около строки 68. Если это занимает больше 16 мсек, то вы, вероятно, теряете здесь кадр.

Если кто-то, кто знает источники Godot, может проверить, что я интересуюсь результатом (извините за мой английский ...)

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

Из любопытства попробуйте профилировать, сколько времени занимает SwapBuffers в context_gl_win.cpp около строки 68. Если это занимает больше 16 мсек, то вы, вероятно, отбрасываете здесь фрейм.

Возможно, будет полезно узнать, возникла ли проблема в GLES2, мы это не тестируем.

Я пробовал поиграть с опциями в Godot по этому поводу, но для меня это ничего не меняет, может быть, я не знаю, что именно изменить?

Пытался запустить игру больше 2 минут, но проблема здесь всегда не решается для меня после 60 секунд.

У меня была аналогичная проблема с 3.0.3. (Win10 64 бит, Nvidia 660) Я не заметил этого с 3.0.2.

Я думаю, что это как-то связано с узлом AnimatedSprite, потому что я вижу проблемы с производительностью на уровнях, которые имеют этот узел. Я получаю опалубку при запуске из IDE или при экспорте в Win 32bit, но если я экспортирую в Win 64bit, все работает как надо, без заиканий.

.. интересно, у меня нет проблем с примером проекта "FirstGame.zip" ... но я все еще имею дело с моей игрой, FPS падает до 5 при запуске из IDE и 32-битной версии, GPU сидит около 2% .. ... но, с экспортом 64 бит GPU стоит на 30% и все нормально.

Привет, есть новости об этой проблеме? Я только что протестировал демо-версию pong (я не делал этого раньше, только с обучающей игрой), и, похоже, проблема здесь и в этом образце проекта. Я использую последнюю версию Godot в Steam, чтобы проверить это.

Обновление драйверов Nvidia ничего не изменило, поэтому я пришел узнать новости об этой проблеме. Я еще не нашел, как на нем ездить.

Теперь у меня есть компьютер с geforce gtx 1060 (3 ГБ - дешево), и у меня нет проблем с Windows 10 home. Это может быть какое-то фоновое приложение? Какая-то аппаратная конфигурация AMD-Nvidia Intel-Nvidia ....? У меня нет игрового приложения на этом компьютере (есть в моей студии звукозаписи), но годот работает плавно даже с 3 экранами, подключенными к компьютеру. Кто-нибудь, у кого есть проблема, может проверить, работает ли какое-либо программное обеспечение для мониторинга игр в фоновом режиме, или в Steam, или что-то в этом роде ...? А если раскусить?

Трудно отключить Steam, когда вы используете его для запуска Godot ... Godot отлично работает, проблема в игре, с которой вы делаете. Я уже пытался отключить все, что можно отключить, это ничего не меняет. Я провел множество тестов безуспешно. Я также пытался сбросить, например, драйверы nvidia, обновить их и т.д., но ничего не меняет.

С другой стороны, у меня есть несколько двигателей, которые работают без сбоев, так почему бы не Годо? Это то, что я пытался найти. Но пока что-то не нахожу. Где-то есть что-то кроме чего и где, вот в чем вопрос :-)

Эта проблема слишком "специфична для движка", чтобы найти приемлемое решение с помощью собственного поиска. я могу часами искать код godot, и я знаю, что у меня никогда не будет возможности найти что-то связанное с этим ... я знаю, что разработчикам движков нравится больше новых функций кода, а «исправление ошибок» считается более «младшей работой "или что-то в этом роде. Но с такого рода проблемами дело обстоит иначе. Нам нужен какой-нибудь разработчик движка, чтобы автоматически назначать эту проблему и другие исправления ошибок типа «сложный-призрачный-низкий-трудно себе позволить» ...

Я упоминаю, что я уже пробовал версию для разработчиков (без Steam), и проблема та же.

Привет, у меня была точно такая же проблема с заиканием (с использованием Godot 3.1 из источника Git), любое движение задерживалось для меня, точно так же, как в вашем видео, будь то move_and_slide или просто движение анимационного проигрывателя. но включение V-Sync в настройках проекта полностью решило проблему заикания в 2D-игре.

Я немного смущен, потому что отключение V-Sync устраняет заикание, но для меня все наоборот.

@Qws отключил его И заставил игру работать со скоростью более 60

Первый тест, который я сделал с новым gtx 1060, не дал никаких проблем ... но позже я испытал это заикание. Единственное, что я изменил, - это соединение с dvi на hdmi (и некоторые установленные программы) ... это немного странно. Единственное, в чем я убедился, это то, что проблема не в стороне Windows 10.

Я скажу это много. Я работаю над учебником по 2D-игре «Hoppy Days» из руководств Gamedev.tv. Я БЫЛ использовал 3.0.2 для его разработки, и он работал нормально. Я заметил, что в учебнике использовалась версия 3.0.4, поэтому буквально СЕГОДНЯ я решил перейти на 3.0.6. Сейчас в игре заметное отставание. _ В 3.0.2_ лага не было вообще . Он сейчас там. Все остальные настройки такие же.

My Laptop - довольно новый (купленный в марте 2017 года) игровой ноутбук Dell Inspiron серии 7000. Процессор - это четырехъядерный процессор Intel Core i7-7700HQ 7-го поколения (кэш 6 МБ, частота до 3,8 ГГц). Видеокарта - NVIDIA GeForce GTX 1050Ti с 4 ГБ GDDR5. Оперативная память - 16 ГБ, 2400 МГц, DDR4. Жесткий диск - это SSD от Samsung. Windows 10.

Мне кажется, что что-то изменилось либо в 3.0.4, либо в 3.0.6 ..... Больше ничего не изменилось. Даже игра (как в ... Я вообще не менял / редактировал / обновлял уровень).

@ emo10001 Не могли бы вы протестировать 3.0.3? Именно тогда мы изменили систему сборки, используемую для создания двоичных файлов 3.0.x (от 3.0 до 3.0.2 были собраны на AppVeyor CI с MSVC 2015, 3.0.3 до 3.0.6 были собраны с GCC 8 через MinGW).

Если на вашем ноутбуке есть графика Optimus / переключаемая графика, возможно, ваша система внесла в белый список двоичный файл 3.0.2, который будет использоваться с графическим процессором Nvidia, тогда как 3.0.3+ по умолчанию будет использовать IGP. Или может случиться так, что версия 3.0.2 была внесена в белый список вашим антивирусом, а версия 3.0.3+ считается исходящей из другого источника (что верно) и еще не считается безопасной, поэтому антивирус будет выполнять свои полные проверки и влиять на производительность.
Это только предположения, но в остальном я не уверен, какое реальное изменение Godot повлияет на производительность, поэтому я могу думать только об изменениях в системе сборки.

CC @hpvb

У меня такая же проблема! Мой проект заикается от 20 до 30 секунд, а потом работает нормально. Я загрузил проект в сообщении OP, и это то же самое.
Отключение V-Sync устраняет проблему, и он работает со скоростью 4000+ кадров в секунду.

Я использую версию 3.0.6 на Linux Mint 19 (так что я предполагаю, что тег Windows неточен, а?) И GTX 760 с последними проприетарными драйверами.

Я использую версию 3.0.6 на Linux Mint 19 (так что я предполагаю, что тег Windows неточен, а?) И GTX 760 с последними проприетарными драйверами.

Нет, но это, скорее всего, другая проблема. Заикание в Linux часто происходит из-за компоновки оконного менеджера (например, у меня есть некоторые с KWin, а с Openbox их нет).

Мой проект заикается от 20 до 30 секунд, а затем работает плавно

Я часто это замечаю, если я выполняю сцену, которую редактирую, есть заикание и некоторые разрывы (с включенной vsync) около 15-30 секунд, но если я запускаю проект из главного меню и открываю сцену с помощью селектора сцен ... ну, в одной и той же сцене нет заикания (иногда бывает, но не всегда). Есть какое-то объяснение этому событию? Годо? Windows? Сколько кадров необходимо для стабилизации воспроизведения? ... было бы здорово знать эти вещи, потому что они необходимы для игрового дизайна.

Нет, но это, скорее всего, другая проблема.

МММ ясно. Я имел в виду, что эта конкретная проблема, вероятно, является многоплатформенной, поскольку многие люди испытывают одни и те же проблемы.

Я возился и заметил, что два кинематических тела заикаются в одно и то же время, как для move_and_slide (), так и для move_and_collide ().

Поднимая камеру до одной, когда они оба колеблются, все в сцене заикается, за исключением двух кинематических узлов. Статическая камера показывает заикание только двух кинематических узлов.

Кажется, не имеет значения, какие настройки графики я меняю, ни _process или _physics_process. также не используется другая дельта-переменная.

Я думаю, что этот проект не представляет реального использования ... более сложные проекты работают немного гладко. Я думаю, что окна плохо справляются с чрезмерно большим временем простоя Godot ... Я обнаружил еще одну связанную проблему, не только для godot, но она сильно страдает от этого: в мультимониторе с расширенным настольным компьютером игра более плавная на мониторе 1, если это помечается как «основной монитор». Если основной монитор отличается от 1, на дополнительном мониторе наблюдается заикание (от этого страдают youtube, но не только коммерческие игры, такие как ori). С полноэкранным режимом на дополнительном мониторе, aero в win 7 и сменой мониторов (например, монитор 2, как у основного), ситуация наихудшая, и есть большое заикание (не только Годот, но и ни создатель игр, ни игры Unity) ... Я знаю, что мультимонитор с расширенным рабочим столом на 2 экранах 1080p сложно для дешевых графических процессоров, но другие игры более плавные (не теряйте fps, только заикание). Если этот тест будет продолжен, нам следует сделать более сложный пример.

@Ranoller, моя установка - это двойной монитор в gtx 760, второй монитор помечен как «основной», linux mint 19 с корицей. Я пытался понять конкретное состояние заикания проекта, но не смог понять. Эти небольшие проекты иногда заикаются, иногда нет (только заикание, без потери кадров в секунду). Кроме того, когда он заикается (работает в оконных конфигурациях тестирования Godot), у меня обычно есть одно или несколько хромированных окон на втором мониторе (не на основном), и когда я их минимизирую, заикание исчезает ... после некоторого минимизации / восстанавливая хромированные окна, заикание полностью исчезло.

У меня 2 компьютера -> один с i5 gtx660 2 экрана 1080p и другой с i7 gtx 1060 3 экрана (2 1080p и другие hdready) ... ну, у меня проблема с заиканием, связанная с дополнительными мониторами в gtx660, я думаю, что относится исключительно к рендерингу, заиканиям godot и chrome, game maker и unity don´t (коммерческие игры, а именно HiperLightDrifter и Ori, я не тестировал демоверсии или шаблоны). Windows aero больше заикается в полноэкранном режиме (я думаю, что это не совсем полноэкранный режим), но у меня очень много кадров в секунду, без aero в win 7 я получил в моем проекте 130-140 кадров в секунду без vsync, с aero я прошел 400 кадров в секунду, но. .. заикается (сильно) в определенных условиях (с vsync и без). Я почти не могу заставить Godot заикаться в i7 gtx 1060 (в реальном проекте демонстрация в этой ветке заикается, и я объясняю свое мнение по этому поводу). Я думаю, это проблема оптимизации / OpenGL, например: Light2D практически непригоден для использования, любой режим микширования, кроме «микширования», может давать сбои, если система не слишком мощная, но Godot должен обрабатывать производительность на том же уровне, что и производитель игр или Unity. Вероятно, как только будет запущен 3.1, работа по оптимизации может начаться (если проблема решаема и это не Direct3D / OpenGL - проблема Windows, конечно ... я не знаю, как найти игры GLES2 / 3 в Windows, чтобы протестировать и отклонить прямая проблема OpenGL - Aero / Win7-8-10) ... Я понимаю, что производительность Godot никогда не будет такой же, как у движков на основе pro -> одной игры (Ej: Rayman origins работает без проблем в старом ноутбуке, который у меня есть , годот 2, нет), но он должен отображать, по крайней мере, на том же стабильном уровне, что и создатель игры (Unity, вероятно, будет лучше оптимизирован, чем годот в течение длительного времени, ну, ну, деньги ...). На данный момент я чувствую, что godot хорошо работает только на высокопроизводительном оборудовании или на экранах с низким разрешением (я тестировал на i5 win7 32-битный 15-дюймовый графический компьютер Intel HD и работал хорошо, но я не думаю, что с экраном HD этот компьютер будет бежать годот ровно) ...

Конечно, все это мое мнение / опыт, я могу ошибаться (и надеюсь, что ошибаюсь ... если бы это было простое однострочное исправление, это было бы здорово !!!)

С другой стороны, я не забываю читать reduz, записывая что-то, относящееся к «приоритету процесса» исполняемого файла godot, но в окнах нет разницы, если вы вручную измените приоритет godot в исполнении, godot don´t underperformant (whoou, I have придумал слово?), у выполнения программы нет всплесков, это рендеринг, что-то связанное с nvidia / godot и рабочим столом компьютера (в windows, в linux я не пробую)

Привет, есть новости об этой проблеме? ^^ Я буду тестировать еще раз с последней версией, но, похоже, проблема все еще существует.

теперь это выходит на платформу android или ios？ в магазине Google есть несколько игр, созданных ранним Godot, у которых также есть проблема со шторкой. например: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Это существует на всех протестированных платформах при определенных обстоятельствах, с различными графическими процессорами и различными операционными системами ... не задокументировано в консолях.

Я тестировал его как на Linux, так и на Windows, и он работал плавно, иногда с небольшими заиканиями, у меня есть встроенная видеокарта Intel HD Graphics Baytrail низкого уровня.

После многих часов попыток выяснить причину заикания, по крайней мере в моем случае, я случайно отследил постоянное заикание в 1 секунду до включения «Автоматического переключения на удаленное дерево сцен» в «Настройках редактора». Снятие этого флажка решает для меня проблемы с заиканием и производительностью. (возможно, есть еще очень небольшое заикание, но оно едва заметно.)

Годо сборки 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit, NVIDIA GeForce GTX 660, драйвер v416.81

У меня также есть проблема с заиканием в моей игре. Единственное, что, кажется, делает его лучше, - это включение и выключение полноэкранного режима во время работы игры ... И даже тогда есть небольшое заикание, которое потом подкрадывается. Кажется, происходит совершенно случайно. Иногда игра идет почти идеально, иногда возникает заикание.

2D проект с кинематическими персонажами.
Процессор Intel i5-2550K
16 гб оперативной памяти
Geforce GTX 970
Win10 64-битная
Годо 3.0,6

В Win 10 заиканий случается больше в полноэкранном режиме, потому что Aero (и его можно отключить). Похоже, что Godot использует меньше CPU и больше GPU с Windows Aero, но это вызывает большее заикание. В Windows 7 при отключении Windows Aero в полноэкранном режиме меньше заиканий, чем в оконном, и используется больше ЦП. Я думаю, что у win 10 нет настоящего полноэкранного режима ....

Я начал делать прототип 2D-игры в пинбол, и у меня слишком дрожь в движении мяча, у меня есть только твердое тело, которое падает под действием силы тяжести. Я использую Win10 / NVidia GTX 560 Ti 1Go (с последними драйверами) / 8 Go Ram, мой компьютер не самый лучший, но в моем проекте есть только мяч и StaticBody2D для границ, и я очень часто вижу отчетливое дрожание, я Пробовал с vsync и без, с opengl 3.0 и 2.0, оконным и полноэкранным режимом, с более или менее физическим fps, проблема все еще существует.
Моя версия Годо - 3.1 альфа.
Я думаю, что это серьезная проблема, которую, может быть, трудно исправить, но ее нельзя пропускать, для 2D-игры важно иметь плавное 2D-движение.

Вы правы, Godot теперь имеет лучшее удобство использования из всех топовых движков (мое мнение, конечно). Юзабилити превосходит их всех. Но ... сторона производительности ... сторона экспорта ... это похоже на то, что Godot победил операционную систему, а не как экспорт Unity или Game maker, который более гибок (пока конструкция в Chrome не станет более гибкой) ), и не из-за медлительности gdscript (случается с GDScript и без него), есть "другая неопределенная вещь", я надеюсь, что однажды кто-то сможет найти одну строку мятежника в файле cpp и изменить одну простую "!" эта проблема будет исправлена ​​... (надежда бесплатна, как Годо!)

У меня в голове несколько проектов, и я бы хотел сделать их с Годо, это займет у меня много времени (не говоря уже о моем свободном времени), но мне грустно говорить, что если движок не может гарантировать плавное 2D движение в анимации с простой сценой, движок несмотря на все эти плюсы просто бесполезен. В этом случае, возможно, для меня самый разумный выбор - не рисковать потерянным временем таким образом.

Я понимаю, что эта проблема возникает только в некоторых конфигурациях (например, в драйверах Windows 10 и NVidia), но я хотел бы знать:

• Планируется ли этот выпуск (или аналогичный) на каком-то этапе или нет?
• Можно ли отложить эту проблему в сторону, ожидая замены OpenGL на Vulkan в этапе 3.2?

PS: Я пробовал с другим компьютером:

• Intel i7 4790K 4,00 ГГц
• Win10 64 бит 16 Go RAM
• NVidia GTX 1060 3Go (с последними драйверами)
• Официальная альфа-версия Godot 3.1
  и у меня такая же проблема с простыми сценами.

Я думаю, что такого рода конфигурации ПК (карты Win10 + Nvidia) очень удобны, и я надеюсь, что сообщество Godot (которое, кстати, отлично поработало) исправит эту проблему очень скоро, и что хорошие 2D-игры начнут выпускаться, чтобы показать что мы можем сделать с Годо, но с такими проблемами для меня это просто невозможно.

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

Изменить: О, и еще кое-что ... Когда я отключил приложение Geforce Experience, все, казалось, стало лучше.

2D проект с кинематическими персонажами
Годо 3.0.6
Win10 64-битная
Процессор Intel i5-2550K
16 гб оперативной памяти
Geforce GTX 970

Я попробовал то, что вы предлагаете, я отключил Geforce Experience, попытался переключиться из полноэкранного режима в оконный, снова в полноэкранный, с включенным и отключенным vsync (хуже с отключенным vsync), но заикание всегда кажется мне неприятным.
Это довольно случайно, но я никогда не превышал 15-20 секунд без заикания.

Спасибо за попытку! Это так странно, твои характеристики лучше моих. Проблема у меня в том, что он такой случайный ... Трудно воспроизвести точно. Иногда он будет работать отлично, иногда - заикаться. Однако я почти уверен, что это как-то связано с самим Годо. Я никогда не сталкивался с заиканием в играх, созданных на Unity или любом другом игровом движке, если на то пошло.

Просто заметил это заикание.

(Godot 3.0.6, Windows 10, 64-разрядная версия, i7-8550U, 16 ГБ ОЗУ, NVIDIA GeForce MX150)

Как уже упоминалось, это серьезная проблема для Godot. На этой неделе я решил создать прототип очень простой игры. Я искал фреймворк или движок (их было довольно много) и решил использовать Godot, поскольку он бесплатный и открытый. Затем я заметил заикание, обнаружил эту проблему - и был удивлен, что вроде никакого прогресса нет. Думаю, я все равно прототипирую свою идею в Godot. Но если бы я хотел создать готовую к выпуску игру, я бы, вероятно, попробовал другой движок. (Это звучит слишком резко ... Я просто думаю, что Годо может потерять много потенциальных последователей, если проблема не будет устранена.)

Прогресса нет, потому что над этим никто не работает, и да, это серьезная проблема. Но пока, если вам нужно выпустить коммерческую игру, вы можете создать прототип в годо и перенести ее на Unity (вы можете использовать C #). Вы должны иметь в виду подход «сцена-игра-объект-компонент», и вы можете воспроизвести его в годо, и если работа идет в единство для потока жидкости и производительности, или, если это 2D, обратитесь к разработчику игры. Я работаю над плагином, чтобы попытаться преобразовать проект godot в другие движки и попытаться перенести gdscript в модуль, в gml или на Unity C #, но это очень огромная задача (я не знаю, стоит ли затраченные усилия это, слишком много времени не работает в игре) и всегда будет несовершенным (я не могу получить все типы, например, объект, возвращаемый при столкновении). У меня есть небольшой синтаксический анализатор для сценариев, и я запустил синтаксический анализатор для tscn и tres, но преобразовать результат синтаксического анализатора gdscript в единство C # или GML для разработчиков игр требует тонны кода, и я не знаю "законность" этого (я нужны все имена api ej. в файлах json и не знают об этом IP). Другая проблема - анимация, я пока не знаю, как к этому подойти, но с помощью позвоночника / драконьих костей будет легко портировать. Моя основная идея заключалась в том, чтобы начать с godot и закончить на unity или gm, но для niw это головная боль ... Если бы единство было одинаково портативным (мне это нужно), крошечным и быстрым, чтобы развиваться, как godot (и иметь 32-битный редактор) Я портировал свой основной проект несколько месяцев назад, я люблю годо, но для проекта среднего размера в небольшой команде (или одинокого человека вроде меня) это риск, никто не гарантирует вам, что готовый проект не даст тонны проблемы. Но если в вашей команде есть хороший программист на C ++, это другое дело, вы всегда можете адаптировать Годо к своей игре (в единстве вы не можете, но это менее глючно) ....
Я ненавижу эту проблему, как ненавижу низкую производительность редактора в промежуточном проекте и экспортированной игре, но я ненавижу большее единство (зачем мне нужен Интернет на всех компьютерах, чтобы открыть редактор? У меня один компьютер без этого!) И ненавижу так глубоко визуальная студия ... я уверен, что если Godot прекратит заикание и поработает над производительностью и экспортом, мы сможем увидеть отличные развивающиеся игры.

Чтобы повторно проверить эту проблему сегодня, я сделал следующее, все еще в Windows 10 с nVidia GTX 1060:

Я открыл The Binding of Isaac в оконном режиме. Бегал по кругу, без заиканий (под этим я имею в виду не менее 30 секунд). Я не знаю, есть ли в игре V-синхронизация или нет, у нее нет такой настройки.

Я открыл Minecraft в оконном режиме. Загрузил плоский мир, глядя на землю, где не было бы задержек, никаких заиканий.

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

Я открыл старую Java-игру, которую сделал с помощью Slick2D (OpenGL), без единого заикания (я еще не видел ни одной Оо). Проверяя параметры, была включена V-синхронизация. Если я отключу вертикальную синхронизацию, я получаю регулярное заикание примерно каждую секунду. Если я удвою ограничение частоты кадров, у меня не будет заикания.

Теперь я открыл 3D-проект с помощью Godot 3.1 alpha3, с картой, имеющей некоторые активы и движущийся персонаж: почти без заиканий, я могу видеть только один раз каждые 20 секунд, что слишком тонко, чтобы беспокоиться.

Я также попробовал свой 2D-проект Wallrider, который я портировал в Godot 3.0.6: то же самое, недостаточно заиканий, чтобы беспокоить (случайное за 20 секунд).

Все вышеперечисленные проекты имеют одну общую черту: они не просто рисуют один спрайт на экране.

Если я попробую тестовый проект @crystalnoir с Godot 3.1 alpha3, я сразу получаю нерегулярное частое заикание, которое проходит только в том случае, если я жду примерно 30 секунд после последнего показа / максимизации. Пробовал переходить на _physics_process , и даже пробовал delta = 1.0 / 60.0 , все равно. Если я печатаю delta , это показывает, что есть колебания каждую секунду, но игра показывает заикания несколько раз в секунду, которые delta не отражаются вообще. Также бывает, если я запускаю игру без редактора.
Я также попытался перенести его на Godot 2.1.5, и возникла та же проблема (проект: Stuttering_issue19783.zip )

А теперь самое интересное:
Если я открою свою 3D-игру и тест @crystalnoir вплотную друг к другу на экране, они сразу же начнут работать плавно. Хотя 2D-игра все еще немного тормозит, но не так сильно. Если я закрою 3D-игру, она все равно будет работать нормально, но если я уменьшу 2D-игру и снова увеличу ее до максимума, она вернется к ужасным заиканиям.

Это еще не конец!
Я сейчас попробовал добавить 3D камеру в 2D игру. И как по волшебству, заикание резко и сразу же уменьшается просто так.
Вы можете попробовать это сами с помощью PlayerWith3D scene: Stuttering_issue19783.zip
Посмотрите, насколько он гладкий по умолчанию. Теперь нажмите кнопку magic , посмотрите, как он переходит в дерьмо, если не отображается 3D-среда (хотя он не всегда возвращается к дерьму на 100%, но я вижу, что PlayerWith3D.tscn всегда выглядит лучше, чем Player.tscn ).

Я хотел бы пойти дальше и посмотреть, что произойдет, если я изменю панель управления nVidia с Optimal Power (по умолчанию) на Maximum performance , но ... эээ ...

В любом случае, все, что я могу предположить из этого (но это предположение, так что воспринимайте это с недоверием): это не прямая вина Годо. Это графические драйверы, пытающиеся быть «умными».

Для бога заикания !!! 😂😂😂

Просто выбросьте это туда ... По состоянию на ноябрь 2018 года 14 лучших видеокарт в Steam - это Nvidia. Давайте посмотрим на лучшие карты в каждой категории графических процессоров:

NVIDIA GeForce GTX 1060: 14,60% пользователей Steam.
Графика AMD Radeon R7: 1,06% пользователей Steam.
Intel HD Graphics 4000: 1,06% пользователей Steam.

https://store.steampowered.com/hwsurvey/videocard/

Учитывая приведенные выше данные, кажется, что эта проблема должна стать приоритетной. Подавляющее большинство геймеров используют карты Nvidia, это самая распространенная конфигурация на сегодняшний день. Для сравнения, количество пользователей графики Radeon и Intel ничтожно.

@ Раноллер ... Ты меня убиваешь. Советовать людям создавать прототипы в Godot, но переносить их на Unity для их коммерческого названия (в ветке выпуска Godot) - это самая нелепая вещь, которую я когда-либо слышал, без обид.

@Zylann Я

@ behelit2 Без обид

@Zylann Я поставил 3D-камеру, которая рендерит сетку перед сценой, которая рендерит тайловую карту с анимированными текстурами, и проблема заикания Годо через несколько секунд после получения фокуса не исправлена. Ранее в этой сцене не было другого вида sttuter (только "начальный"), поэтому я не знаю, исправит ли этот трюк что-то, но интересно, что вы обнаружите. Протестирую с вами файлы. Я тоже думаю, что годот простой делает что-то в компьютере "ленивым", но, вероятно, это операционная система, потому что различия в выигрыше с аэро и без него в FPS, использовании процессора и заикании очень велики. Вероятно, это ОС, которая пытается быть умной, а не графическая карта.

Мне нравится идея Zylann проанализировать, что делают другие игры. Не знаю, оффтоп это ли, но кое-что проверил.
Во-первых, кажется, что 95% игр Steam 32-битные (в том числе и последние выпуски). Похоже, что ровно столько же игр рендерит по DirectX. Я фиксирую процессы, выполняемые играми, и пытаюсь увидеть, что происходит с рендерингом. Некоторая информация позади (не для каких-либо выводов, это только информация):

Игра / Исполняемые биты / Движок / Процесс, который используется для рендеринга в 64-битной Windows 7 и заметок.

• HyperLightDrifter -> 32 бит / Game Maker / Windows GDI
• Хук -> 32 бит / Unity / Windows GDI
• Нидхёгг -> 32 бит /? / Windows GDI

• Ори и слепой лес -> 32 бит / Unity / Windows GDI. Выполняет процесс под названием OPENGL32 как godot, но является своего рода оболочкой в ​​Windows GDI. Ни одного звонка из OpenGL32, все звонки из Windows GDI.
  

• Dust: An Elysyian Tail -> 32 бит / Microsoft XNA / Windows GDI. Имеет gameoverlayrenderer.dll и все вызовы из этого (ClientToScreen). Нет OpenGL dll.

• SuperMeatBoy -> 32 бит, выполнение внутри Steam Overlay, Windows GDI

• ΔV: Rings of Saturn (demo) -> 64 bit, godot / Выполняет вызовы OpenGL и Windows GDI, выполняет один вызов OpenGl SwapBuffers - GetPixelformat со значением 8. Делайте много вызовов Windows GDI. Делают дублированные звонки? в WindowsFromDC - SetRect (размер окна), OffsetRect.
  

• Bastion -> 32 бит / SDL2 / Выполняет чистые вызовы OpenGL, без Windows GDI, выполняет уникальный вызов swapBuffers - GetPixelFormat все время со значением 10.

• SouthPark, палка истины -> 32 бит / Unknow engine / Выполняет все вызовы в Windows GDI, похоже, direct3D v 9 (имеет d3d9.dll, но делает небольшие вызовы этим процессом), большинство вызовов поступает от gameoverlayrenderer Steam и uxtheme.dll, который выполняет OffsetRect и IsRectEmpty и другие оконные функции.
  

• Sine Mora -> 32 бит / Unknow engine / Выполняет все вызовы в Windows GDI с помощью наложения Steam, dicect3d 9

• Apotheon -> 32 бит / Microsoft XNA / Все вызовы в Windows GDI, один вызов из оверлея Steam (клиент на экран), один вызов Microsoft XNA (ScreenToClient) и вызовы из процесса под названием uxtheme.dll (управление окнами в windows?) в IsRectEmpty и PtInrect (все логические).
• Яйца возвращаются домой -> 64 бит / Годо / Звонки из OpenGL и из окон GDI, то же самое, что Ring of Saturn.
• Гуакамеле! Супер турбо .... -> 32 bit / Unknow engine, но для файлов может быть похож на sine mora. Эта игра позволяет изменять размер экрана. / Все вызовы из Windows GDI.
• Not a Hero -> 32 бит / SDL2 (википедия говорит, что ClickTeam Fusion) / Все вызовы из Windows GDI Directx 9.
• Средиземье Shadow of War -> 64 бит (да, есть один) / Во вступлении говорится, что Firebird, сейчас ничего о процессах / Все вызовы из Windows GDI, но очень очень мало вызовов, мало, что в других играх, несколько вызовов в секунду (например, вы едва можете следить за вызовами godot api, их тонны в секунду). Но эта игра сжигает де ГПУ.

Я замечаю, что большинство игр в фокусе потеряно останавливают процесс и ставят на паузу (может быть, хорошая практика?), И очень немногие игры позволяют вручную изменять размер экрана (например, не герой). К сожалению, у меня проблема потери фокуса / увеличения фокуса в ΔV: Rings of Saturn (демо).

Изменить: Похоже, что Godot - единственный движок, который одновременно использует процесс OpenGL32 и WindowsGDI.
Используемое приложение: API Monitor v2

(Правка: правильное название ΔV: Rings of Saturn (демо))

Если под Rings of Saturn вы имеете в виду ΔV: Rings of Saturn (демо), он был построен с помощью Godot 3.1, но я не уверен, какую именно версию они использовали?

После многих часов попыток выяснить причину заикания, по крайней мере в моем случае, я случайно отследил постоянное заикание в 1 секунду до включения «Автоматического переключения на удаленное дерево сцен» в «Настройках редактора». Снятие этого флажка решает для меня проблемы с заиканием и производительностью. (возможно, есть еще очень небольшое заикание, но оно едва заметно.)

Годо сборка 8849d3b
Win10 64bit, NVIDIA GeForce GTX 660, драйвер v416.81

У меня была такая же проблема с заиканием, и виновато было отключение автоматического переключения на удаленное дерево.

У меня такая же проблема. Есть несколько проблем с этим джиттером, но для большинства из них, похоже, нет подходящих решений, и мне действительно нужна помощь.

Я собираюсь подписать с издателем сделку с моей игрой, которую я заключил с Godot, и из-за дрожания мне, возможно, придется перенести все мои коды в Unity. Отложив время и деньги на перенос всех кодов, я не хочу переключаться на другой движок, потому что мне очень нравится философия дизайна Godot и сам Godot.

Я также заметил, что в 3.1 была добавлена ​​опция «Physics Jitter Fix» в меню настроек (https://twitter.com/reduzio/status/984783032459685890), но это тоже не помогает.

Годо версия:
Годо 3.0.6

ОС / устройство, включая версию:
MacOS 10.14.1
MacBook (Retina, 12 дюймов, 2017 г.)
Intel Core m3 с тактовой частотой 1,2 ГГц
8 ГБ 1867 МГц LPDDR3
Intel HD Graphics 615 1536 МБ
(Но эта проблема возникает на нескольких устройствах, включая ПК, и экспортированная игра на мобильных устройствах и ПК.)

Описание проблемы:
Кажется, что любой движущийся объект периодически заикается или дрожит, что сопровождается зависанием экрана.

Действия по воспроизведению:
Создайте новый проект с KinematicBody2D или даже AnimatedSprite и измените положение с помощью move_and_slide () или set_position () после добавления Camera2D в качестве дочернего узла (но это все равно происходит даже без Camera2D).

И, похоже, это происходит чаще на устройствах с низкой вычислительной мощностью.

Проект минимального воспроизведения:
Godot_Jitter.zip

KinematicBody2D, _physics_process (), move_and_slide ()

https://youtu.be/78S95yugRDk

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    motion = move_and_slide(motion, Vector2(0, -1))
    print(delta, position)

AnimatedSprite, _physics_process (), set_global_position ()

https://youtu.be/gdc6NOoWG4E

extends AnimatedSprite
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

KinematicBody2D, _process (), set_global_position ()

https://youtu.be/YVFtkbuyqEQ

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

Win 7 64 бит, GTX 660 (драйверы 391.35), Godot 3.0.6 и 3.1-beta1

Привет, я изменил исходный проект (остановил анимацию, использовал твердое тело вместо ручной настройки позиций, добавил слегка анимированный фон и т. Д.)

Вот он: FirstGame_2.zip

Протестировано с размером окна ~ 500x500 и разрешением монитора 1920x1080

Теперь мои наблюдения:

• Джиттер является всенаправленным (не только вертикальным, как обычные проблемы с vsync)
• Чем меньше размер окна, тем чаще возникает дрожание.
• Отключение vsync устраняет дрожание (следующие пункты списка с включенной vsync)
• Одновременный запуск игры без редактора на экране (сверните его, чтобы это был просто рабочий стол - значки, обои, панель задач и, возможно, некоторые статические окна, такие как файловый менеджер или терминал), устраняет дрожание
• Экспортированная игра или запуск из редактора не имеет значения
• Если я запускаю игру с quakespasm-sdl2 на том же экране (когда зомби атакует игрока под водой), я вижу небольшое дрожание
• Если я запускаю игру с сайтом shadertoy (эта демонстрация: https://www.shadertoy.com/view/ll3fz4) без паузы на том же экране, я вижу много дрожания
• Если я запускаю игру с сайтом с шейдерной игрушкой, но ставлю на паузу на том же экране, я вижу небольшое дрожание
• Если я запускаю игру с редактором на том же экране, когда сцена, показанная в редакторе, не обновляется (Player.tscn), я вижу небольшое дрожание
• Если я запускаю игру с редактором на том же экране , а сцена, показанная в редакторе, часто обновляется (main.tscn, у меня там есть анимированный шейдер), я вижу много дрожания

Не пробовали с выключенным Aero, забыли как быстро переключить туда и обратно?

@ starry-abyss, чтобы выключить аэро, перейдите на панель конфигурации, выберите «Внешний вид и персонализация», там вы сможете переключиться на старую тему, такую ​​как «Windows Classic», в которой нет визуальных эффектов (а затем нет t используйте Aero) или "Windows 7 Classic".

Итак, с классической темой игра, с игрушкой шейдера / редактором на экране, тоже переходит из состояния заикания в плавное (каждое состояние может оставаться в течение нескольких секунд). Причем в этом режиме заикание сопровождается вертикальным разрывом кадра. Тем не менее, даже Firefox прокручивает слезы с классической темой: 'D

У меня та же проблема, что и у diiiiiiiii, его вариант использования с move_and_slide такой же, как у меня. Если вы внимательно посмотрите, то это не дрожание объекта игрока, а фон параллакса за ним.

2D проект с кинематическими персонажами
Годо 3.0.6
Win10 64-битная
Процессор Intel i5-2550K
16 гб оперативной памяти
Geforce GTX 970

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

Если вы внимательно посмотрите, то это не дрожание объекта игрока, а фон параллакса за ним.

@ behelit2 Но я не уверен в этом. https://youtu.be/YVFtkbuyqEQ В этом кадре, если вы посмотрите на объект игрока, он даже сам по себе покачивается. Это может быть отдельная проблема, но она становится намного хуже, когда включено сглаживание камеры или объект переключается на Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
Вот что происходит, когда включено сглаживание камеры и объект переключается на Rigidbody2D.

extends RigidBody2D
const SPEED = 7
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    apply_impulse(position, motion)

Возможно, я усилил дрожание, используя apply_impulse () подобным образом, но изменение положения объекта напрямую с помощью set_position () не имело большого значения.

@diiiiiiiii Думаю, тогда у вас должен быть отдельный вопрос. В противном случае ветка будет полна противоречивых утверждений, потому что люди тестируют разные вещи.
Например, сейчас я пробую проект OP, а не ваш (извините).

@ starry-abyss Понятно;)
Хотя есть много проблем с джиттером, и я думаю, что они тесно связаны и могут иметь одну и ту же основную причину.

Обновление по проблеме OP. Я нашел несколько вариантов в Godot, чтобы ограничить частоту кадров без использования v-sync. Так что для меня это 60 кадров в секунду с выключенной v-sync, а не ~ 4000 сейчас.
И сам факт отключения v-sync решает проблему для меня.

Интересно, имеет ли вообще смысл v-sync в оконном режиме. Windows, кажется, использует v-sync сама по себе, и, вероятно, борется с игрой Godot, которая быстрее подготовит кадр после получения сигнала v-sync. Также IIRC другие игры разрывают только в полноэкранном режиме с выключенной v-sync, а не в оконном режиме.

К вашему сведению, проблема diiiiiiiii продолжается здесь: # 25162

Помимо подхода v-sync off, я нашел интересный способ, специфичный для Windows (по описанию фиксации это может быть эта проблема), не уверен, что Годо уже использует это, но, возможно, у кого-то есть время попробовать:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Также это связано: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

Однако есть также эта ветка, которая более подробно описывает и использует разные подходы:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
И это дополняет, короче и по существу, но в начале тоже вызывает некоторые эмоции: https://www.vsynctester.com/firefoxisbroken.html

В моем отчете выше слово "заикание" заменено на "дрожание", поскольку это то, что я испытал (см. Https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Моя идея заключалась в том, чтобы отключить v-синхронизацию только в оконном режиме (то есть это можно сделать из кода, даже может запросить частоту обновления монитора для ограничения fps), но поскольку основные разработчики не поддерживают этот подход, нет ничего пересматривать пока. :) Есть и другие способы, более специфичные для Windows, но мы все еще должны доказать, что они работают хорошо и не слишком опасны.

Обновление по проблеме OP. Я нашел несколько вариантов в Godot, чтобы ограничить частоту кадров без использования v-sync. Так что для меня это 60 кадров в секунду с выключенной v-sync, а не ~ 4000 сейчас.
И сам факт отключения v-sync решает проблему для меня.

Интересно, имеет ли вообще смысл v-sync в оконном режиме. Windows, кажется, использует v-sync сама по себе, и, вероятно, борется с игрой Godot, которая быстрее подготовит кадр после получения сигнала v-sync. Также IIRC другие игры разрывают только в полноэкранном режиме с выключенной v-sync, а не в оконном режиме.

как вы ограничили fps до 60?

Использование поля "Force fps" где-нибудь в категории Debug в настройках проекта

Воскресенье, 17 февраля 2019, 9:25 +03: 00 от FabiánLC [email protected] :

Обновление по проблеме OP. Я нашел несколько вариантов в Godot, чтобы ограничить частоту кадров без использования v-sync. Так что для меня это 60 кадров в секунду с выключенной v-sync, а не ~ 4000 сейчас.
И сам факт отключения v-sync решает проблему для меня.
Интересно, имеет ли вообще смысл v-sync в оконном режиме. Windows, кажется, использует v-sync сама по себе, и, вероятно, борется с игрой Godot, которая быстрее подготовит кадр после получения сигнала v-sync. Также IIRC другие игры разрывают только в полноэкранном режиме с выключенной v-sync, а не в оконном режиме.
как вы ограничили fps до 60?
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

Я не видел, чтобы люди размещали свои процессоры с системами, за исключением I5-2500K, который имеет встроенный графический процессор Intel.

В моем ноутбуке есть как встроенный графический процессор Intel, так и выделенная карта Nvida. Мне просто интересно, может ли быть проблема между двумя графическими процессорами / драйверами и годотом

Может быть. Но это не похоже, что gpu / cpu зависимо. На i7 2700 + 1080ti можно заикаться (с окнами) и плавно работать на мобильном i5 с Intel 4000 (1-е поколение Surface Pro) - в полноэкранном режиме.

Забавно, вы должны сказать, что если я запускаю демонстрационный проект на своих ноутбуках 940 м, я вижу заикание. Однако, когда я запускаю приложение на выделенном Intel 530, я вообще не заикания.

Windows 10 домашняя
i3-6100H CPU @ 2,70 ГГц,
GeForce 940M (26.21.14.3064)
Intel (R) HD Графика 530 (26.20.100.6709)

Видно ли заикание в этом проекте ? (Перемещайтесь, нажимая клавиши со стрелками.)

Я просто сделал быстрый экспорт, оставив интерполяцию включенной и установив физику на 60:
940M были случайные рывки, но не срезание
Intel 530 рывков не было, но временами явные срезы vsync,

Я сделаю больше позже и дам вам знать.

Кажется, у меня был некоторый успех с ограничением моего FPS на уровне 60. Не уверен, что 60 - это магическое число, мой экран может поддерживать 144, я пытался установить ограничение на 144, но заикание все еще было видно. Я снизил свой FPS до 120, заикание все еще было видно, но не как «размытое», что заставляет меня думать, что это просто происходит с меньшим интервалом. Затем последовало снижение FPS до 80 и тот же результат, что и раньше, но теперь заикание заметно медленнее. Кроме того, я должен сказать, что я отключил v-sync и работал в оконном режиме, я тестировал полноэкранный режим, но результат тот же. Есть ли в движке какие-то процессы, ограниченные 60 FPS?

Есть ли в движке какие-то процессы, ограниченные 60 FPS?

По умолчанию физика моделируется со скоростью 60 FPS, что означает, что будет видимое несоответствие, когда FPS рендеринга выше, чем FPS физики (при условии, что дисплей достаточно быстр, чтобы показать разницу). Физический FPS можно изменить в настройках проекта ( Physics> Common> Physics FPS ).

Его можно облегчить путем интерполяции физических тел, но для этого нет официальной поддержки. В версии 3.2alpha вы можете использовать это дополнение сглаживания, которое упрощает интерполяцию узлов.

Есть ли в движке какие-то процессы, ограниченные 60 FPS?

По умолчанию физика моделируется со скоростью 60 FPS, что означает, что будет видимое несоответствие, когда FPS рендеринга выше, чем FPS физики (при условии, что дисплей достаточно быстр, чтобы показать разницу). Физический FPS можно изменить в настройках проекта ( Physics> Common> Physics FPS ).

Его можно облегчить путем интерполяции физических тел, но для этого нет официальной поддержки. В версии 3.2alpha вы можете использовать это дополнение сглаживания, которое упрощает интерполяцию узлов.

Замечательно, спасибо, это может объяснить, почему персонажи заикаются, когда движение обрабатывается в вызове физического процесса.

Все еще может воспроизводиться в 3.1.1 BTW, самый простой способ - открыть Shadertoy в Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

Я наткнулся здесь, надеясь, что найдется решение, но, попробовав почти все советы, которые я видел в этой теме, все еще не было кубиков. Для меня дрожание возникает только тогда, когда я запускаю проект на карте NVIDIA. Если я запускаю его с помощью встроенного графического процессора Intel, он работает плавно и плавно. : /

Я использую последнюю альфа-сборку Godot 3.2 в Windows 10

Я наткнулся здесь, надеясь, что найдется решение, но, попробовав почти все советы, которые я видел в этой теме, все еще не было кубиков. Для меня дрожание возникает только тогда, когда я запускаю проект на карте NVIDIA. Если я запускаю его с помощью встроенного графического процессора Intel, он работает плавно и плавно. : /

Я использую последнюю альфа-сборку Godot 3.2 в Windows 10

Я не думаю, что вы можете исправить это в Windows, этого не происходит в Linux, это может быть исправлено в 4.0 с помощью нового модуля визуализации vulkan.

Я наткнулся здесь, надеясь, что найдется решение, но, попробовав почти все советы, которые я видел в этой теме, все еще не было кубиков. Для меня дрожание возникает только тогда, когда я запускаю проект на карте NVIDIA. Если я запускаю его с помощью встроенного графического процессора Intel, он работает плавно и плавно. : /
Я использую последнюю альфа-сборку Godot 3.2 в Windows 10

Я не думаю, что вы можете исправить это в Windows, этого не происходит в Linux, это может быть исправлено в 4.0 с помощью нового модуля визуализации vulkan.

Ну, это отстой, разве API Vulkan не ориентирован только на высокопроизводительные устройства?

Я специально нацелен на OpenGL 2.0, чтобы поддерживать устройства низкого уровня. Глупо использовать высококлассный графический API только для 2D-игры и не пускать людей с низкопроизводительными компьютерами / ноутбуками. 😕

Похоже на миф. Может быть, время от времени заикание нельзя исправить в банкомате, но заикание, с которым мы сталкиваемся, - это только функция Godot.

Похоже на миф.

Что вы имели в виду?

Это сложный вопрос. С одной стороны, я хотел бы лично исправить это как можно скорее. Но я не могу воспроизвести, поэтому ничего не могу поделать. (Я использую Windows 10 с видеокартой NVidia)

Кто-то, кто может воспроизвести проблему, должен, к сожалению, попытаться ее исправить. :(

Хотя это редкая проблема, она кажется достаточно распространенной, чтобы привлечь к этой теме множество людей. Надеюсь, кто-то из вас сможет над этим поработать.

Ах, я всегда забываю, что то, что я испытываю, в официальных терминах Godot называется джиттером.

_Кто-нибудь знает, как идеально зафиксировать проблему со скоростью 60 кадров в секунду без покупки какого-либо оборудования? _
Я думаю, что некоторые люди недооценивают то, насколько это дерьмо, и, возможно, это другая проблема на разных ПК.

Что вы имели в виду?

Миф: «Это всегда так в OpenGL (или Windows и т.д.). Только Vulkan может нас спасти».

Итак:

1. это видео из OBS: https://www.youtube.com/watch?v=osbJlk1XD8c Влияние OBS заключается в том, что просто запуск OBS вызывает дрожание в проекте Godot (даже когда захват отключен).
2. Без OBS все будет гладко, пока я не минимизирую Firefox с помощью shadertoy, затем он начинает заикаться, но не может захватывать с OBS, потому что 1.

Включая мою собственную запись, это делается с помощью Bandicam, и по большей части именно так он работает с записью или без нее. Как видите, все начинается гладко, но постепенно возникают проблемы.

@clayjohn Я думаю, что это можно исправить, реализовав физическую интерполяцию, но reduz против того, чтобы она была в ядре по нескольким причинам. Тем не менее, в 3.2alpha был добавлен метод, показывающий текущее физическое соотношение шагов, что позволяет реализовать точную физическую интерполяцию вручную.

@ starry-abyss Если вы можете использовать 3.2alpha, попробуйте аддон сглаживания lawnjelly: слегка_smiling_face:

Просто подумайте, есть ли что-нибудь полезное в нереальном движке или источнике PhysX?

Привет,
Виктор Стэн

22 октября 2019 г. в 4:17 Hugo Locurcio [email protected] написал:

Взаимодействие с другими людьми
@clayjohn Я думаю, что это можно исправить, реализовав физическую интерполяцию, но reduz против того, чтобы она была в ядре.

@ starry-abyss Если вы можете использовать 3.2alpha, попробуйте аддон сглаживания lawnjelly 🙂

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

@victorbstan Мы не должны смотреть на исходный код Unreal, поскольку он не находится под лицензией с открытым исходным кодом. (Он даже не разрешает распространение среди пользователей Unreal Engine без лицензии.)

Определенно не поднимайте код из закрытого источника, но с архитектурной точки зрения вы можете
не почерпнуть из этого идеи? [не юрист]

Вторник, 22 октября 2019 г., 11:07 Hugo Locurcio [email protected]
написал:

@victorbstan https://github.com/victorbstan Мы не должны смотреть на
Исходный код Unreal, поскольку он не находится под лицензией с открытым исходным кодом. (Это не
даже разрешить распространение среди пользователей Unreal Engine без лицензии.)

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HBBLY2YY3PNVWWK3TUL52HS443DFMVREXWOFWWK3TUL52HS443DFMVREXWOFWW4TUL52HS443DFMVREXWFWO4TUL52HS443DFVREX
или отписаться
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Я бы все равно не рекомендовал смотреть его исходный код. Если вы когда-нибудь захотите почерпнуть вдохновение из запатентованного алгоритма, вам следует выполнить обратный инжиниринг в

Тем не менее, здесь нам не нужно ничего делать. Решение состоит в том, чтобы использовать физическую интерполяцию, которую сегодня используют самые популярные игровые движки. У него есть некоторые недостатки (например, от пользователя требуется работа, чтобы избежать интерполяции при телепортации объектов), но я думаю, что положительные стороны намного перевешивают их.

Я понимаю, что предложение состоит в том, чтобы получить представление о возможных путях поиска решения, не обязательно плагиат. Я бы не подумал, что есть патент на решение проблем с мерцанием / заиканием, кроме IANAL.

Привет,
Виктор Стэн

22 октября 2019 г. в 14:07 Hugo Locurcio [email protected] написал:

Взаимодействие с другими людьми
@victorbstan Мы не должны смотреть на исходный код Unreal, поскольку он не находится под лицензией с открытым исходным кодом. (Он даже не разрешает распространение среди пользователей Unreal Engine без лицензии.)

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

В моих сценариях профилировщик Godot показывает идеальные 60 FPS, даже когда я вижу дрожание / заикание. Означает ли это, что проблема не связана с интерполяцией, или я что-то упустил?

Я предполагал, что тайминги Godot были реализованы таким образом, чтобы мешать таймингу композитора Windows (и, возможно, SDL делает это лучше, чем

(и, возможно, SDL делает это лучше, чем GLFW, следовательно, другие движки просто работают там, где Godot не работает).

Godot использует собственный код управления окнами, он не использует ни SDL, ни GLFW: слегка_smiling_face:

У меня Windows 10 и nVidia GeForce GTX 1070, и со сборкой 3.2 alpha2 с включенной функцией vsync возникают дрожания в оконном режиме. Полноэкранный режим вроде нормально. Проблема особенно серьезна, если редактор не свернут во время игры. Игра, которую я тестирую, использует только _process() для обновления позиций. Из-за этого я подозревал, что проблема связана с очень шумным delta или пропущенными кадрами (большие дельты), но это не так. delta действительно стабильно работает во время дрожания.

Основываясь на исследованиях других участников этой ветки, я ввел изменение в context_gl_windows.cpp чтобы установить интервал подкачки равным 0 и вызвать DwmFlush() в swap_buffers() .

#include <dwmapi.h>

#pragma comment(lib, "dwmapi.lib")

...

void ContextGL_Windows::swap_buffers() {

    DwmFlush(); // Added this.
    SwapBuffers(hDC);
}

void ContextGL_Windows::set_use_vsync(bool p_use) {

    if (wglSwapIntervalEXT) {
        // changed this: wglSwapIntervalEXT(p_use ? 1 : 0);
        wglSwapIntervalEXT(0); // To this.
    }
    use_vsync = p_use;
}

Это основано на том, что делают проекты Chromium .

Внесение этого изменения, похоже, устраняет дрожание в оконном режиме. В полноэкранном режиме игра разрывается, поэтому DWM, вероятно, отключен, и двойная буферизация через значение интервала 1 кажется необходимой. (По сути, код должен делать то, что он делает сейчас.)

Если кто-то еще захочет и сможет попробовать это, мне было бы интересно узнать, как это происходит.

Похоже, что wglSwapIntervalEXT(0); part - это то же самое, что отключить v-sync в параметрах.

Похоже, wglSwapIntervalEXT (0); часть аналогична отключению v-sync в параметрах.

Это. 1 - включить vsync, 0 - отключить, а также -1 для «адаптивной vsync» (отключить синхронизацию при низкой частоте кадров, включить при высокой).

Я тестировал DwmFlush () сверху с моими простыми случаями в ветке 3.1.x.

• Исправляет ситуацию с тестовым примером shadertoy;
• V-sync включен или выключен - для меня выглядит одинаково (я не патчил часть wglSwapIntervalEXT ())
• Случай OBS все еще дрожит (я думаю, выглядит так же), но Годо теперь сообщает о падении FPS до 40 (интересно, действительно ли профилировщик в Godot совпадает с исходной версией Godot);
• Я также попытался вызвать DwmFlush () после SwapBuffers (hDC), и все 3 точки остались прежними.

Я не уверен, но думаю, что DwmFlush () после SwapBuffers (hDC) может быть более правильным, поскольку Годо помещает кадр в ближайшее обновление композитора, а не в следующее, которое находится после ближайшего.
Интересно, должен ли Godot лучше определять, работает ли композитор, и переключаться обратно на ванильный метод v-sync, если это не так.

Так что следующей попыткой будет новая функция интерполяции, упомянутая Калиноу.

ОБНОВЛЕНИЕ: да, в случае OBS Godot сообщает о времени обработки 0,03 секунды (но FPS отображается как 60), вероятно, счетчик Godot FPS не учитывает пропуск v-blank каждый раз
ОБНОВЛЕНИЕ 2: к сожалению, плагин интерполяции здесь не помогает; У меня все еще наблюдается джиттер в случае OBS и заикание и / или микширование джиттера в случае с игрушкой для шейдеров

Похоже, что wglSwapIntervalEXT(0); part - это то же самое, что отключить v-sync в параметрах.

Верно, но добавление DwmFlush() в swap_buffers() приведет к тому, что игра будет использовать композитор (DWM) для синхронизации. Когда композитор включен, у вас фактически есть двойная буферизация, хотите вы этого или нет. У вас будет тройная буферизация в случае, если вы установите интервал обмена OpenGL равным 1. (ваши два буфера и композитор.)

Мне тоже интересно, почему другие проекты помещают вызов DwmFlush() перед SwapBuffers() . Это кажется обратным, но я почти убедил себя, что это правильно.

В случае этих проектов они не используют двойную буферизацию OpenGL (когда включен композитор), поэтому такой способ кажется лучшим способом синхронизироваться с вертикальной пустой точкой. С интервалом подкачки OpenGL, равным 0, вызов SwapBuffers() не блокируется, поэтому вы представляете композитору следующий кадр, как только вы знаете, что он закончил с текущим. Это фактически дает тот же эффект, что и использование интервала подкачки OpenGL, равного 1. (Когда композитор не мешает - например, в полноэкранном режиме).
>
>

Интересно, должен ли Godot лучше определять, работает ли композитор, и переключаться обратно на ванильный метод v-sync, если это не так.

Я думаю, вы правы. Кажется очевидным, что v-синхронизация OpenGL прерывается, когда включен композитор. Если вы посмотрите на код glfw и Chromium, они называют это (используя DwmFlush() ) HACK. Скорее всего, они думают, что OpenGL в этом случае не работает, и вынуждены делать то, что должен делать.

@ starry-abyss Перечитав ваш пост о том, что случай OBS не меняется, мне интересно, включен ли в этом проекте vsync. Поскольку вы не изменили вызов на wglSwapIntervalEXT() при включенной vsync в основном приведет к блокировке игры как в DwmFlush() и в SwapBuffers() . Это объяснило бы время обработки 0,03 секунды.

@TerminalJack Нет, все комбинации перепробовал. При запуске OBS время процесса всегда увеличивается до 0,03. Просто Годо, кажется, изо всех сил старается достичь 60 FPS, даже когда не может добиться этого несколько кадров подряд.

Поэтому я бы разделил это на две части:
1) Годо не дружит с наборщиком;
2) Godot слишком хочет иметь максимальный FPS, в то время как он может выдавать стабильные 30, если под нагрузкой.

Но если есть надежный способ (не) доказать, что 0,03 - это чистое время вычисления, а не синхронизация, я могу попробовать.

@ starry-abyss В целях тестирования вы можете использовать диспетчер задач, чтобы повысить «приоритет» этого процесса до «высокого». Это заставит его вытеснить другие и даст ему львиную долю времени обработки. То есть до тех пор, пока он находится в рабочем состоянии и не заблокирован в DwmFlush() и / или SwapBuffers() .

У меня не было возможности возиться с этим сегодня, но я попытался запустить изменение в системе Windows 10, которая имеет встроенный графический процессор Intel UHD Graphics 620. (Достаточно бюджетный графический процессор.)

Сначала я запустил игру (в оконном режиме) с последней сборкой 3.2 alpha2, и в ней не было заметного дрожания. Затем я запустил игру с изменениями, и она тоже работала нормально.

Я случайно зарегистрировал delta раз во время двух прогонов, и я обнаружил, что они были намного более стабильными с вызовом DwmFlush() чем без ...

3.2 альфа2

0.016667 (10 times)
0.016501
0.016667 (15 times)
0.016628
0.016667 (3 times)
0.016646
0.016667 (5 times)
0.016659
0.016667 (6 times)
0.016571
0.016667 (2 times)
0.016661
0.016667 (10 times)
0.016626
0.016667 (13 times)
0.016567
0.016667 (8 times)
0.016653

Тестовая сборка

0.018182
0.022628
0.018182 (3 times)
0.017982
0.016836
0.016781
0.016667 (5 times)
0.01671
0.016667 (129 times)
0.016935
0.016667 (13 times)
0.018094
0.016667 (2828 times)

(Высокие дельты в начале здесь связаны с тем, что они были сняты сразу после загрузки сцены. Альфа-сборка демонстрирует такое же поведение.)

Обратите внимание, как тестовая сборка в конечном итоге успокоилась и достигла устойчивого состояния. Сборка 3.2 alpha2 так и не появилась.

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

Я создал форк с одним коммитом, который должен решить эту проблему.

Однако я тестировал его только на двух машинах с Windows 10, поэтому было бы здорово, если бы другие люди могли собрать его и протестировать на других версиях Windows. Кроме того, я построил его с использованием VC ++ 2019, поэтому, если кто-то, использующий mingw, сможет его собрать, это тоже будет здорово.

Если у вас есть собственный (недавний) форк проекта, вы сможете без проблем внести в него это изменение.

Я работаю в Windows 10 с NVidia GTX 1050.

У меня нет заикания в примере проекта, если у меня не открыта и не запущена шейдерная игрушка (как описано в нескольких комментариях выше).

При фиксации @TerminalJack заикание все еще присутствует при запуске shadertoy.

@clayjohn Спасибо за тестирование. Интересно, проблема в вашем случае просто в вычислительной мощности?

Я могу запустить шейдерную игрушку 800 x 450 в фоновом режиме и игру Godot (запускаемую из редактора) в окне на переднем плане и получить очень небольшое дрожание с внесенными мной изменениями. С другой стороны, сборка alpha2 имеет серьезный джиттер при тех же обстоятельствах. Я один из тех, у кого есть серьезный джиттер даже без какой-либо нагрузки на мою систему, так что, вероятно, это тоже нужно учитывать.

@TerminalJack Хорошее замечание. Я запускал шейдер тропических лесов iq :)

Я думаю, что здесь также высока вероятность того, что здесь есть несколько проблем. Как отметил @Calinou выше, у многих пользователей также исправлена ​​проблема при использовании интерполированной физики.

На этом этапе, я думаю, вам следует пиарить свой коммит, он выглядит хорошо, а пиар сделает его более заметным и упростит другим пользователям создание и тестирование.

@clayjohn Да, я согласен с тем, что, вероятно, есть другие проблемы, которые ведут себя аналогичным образом.

На самом деле я начал с попытки отследить проблему с плохим заиканием, которое случается каждые 60–90 секунд, и наткнулся на эту цепочку. (Кажется, что что-то время от времени блокирует процесс на 60–100 мсек.) Я запускал свою игру в полноэкранном режиме и не испытывал дрожания. Однако, наткнувшись на эту ветку, я попытался запустить ее в окне и, о чудо: я один из счастливчиков, которые могут воспроизвести эту конкретную проблему.

Скорее всего, я удалю операторы отладки из своих изменений и пришлю PR через пару часов.

@TerminalJack Форк больше не доступен (или он настроен как закрытый), не могли бы вы снова сделать его доступным?

@Calinou Извини. Я поднял репозиторий и удалил его. Я раскрою его снова и вскоре повторно зафиксирую здесь изменения.

@Calinou Новый коммит здесь .

@TerminalJack Ваше исправление, похоже, предназначено только для Windows, но я сталкиваюсь с той же проблемой в Ubuntu.

@TerminalJack Ваше исправление, похоже, предназначено только для Windows, но я сталкиваюсь с той же проблемой в Ubuntu.

Да, это определенно исправление только для Windows. Сожалею.

Не знаю, нужно ли делать что-то подобное на Ubuntu или нет. Я даже не уверен, использует ли он композитор.

Не знаю, нужно ли делать что-то подобное на Ubuntu или нет. Я даже не уверен, использует ли он композитор.

Фактически, нет способа отключить его в некоторых оконных менеджерах (в том числе в Ubuntu по умолчанию): слегка_smiling_face:

@TerminalJack Может также потребоваться некоторая логика, когда Aero отключен, например, в Windows 7 (IIRC не выполняет v-синхронизацию, поэтому Godot, вероятно, все равно должен сам v-синхронизировать в этом случае)

@ starry-abyss Я надеюсь, что это дело будет раскрыто. У меня есть старый ноутбук с Windows 7. Если он все еще работает, я проведу с ним несколько тестов и посмотрю, нужны ли какие-либо изменения.

Я завел свой ноутбук 10-летней давности с Windows 7 и протестировал свои изменения. Пришлось использовать для тестирования самый простой из проектов. (Графические процессоры для ноутбуков тогда были очень плохими.) Я использовал проект из этого поста. Я добавил следующее, чтобы я мог переключаться в / из полноэкранного режима.

func _input(event):
    if event is InputEventKey && event.scancode == KEY_F && event.pressed:
        # Switch into or out of full screen mode.
        OS.window_fullscreen = !OS.window_fullscreen

Я запустил проект как со своими изменениями, так и без них, и в любом случае заметных отличий не было. С моими изменениями композитор будет использоваться для v-синхронизации, когда ожидается (оконный режим, композитор включен), а двойная буферизация OpenGL будет использоваться во всех остальных случаях.

Хорошая новость заключается в том, что в _code_ не потребуется никаких изменений. Код определяет, включен ли композитор или нет. Он даже обрабатывает случай, когда вы включаете или отключаете композитор во время работы приложения. Однако это случай, который я не предвидел, поэтому я не включил его в комментарии в swap_buffers() относительно случаев, когда стратегия v-синхронизации меняется на лету. Насколько я знаю, это единственное, что мне нужно изменить.

Одна из вещей, поднятых сегодня на irc при обсуждении этого (и PR TerminalJack), - это отделение ошибки измеренной входной дельты от ошибки выходной дельты.

Калину указал, что мы можем проверить это до некоторой степени, запустив с переключателем командной строки --fixed-fps 60 . Это будет обрабатывать входную дельту так, как если бы она всегда составляла 1/60 секунды.

Было бы очень полезно, если бы те, у кого есть проблема (особенно с Windows), могли сообщить нам, влияет ли это на джиттер.

@lawnjelly Я быстро попробовал с опцией командной строки и без
Не случайно ли значение параметра сохраняется между запусками редактора?

Не случайно ли значение параметра сохраняется между запусками редактора?

Нет, это всего лишь аргумент командной строки (не имеющий состояния).

ХОРОШО. Кроме того, кстати, доступна ли эта опция в Godot 3.1.1 (версия, на которой я проводил большую часть тестирования здесь)?

ХОРОШО. Кроме того, кстати, доступна ли эта опция в Godot 3.1.1 (версия, на которой я проводил большую часть тестирования здесь)?

Если вы используете 3.1.1 для проверки этого, вам нужно будет перемещать объекты на расстояние, пропорциональное разнице во время _process, поскольку нет фиксированной интерполяции временного шага.

@ starry-abyss Этот аргумент командной строки был добавлен в 3.1, поэтому он должен быть доступен и в 3.1.1.

Итак, --fixed-fps 60 мне не помогло. И запуск игры из командной строки напрямую тоже не помог (у меня все еще был отдельный экземпляр редактора на экране, хотя для более быстрого воспроизведения).

А также попробовал оба сразу, в случае, если запрос --fixed-fps 60 подразумевал это, все еще дрожит.

Вчера сложность воспроизведения была связана с тем, что в предыдущих тестах у меня была отключена вертикальная синхронизация. : /

нет фиксированной интерполяции временного шага.

Конечно, я тестирую методы один за другим, а не все сразу (не как плагин интерполяции + dwmflush + любая новая идея).
Также, пожалуйста, в следующий раз включите конкретные шаги, чтобы опробовать новую идею, чтобы мне не приходилось угадывать версии Godot, запускать редактор или игру напрямую и т. Д. У меня нет желания пробовать все возможные комбинации всего (с каждая идея удваивает количество комбинаций). :П

Конечно, я тестирую методы один за другим, а не все сразу (не как плагин интерполяции + dwmflush + любая новая идея).
Также, пожалуйста, в следующий раз включите конкретные шаги, чтобы опробовать новую идею, чтобы мне не приходилось угадывать версии Godot, запускать редактор или игру напрямую и т. Д. У меня нет желания пробовать все возможные комбинации всего (с каждая идея удваивает количество комбинаций). :П

Я понимаю, что это не упоминается в документации, и в ядре нет фиксированной интерполяции временного шага. Возможно, мне стоит попробовать написать что-нибудь об этом для документации, я раньше не добавлял документацию.

_В результате получается следующее: _
Независимо от других проблем (дельта, ОС), если вы используете физику или перемещаете объекты в _physics_process, в настоящее время Godot будет выдавать дрожание в результате сглаживания между тиками физики и фактическими кадрами. В некоторой степени это будет происходить во всех комбинациях тиков физики / частоты обновления монитора, некоторые из них будут хуже, чем другие.

Метод «исправления джиттера» был попыткой обойти это сглаживание, сделав его менее выраженным (оно все равно будет происходить). Подумайте о сглаживании лестницы.

Чтобы предотвратить этот джиттер «базового уровня», вам в настоящее время необходимо либо
1) (Доступно во всех версиях Godot) Перемещайте объекты в _process и перемещайте их на расстояние, пропорциональное дельте. Это не идеально для игр, поскольку вы не можете использовать физику, а поведение зависит от частоты кадров, однако это нормально для тестирования джиттера.

2) (Доступно в Godot 3.2 и новее) Используется фиксированная интерполяция временного шага. Это действительно возможно только в версии 3.2 с функцией Engine-> get_physics_interpolation_fraction (). См. Https://github.com/lawnjelly/smoothing-addon для примера того, как это использовать.

Это предварительные условия ДО того, как вы начнете исследовать джиттер. Они дадут линейную зависимость между положением объекта и временем, чего мы и хотим.

Альтернативный (более удобный для новичков) метод достижения этого - полуфиксированный временной интервал, о котором я получил PR с июля № 30798.

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

Здесь действуют 3 основных фактора:

1) Линейная зависимость между положением объекта и временем из игры (см. Выше)
2) Ошибка времени ввода
3) Ошибка времени вывода

Удалите (1), как указано выше. Исключите (2) с помощью аргумента командной строки, тогда вы можете исследовать (3) изолированно.

Кроме того, для любого исследования джиттера вы должны перемещать объекты напрямую, а не с помощью физики, поскольку физика потенциально может добавить джиттер сама.

_Редактировать:_
Я только что взглянул на проект с минимальным воспроизведением в этом потоке (избегайте крипов), и он движется со скоростью * delta в _process, что должно быть нормально. Он действительно полагается на is_action_pressed, и лично я бы удалил это как возможную проблему, но, вероятно, это нормально. Если вы используете другой проект для проверки джиттера, обратите внимание на пункты выше.

@lawnjelly Понятно . У меня сложилось впечатление, что плагин интерполяции все еще тестируется только несколькими парнями и может содержать ошибки (и даже увеличивать джиттер). Итак, я взял то, что стабильно (3.1.1), вот как у меня "научный" работает.
Я попробую с новыми соображениями в следующий раз.

Я только что посмотрел на проект с минимальным воспроизведением в этой теме

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

Итак, --fixed-fps 60 мне не помогло.

Это очень полезная информация. Кажется, это действительно сдвигает острие обвинения в сторону задержки вывода (и композитора) и придает вес подобному подходу в PR. Это предполагает использование двойной / тройной буферизации и поддержание подачи в конвейер, а не отбрасывание кадров.

Это также относится к @TerminalJack с аргументом командной строки?

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

Ах хорошо, спасибо! : +1:

@lawnjelly Понятно . У меня сложилось впечатление, что плагин интерполяции все еще тестируется только несколькими парнями и может содержать ошибки (и даже увеличивать джиттер).

Немного не по теме, но все должно быть в порядке (я не касался этого несколько недель), не должно вызывать дрожание. Если вы обнаружите какие-либо ошибки, дайте мне знать о проблемах или даже сделайте PR. : +1: Я собираюсь добавить его в официальные аддоны для 3.2 _ когда я доберусь до него _: smile:.

@lawnjelly

Это также относится к @TerminalJack с аргументом командной строки?

Извините, у меня не было возможности опробовать ваши предложения. Я как бы попал в кроличью нору по проблеме, над которой работаю.

@lawnjelly В ходе нашего обсуждения в ветке PR я просто подумал, что упомяну, что вы были правы в отношении параметра командной строки --fixed-fps <fps> . Фактически, он поддерживает vsync. Итак, как вы и говорили, его использование - хороший способ устранить любые проблемы с вычислением дельты. Я, должно быть, напортачил, когда пробовал это раньше, и у меня было заикание, потому что сейчас это не так.

Я использовал эту опцию вместе с моими изменениями, чтобы убедиться, что использование DwmFlush() действительно помогает при работе вне редактора. Если вы отключите DwmFlush() вы можете вызвать заикание в игре, просто перетащив какое-нибудь другое окно или наведя указатель мыши на одну из запущенных задач на панели задач. Очевидно, что, поскольку игра работает с приоритетом «Выше нормального», этого не должно происходить. (И этого не происходит, если используется DwmFlush() .)