#лытдыбр

Давеча немножко пощебетал в твиттере с господином Сандером Мертенсом, автором библиотеки Flecs, реализующей паттерн Entity-Component-System, который позволяет эффективно хранить и обрабатывать данные об объектах в игровых мирах. Я эту библиотеку даже в своё время демонстрировал на открытом уроке на работе.
Сандер начал к своему детищу прикручивать планировщик запросов, прямо как в настоящей реляционной базе данных, и, внимание, небольшую виртуальную машину, что, на мой взгляд, жуткий оверкилл. Возможно, к таким архитектурным решениям его привёл выбор реализации паттерна, — классически есть два стула варианта: на основе разреженных массивов, это тот подход, которого я придерживаюсь в своём движке, и на основе т.н. архетипов, когда объекты со схожими наборами компонент группируются в таблицы. Опять-таки, второй подход мне кажется более громоздким.
В твиттере я Сандеру немножко набросил на вентилятор, мол, больно уж ваш труд на Prolog/Lisp смахивает 😅 Сандер, в свою очередь, пояснил, что большая часть сложности его реализации проистекает не из-за поддержки взаимосвязей между объектами (что мне, конечно, тоже кажется оверкиллом), а из-за поддержки в запросах булевских операторов Not/Or и т.д. Что ж, в ближайших планах у меня оформление собственного кода для ECS в отдельную библиотеку, плюс обогащение его идеями, подсмотренными в том числе у Сандера, так что там видно будет 😊

#лытдыбр #проекты

Наконец перетащил все запланированные на будущее задачи в проекте d2clone-kit из issues Gitlab'а в простой советский трёхкопеечный Org-файл: ROADMAP.org. Как мне представляется, это такой ультимативный анти-vendor-lock-in: даже если Gitlab последует судьбе Github и будет скуплен Microsoft, и если придётся переезжать на какой-нибудь, прости г-ди, Sourcehut или вовсе хостить проект на CGit, запущенном на Raspberry Pi под кроватью — все мои планы останутся со мной в неприкосновенном виде 👍🏻
Ещё бы перетащить все TODO из комментариев в кодовой базе туда же, но тогда файл станет неприлично огромным 😅

#анонс #видео

Завтра в 9:00 МСК собрался триумфально вернуться на twitch немножко постримить кодинг ECS-библиотеки на Common Lisp, часик-полтора, не более. Особой пикантности стриму придаст тот факт, что в моём часовом поясе он начнётся в 7:00, так что буду максимально невыспан, но другого времени в плотном графике дел найти не удалось.

Трансляция, как всегда, будет тут: https://twitch.tv/awkravchuk. Записи не будет, но потом планирую из нарезок стримов смонтировать один небольшой видос. Оставайтесь настроенными 😊

#лытдыбр

Ну что ж, вот снова пошла вода по трубам в моём утреннем стриме 😊
https://twitch.tv/awkravchuk

#мемасики

Тут это, произошло аниме 😁
Есличо генератор вот этот https://imgcreator.zmo.ai/genwitht

#репост

Немножко мотивации от коллеги-лиспера 😊

#мемасики

Wow, this is literally me 😅

#лытдыбр #мемасики

На прошлых выходных пытался настроить Netflix на Raspberry Pi, воткнутой в телевизор, и, как всегда, чуть не улетел в космос на жопной тяге из-за пакетного менеджера Debian. Можно сколько угодно шутить про Gentoo, однако сообщения об ошибках от её пакетного менеджера всегда предельно ясны: "программа foo не может быть установлена, потому что зависит от библиотеки bar с выключенным USE-флагом baz, но уже установленная программа qux требует, чтобы USE-флаг baz у библиотеки bar таки был включен". Debian'овский пакетный менеджмент хорош, более того, я считаю, что Debian — самый годный из дистрибутивов с бинарными пакетами, но его сообщения об ошибках меня уже второй десяток лет поражают до глубины души: "kodi-bin:armhf : Depends: libsmbclient:armhf (>= 2:4.0.3+dfsg1) but it is not going to be installed". А почему libsmbclient:armhf 2:4.0.3+dfsgklmnёprst не будет установлен? Да потому что пошёл ты нахуй, вот почему. Понятная картинка (я аж GIMP ради неё расчехлил):

#fennel #проекты

Наш с товарищем игровой проект, судя по всему, переезжает с Defold на Löve2d — первый, конечно, является замечательным движком, но больно уж мне не нравится, что прежде чем написать хоть строчку кода, в нём нужно полчаса вазюкать мышкой, коей необходимо мацать туда-сюда графическое представление игровых объектов в редакторе. В Löve2d всё делается кодом, никаким редактором и не пахнет 😅
Заодно благодаря переезду появилась возможность сделать истинно интерактивную разработку, прямо как в горячо любимом нами Common Lisp 😊 Не без костылей, конечно, но стараниями господина Фила Хагельберга в Fennel и парой взмахов моим напильником получилось как будто бы сносно, см. видос.

