Advertisement
Guest User

bfme

a guest
Nov 20th, 2018
185
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.28 KB | None | 0 0
  1. В общем, баг известен с релиза игры и в течение 15 лет мешает жить всему коммьюнити, имеет актуальность только в мультиплеере. Имеет имя *off-host delay*. Суть в том, что при игре через LAN (без разницы, виртуальная это сеть или два компа физически рядом стоят), компьютеры-клиенты видят происходящее в игре с задержкой в одну секунду. Это касается всего, в том числе и их собственных действий.
  2.  
  3. Это порождает две проблемы:
  4. 1. Ты видишь все действия противника на секунду позже, чем они происходят на самом деле, что даёт хосту большое преимущество, так как off-host-player имеет меньше времени на реакцию. Да, секунда кажется незначительной разницей, это же не шутер_от_первого_лица, но это не так, коммьюнити сильно страдает по этому поводу.
  5. 2. На твои собственные действия игра тоже реагирует с задержкой, то есть ты направил юнита делать что-то, эта команда сразу ушла на сервер, но твой клиент отобразит это только спустя секунду, в течение которой создаётся ощущение, как будто игра лагает, так как приказ юниту ты уже дал, а реакции нет.
  6.  
  7. На данный момент известно, что есть некая единица logic frame, на основе которых происходит общение сервера и клиентов. Logic frame пересылаетс раз в 200 ms, то есть 5 раз в секунду. Таким образом, положение дел у клиента отстаёт от реальности на 5 logic frame'ов. При это рассчитана строго на 30 кадров в секунду, но через конфиги или редактирвоание памяти можно установить другое значение. Повлияет это только на то, будет ли движок вызывать Sleep в конце main-loop'а, и если будет, то на как долго.
  8.  
  9. НО, если поставить 60 fps, то секундная задержка исчезает. В сингле при этом ускоряется вообще всё, а в мультиплеере ускоряеются только менюшки, чатики, скроллинг, но сама игра продолжает работать на 30 fps с глитчами и артефактами. То есть мы бегаем по main-loop'у с двойной интенсивностью, но есть какая-то синхронизация на уровне сети или рендера - не знаю - которая оставляет игру на прежней скорости. По ощущениям, при 60 fps теряется примерно каждый второй кадр анимации, поэтому всё двигается рывками.
  10.  
  11. Если поставить, например, 40 fps, то off-host delay просто уменьшится, но не исчезнет совсем.
  12. Я подозреваю, что если у нас за секунду обрабатывается 5 logic frame'ов, то один logic frame обрабатывается каждые 6 обычных кадров. И если клиент отстаёт на одну секунду от сервера, а при 60 fps задержки нет, то прирост на каждые 6 кадров уменьшает задержку на 200 ms (весьма условно конечно). Складывается ощущение, что есть некоторое queue с логическими фреймами, которые буферизируются, а клиент потом разбирает их. Возможно, в 2004 году (интернет ещё не был таким стабильным) в этом даже был смысл: появлялась задержка в одну секунду, но сам геймплей делался более плавным - не знаю. Вот, таким образом прирост в 30 кадров (с 30 до 60) делает так, что движок вытягивает элементы из очереди быстрее, что уменьшает задержку. Отсюда и вывод, что клиент получает всю информацию вовремя (и на действия игрока-клиента он тоже способен реагировать вовремя), но не делает этого по каким-то искусственным причинам.
  13.  
  14. Все три игры серии Battle for Middle-Earth наделены этим багом. При этом в других играх (Command and Conquer: Generals / Zero Hour) на том же движке (SAGE Engine) этого бага нет.
  15.  
  16. Экзешник очень здоровый - 10 мегабайт. Я провёл некоторое время с идой и дебагером, но пока что безуспешно.
  17. Знаю, где голова и хвост основного цикла, где разбор сообщений окна, где вызов функции, в дебрях которой вызывается сама смена кадра, где recvfrom вызывается для сокета, но этого пока что недостаточно, кода слишком много. Я в этом деле начинающий, большая часть информация добыта за счёт того, что сама IDA достаточно умная, а не я. Ну и тестами.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement