javawatch
884 subscribers
454 photos
6 videos
1 file
477 links
- Все про разработку
- Всратые новости
Download Telegram
Опять скрипит потертое седло!
Веду второй трек конференции SmartData.
Наконец-то докладчик говорит свой доклад и можно снять фоточку
Сейчас после конференции дошел до кровати, лег, полежал немного. Хочу сходить на кухню пожрать.

Резко встаю - и как будто на секунду залипаю как в киселе, а дальше снова легко. Смотрю себе на руки - и не вижу их! Ни рук, ни тела, ничего нет.

Думаю - что за фигня, я наверное отравился или заболел!

Иду на кухню, сворачиваю по коридору - та же фигня! Вначале как в киселе и тело видно, потом снова ничего нет. Даже не прозрачный - ничего.

Дошел до кухни, вынимаю пиццу из коробки - всё то же самое. Мне, прямо скажем, поплохело.

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

Артем говорит: "так а что ты хотел, это известная проблема. Самые важные события, "настоящие" лежат в I-фреймах, а всё что посредине - кодируется нейросеткой с частотой не ниже чем фреймрейт в DLSS, и промежуточные результаты складывает в B-фреймы. Там кроме B-фреймов ничего нет.

А тормоза случаются, когда сетка пытается отследить, что ты пиццу начал жрать или что-то такое. Надо квадратик вокруг тебя нарисовать, протречить его."

"Так" - говорю я - "так если всё считается с частотой фреймрейта, то почему меня нет посредине?"

"Ты у нас" - говорит Артем - "очень большой человек, много пиццы жрешь, поэтому не успеваем тебя обсчиать. Но нельзя же мир от этого останавливать, поэтому мы тебя по границам спайков в сложности просто не рисуем. Ты у нас отдельным слоем, это легко."

"Блядь" - говорю - "если первый я в первом I-фрейме и второй я во втором-айфрейме ничем вобще не соединены графически, ни единым вектором, то каким образом понять, что второй "я" - это всё ещё я, а не совсем другой человек?!"

"Олег, какой ещё "ты", очнись! Там только одни кадры, там больше ничего нету!"

===

Я проснулся и пошел жрать пиццу на кухню. Больше ничего не тормозит и тело всегда видно.

Одно меня беспокоит - как часто на самом деле стоят ключевые кадры и сколько на это тратится ресурсов. Ведь на самом деле в мире нет никого, там только одни кадры.

Надеюсь, там на верху нет никакого "райского Амазона", и мне потом не выставят счёт за весь потраченный GPU. Возможно, библейский грех "чревоугодие" имеет под собой куда более понятые и меркантильные мотивы - экономия денег на счёте облачного провайдера.
Начал разбираться в WebRTC. Пока что наблюдение за готовыми проектами - всё работает через жопу. Рвется связь, случаются дикие вещи вроде сплитбрейна, видео не работает в Сафари (а в других браузерах на iOS WebRTC вообще невозможен), и так далее, и тому подобное.
Вот ругаются на забагованность Киберпанка. А между тем, главная проблема музыки в России известна, и производители контента адаптируются к этому

Вряд ли у кого-то нет такого постоянного скребущего ощущения, что "еще неделя - и сделаем". И оно может длиться месяцами, годами. У меня на работе (на любой из всех что были) так было примерно постоянно - релизы сдвигались, сдвигались, сдвигались.

И у Киберпанка релиз сдвигался, сдвигался, сдвигался. И даже в самый последний момент, очевидно, им оставалось всего недельку-то доделать. И это нормально, у всех так. Что, создатели Киберпанка - не люди что ли?

Собственно, поэтому и придумали фреймворки со спринтами внутри (например, scrum). Планируем разработку на 2 недели или около того - один "спринт". После спринта разработчики останавливаются и смотрят на сделанное как на что-то чужое, самостоятельное и завершенное. И планируют следующий спринт как нечто совершенно новое, с чистого листа.

Имхо, это очень крутая психологическая установка. Можно например, считать каждый новый день своей жизни отдельным спринтом. Или каждый час. Или каждую таску в todo-листе. Насколько знаю, спортсменов учат делать такую перезагрузку восприятия каждую составную часть матча например, в баскетболе.

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

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

