#мемасики

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

#мемасики #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 и потому вполне себе пригоден для геймдева 🔥

#лытдыбр

Вчера впервые сыграл в настольный вархаммер, пусть и не "большой" 40k, а Underworlds, но все равно очень понравилось 😊 Спасибо организаторам ❤️

#лытдыбр #common_lisp #видео

На своём утреннем стриме, потихоньку проникаясь Test-Driven Development (моего внутреннего перфекциониста-аутиста очень радует превращать свеженаписанные проваливающиеся тесты в вереницу зелёненьких), наткнулся на уморное сообщение от компилятора SBCL, см. видос. ЛЕКСИЧЕСКОЕ ОКРУЖЕНИЕ СЛИШКОМ ВОЛОСАТОЕ, КАРЛ!

#лытдыбр

Спам категории «фэнтези»: г-н Кадзухиро Токимаса из ЯНДЕКСа пишет с домена outlook.com и предлагает присоединиться к его команде за щедрое вознаграждение в размере 2000 рублей в день. В принципе, уровень зарплаты как раз яндексовский, но в остальном, конечно, эклектика

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

На протяжении уже пары недель маниакально работал, чтобы вчера выпустить версию 0.1.1 своего мини-фреймворка для паттерна Entity-Component-System на Common Lisp: https://gitlab.com/lockie/cl-fast-ecs
Пока там только базовая функциональность, но я продолжаю маньячить над кодом на утренних стримах 😅

#лытдыбр

Дожили, использую ЧятЖПТ, чтобы придумывать имена переменным 😅 Как известно, именование — одна из двух самых сложных проблем в программировании, наряду с инвалидацией кэшей и off-by-one-error, так что не грех для этого использовать математическую модель с миллиардами параметров)
Довольно интересный экспириенс, оно не даёт каких-то внятных, готовых к использованию ответов, но по мере того, как пытаешься сформулировать правильный промпт, сам начинаешь понимать, что же тебе нужно, и вот уже оно становится не нужно 😁