Тёмная тема
- Gradius
- Постоялец
Иногда, когда мне грустно, я открываю сайт itch.io и ищу что-нибудь интересное по теме LOWREZJAM.
Сегодня раскопал одну интересную нано-игру, сделанную на опенсорцном движке (автор игры и движка - один) на базе LUA:
Знакомьтесь: нано-платформер и цып-очкарик в нём!
Исходники движка игры - Juno: https://github.com/rxi/juno
Сама игра представляет собой pak0-файл (как выяснилось - это zip-архив со скриптами, ассетами и музыкой).
Теоретически, собрав этот движок, мы можем запускать любые игры-pak0:
game_title.exe (juno executable)
pak0 (zip archive of game)
lua51.dll
SDL.dll
С сегодняшнего дня, я меняю своё отношение к игровым движкам.
Не всякий движок - говно-движок!
Есть легковесные отличные движки.
Этот же автор сделал игровой движок LUA под DOS - LOVEDOS :))) : https://github.com/rxi/lovedos
Заявлена частичная совместимость с LÖVE API !
Уже подумываю портануть этот движок на свои консоли и получить нано-цыпа! 
P.S. Интересно, под этот движок ещё игры есть такого жанра?
P.P.S. Цып-очкарик великолепен! 
Марио, снимай грим я тебя вычислил
Gradius
> С сегодняшнего дня, я меняю своё отношение к игровым движкам.
> Не всякий движок - говно-движок!
Я вот также думаю. Тоже считаю идею таких движков более адекватной чем попытки по десять лет запилить своего убийцу юнити (который никому, даже автору, не нужен). Такими движками проще пользоваться, и хоть они заточены под определенные игры, но... Вон рпг макер тоже заточен, никому это не мешает. И тут это тоже не проблема. Кому надо сделать свою гта, возьмет UE5. А вот под всякие там джемы эти нано-движки прям идеальны
p.s. считаю луа там лишним, надо было еще более нано делать (либо еще более простой скриптовый язык (такие есть, даже only header, либо чистый си для кодинга)
war_zes
> p.s. считаю луа там лишним, надо было еще более нано делать (либо еще более
> простой скриптовый язык (такие есть, даже only header, либо чистый си для
> кодинга)
Того же мнения. LUA не даст пойти игре на девайсах с памятью в несколько килобайт. Хотя сама игра минималистична - её исходники легко получаются путём распаковки файла pak0 (добавлением расширения zip).
Но есть и плюсы от LUA - на контроллерах с флеш-памятью очень удобно один раз прошить движок, а игру грузить с SD-карты памяти и тут же исполнять. Но оперативы всёравно надо 1..2МБ для стека LUA-машины (он там сделан через кучу).
Данный движок получается своего рода виртуальная игровая консоль, а архив ассетов со скриптами - РОМ игры :)
Для меня остаётся загадкой, почему игроделы используют скриптовые языки (LUA, Python) для написания игр?
Чем C++ не угождает?
Всёравно движки делают на C++, так зачем работать через прослойку( LUA=>C ) и усложнять жизнь проект?
P.S. Собрал этот движок под винду. Там кроме GCC(MinGW) ничего не нужно. На Питоне 2.7 там только скрипт сборки, его можно разложить на обычные команды GCC.
Подсунул движку эту игру -сожрал, заработала! Причём как в виде архива, так и в виде отдельной папки.
Gradius
> Но есть и плюсы от LUA - на контроллерах с флеш-памятью очень удобно один раз
> прошить движок, а игру грузить с SD-карты памяти и тут же исполнять.
Это не плюс. Движок-то малюсенький, зачем этот геморой с раздиранием дистриба на части?
beejah
> зачем этот геморой с раздиранием дистриба на части?
Чтобы запускать много игр, не перепрошивая каждый раз контроллер (движком+игрой)
war_zes
> (либо еще более простой скриптовый язык (такие есть, даже only header, либо
> чистый си для кодинга)
А это какие? Интересно!
И что такое "only header" ? Это где сорец в один h-файл завёрнут?
Из Си-подобных нашёл "Пешку": https://www.compuphase.com/pawn/pawn.htm
Gradius
> Для меня остаётся загадкой, почему игроделы используют скриптовые языки (LUA,
> Python) для написания игр?
потому что интепритируемые языки, можно писать и на ходу играть с минимум неудобств.
Gradius
> Это где сорец в один h-файл завёрнут?
Да
> А это какие? Интересно!
да уже не помню, но видел
Gradius
> Данный движок получается своего рода виртуальная игровая консоль, а архив
> ассетов со скриптами - РОМ игры :)
>
> Для меня остаётся загадкой, почему игроделы используют скриптовые языки (LUA,
> Python) для написания игр?
> Чем C++ не угождает?
Тоже загадка, чем Форт (Forth) плох :)
(ресурсов, при нативной реализации вообще мало требует усилий, реализаций уйма)
и "шлёпай" игры в своё удовольствие.
Mako in Github (483 stars)
Mako.JS в браузере
или такой проект jeforth.3we
P.S. Хотя, понимаю, традиции в привитых кодопостроениях - наши возможности и одновременно оковы.
KPG
> Тоже загадка, чем Форт (Forth) плох :)
> (ресурсов, при нативной реализации вообще мало требует усилий, реализаций
> уйма)
> и "шлёпай" игры в своё удовольствие.
Форт здесь плох точно также, как и LUA. Ещё одна прослойка. Нужно биндить на натив-код API через С++. Проще всё сразу на С++ было написать.
Приведённая ваша игра скучна до безобразия, ибо не динамичный платформер, а подобие Space Invaders. В такое со времён Atari нажрались вдоволь, поэтому - неинтересно.
---
Размотал скрипт сборки на Питон, сделал обычный батник - компиляция, сборка нано-движка с помощью mingw.
Текст батника в спойлере:
Он зачем-то использует флаг
-fno-strict-aliasing
, очевидно, что-то не так с алиасингом :)
И ещё он компилирует C в ASM и потом ассемблером получает объектники. Зачем? - Не понял.
Сделал сразу компиляцию в объектники без ассемблера.
P.S. Для начала в первый раз лучше собрать через питоновский скрипт. Потому что мне интересна версия без LUA JIT, нужна Lua Embed (встраивание LUA в движок, а не в виде отдельной DLL):
python build.py nojit
И он ещё создаст папку .tempsrc - в ней скомпилированные в байт-код модули движка на LUA в виде H-файлов.
Проделать это 1 раз.
Для удобства закомментировать строку в build.py - clearup(). Иначе папку потрёт в конце.
Далее надо будет исключить всё лишнее (например - управление мышью. Оно не нужно, так как в консолях мыши нет и не будет. В игре управление кнопками).
Было принято решение портануть для начала этот движок в DOS, с помощью Open Watcom C.
Такое решение выбрано исходя из того, что программирование в DOS более-менее приближено к стилю BareMetal, которое необходимо в моих консолях. А потом, собственно, портировать на консоли.
При портировании возникли небольшие сложности, которые успешно разрешились:
1) fs.c:
- Watcom не имеет #include <dirent.h>. Заменил на <direct.h>.
- изменено имя макроса mkdir() на Mkdir():
#define Mkdir(path, mode) mkdir( path)
2. ttf.c:
void *pixels = calloc(1, *w * *h); pixels + x + ( y * *w),
Нахипстерили с указателем. Пришлось задать явный типкаст в char*, чтобы арифметика сработала:
(char*)pixels + x + ( y * *w),
3. stb_image.h:
Не найден модуль #include <emmintrin.h> для SSE.
задал принудительно дефайн: #define STBI_NO_SIMD
4. jo_gif.c:
ругался на конструкцию int bias[256] = {},
заменил на:
int bias[256];
memset(bias,0,sizeof(bias));
Итог:
Проверил изменения в винде - движок работает.
Осталось избавиться от SDL: заменить на DOS-овские функции (взять с предыдущих наработок):
- графика
- звук
- таймер, задержки
- клавиатура
- мышь (убрана)
В модулях:
- m_audio.c
- m_graphics.c
- m_system.c
- m_time.c
- main.c
Портирован цып под DOS! 
С видео, звуком, музыкой.
Скейл сделал 1:1 чтобы не усложнять себе жизнь. На консолях будет в полный экран.
Нашёл багу в Цыпе.
Если сделать LookDown, то в некоторых местах проглядывают тайлы задников из-за недостаточного замощения тайлов платформ.
Но это фигня, уровень сделан в Tiled, при желании можно его подправить.
Gradius
> Портирован цып под DOS!
В Дос-боксе идёт медленно, подозреваю, из-за LUA. Или декодирования OGG. При запуске игры графический ассет распаковывается несколько секунд.
Запустил в WinXP в режиме эмуляции DOS (ntdvm) - DOS-порт идёт шустро (как надо). Графический ассет распаковывается моментально при запуске.
Успешно портирован Цып-очкарик на игровую приставку "Cobura" (на базе процессора ARM Cortex Allwinner V3s)!
Подводные камни при портировании:
1) Необходимо было заменить файловые функции на свои реализации:
fopen, fclose, fread, fwrite, fseek, ftell, fgetc, fgets, fputc, fputs, ferror, clearerr, ugetc, mkdir и многие другие.
2) Использование штатного GCC-шного аллокатора памяти тормозило распаковку и парсинг ассета, а также приводило к постепенному замедлению процесса игры. Проблема решилась заменой штатного аллокатора на o1heap. Это болезнь LUA на микроконтроллерах.
3) Мощный подводный камень: ошибка открытия ассета. В игре используется Linux-стайл указание имени файла:
./pak
В винде такое указание файла работает, а вот на микроконтроллере (с использованием либы FatFs) не заработало.
Пришлось подправить скрипт: init.lua.
Убрать:
-- Mount project paths
if juno._argv[2] then
-- Try to mount all arguments as package
for i = 2, #juno._argv do
juno.fs.mount(juno._argv[i])
end
else
-- Try to mount default packages (pak0, pak1, etc.)
local dirs = { juno.system.info("exedir") }
if juno.system.info("os") == "osx" then
table.insert(dirs, juno.system.info("exedir") .. "/../Resources")
end
for _, dir in ipairs(dirs) do
local idx = 0
while juno.fs.mount(dir .. "/pak" .. idx) do
idx = idx + 1
end
if idx ~= 0 then break end
end
endИ написать просто:
juno.fs.mount("pak0")И скомпилировать питоновским скриптом в init_lua.h
В итоге заработало! 
Выставил видеорежим 64x448 85 Гц, каждая строка рисуется по 7 раз. Получается 64x64.
Видео добавлю по-позже.
Про игровую приставку здесь: https://gamedev.ru/flame/forum/?id=252846&page=3
Тема в архиве.