Hacker News Digest

В файле rlsw.h представлен упрощённый API SimpleWindow для raylib, созданный для быстрой разработки оконных приложений с минимальным кодом. Основная структура SimpleWindow инкапсулирует параметры окна (ширина, высота, заголовок), а SimpleWindowEvent обрабатывает базовые события (закрытие, перемещение, изменение размера). API содержит всего 12 функций, включая swCreateWindow для инициализации, swBeginDrawing/swEndDrawing для рендеринга, и swPollEvents для обработки ввода.

Ключевое преимущество — лаконичность: весь функционал сводится к нескольким вызовам, что идеально подходит для прототипов и небольших проектов. Поддерживаются все основные платформы (Windows, Linux, macOS), а зависимость сводится к одному заголовочному файлу без необходимости линковки. Разработчики отмечают, что это решение особенно полезно для образовательных целей или когда требуется минимальная сложность без избыточных возможностей полного raylib.

• Raylib теперь компилируется без внешних зависимостей, что делает его идеальным для встраиваемых систем и ретро-харда.
• Сообщество вспомнило, что ПО-рендеринг всегда был возможен, и теперь можно делать 2D/3D игры даже на 20-летнем железе.
• Появился спор о том, насколько полезен этот факт для разработки игр на микроконтроллерах и эмуляторах старого железа.
• Некоторые участники обсуждения отметили, что это также открывает путь к созданию игр для таких систем, как Nintendo 3DS и других портативных устройств.
• Были упомянуты проекты TinyGL и PortableGL как альтернативы, а также отмечено, что OpenGL 1.1-совместимое ПО-рендеринг всегда было возможно, но теперь это стало еще более доступным.

Practical Scheme — это коллекция библиотек и расширений для использования Scheme в качестве инструмента для повседневных задач системных инженеров и программистов. Автор, в настоящее время использующий Perl, стремится заменить его Scheme для обработки файлов, генерации отчетов, отслеживания процессов и создания GUI-оболочек. На сайте представлены как готовые приложения, так и библиотеки, некоторые из которых находятся в стадии alpha/beta. Основная цель проекта — сделать жизнь автора счастливее, без каких-либо гарантий для пользователей.

Среди ключевых инструментов — Gauche (версия 0.9.15, 2024), реализация R7RS Scheme с быстрым запуском и встроенными системными интерфейсами; WiLiKi, движок вики (0.6.2, 2014); и escm, фильтр для обработки Scheme-выражений в текстовых файлах. Также доступны библиотеки Gauche-gl (OpenGL, версия 0.6, 2014) и Gauche-gtk2 (GTK2, версия 0.6.1, 2022). Сайт содержит документы по применению Scheme в реальных проектах, включая создание баз данных для трекинга производства и обработку чисел с плавающей запятой.

• Сайт не обновляется, поэтому список инструментов устарел, но в целом он всё ещё полезен как ориентир.
• Список не охватывает все реализации, но охватывает те, которые действительно важны.
• Существует несколько реализаций Scheme, которые могут компилировать в исполняемые файлы, включая Chez Scheme, Chicken, Gambit и Bigloo.
• Некоторые из них могут компилировать в исполняемые файлы, но не все.
• Некоторые из них могут компилировать в исполняемые файлы, но не все.

Матрицы — это мощный инструмент, а не просто набор чисел. Первые девять элементов матрицы представляют поворот объекта. Например, первые три элемента первой колонки (m[0], m[1], m[2]) — это направление оси X после преобразования. Аналогично, следующие три (m[4], m[5], m[6]) — это новая ось Y, и так далее.

Вместо того чтобы выполнять множество отдельных операций (вращение, масштабирование, перемещение), можно просто применить одну матрицу, которая объединяет все эти преобразования. Это эффективно: один вызов к glMultMatrixf() заменяет множество вызовов других функций.

Например, чтобы повернуть объект на 45 градусов вокруг оси Z и переместить его на 10 единиц по X и Y, можно использовать матрицу, где первые три элемента первых двух столбцов — это косинусы и синусы угла, а последние элементы первого и второго столбца — это координаты перемещения. Это не только проще мысленно, но и эффективнее для процессора.

Таким образом, матрицы — это не просто математическая абстракция, а практический инструмент для эффективного и интуитивного управления преобразованиями в 3D-графике.