Было бы неплохо, если бы сюжетные игры тоже делали в формате сериала. Ну например, Telltale и делали, но куда-то сгинули. Life is Strange, опять же.

Но ведь и Киберпанк можно было открывать кусочками, например вначале выкатить один только пролог, который довольно неплохо работает.

И не было бы всех этих толп нытиков, у которых в зеркале иногда прическа не рисуется (да, у меня тоже иногда не рисуется, и что, это на что-то влияет?). И можно было бы использовать фидбек от сообщества, которое выступило бы в роли тестировщиков.
К сожалению, в реальной игрушке WebRTC - это только часть, хотя и значительная. Похоже, пока не сделаешь платформу для экспериментов, о звуке можно забыть.

А для платформы основная часть - это объектная система и неткод синхронизации. Не так важно, как и каким движком рисуются участники, как синхронизация их местоположения на карте.

Если кому-то это интересно, могу посоветовать вот это видео с GDC трехлетней давности. Конечно, механика из Overwatch - это из пушки по воробьям для более простых применений, но там есть масса интересных идей.

Кстати, заметьте, какой крутой работодатель Blizzard. Они позволили пойти и рассказать обо всем этом наружу. Создатели мобильных донатных дрочилен из славного града Новосибирска скорее бы удавились насмерть, вывезли этого чувака в ближайший тёмный лес и заставили копать себе могилу, чем позволили вот так открыто рассказывать про их интеллектуальную собственность (c)(r)(tm)

https://www.youtube.com/watch?v=W3aieHjyNvw
Кроме того, чтобы чесать языком в телеге, я имею счастье работать в команде Big Data Tools. Не могу не сообщить, что только что вышло новое крутое обновление, приглашаю попробовать.

Привезли Питон, баги напротив - увезли. Работает глобальный поиск по ноутбукам. Питон очень-очень сырой, но в следующих релизах (возможно) будет лучше.

https://habr.com/ru/company/JetBrains/blog/533370/
Удручающее про события

Часть событий пользователь ожидает увидеть мгновенно: например, игрок выстрелил из хитскан пистолета по врагу. Но выстрел - это событие, и это событие ложится в общую очередь в самый конец. Чем больше событий, тем медленней очередь дойдёт до обработки этого конкретного, и получается, что от скорости железа на сервере и клиенте зависит качество происходящего. Это еще неинтересная часть.

Интересная часть, что таких событий может сгенериться 100500 в секунду, и всё это ощущается как куча мусора. Во-первых, ни в Java (сервер) ни в JavaScript (клиент) нету легких дата-классов, и каждое событие - это самый настоящий долбаный объект со всеми гарантиями. Во-вторых, вся эта орава оседает на сборщике мусора, который работает совсем даже не мгновенно, ну и жрет оперативку. В Java и JS нельзя просто взять и удалить объект, когда ты понимаешь, что его жизненный путь закончен. Ты можешь только намекнуть рантайму, а уж как он поймет твои намеки - зависит от тысячи и одной причины.

А тут у нас время жизни очевидное - длина кванта симуляции * размер истории. Кажется, тащить мусор дальше, и потом устраивать stop the world чтобы его вынести - полнейшее расточительство.

Допустим, для электронного магазина это вполне нормально. Даже для банка. Много ли банков проводят болше чем сотню транзакций в секунду одновременно? Если что-то у них тормозит, они могут просто закупить побольше серверов и всё. А что, имеют возможность, с >100 транзакциями в секунду-то. Но маленькая игрушка - это не сириус бизнес, человек не может закупить себе ещё десять ПК и три новый айфона. А нагрузки из событий она генерит дай боже.

И вот возникает дикая идея - а может на хрен эту Java и JS, а писать этот код на C++. Всё равно, обработка событий как мутации глобального состояния - это не "системный код" , это просто какое-то подмножество языка, оно не обязано быть сложным. Я не умею писать на C++, но уж "field = value" я написать могу в любом случае.

Но это не поможет на фронтенде. Там только JS и всё. Есть еще webassembly, но это какой-то ад, лучше туда не смотреть даже пока Кирилл не выпустит на публику свой движок.

Можно еще не выпендриваться, а использовать прямые вызовы методов вместо объектов-событий, но тогда код превращается в говно. Или можно использовать преаллоцированные пулы объектов, но тогда писать это очень сложно, меня к такому жизнь не готовила.

