doom2d.org

Не секрет, что при r_interp=1 управление становится несколько ватным.
Было бы очень здорово это пофиксить.

У ЧД есть пара мыслей:

Dmitry D. Chernov» управление это проблема не интерполяции, а того, что оно привязано к UPS. все нормальные игры считают свою логику примерно вполовину реже, чем собираются выдавать fps, так что тут всё правильно, иначе бы тупо проца не хватало

Dmitry D. Chernov» ещё мб там косяк в том, что интерполяция считается от предыдущего кадра, а не от текущих скоростей объектов. тогда да, теряем тик на этом и получаем вату

Jabberwock» а вот это можно пофиксить?

Dmitry D. Chernov» можно и нужно. создай багрепорт на форуме, опиши вату и сошлись на обе мои идеи (либо криво интерполируем, либо управление, либо и то, и другое)

_________________
И неважно, что нет морей на Марсе, каждый морпех носит море в сердце.

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

DeaDDooMER» без пропуска тика любые решения будут всего лишь костылём, пытающимся предсказать будущее вперёд на 27.7 мс.
Почему же? Нам ведь известны текущие скорости всех объектов в промежутке между тиками.
Как только наступит следующий тик, координаты объектов будут увеличены на свою скорость, после чего уже она будет пересчитана.
Значит, в промежутке можно спокойно считать LERP( coord, coord+speed, (next_tick - NOW()) / tick_delta ) для X и Y. Или я что-то упускаю?

DeaDDooMER» и эти костыли без забавных эффектов не обойдутся.
Например? У нас же нет больше никаких факторов, кроме скорости, да и не может их быть, по идее.

DeaDDooMER» уверен что даже полный просчет промежуточных тиков не обойдется без эффектов и/или кучи особых случаев.
Так нам надо считать не промежуточные тики, а промежуточные кадры. Тиков должно быть 36 в секунду и точка, здесь у нас как раз всё нормально.
Я умудрялся делать такое даже в GameMaker 8.1, хотя тики там жёстко привязаны к кадрам.
Вот ссылка (может потребоваться VPN): https://www.ganggarrison.com/forums/index.php?topic=38250.0

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Упускаешь. Должен быть не speed, а speed_from_next_tick. Скорость сохраненная в объекте уже устаревшая на момент рендеринга. А скорость для следующего тика в общем случае не предсказуема, так как зависит от сайд эффектов в виде мясных пальцев человека.

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

То есть здесь получается надежда на обоснованное предположение, что чаще мы всё-таки предсказываем то, что нужно. Потому что вырожденных случаев только два: смена управления в момент между тиками и телепортация игрока. Второй можно обрабатывать явно.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Картинка на больших скоростях будет сильно расходиться с реальностью
Меняешь шило на мыло

DeaDDooMER» Картинка на больших скоростях будет сильно расходиться с реальностью
Можно впилить ограничение по скорости. Если слишком большая, то пусть с рывками летает. Но это ещё посмотреть бы, как оно в действительности расходиться будет.

DeaDDooMER» Меняешь шило на мыло
Не могу согласиться. Все эти проблемы в той или иной степени решаемы, в отличие от чудовищно раздражающего лагающего ввода.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Занимайся. Только не ломай как есть сейчас (т.е. отдельным режимом). УМВР и ничего не лагает.

DeaDDooMER» Занимайся.
Хорошо, но это уже скорее после вливания renders_updated в master, уж слишком много всего у тебя там поменялось.

DeaDDooMER» Только не ломай как есть сейчас (т.е. отдельным режимом).
Да, постараюсь сделать как r_interp 2. Если по отзывчивости окажется лучше, чем нынешний вариант, то просто поменяем их местами.

DeaDDooMER» УМВР и ничего не лагает.
Это вопрос восприимчивости. Скажем, я в упор не замечал присущий GameMaker лаг ввода всё то время, что играл в сделанные на нём игры, но как только попробовал gm8x_fix, то без него уже больше совсем не могу. А суть лага там была похожая: кадр рендерился, но на экран выводился только в начале следующего тика.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Подумалось ещё вот что, хотя это более общие соображения по точности ввода как таковой:

1. Ввод всегда надо брать непосредственно по месту обработки, а не запоминать его где-то в начале тика и уже потом оттуда доставать. Потому что между моментом считывания ввода и моментом его обработки игрок может успеть сделать новое нажатие, которое в таком случае придётся уже на следующий тик.

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

Частично связано с вот этим: viewtopic.php?f=36&t=3437. Но там поправить куда проще.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

1. Забинденные команды по нажатию кнопок выполняются всегда, в порядке нажатия кнопок(ну или как бэкэнд выдаст). Для большенства команд проблемы уже нет.
2. Для команд-действий игрока (+left/-left и ко) достаточно будет сделать дополнительным флажком "было нажато в этом тике" и использовать его внутрях игры вместо текущего "кнопка зажата". Очередь не нужна.
3. Использование InputBuffer и функций ввода из e_input вообще надо в повыкидывать, а не расширять использование, так как это приводит к захардкоженным кнопкам.
Плохая идея. Сейчас кнопка нажата, а через строчку уже не нажата, а ещё через строчку снова нажата. Бред и прямой путь к невоспроизводимым багам.
Весь инпут должен собираться в начале тика и оставаться одинаковым в течении тика.

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

Так клавиши не отжимаются. Виноват, во втором пункте должно было быть "все клавиши, нажатые до конца тика", я слово пропустил. Исправил.
Учти ещё, что тут мной неявно подразумевается опрос ввода вне FPS и UPS.

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

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.