• Обсуждение развернулось вокруг того, как именно представлять и обсуждать матрицы: какие обозначения и соглашения используются, как они влияют на понимание и как они связаны с тем, как мы привыкли думать о линейных преобразованиях.
• Участники обсуждали, что в разных областях (математика, компьютерная графика, машинное обучение) используются разные соглашения, что может вызывать путаницу.
• Обсуждались различия между подходами "row-major" и "column-major", а также то, как разные ПО и языки программирования (например, C vs. FORTRAN) влияют на то, как мы представляем и обсуждаем матрицы.
• Также обсудили, что важно различать матрицы как сетку чисел и как линейное преобразование, и как это влияет на то, как мы думаем о таких понятиях как повороты и масштабирование.

Khronos одобрила расширение GL_EXT_mesh_shader для OpenGL, и это первый шаг к полному Mesh Shaders в линейке Mesa. Реализация уже влили в mesa, а вот драйвер RadeonSI ждёт своей очереди. Релиз ожидается в ближайшие дни.

Это первая крупная фича для OpenGL за долгое время, и она привнесёт геометрические шейдеры в core Mesa. Работа велась под эгидой AMD, при поддержке Qiang Yu и Shihao Wang.

• Обсуждение в основном вращается вокруг будущего OpenGL и его расширений, включая GL_EXT_mesh_shader и GL_EXT_descriptor_buffer, а также их влияние на Minecraft и другие проекты.
• Участники обсуждают, что новые расширения делают возможным использование шейдеров накладки и дескрипторов буферов, что может быть полезно для таких проектов, как Minecraft.
• Также обсуждается, что OpenGL всё ещё используется в Minecraft и других проектах, и что новые расширения могут помочь в разработке игр.
• Некоторые участники выражают обеспокоенность по поводу того, что OpenGL может быть вытеснен Vulkan и другими API, и что поддержка OpenGL может быть прекращена в будущем.
• В обсуждении также затрагиваются такие темы, как эволюция графических API и их влияние на разработку игр и будущее OpenGL.

Выпуск Blender 4.5 LTS знаменует завершение линейки 4.x, с фокусом на улучшении бэкенда Vulkan для рендеринга интерфейса и 3D-сцен. Хотя Vulkan ещё не включён по умолчанию из-за проблем с поддержкой сеток из 100+ миллионов вершин, он уже сравним по функциональности и производительности с OpenGL, предлагая лучшее использование многопоточности современных GPU для плавной работы вьюпорта.

Обновление также поддерживает соответствие стандартам VFX-индустрии через синхронизацию с VFX Reference Platform и обновления библиотек. Основное внимание разработчиков теперь переключено на Blender 5.0, где ожидаются масштабные изменения в системе Geometry Nodes, ключевой для процедурных неразрушающих workflow.

• Blender не является полноценной заменой параметрическим CAD-системам (например, Fusion 360, SolidWorks) для точного проектирования под 3D-печать или станки с ЧПУ, но может быть полезен для редактирования и исправления мешей.
• Для эффективной работы в Blender не требуется врожденный художественный талант; это навык, который можно развить на практике, начав с базовых руководств за несколько дней.
• Многие пользователи со схожим бэкграундом в CAD находят переход сложным из-за принципиально разных подходов к моделированию (полигональное vs. параметрическое), но в итоге осваивают и ценят Blender за гибкость.
• Blender активно развивается (ожидается версия 5.0 с новыми функциями, например, нодами для композитинга в видеоредакторе) и широко используется в индустрии (кино, AAA-игры), несмотря на сложности с UI.
• Выбор инструмента (Blender vs. CAD) зависит от конкретных задач: Blender силён в визуализации, скульптинге и работе с органическими формами, в то время как CAD-системы незаменимы для точного инженерного проектирования.

Разработчики создали полностью свободную альтернативу Minecraft, используя три независимых проекта: сервер Cuberite, прокси ViaProxy и клиент Minosoft. Это позволяет играть в совместимую версию игры без использования оригинального кода Mojang, что особенно интересно для энтузиастов open-source и тех, кто хочет избежать лицензионных ограничений.

Для запуска требуется 64-битная система с 4 ГБ ОЗУ, Java 17 и OpenGL-совместимая видеокарта. Cuberite эмулирует версию 1.12.2 с поддержкой измерений, а ViaProxy решает проблему совместимости между версиями протокола. Minosoft, написанный на Kotlin, завершает цепочку, предоставляя клиент с открытым исходным кодом.

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