#common_lisp #лытдыбр

Сегодня на утреннем стриме зритель задал коронный вопрос, почему, мол, пишешь на лиспе. Я выдал вот такой экспромт 😅

https://youtu.be/iGkkRwCj3Po

Пора бы побриться, да

#мемасики

Твоё лицо, когда пытаешься установить триалку LispWorks

#лытдыбр #соцсети

Пока не знаю зачем, но завёл себе учётку в Mastodon, пусть будет: @awkravchuk@functional.cafe

Первый раз в моей жизни, когда мне пришлось гуглить, как пользоваться социальной сетью, лол. Чтобы не забыть:

• a favorite is for the author ("I liked this")
• a bookmark is for you ("I want to see this again later")
• a boost is for your followers ("more people should see this")

О, про мой любимый город пишут ❤️

#мемасики

Хахаххах подождите ето не мем, ето моя жызнь

#мемасики #linux

Базированная база, только у меня вместо XFCE — i3 с 2017 года, а до этого с 2012 был awesome WM, который визуально и функционально был примерно таким же 👌

#проекты #common_lisp

Вот уже третью неделю по утрам занимаюсь тем, что выпиливаю из своего проекта d2clone-kit код, реализующий паттерн Entity-Component-System в отдельную библиотеку с пермиссивной лицензией, которую можно будет использовать в других проектах, и стримлю процесс на Twitch (записи не выкладываю, но вот-вот найду время на монтаж недлинного видео-нарезки).
Рабочее название библиотеки, или, скорее, мини-фреймворка — cl-fast-ecs. Паттерн ECS, в свою очередь, необходим для того, чтобы хранить и обрабатывать игровые объекты таким образом, чтобы обеспечивать максимальное быстродействие, собственно, главная его идея состоит в хранении логически взаимосвязанных данных игровых объектов последовательно в памяти, чтобы расчёсывать кэш процессора вдоль шёрстки 😽

По ходу реализации понял, что для наибольшего быстродействия придётся изменить схему хранения, со sparse array в терминологии г-на Мишеля Каини, автора аналогичной библиотеки EnTT для C++, на big matrix в его же терминологии. Первая позволяет экономить память, при этом продолжая почти также эффективно утилизировать кэш процессора, но возникают проблемы, если нужно перебрать несколько разных аспектов данных (компонентов в терминологии ECS) у объектов одновременно — при этом паттерн доступа к памяти оказывается таким же хаотичным, как и без всяких этих наших ECS. Более того, аналогичные проблемы возникнут и тогда, когда понадобится обратный индекс, т.е. возмножность по конкретному значению поля компонента получить один или несколько объектов, которым оно принадлежит, — такое может быть полезно для реализации имён объектов, или взаимоотношений между объектами (например, родитель ⇿ дочерний объект).

Помимо sparse array, есть вариант реализации под названием archetype, он используется в сишной библиотеке Flecs, но этот вариант довольно сложен в реализации, мне не кажется, что я бы его потянул в какое-то разумное время. Остаётся третий, самый простой вариант, именуемый big array или big matrix, в котором данные объектов просто сваливаются в огромные массивы соответствующих типов, по длине равные количеству объектов в игре, и насрать, если не у каждого объекта есть все аспекты данных (компоненты). Понятное дело, что память при этом расходуется чудовищно неэффективно, по моим примерным прикидкам, в типичной среднего размера игре с двумя сотнями разных компонентов, каждый из которых содержит в среднем по пять полей данных, на каждый объект будет расходоваться где-то по 8 килобайт памяти, т.е. миллион объектов — и вот игра уже выжрала 8 гигабайт 😅 Зато быстродействие у этого метода самое непревзойдённое, никаких лишних хопов по памяти, всё оседает в L1/L2/L3 кэшах, красота кругом. Можно даже решить проблему с излишней памятью, добавив механизм разбиения массивов с данными компонентов на "страницы", но это я решил отложить на будущее.

Решив поменять внутреннее устройство, понял, что и без тестового фреймворка не обойтись, несмотря на то, что я обычно свято следую принципу "I don't always test my code, but when I do, I do it in production". В качестве такового взял rove г-на Фукамачи, благо он довольно симпатично выглядит и входит в состав шаблона проекта, сгенерированного для меня его же утитилой cl-project. Как всегда у г-на Фукамачи, не обошлось без косяков — из командной строки тесты почему-то не запускаются, приходится запускать лисповый файл с одной-единственной формой (asdf:test-system :cl-fast-ecs).

К чему я затеял этот суб-проект — надеюсь, в этом году будет проводиться ежегодный Lisp Game Jam, на котором удастся повыделываться этой своей библиотекой 😊 Собственно, задача-максимум — повторить вот эту дёмку, сделанную на Flecs, и сравнить быстродействие, — очень уж хочется показать, что Common Lisp по производительности может дышать в спину чистому C и потому вполне себе пригоден для геймдева 🔥