Получается, пользователь в браузере, исходя из устройства современного мира, обязан страдать и видеть, как всё лагает, срабатывает не совсем вовремя и жрёт оперативную память. Судьба такая, ничего не поделаешь.
Там HashiCorp выпустили Nomad. Это "архитектурно легковесная" замена Куберу. Кубер умеет всё в себе, а Номад - это один бинарник, который делегирует как можно больше функций другим продуктам HashiCorp (например, сервис дискавери делает Consul, а секреты хранит Vault).

https://www.nomadproject.io/
Стыдное признание - писал сегодня ручкой по бумаге, впервые за последние 15 лет.
Потому что надо рисовать диаграммки, в формате чего-то среднего между UML и комиксами.

Немного порисовал их в Визио сидя за компом и возненавидел всё на свете. Когда нет вообще никакого понимания, что ты собираешься нарисовать и как оно будет выгляедть - похоже, ручка лучше, чем Визио.

Пойду сейчас окончательно зашквариваться - куплю в книжном магазине несколько тетрадок и цветных ручек, буду писать и плакать, писать и плакать. Плакать потому, что бумажные заметки имеют все те же недостатки, по которым я не читаю бумажных книг.
То, что я называл для себя общим словом "Spring", потому что в Java-мире нет ничего лучше, во внешнем мире называется ECS - Entity Component System.

Системы - это всякие @Component (не считая репозиториев), энтити - это @Bean, стейт энтитей - это data transfer objects которые ты руками оформил как pojo. Каждая система точно так же на входе заявляет тупл зависимостей (@Autowired поля).

Так ведь можно рассказывать о Java какому-нибудь C++-нику, чтобы он меньше офигевал от набора сказанных жутких слов и меньше тебя ненавидел 🙂
- Если вы заботитесь о своём пищеварении, мой добрый совет – не говорите за обедом о большевизме и о медицине. И – боже вас сохрани – не пишите до обеда на Java, JavaScript, Python и C++.

– Гм… Да но ведь других языков нет.

– Вот ни на каких и не пишите. Вы знаете, я произвёл 30 наблюдений у себя в клинике. И что же вы думаете? Поциенты, не пишущие на императивных языках, чувствуют себя превосходно. Те же, которых я специально заставлял писать тесты на Python, – теряли в весе.

– Гм… – с интересом отозвался тяпнутый, розовея от супа и вина.

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

Ах да, этот жабобоярин - из криптолибы BouncyCastle.

https://www.bleepingcomputer.com/news/security/bouncy-castle-crypto-authentication-bypass-vulnerability-revealed
Вчера выбирал, в чем вести заметки.

1) Многие советовали Adobe Sketchbook. А еще он стал бесплатным!

2) К сожалению, к тому чтобы вести заметки он совершенно неприспособлен. Все кто его советовал - либо врут как дышат, либо страшно мучаются.

3) Вместо него я перепробовал кучу всякого сомнительного софта и остановился тупо на OneNote. Он воспринимает ввод с планшета, умеет сглаживать рукописные буквы. Вставляет текст с клавиатуры и картинки. Синхронизируется. Есть управление записными книжками. Пойдёт.

4) Другая рекомендация - iPad Pro, но кажется, его имеет смысл покупать только когда закончится локдаун и нужна будет мобильность. То есть, с шансами - никогда.

5) Но кажется, всё это баловство, и проще всего писать на бумаге.
В сетевой игре у нас нет "настоящего времени", есть история и её симуляция. Клиент симулирует мгновенно, сервер - с отставанием. Нужно, чтобы симуляция на сервере и клиенте приводила к примерно одинаковым результатам (может быть, не идеально одинаково, но "достаточно одинаково")

Вижу три варианта:

1) Написать два разных языка/рантайма на клиенте и сервере. Придумать некий стандарт, "абстрактную виртуальную машину", которая будет проигрывать историю. Воплотить её на разных технологиях два раза: и на клиенте, и на сервере. Сказать, что конкретная реализация написана корректно, если для одной и той же истории она выдает те же результаты, что абстрактная машина из стандарта. Это чертова гора головняка, написать в точности один и тот же код на разных языках - непросто.