• Обсуждаются технические требования и альтернативные реализации Minecraft, такие как Minosoft, Cuberite и Minetest (Luanti).
• Участники отмечают отсутствие официальной поддержки модификаций от Mojang и постепенный переход Microsoft на менее гибкую версию Bedrock.
• Предлагаются решения для совместимости разных версий, например, использование прокси-сервера ViaProxy для устранения багов.
• Minetest (Luanti) хвалят как образовательную платформу для обучения детей программированию, несмотря на некоторые ограничения.
• Упоминаются конкретные проекты, такие как Mineclonia, как наиболее близкие к оригинальному Minecraft по функциональности.

Космический симулятор на Clojure  
Автор: Jan Wedekind

В 2017 г. увидев проприетарный Orbiter 2016, решил написать свой симулятор. Первые прототипы — на C и GNU Guile, потом перешёл на Clojure: immutable-данные, быстрые коллекции, многопоточность через atoms/agents/refs.

Сразу взялся за сложное: 3D-планета, атмосфера, тени, объёмные облака. Открыл «OpenGL Superbible», изучил исходники Orbiter (90 % кода — графика) и понял, что выбор верный.

**Зависимости**  
- Clojure  
- LWJGL: OpenGL, GLFW, Nuklear, STB, Assimp  
- Jolt Physics — коллизии и машины  
- Fastmath — матрицы/сплайны  
- Instaparse + Gloss — парсинг NASA PCK/DAF  
- Coffi — FFI  
- Malli — схемы, Progrock — прогресс, Claypoole — параллельные циклы и др.  

deps.edn для Linux:

