60 FPS

Итак, ОФИЦЕР ГРАФОУНИ ОН ДЮТИ, короче слушайте, есть такая тема.
Движение персонажей и предметов происходит скачками, а спрайты потенциально не могут аккуратно анимироваться из-за слишком низкого установленного значения FPS в игре (12 в секунду).

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

Вот что я нагуглил по этому запросу:
https://code.google.com/p/arctic-observatory-13/source/browse/trunk/code/modules/admin/verbs/ticklag.dm?r=56

На большинстве форумов мне отвечали (или не мне, но отвечали) что изменение FPS в играх BYOND’a довольно простое дело.

Вы только представьте. Плавно открывающиеся двери. Движение персонажа без этих едва заметных, но бесящих “залипаний”. Да и много чего ещё.
Как думаете, пасаны, реально?

Пробывали уже, лагать начинает

Чему там лагать-то. Графон не на сервере отображается, а у пользователей.

Слишком хорошо и просто. Подозрительно

Мне вот подозрительно нахуя такой низкий ФПС изначально поставили. Что, ебать, спрайты рендерить за 0.016 секунды не успеваем? И спрайтов-то в области видимости игрока меньше чем у Sega Genesis, хотя Сега выдавала около 30 ФПС.

Очевидно, что нужно менять это на стороне клиента а не сервера, ведь, меняя на стороне сервера, наверняка будет еще больше лагов, так что полазил в памяти игры и нашел этот ваш tick_lag в byondcore.dll
Вот вам dll-ка с tick_lag-ом на 0. Просто скопировать в папку byond\bin
http://rghost.ru/55101604

Разница конечна большая
tick_lag 1 (стандарт)

tick_lag 0

ліл

У меня компу 7-8 лет, а ФПС на сске где-то 8-9.

А мне норм, подлагивает, персонаж медленно ходит, и ещё я никогда не видел графона.

Для более плавных дверей нужны более детальные спрайты, или больше времени для открытия.
А вот движение у меня более менее плавное, но только при ходьбе. Если шаг персонажа больше одного тайла то он начинает прыгать, а не ходить.

Если шаг персонажа больше одного тайла то он начинает прыгать, а не ходить.

Это зашито в бьенде.

A movement is considered a slide if src is moving from one turf to another on the same z level, and the total pixel distance is less than either src.step_size or a full tile size (whichever is largest). Any other movement is a jump. Movement to the same turf with no step_x/y change is also considered a jump.

Так я и говорю, что это так.

Спасибо большое, у меня были проблемы с тем что анимация не полностью проигрывалась, на половине или 2/3 обрывалась.
Теперь все работает отлично.

Да вы поехавшие.

Заменил, теперь вообще не запускает byond игры, благо сохранил перед этим нормальный фаил.

Наверное у тебя другая версия Byond’a. Лично у меня - 504.1234

переустановил на 504.1234
Терь пашет

Очевидно, что нужно менять это на стороне клиента а не сервера, ведь, меняя на стороне сервера, наверняка будет еще больше лагов, так что полазил в памяти игры и нашел этот ваш tick_lag в byondcore.dll

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

нужно менять это на стороне клиента а не сервера
Это очевидно, ведь сервер не рендерит спрайты, ему ФПС по барабану.

Итак, копипаста человека с форума бьёнда. Походу, адекватен.

If your game is setup by default in 32x32 pixels icons, technically the most smooth would be either 32 FPS or 64 FPS.

Edit: It’s also worth noting that having a “clean” number will effect performance as well. If you’re requesting 60 fps, you can’t actually get that because it doesn’t round down perfectly to a integer millisecond timing. In order for the client and server to stay in sync, they agree on a millisecond type of tick rate. So requesting 60 FPS will actually give you about 59. tick_lag IS the rate they agree upon, and is only available in milliseconds (nothing in between a single millisecond). Furthermore, BYOND makes no attempt to insure you’ll get stable ticks above 40. This is because they support too many operating systems and must adhere to these limitations in order to do so. It’s better to find a comfortable tick_lag rate that is a clean number (like fps = 40 which is tick_lag = 0.2) and to stick with that. You’re not going to need more response than 30 FPS probably ever in terms of input. But since the output (visual) is tied to the input with BYOND, you’ve gotta find a happy medium.

" Если в вашей игре 32х32 спрайты, технически самым гладким FPS для нее будет 32 или 64 кадра в секунду.

Следует заметить, что “чистое” (чё?) число также будет влиять на производительность. Если вы запросили 60 FPS, фактически вы не сможете их получить, потому как оно округляется не идеально к Integer в миллисекундах. Чтобы сервер и клиент были синхронизированны, они должны “согласиться” на конкретное число миллисекунд. Так что запрос 60 FPS на деле даст вам около 59. tick_lag является частотой, на которую они соглашаются, и эта чистота может быть указана только в миллисекундах (т.е., не менее одной миллисекунды). Более того, говноБьёнд не будет предпринимать попыток удостовериться что у вас будут стабильные тики выше 40. Так сделано потому что говнястый ебучий Бьёнд пытается поддерживать очень много ОС, и из-за этого придерживается таких стандартов. Лучшим решением в этом случае будет выбрать удовлетворяющий tick_lag, который будет “чистым” числом (например, 40 FPS, которые соответствуют tick_lag 0.2) и остановиться на этом. Вам едва ли понадобится больше 30 FPS, даже вероятно для удобства управления. Но, так как вывод (визуализация) связанна с управлением с обоссаного Бьёнда, вам нужно будет найти золотую середину. "

Перезалить можно? Если еще актуально.

Скачай билд бея и вруби во вкладке админов. Не ставь 0, оптимальное значение 0.3, меньше — визуально быстрее, но там всё будет работать немного… не так как нужно.

Там речь шла о дллке для клиентской стороны.