2) Написать симуляцию на одном и том же языке. Это означает либо отказ от браузера (и тогда писать можно на чем угодно). Либо написание на универсальном языке (или сервер на JavaScript, или клиент на WebAssembly).

3) Объединенный вариант: на универсальном языке написать интерпретатор какого-то простого скриптового DSL, единственная суть которого - переключение состояний. Тогда вместо стандарта будет готовая реализация: скрипт написан корректно, если работает на свежей версии интерпретатора DSL.

Заметки про третий вариант:

- Если сам по себе JS/V8 работает достаточно быстро (когда включается JIT), то интерпретатор, написанный на JS должен работать чудовищно медленно. Значит, остаётся только Wasm.

- Интерпретатор DSL сам по себе может быть ценностью, потому что может дать возможность делать какие-то вещи, недоступные для обычного языка. Например, обращать время для всего промежутка между сэйфпоинтами (в строго однопоточном случае с обратимыми операциями - для многопоточности нужен happens-before и это ужас).

- DSL на самом деле может быть простым подмножеством какого-то языка типа JavaScript, и тогда "прямое" выполнение может работать очень быстро - прямо на интерпретаторе первого уровня. Тормоза случатся только про ревинде, но к сожалению это должно происходить очень часто - примерно половину времени.
Выглядит сложно. Я начинаю догадываться, чем занимаются все эти игропрограммисты, не зря свой хлебушек жуют.
Отличное видео про архитектуру риплеев в Overwatch.

https://www.youtube.com/watch?v=W4oZq4tn57w

(Кроме того, в самом начале там уточняется терминология, которая используется в видео Тима Форда простыми словами.)
Про "обращаемый язык", про который писал вчера. У меня была наивная мысль для каждого листа AST сделать обратную операцию и отмотать историю.

Сейчас погуглил, это целая научная проблема. Пока нашел хороший кейворд для гугления - "инверсная семантика", а во-вторых есть мастер тезис про обращаемые объектно-ориентированные языки. В отличие от простого Janus, с разбора которого начинается тезис, автор пытается построить полноценного обратимого ООП-монстра. Мне такое, конечно, не нужно, но это может оказаться хорошим гидом по граблям.

https://arxiv.org/pdf/1707.07845.pdf
Я пока читаю книжку про синтаксис C++ и наверное, пропаду от этого на пару дней (невообразимо нудное занятие).

А пока хочу показать целый ДОКЛАД про то, о чем я писал вчера - реверсируемый язык, который написали в Blizzard для Overwatch. (С Ютуба они его удалили - боятся конкурентов лол? Поэтому вот этот странный видеосервис)

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

Важно, что в целом "отмотку времени" пользователь визуально не видит. Даже если отмотка затрагивает несколько кадров, её симуляция делается внутри одного кадра. Т.е. ты можешь выглянуть в окно и пойти пить чай, и внезапно телепортироваться назад во времени к окну, где ты стоишь с простреленной головой - это произойдет единомоментно. Важно, что это именно отмотка, а не восстановление полного снапшота состояния всего игрового мира.

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

https://www.bilibili.com/video/av74390948/
Ребятки, не будьте же вы такими [как бы так сказать слово "тупыми", чтобы не было токсично] - эээ консервативными!

Вчера придумал идею про реверсивный язык. Все такие сразу - да ну, дичь какая-то. Сегодня привожу пример уже реализованной системы - о, ну раз реализована, значит хорошая штука!

Давайте еще накинем фрейм поверх фрейма: реализована, но только в одной-единсвтенной игре. Согласно общей идее эээ консервативности, ответ на такое - ну, значит дичь какая-то!

Паттерн прослеживается очень простой: если что-то используют все ваши знакомые - значит это круто, а если не использует вообще никто, в особенностит если оно придумано примерно три секунды назад - то это дичь

Есть вот такая картинка, с вашего позволения я на ней порисую, чтобы показать в чем у вас проблема
Картинка получена из отличной книги "crossing the chasm".

Иногда chasm - это не минус, а отличная штука. Во-первых, можно писать саркастические посты в телеге про тех, кто справа. Во-вторых, меньше народа (слева) - больше кислорода! 🙂
Рома Шапошник подогнал раширенную картинку