```clojure
org.lwjgl/lwjgl {:mvn/version "3.3.6"}
org.lwjgl/lwjgl$natives-linux {:mvn/version "3.3.6"}
;; аналогично для opengl, glfw, nuklear, stb, assimp

Для Windows — отдельная ветка.

Атмосфера
Реализован precomputed scattering Брунетона: 2D-трансмиттанс, 2D-поверхностное рассеяние, 4D-Релея и Ми. Таблицы строятся численным интегрированием; высшие функции на Clojure интегрируют по сфере и отрезку. Пример интеграла по лучу:

(defn integral-ray
  "Интеграл функции f вдоль луча"
  [{::keys [origin direction]} steps distance f]
  (let [step (/ distance steps)
        pts  (mapv #(%2 %1) (range steps) (repeat step))]
    ;; …
    ))

Проект живёт 5 лет, код открыт (CC BY-SA).

• Пользователи восторженно встретили проект Jank, особенно его визуалы и использование Clojure без Unity/Unreal.
• Критики отметили: 90% кода — C++ (OpenGL, физика, коллизии), Clojure лишь «высокоуровневый» слой.
• Спор: «функциональный» ли код, если рендер и физика императивны; сторонники отвечают — важна логика приложения, а не движок.
• Сомнения, что indie-разработчики массово перейдут на Clojure/Jank: язык нишевой, производительность и JVM пугают.
• Практический совет: попробовать библиотеки ham-fisted, neanderthal для ускорения.

Rasterizer — GPU-ускоренный движок 2D-векторной графики от mindbrix.
Проект на GitHub: mindbrix/Rasterizer.

• Автор показал компактный GPU-рендерер 2D-векторов (Rasterizer), 10 лет развивавшийся из VectorGL; использует «традиционный» граф-конвейер Metal, а не compute-шейдеры.
• Лицензия «personal-use zlib» вызывает вопросы: неясно, что считать личным/некомерческим и можно ли распространять ПО с этой библиотекой.
• Производительность конкурентна с Vello (Apache/MIT) и, вероятно, выше Rive на сложных сценах; у Vello бывают подвисания при зуме.
• Поддерживаются любые масштабы и огромные пути, но самопересечения и правило winding остаются главной головной болью параллелизации.
• Реализованы только базовые заливки; текста, градиентов, фильтров пока нет. Кеширование текстур не используется — 60 fps достигается полным перерисом.
• Планы: добавить коммерческую лицензию, написать подробный пост о методике, оценить порт на Vulkan/OpenGL.

В декабре 2020-го Хектор Мартин запустил Asahi Linux, а я, работая над Panfrost, лишь хотел подсказать. В итоге купил Mac mini и начал реверсить GPU. Через пару недель нарисовал треугольник, потом — компилятор шейдеров, а после сессии за несколько дней поднял OpenGL-драйвер.

Год улучшал драйвер, пока игры не пошли под macOS. Параллельно Asahi Lina писала kernel-драйвер; в декабре 2022-го у нас впервые заработала графика в Linux.

В 2023-м, заканчивая универ, я решил:

• довести M1-драйвер до ума;
• сделать полноценный OpenGL 4.6 и Vulkan;
• запустить Proton-игры.

Через месяц после выпуска — OpenGL 3.1, затем ES 3.1. Добавил эмуляцию geometry/tessellation, в январе 2024-го сдал OpenGL 4.6. Vulkan 1.3 прошёл за пару недель, 1.4 вышел в день публикации спецификации. Karol Herbst добавил OpenCL 3.0. Подключил sparse-текстуры — заработал Direct3D 12 через Proton.

Цели выполнены: драйверы в Mesa, игры идут, миф о несовместимости Vulkan с Apple развеян.

• Alyssa за 5 лет с нуля довела Vulkan-драйвер для Apple Silicon до upstream, чем вдохновила всё open-source-сообщество.
• Учёба, работа в Collabora и «хобби»-проект — комментаторы поражаются, как она всё успевала.
• С августа она в Intel и, судя по резюме, занимается open-source-графикой Xe-HPG.
• Многие жалеют, что она уходит из Asahi, но считают переход новым вызовом, а не «уходом».
• Появились вопросы о будущем Asahi на M3/M4 и о том, почему Apple не мешает проекту, в отличие от других.

Librebox-demo — репозиторий движка Librebox: открытой альтернативы Roblox.
Цель — совместимость с Roblox-играми и инструментами, но без проприетарных ограничений.

Ключевое

• Язык: C++ + Lua
• Лицензия: MIT
• Статус: ранняя альфа
• Сборка: CMake + vcpkg

Быстрый старт

git clone https://github.com/librebox-devs/librebox-demo.git
cd librebox-demo
cmake -B build -S . -DCMAKE_BUILD_TYPE=Release
cmake --build build
./build/librebox

Функции

• Загрузка .rbxl и .rbxm
• Базовый рендер OpenGL/Vulkan
• Серверный режим headless

Планы

• Поддержка плагинов
• Web-клиент
• Мобильные порты

PR и issue приветствуются.

• Librebox — это пока демо с очень ограниченным подмножеством API Roblox; серверов и сети нет.
• Пользователи надеются на Linux-клиент и сохранение творений Roblox, но опасаются юридических проблем.
• GitHub и Discord проекта выглядят странно: разработчики скрыты, активности мало, но код реально пишется.
• Некоторые считают, что такие проекты важнее для Roblox, чем борьба с хищниками на платформе.
• Есть предложения переименовать в OpenBox из-за лицензии MIT, но другие напоминают, что MIT — это тоже «свободно».

manim — движок анимации от 3Blue1Brown для создания пояснительных математических видео.
Python-библиотека превращает LaTeX-формулы и геометрические объекты в плавные сцены, которые можно рендерить в Full HD или 4K.

Ключевые возможности

• Объектно-ориентированный API: создаёте Mobject-ы (Math-Objects) и анимируете их методами .animate, .play, .transform.
• Встроенные шаблоны: графы, векторы, интегралы, матрицы, 3D-сцены.
• LaTeX-рендеринг: компилирует формулы в реальном времени.
• GPU-ускорение (OpenGL) для сложных сцен.
• CLI и Jupyter: запускайте manim -pql scene.py или интерактивно в ноутбуке.

Установка

pip install manim
# или
conda install -c conda-forge manim

Минимальный пример

from manim import *

class HelloMath(Scene):
    def construct(self):
        eq = MathTex(r"\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}")
        self.play(Write(eq))
        self.wait()

Ссылки

• Документация
• Discord-сервер
• Галерея примеров

• Современные LLM отлично генерируют код Manim, экономя время при создании математических видео.
• Пользователи хвалят красоту и понятность роликов 3Blue1Brown и сами делали успешные презентации.
• Актуальная версия библиотеки — community-форк ManimCommunity/manim.
• Ищут аналоги Manim для общих инфографик и моушен-графики (MotionCanvas.io, After Effects и др.).
• Некоторые жалуются на старые проблемы: kwargs-итис и отсутствие типов.
• Есть эксперименты с интерактивной 3D-графикой и автоматическим озвучиванием видео.

• 3d hilbert curve
• shingles
• temple
• rusty maze
• spring
• fbm terrain
• torus knot
• dandelion
• power line
• woven WIP
• roots
• bumpy sphere
• abstract hourglass
• birdbath
• concrete tetrapod
• terraced floating island
• extruded clay bowl
• fancy shader props
• superellipse dominos
• dark souls tree

Автор всех работ: ameo
Geoscript и Geotoy — Casey Primozic, открытый код.

• GeoToy — это «Shadertoy для геометрии»: вместо цвета пикселя функция возвращает вершины, поэтому куб рисуется 36 вызовами, а не 921 600.
• Похож на DSL для 3D-моделей; пример «temple» помогает быстрее понять синтаксис.
• Материалы задаются не кодом, а через UI (три пиктограммы → «materials») и используют трипланарное отображение без UV.
• Анимации пока нет, но пользователи просят добавить переменную вроде iTime из Shadertoy.
• Проект вызывает ассоциации с Structure Synth и geometry-шейдерами, но последние считаются трудными для оптимизации.

Это вторая часть серии о разработке Tyr — современного GPU‑драйвера на Rust для ядра Linux с поддержкой Arm Mali на CSF.

Разберем, как работают GPU‑драйверы, на примере VkCube — простого приложения на Vulkan, рисующего вращающийся куб. Простота сцены помогает понять путь данных и команд от приложения к GPU.

UMD и KMD

• UMD (usermode) реализует API вроде Vulkan/OpenGL/OpenCL и преобразует команды приложений в низкоуровневые команды для GPU. В нашем случае это panvk из Mesa.
• KMD (kernel mode) соединяет UMD с железом: инициализирует устройство, управляет памятью, очередями, планированием и уведомлениями. В нашем случае это Tyr, нацеленный попасть в основное дерево Linux.

Что делает UMD

• Подготавливает данные: геометрию, текстуры, машинный код шейдеров, матрицы трансформаций.
• Просит KMD разместить их в памяти GPU, создает VkCommandBuffer с командами отрисовки, настраивает состояние конвейера, указывает, куда писать результат, и как получать сигнал о завершении.

Про шейдеры

• Это полноценные программы на GPU. Для VkCube им нужны хотя бы геометрия, цвета и матрица вращения, чтобы расположить и раскрасить куб и крутить его.

Что делает KMD

• Выделяет и отображает память, изолируя процессы в отдельных контекстах/VM.
• Принимает работу от UMD, ставит в аппаратные очереди, отслеживает зависимости и завершение.
• Планирует выполнение на массово параллельном, асинхронном железе, соблюдая порядок и справедливое распределение ресурса между клиентами.
• Инициализирует устройство: тактирование, питание, стартовые процедуры; обеспечивает совместный и честный доступ приложений к GPU.

Ключевой вывод

• Основная сложность — в UMD, который переводит высокоуровневые API в команды GPU. Но KMD обязан предоставить надежные примитивы: память, очереди, синхронизацию, планирование и разделение ресурсов, чтобы UMD было реально реализовать.

Интерфейс драйвера

• На основе этих задач KMD экспонирует минимальный набор операций: запрос сведений об устройстве, создание/уничтожение VM, привязка/отвязка памяти к VM, получение состояния VM, отправка работ в очереди и механизмы уведомлений — тот же API, что у C‑драйвера Panthor для того же железа.

• Обсуждение статьи о драйвере GPU: часть читателей хвалит материал, но считает его слишком коротким и ждёт продолжения/второй части.
• Уточняют, что речь идёт о драйвере panthor для Mali CSF (на RK3588), а не panfrost; один из комментаторов отмечал баги в Firefox на RK3588, ему ответили про соответствующий драйвер.
• Спор о фокусе: одни подчёркивают важность того, что это один из первых GPU-драйверов Linux на Rust; другие критикуют кликбейт заголовок и считают, что нужно акцентировать Mali CSF, а не Rust.
• Техническая дискуссия: вопрос о целесообразности uring_cmd вместо ioctl; ответы поясняют, что из-за природы асинхронных очередей GPU дополнительная CPU-очередь мало что даст, а интерфейс драйвера следует ожиданиям Mesa.
• Отмечают, что текущая часть охватывает в основном границу пользователь/ядро и управление очередями/буферами; «основное действие» — выполнение команд GPU — ожидается в следующих частях.
• Дополнительно подчёркивают сложность современных GPU-драйверов и их объём в ядре Linux, что оправдывает выбранные подходы и терминологию.