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, то без него уже больше совсем не могу. А суть лага там была похожая: кадр рендерился, но на экран выводился только в начале следующего тика.

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