Пятница, 23 Октября 2026, 01:50

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
NoName Engine 2.5D
VuvkДата: Четверг, 24 Сентября 2026, 15:30 | Сообщение # 1
заслуженный участник
Сейчас нет на сайте
Название: NoName Engine 2.5D (я просто не придумал название)
Жанровая направленность: Boomer Shooter
Язык программирования: Python + Cython
Платформа: Linux, Windows, вероятно MacOS, но не тестировал
Графический API: OpenGL
Зависимости: wxPython, PySDL2
Лицензия: GNU GPL v3
Автор: Anton <Vuvk> Shcherbatykh

Паблик ВКонтакте
Зеркало паблика в Telegram

Исходный код:
Основной репозиторий на GitFlic
Зеркало на GitVerse

Сборки:
GitFlic
GitVerse

Всем привет! Я вдруг решил осветить своё текущее хобби и вести лог разработки дополнительно здесь. Надеюсь, не выгоните ))

NoName Engine 2.5D - это побочный продукт от желания разобраться как работает движок с портальным рендерингом от Кена Сильвермана Build (игры Duke Nukem 3D, Blood, ShadowWarior, Redneck Rampage и т.д.). В какой-то момент что-то стало получаться и я решил, что нужно делать инструментарий по работе с движком и тут понеслось...

Итак, это движок со встроенным редактором карт, выполненным в духе Build Engine: редактирование полигонов, стен, порталов и спрайтов в двумерном виде с мгновенным 3D-предпросмотром. Рендеринг построен на портальной отсечке невидимых полигонов и пакетном рендеринге на Legacy OpenGL. Реализовано 2 рендер-бэкенда под GL1.2 (фиксированный конвейер с имитацией эффектов) и GL2.0 (GLSL-шейдеры). Критичные участки математики ускорены через Cython (+ враппер над OpenGL без прослоек в виде библиотек на Python).

═══════════════════════════════════════════════════════════════════════════════

ВОЗМОЖНОСТИ ДВИЖКА

• Портальная архитектура мира — полигоны, стены, перемычки (верхние и нижние части порталов), полы и потолки с независимым управлением высотами.
• Агрессивный куллинг видимых полигонов через 1D Z-буфер и обход соседей портала — рисуются только реально видимые поверхности.
• Пакетный рендеринг (BatchRenderer): один draw call на батч материала (glDrawArrays, клиентские вершинные массивы), запечённые нормали, порядок отрисовки и текстурные координаты.
• 3D-предпросмотр в стиле FPS со свободным обзором мышью.
• Шейдерный менеджер с кэшированием uniforms; шейдеры материалов: базовый (base) и «жидкость» (water) — для воды, лавы, слизи и т.п.
• Туман, освещение полигонов (яркость и цвет), отсечение задних граней, отключение текстур и wireframe-режим — всё переключается в предпросмотре.
• 3D-звук на основе pygame.mixer (пространственный аудио-менеджер) и 2D-звуки для событий игрока/меню и т.д.
• Спрайты с пивотами (bottom/center/top) и тремя режимами ориентации: биллборд (всегда лицом к камере), вращение вокруг оси, фиксированный поворот.
• Анимированные материалы и спрайты (кадры с префиксом «+»), анимация с настраиваемой частотой кадров.
• Цвет и яркость полигона накладываются на все спрайты внутри него.
• Эффекты полигонов: предустановленные (тряска, мерцание/пульсация освещения) и кастомные внешние скрипты на языке Python.
• Эффекты камеры: проседание при приземлении, тряска при сильном ударе, эффекты от подъёма на ступеньки.
• Физический движок: физические тела, столкновения с полигонами, гравитация, зашагивание на ступеньки до определённой высоты.
• Оружие в руках игрока: покачивание, наклоны, проседания, анимация, смена оружия с эффектом «выползания», стрельба через рейкастинг, кучность, количество пуль и дальность выстрела.
• Озвучка игрока: шаги, прыжки, приземления.
• BMP-шрифты, отображаемые прямо в OpenGL.

═══════════════════════════════════════════════════════════════════════════════

РЕДАКТОР КАРТ

