То, что табличка уже сделана, надо только таймер убрать. И не факт, что Флэш-клиенту можно отдавать статичную страничку вместо swf-ки. (Скорее всего нет, это же не Electron.)

Марк, ты ли это?

Да это может быть экспериментом по выпиливанию дропа вообще. Не, а что? Припасы только в гараже/из контейнеров/из магазина. Звучит как бред, но... эти люди хотели убрать устройства в лутбоксы! От них можно все что угодно ожидать.

Как же? Неужто это не искреннее желание порадовать игроков и ностальгически проводить Флэш, а снова какой-то сухой расчет? Я так и думал.

http://s.eu.tankionline.com/resources/client/3/win/tankionline_eu.exe

Где шапку потерял?

Мне всем нравится HTML5, единственное только раздражали яркие вырвиглазные цвета. Но я нашел решение! Так и играю. Теперь HTML5 - идеален. Не понятно только где враг, а где нет, но спокойные цвета - самое главное в любой игре!

Чего сразу я? Я стараюсь для простого народа, донаты пусть мучаются. (На самом деле я представления не имею как это сделать и поэтому придумал глупую отговорку.)

Чертов колхоз с надписями выглядит еще хуже, чем я предполагал. Ну как вам теперь вовремя прожимается аптечка когда надписи загораживают индикаторы?

Я же говорил. Посмотрел логи на Линуксе и у меня показывает, что именно загрузка (выделяется синим) каждого файла занимает кучу времени. Очень странно. Да, это из-за системного масштабирования зоны управления (как это еще назвать?) некорректно расположены. На Винде то же самое. Я уже больше месяца назад сообщал об этой проблеме, взяли ли ее на заметку - неизвестно.

И еще раз не попал. Садисты никак насытиться не могут. ?

А может все-таки сделаем HTML5 лучше?

Ну я тебе и говорю, что это "почти то же самое". Там многое сделано для interoperability с JS (ну, это логично). По крайней мере, не вижу ни одной сложности фиксить такие баги на Котлине. Люди слишком много уделяют внимания языкам программирования. Не открою Америку заявив, что все популярные general-purpose языки в основе - the same shit, только каждый со своими "премудростями". А как придумываются новые языки? "Ну, мы хотим вот эту фичу как там, а ту - как здесь... А давай сделаем новый язык и заставим всех на него переходить!" (Да, я смотрю на тебя, Apple!). С моей точки зрения, это безумие. Но это так, лирическое отступление.

Причем тут Котлин? С Котлина доступны почти все API "из коробки" (т. е. уже типизированные), а те, что не доступны, все равно можно использовать через dynamic тип. Или можно даже заинлайнить чистый код JS - для извращенцев. Не знаешь, каким образом они пофиксили это чудо? Не понимаю, что сложного вызывать функции, которые не вызываются браузером, вручную. А им только с четвертой попытки удалось!

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

А вот здесь я взоржал. 700 ФПС в среднем. Вспоминается шутка "Корова утонула в реке, где ей в среднем было по колено".

Не самого древнего i7 на частоте 4.2 для игры на 240, как мы видим, не хватает: в какие-то моменты (и довольно часто) монитор будет превращаться в 120 герцовый. На какие-то мгновения. И сомневаюсь, что это не будет раздражать. Комфорт же в стабильности, а не в больших числах "почти постоянно". Куда бы я смотрел - так это в сторону G-Sync/FreeSync. С ними должно быть сильно лучше. К сожалению, сам это проверить я не могу.

Что смешного-то? Давай говори, мы тоже все посмеемся.

https://blog.chromium.org/2015/12/smarter-garbage-collection-for-smoother.html Для того, чтобы продемонстрировать суть, а именно боль игры на 240 Гц мониторе, этого достаточно. Время между началами подготовки будет больше - здесь к бабке ходить не надо. К тому же, чтобы время между подготовками было не 16.6 мс, нужно снимать лимит, и ты будешь гарантированно измерять еще и GC паузы. А я хотел всего-навсего измерить то, что блокирует дальнейшую отрисовку страницы - а это те самые функции, переданные requestAnimationFrame. После их выполнения браузер волен дальше композайтить страницу в другом потоке, который GC не затрагивает. Блин, это называется "смотрю в книгу, вижу..." Ну теперь все прояснилось.

Значит, что GC незачем тревожить код JS, если он может втиснуться между. Я же тебе давал ссылку. Хотя он теоретически может потревожить выполнение, но что-то я сомневаюсь, что он это так нагло делает, вызывая подобные скачки. Особенно учитывая, что затем идет куча почти idle time до следующего фрейма. То и значит. Это те функции, занимающиеся отрисовкой и внутриигровой логикой (хотя это спорно), и без выполнения которых поезд дальше не двинется, т. е. фреймбуферы не переключатся, если этого не произойдет вовремя (за 16.6 мс в вакууме) - на экран уйдет старый кадр и пользователь это заметит.

Какой GC? Мы же знаем, что GC выполняется отдельно от кода. А это чисто время выполнения функций, переданных requestAnimationFrame. Да по-быстрому состряпал, можно и подзаморочиться. Нет, это все из одной ММ битвы. Как бы то ни было, на 120 Гц мониторе пики еще не будут заметны (ну, не 52 мс конечно), выше - уже будут довольно часто. Особенно в начале битвы.

Ну, рендеринг в такой ситуации точно не выполняется. Привет, поломка управления. Получается, логика обрабатывается в другом месте, отдельно от рендеринга. Кстати, вот как довольно часто игра ведет себя по времени отрисовки (среднее за секунду и худшее): Вот тебе и 240 ФПС...

Еще бы время отрисовки периодически не подскакивало до 6-7 мс на довольно мощном компе...

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

Что-то он недоадаптировал. И где же хваленая упаковка ивентов?