• 2D-канва с сеткой, масштабированием и прокруткой (в том числе через Ctrl + колесо и Shift + колесо).
• Режимы: вершины (V), рисование сегментов (D), выделение сегментов (S), выделение полигонов (P), закраска материалом из предпросмотра (F), размещение спрайтов (X).
• Многоточечное выделение вершин (Ctrl + ЛКМ) и перенос с привязкой к сетке.
• Рисование сегментов с авторазбиением существующих сегментов в точке пересечения и корректным обновлением полигонов при разбиении.
• Удаление вершин, сегментов и полигонов; изменение высот пола/потолка как из редактора, так и прямо из окна предпросмотра (Home/End, PageUp/PageDown).
• Инструмент наложения любого материала на стены, порталы, полы и потолки одним кликом в предпросмотре.
• Размещение, перезапись и удаление спрайтов прямо с 2D-карты; приклеивание спрайта пивотом к полу, потолку или центру полигона.
• Выделение сегментов и полигонов в окне предпросмотра с подсветкой и синхронизацией
с редактором.
• Отображение положения камеры игрока на 2D-карте.
• Выбор материала, шейдера и настройка полигонов через поля ввода..

═══════════════════════════════════════════════════════════════════════════════

ГЕНЕРАТОРЫ МАТЕРИАЛОВ И СПРАЙТОВ

Отдельные инструмент автоматически создаёт из дерева текстур (png/jpg/bmp:

• Материалы (.mat) с шейдером, кадрами и анимацией. Имена с префиксом «+» группируются в анимированные материалы (кадры сортируются по числовому суффиксу). Имена, содержащие water/liquid/slime/sludge, получают шейдер «жидкость».
• Спрайты (.spr) с пивотом (bottom/center/top), режимом ориентации, осью и углом поворота. Пивот может переопределяться суффиксом в имени текстуры.

═══════════════════════════════════════════════════════════════════════════════

ПРОИЗВОДИТЕЛЬНОСТЬ И СБОРКА

• Cython-код компилируется под нативные либы на Си с помощью GCC или MSVC.
• Сборка релизов через Nuitka: все программы (editor, runner) компилируются
в standalone-режиме под натив.

═══════════════════════════════════════════════════════════════════════════════

ПЛАНЫ В РАЗРАБОТКЕ

Взаимодействие физических тел между собой, HUD игрока, размещение сущностей
(включая игрока) и источников звука на карте, редактор материалов/спрайтов,
шейдер «металл», текстуры с прозрачностью и палитрой, отмена операций и многое другое.

Это всё ещё не готовый продукт, но уже можно скачать сборку и поиграться с редактором и средой запуска.

═══════════════════════════════════════════════════════════════════════════════

СКРИНЫ



═══════════════════════════════════════════════════════════════════════════════

ВИДЕО




Старое:






Сообщение отредактировал Vuvk - Понедельник, 12 Октября 2026, 08:45
AlexanderBekkerДата: Пятница, 25 Сентября 2026, 13:02 | Сообщение # 2
BekkerDev Studio
Сейчас нет на сайте
Крутая работа! Уважаю людей, которые занимаются всякими такими низкоуровневыми штуками. Хотелось бы поделиться результатом работы и над своим движком, который я пишу на Java & LWJGL & OpenGL. Вот немного скринов:


Разработчик, композитор и издатель инди-игр в Steam.
Редактор карт: BekkerDev Level Editor 4
Страница разработчика в Steam
Паблик ВК: BekkerDev Studio
VuvkДата: Четверг, 01 Октября 2026, 20:42 | Сообщение # 3
заслуженный участник
Сейчас нет на сайте
Привет всем!
Делюсь чем занимаюсь в движке. ОПТИМИЗАЦИЕЙ.

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

Я проверил на ноуте 16-летней давности и оно работает весьма плавно. Но ~150 фпс не мало ли для такой картинки? А если будет уровень архитектурно сложнее? И вот для общего блага (как для компов а-ля "говно мамонта", так и для современных железяк) решил поэкспериментировать.

Первый шаг - отключить логирование и всякие проверки в самом PyOpenGL:
Код
import OpenGL
OpenGL.ERROR_CHECKING = False
OpenGL.ERROR_LOGGING = False
OpenGL.FULL_LOGGING = False


И уже здесь добавилась нехилая цифра к FPS.

Второй шаг - установить PyOpenGL-accelerate. Эта пришлёпка оптимизирует куски PyOpenGL, прикручивая компилируемую реализацию на Cython.

Итог - заявленные 5-10% и правда добавилось.

И было у меня желание всё-таки проверить - каков будет результат, если на Cython написать враппер, который будет напрямую дергать функции OpenGL?

В этом письме от 2009 года Sturla Molden озвучивает мнение, что PyOpenGL is a bad idea anyway https://marc.info/?l=python-list&m=125319393320851&q=mbox

А Lorenzo Mancini в том же году поэкспериментировал с разными подходами и выяснил, что вызов OpenGL из прослойки Си/Cython быстрее в 4 раза, чем PyOpenGL - https://web.archive.org/web....ttp

Изменилось ли что-то за 17 лет? Вот и проверим!

...Так и родился враппер fast_gl, в котором завёрнуты только те функции, которые используются в NoName Engine - в части OpenGL 1.1 + вкрапления OpenGL 2 для шейдеров.

И результат оказался даже круче, чем я думал! Итоги под Windows и Linux на скринах. Уж почему венда отстаёт я хз, если честно. Железо абсолютно идентичное (собсно один и тот же комп).

Это позволило мне избавиться ВООБЩЕ от PyOpenGL и его пришлепок. Минус зависимость.
Попутно решил удалить весь fallback код на Питоне, который вызывался, если нет скомпилированных либ на Cython с горячей математикой. Раз уж все равно нужно компилировать fast_gl, то и смысла таскать это нет - компилируем всё. И не надо поддерживать две ветки кода.

Собираю через MSVC на венде с агрессивными ключами
Код
/O2 /fp:fast /GL /Gy /Gw /Oi /GS- /Qpar /MD


А на всём остальном через GCC с ключами
Код
-O3 -march=x86-64 -mtune=generic -fno-math-errno -funroll-loops -fno-semantic-interposition -fno-stack-protector


Nuitka при сборке standalone использует их же.

Тем временем ко мне пришел отечественный одноплатник Repka Pi 3. Хочу теперь на нём попробовать запустить двиг. Чисто из научного интереса.
У кента есть ноутбук на Pentium 3, который умеет в OpenGL 1.2 - думаю на него попробовать поставить AntiX и тоже запустить NoName. Сначала проверю в виртуалке на 32-битной системе. Зачем? Да любопытно уже просто. Но тогда нужно два бэкенда и возможность их переключать: OpenGL 1.2 и OpenGL 2.0...

Поживём-увидим.



Добавлено (02 Октября 2026, 16:36)
---------------------------------------------
Первый экспериментальный запуск движка NoName Engine 2.5D на платформе одноплатного компьютера Repka Pi 3 (отечественной разработки, на базе Aarch64). Мы видим, что шейдер освещения/тумана нуждается в доработке.
Интересно, как он будет работать на стандарте OpenGL 1.1 / GLES1?

Присоединяйтесь:
https://vk.com/antoshka_diary
https://t.me/antoshka_diary

Short на YouTube: смотреть

Добавлено (05 Октября 2026, 21:00)
---------------------------------------------
В проекте NoName Engine 2.5D реализовано два параллельных бэкенда для рендеринга:

- OpenGL 1.2 (фиксированный пайплайн) — классический подход без шейдеров. Подходит для старого и экзотического железа. Для жидкостей используется имитация движения за счёт сдвига UV текстуры — это даёт эффект течения без сложных вычислений. Туман фиксированный, повершинный.

- OpenGL 2.0 (с шейдерами) — вариант, позволяющий использовать логику отрисовки на GPU. Жидкости приобретают не только текстурное, но и вершинное искажение. Туман шейдерный, попиксельный.

По умолчанию ('auto') движок пытается установить режим gl20, если оборудование поддерживается (уж в наше-то время...). Но можно принудительно задать желаемый бэкенд:
1. в файле video.cfg установить значение для ключа "render_mode" - gl12/gl20/auto
2. либо передать раннеру ключ запуска --render_mode <gl12 | gl20 | auto>. Ключ имеет приоритет над файлом конфигурации

После некоторых оптимизаций на стороне движка в режиме "gl12" на Repka Pi 3 выходит уверенные 35-60 fps, что уже достаточно для относительно комфортной игры. А ещё в этом режиме адекватно рисуется туман на этом одноплатнике.
Но gl12 не панацея, потому что современные видеокарточки наоборот могут не поддерживать некоторые функции старого фиксированного пайплайна. Например, есть сообщения, что у некоторых в этом режиме нет вообще тумана.

На видео можно лицезреть, что разница есть, но визуально минимальная.


Сообщение отредактировал Vuvk - Понедельник, 05 Октября 2026, 21:01
AlexanderBekkerДата: Вторник, 06 Октября 2026, 20:30 | Сообщение # 4
BekkerDev Studio
Сейчас нет на сайте
Цитата Vuvk ()
- OpenGL 2.0 (с шейдерами) — вариант, позволяющий использовать логику отрисовки на GPU. Жидкости приобретают не только текстурное, но и вершинное искажение. Туман шейдерный, попиксельный.

Геометрические волны можно было и в первом варианте реализовать. Для реализма разбить сетку на более мелкие полигоны, чтобы добиться большей детализации, и смещать Y вершин сетки синусоидой и шумом. Чтобы не вычислять шум динамически и сильно сэкономить ресурсы, можно создать, к примеру, 32 сэмпла, где первый и последний будут замыкать друг друга (образуя бесшовный переход). И потом итерироваться по индексу массива, беря за основу нормализованные до размера массива XZ координаты вершины. Ну а для растеризации треугольников сетки использовать Scanline алгоритм, который будет заниматься только закраской пикселей без лишних вычислений UV, перспективной коррекции и прочего. За счёт того, что треугольники сетки мелкие, всё должно работать очень быстро. А если ещё и отсечь Frustum-ом невидимые части сетки, то можно хорошо сэкономить на матричных умножениях невидимых камере вершин и циклах растеризации.


Разработчик, композитор и издатель инди-игр в Steam.
Редактор карт: BekkerDev Level Editor 4
Страница разработчика в Steam
Паблик ВК: BekkerDev Studio
VuvkДата: Вторник, 06 Октября 2026, 21:02 | Сообщение # 5
заслуженный участник
Сейчас нет на сайте
Спасибо за комментарий.
Да, думал о подходе с усложнением сетки для жидкостей, но в итоге решил, что это не нужно, потому что gl12 бэкенд наоборот используется для ускорения на слабом железе, а создание лишних треугольников ради анимации воды как будто противоречит основному посылу. Можно вообще наложить анимированный материал, как это было в старых играх и не париться.
Насчёт растеризации и сканлайна - у меня ж не софтверный рендеринг (во всяком случае пока что нет такого бэка).
Вместо фрустума у меня отсечение по порталам через 1D Z-буфер по мотивам Build Engine.

Добавлено (09 Октября 2026, 21:59)
---------------------------------------------
Один мой товарищ резонно спросил у меня: "а почему бы тебе не сделать игру под ведроид на своём движке?" Я сначала ответил, что это слишком сложно с питоном, а потом решил поизучать тему. И так я наткнулся на проект p4a: https://github.com/kivy/python-for-android
В нем есть рецепт сборки для приложений на основе PySDL2.
"Но ведь pygame тоже на SDL2. Надо хоть на Termux проверить запуск" - подумал я. И этот pygame компилировался наверное час, но так и не скомпилировался. Уж не знаю, что у него там не так.
Эта вся история подтолкнула меня всё-таки переехать на голый PySDL2, о чем я уже размышлял ранее. Пришлось написать еще один враппер (на питоне) (но я уже думаю, что может на ситоне поверх настоящего SDL2 надо?). И в общем в движке теперь нет pygame-ce 😄
На видео демонстрируется запуск NoName Engine 2.5D на Андроиде через Termux. Да, это работа через симуляцию, а не приложение в APK, но всё же показательно, что как будто бы переезд был не зря и портируемость улучшилась.
А еще на видео заскриптованный лифт.
Всё видео записано с экрана телефона, поэтому качество не суперское.

Добавлено (16 Октября 2026, 22:21)
---------------------------------------------
Сборка 261016 <0x3fb98>

Развитие идёт несколько медленнее, чем хотелось бы (основная работа накладывает свои коррективы), но проект потихоньку развивается.
Да, в этой сборке по новым фичам как будто почти ничего нет... НО проделана большая работа по фундаментальной переработке:
1. реализован враппер на Cython для вызова OpenGL напрямую
2. реализован враппер над PySDL2 для более очевидных вызовов SDL2 и повышения переносимости
3. "горячий код" теперь только на Cython, Python-fallback вообще удален
4. удалены зависимости от PyOpenGL, pygame
5. методом тыка подобраны исключаемые из сборки модули, что очень сильно ускорило компиляцию и уменьшило объём дистрибутива
6. параметры оружия (размеры, кадры, опорная точка, скорость анимации, дальность, кучность) вынесены в конфиг-файлы WPN для кастомизации без пересборки движка. Они просто текстовые
7. оптимизирован формат карт (теперь старые не открываются - нужно конвертировать)
8. реализован бэкенд для рендеринга в OpenGL 1.2.
9. добавлена возможность выбора режима запуска: полноэкранность, бэкенд рендеринга, размер окна/разрешение экрана, макс. FPS, вертикальная синхронизация. Всё устанавливается либо в video.cfg, либо передаётся ключами запуска
10. переключение между полноэкранным или оконным режимом по нажатию Alt+Enter.

Подробнее в описании к сборке.
Далее приступаю к добавлению новых фич.

Ссылки на релиз:
https://gitflic.ru/project....1e75632
https://gitverse.ru/vuvk/portal-engine-2_5d/releases/tag/261016
Кроме сборки под Windows/Linux x86-64 докинул раннер под Aarch64 (компиляцию wxPython для редактора пока что не победил).

  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.info © 2008-2026