Войти
ПроектыФорумУтилиты

[OpenSource] Cheetah 2D Engine

Страницы: 1 2 3 Следующая »
#0
22:45, 2 авг. 2013

Тип: графический 2D движок общего назначения на SDL/OpenGL
Лицензия: MIT (OpenSource)
Исходный код: https://github.com/scriptum/Cheetah
Статус: ещё даже не назначена версия
Язык программирования: Движок на чистом Си, логика - Lua (JIT)
Документация: https://github.com/scriptum/Cheetah/wiki (на английском языке)
Платформа: Linux, есть кросс-компиляция в Windows
Daily Build: http://dl.dropbox.com/u/59878867/Cheetah-2D-Engine-daily.tar.gz (20 мб с примерами и всеми собранными библиотеками под Windows и Linux)

Изображение

Движок (ещё один). На самом деле это пока нельзя называть игровым движком, хотя игры, конечно, на нём делать можно, основные функции пока заключаются в аппаратно ускоренном выводе графических примитивов.

Ещё один очередной движок? Может и нет. Данный проект реализует концепцию FFI для Lua. То есть вся игра целиком пишется на Lua (необходимо использовать LuaJIT), при этом в Lua-скрипте можно загружать динамические библиотеки при помощи FFI. То есть фактически нет никаких биндингов кроме декларации функций: библиотеки просто динамически линкуются к скрипту, движок также реализован в виде обычной ldd/so библиотеки. Скорость приложений остаётся на приемлемом уровне, так как 1) JIT-компилятор 2) всё алгоритмически сложное можно написать на си и слинковать со скриптами. Всё это позволяет сохранять объём исходного кода в рамках 100 кб. Программа на Lua по потреблению памяти и ресурсов практически неотличима от такой же программы на Си, если грамотно разделить алгоритмы и логику.

В итоге получаем модульную систему: центральное звено - это lua скрипт, из него загружается dll с графическим движком, после чего, при желании - загружается библиотека со звуком, нужна физика - загружаем библиотеку chipmunk.

Что есть из возможностей:

  • Кроссплатформенность
  • Со свободной лицензией
  • Производительность: JIT компилятор, OpenGL, эффективный динамический батчинг - баланс между производительностью и удобством использования (но VBO не поддерживает)
  • Можно создавать приложения как на lua, так и на чистом С - полная свобода
  • Мощный фреймворк на lua - lQuery, источником вдохновения, как ни странно, была библиотека jQuery
  • Граф сцены, плавные анимации с различными функциями перехода, продвинутая система событий, пользовательский интерфейс через lQuery
  • Простая связь с кодом на С при помощи механизма FFI в LuaJIT
  • OpenGL: фреймбуферы, шейдеры
  • Модули: присоединяйте любые динамические библиотеки прямо в код на lua
  • Растровые шрифты с кернингом и Distance Field
  • Автозагрузка ресурсов путем сканирования файловой системы, асинхронный загрузчик ресурсов, динамическая подгрузка нужных ресурсов
  • Звук через SDL_mixer
  • Физика через Chipmunk
  • Компактный загрузчик изображений с использованием библиотеки SOIL (можно заменить на DevIL) и возможностью маскирования (RGB и Alpha в разных файлах https://github.com/scriptum/Cheetah/wiki/Mask-image-loader)
  • Немного документации и много демок
  • Поддержка тайлов (тайлы делал не я, патч присылал энтузиаст и сейчас тайловый рендер не работает в связи с динамическим батчингом)
  • Небольшой особенностью является то, что можно лишь рисовать спрайты. Т. е. нет даже API "нарисовать квадрат" - нужно создать текстуру с квадратом и выводить как спрайт, впрочем, для этого существует простой генератор процедурных текстур. Почему я так сделал? Полноценную векторную графику на OGL делать сложно, пусть это лучше это будет большая отдельная библиотека, которая линкуется при необходимости. А лучше вообще взять Cairo.

    Движок частично подготовлен к экспорту на Андроид - всё рисование происходит через одну строчку кода и можно во время компиляции поменять вывод QUADS на вывод TRIANGLES. К сожалению, до ведра руки не дошли.

    + Пример программ

    Собственно, суть публикации - не хватает времени чтобы доделать до релиза - планировалось доделать документацию, звук через OpenAL, поддержку Mac и Android (LuaJIT собирается под ARM). Возможно, кому-то исходный код пригодится, не исключено что пригодятся какие-то идеи или алгоритмы. Система сборки работает только в Linux, винда собирается через кросс-компилятор. Патчи, фича реквесты и багрепорты, разумеется, принимаются:)

    Сейчас движок использую в основном как Shader Toy, с чем неплохо справляется.


    #1
    15:49, 6 авг. 2013

    Что-то у публики совсем нет интереса к движку, в отличие от других проектов автора. А жаль. Натыкался на него пару месяцев назад, взял на заметку, собирался подглядывать в код, когда буду делать свой велосипед. Смутило тогда что последний коммит был вроде двухлетней давности, ну и что-то я проектов на этом движке не нашел, даже от самого автора.

    #2
    21:39, 6 авг. 2013

    angru
    Вы явно не туда не смотрели - коммиты там бывают регулярно. Два года назад этого движка ещё не существовало, вы наверняка смотрели Engine - форк и объединение движков Scrupp и LOVE, потом появился вот этот, уже на LuaJIT. Сначала я хотел делать патчи для LOVE, но взглянув на объёмы плюсового кода я плюнул на это дело. Идея появилась в 2012 году, тогда же - первая реализация на основе кодовой базы Scrupp.

    По поводу проектов на движке - они тут мелькали (нарды, монополия), просто тоже времени не хватает доделать. Человек, который мне помогал их делать, потерял интерес.

    Будет время - приведу тему в порядок. Кое-какие проекты на нём уже были реализованы.

    #3
    23:43, 6 авг. 2013

    Небольшая демонстрация производительности ffi


    Также это показывает, насколько прост биндинг в Lua JIT:

    Берём и делаем простую библиотеку:

    //mylib.c
    int myadd(int x, int y)
    {
      return x + y;
    }

    Компилируем:

    $ gcc -Ofast --shared -o mylib.so mylib.c

    Тестовый скрипт:

    --test.lua
    local ffi = require 'ffi'
    local C = ffi.cdef('int myadd(int x, int y);')
    local li = ffi.load('./mylib.so')
    -- local ff = li.myadd
    for i = 1, 500000000 do
      li.myadd(2, i)
    end

    Запуск:

    $ time ./luajit test.lua 
    
    real  0m1.176s

    Итог: практически полмиллиарда вызовов в секунду.

    Сравнение с нативным кодом на Си:

    $ cat test.c
    int myadd(int x, int y)
    {
      return x + y;
    }
    int main(int argc, char **argv)
    {
      volatile int x;
      int i;
      for (i = 0; i < 500000000; i++)
      {
        x = myadd(2,i);
      }
    }
    $ gcc test.c -O3 -o mytest
    $ time ./mytest 
    
    real  0m0.261s
    И хотя скорость вызовов в Lua ниже в 4 раза, эта разница измеряется в наносекундах а также сделаем скидку на то, что в Си компилятор наверняка подставил тело функции в цикл, в то время как lua такой блажи не имеет. Если принудительно выключить inline, LuaJIT даже обгонит Си.

    P.S. FFI в среднем показывает себя чуть лучше, когда функция не в библиотеке, а непосредственно в исполняемом файле модуля (при условии, что исполняемый файл собран как PIC), но эта разница не сильно ощутима.

    #4
    2:45, 7 авг. 2013

    RPG
    > И хотя скорость вызовов в Lua ниже в 4 раза
    А потом удивляемся, почему игра 2000 года летает, а с такой же графикой слепленная демка движка на том же железе и работать не станет. А если станет, то как мертвая черепаха.

    И еще удивляемся, что на 286 ДОС грузился быстрее, чем сегодня Вин7 грузится, на в сотни раз быстром железе.

    Ну да, чего уж там, четыре раза всего лишь. :)

    Вот, откопал твой же скрин:

    + Показать

    В небольшом окошке считай только фон заливаем. И всего 146 фпс. Ну, я не знаю, как делать 3д игру, если в 2д заливке фоном всего 146 фпс. Квейк1 в софтрендере и то небось быстрее на том же компе, а? А уж Квейк 2...

    #5
    7:49, 7 авг. 2013

    Крысеечник
    > И еще удивляемся, что на 286 ДОС грузился быстрее, чем сегодня Вин7 грузится,
    > на в сотни раз быстром железе.
    Проблемы виндусятников. У меня холодный старт линукса секунд 15. А вот тёплый ламповый дос на 486-м грузился минут 5, я хорошо даже помню характерную последовательность звуков, которые издавал дисковод при этом и по набору звуков можно было отследить статус загрузки.

    Крысеечник
    > А потом удивляемся, почему игра 2000 года летает, а с такой же графикой
    > слепленная демка движка на том же железе и работать не станет. А если станет,
    > то как мертвая черепаха.
    Графику 2000 года ещё умудриться сделать надо - низкие разрешения 640х480, текстуры 128х128, 256 цветов.

    В нардах текстуры 1024х1024 hicolor и комп, на котором запущен этот "пустой экран" родом из 2000-х как раз. На современном железе будет 1000+ fps, вам ли не попробовать. А ещё набросайте такую же игру на С++ и сравним, насколько быстрее будет - на 2 или 3 фпс.

    #6
    14:57, 8 авг. 2013
    Платформа: Linux

    Уважаю, мужик! За это большущий респект :)

    Прошло более 8 месяцев
    #7
    19:55, 6 апр. 2014

    Движок "переехал" на SDL2, используя статическую линковку с lua и SDL. Поломалась сборка для Windows, что поправимо, если раздобыть статик либы для винды. Также изменился дизайн поставки: теперь всё находится в "толстом" бинарнике, из которого при помощи JIT FFI выдёргиваются функции. Это поможет прикрутить такие вещи как: автостарт (чтобы вручную не дёргать mainloop), виртуальные файловые системы zip и т.п.

    Хочу поделиться очень неприятными впечатлениями от SOIL: крайне медленная (в 10 раз) загрузка изображений. Я уж молчу про ограничения и неудобства, связанные с ошибками в этом коде и утечками памяти. В общем, совет всем кто использует SOIL - выкиньте. Обычный libpng/libjpeg или SDLimage стабильнее и быстрее. Зачем я его только прикрутил - непонятно...

    #8
    23:04, 6 апр. 2014

    RPG
    > Хочу поделиться очень неприятными впечатлениями от SOIL: крайне медленная (в 10
    > раз) загрузка изображений. Я уж молчу про ограничения и неудобства, связанные с
    > ошибками в этом коде и утечками памяти. В общем, совет всем кто использует SOIL
    > - выкиньте. Обычный libpng/libjpeg или SDLimage стабильнее и быстрее. Зачем я
    > его только прикрутил - непонятно...
    Можно же средствами qt грузить. А в винде GDI+.

    #9
    23:17, 6 апр. 2014

    gammaker
    > Можно же средствами qt грузить. А в винде GDI+.
    На виндовое API надежды совсем никакой нет, а привязываться к такому монстру как Qt не хотелось бы. Самое оптимальное это использовать нативные libjpeg и libpng, которые есть везде (кроме винды, но винде не привыкать, что приложения за собой таскают груз из 100500 библиотек).

    #10
    10:54, 7 апр. 2014

    интересно, как раз недавно начал себе подыскивать движек с логикой в скриптах, хотелось бы посмотреть как будет выглядеть код простейшей программы которая загружает одну текстуру-спрайт и в каждой новой точке клика выводит на экран вращающийся спрайт, так же интересно как сделать так чтобы выводить меш на экран, я часто использую сетки в своих играх

    #11
    11:07, 7 апр. 2014

    RPG
    > Хочу поделиться очень неприятными впечатлениями от SOIL: крайне медленная (в 10
    > раз) загрузка изображений.

    Не знаю чего уж ты такого делал, но stb_image который и юзает SOIL (правда версию древнюю какую-то) вполне норм по скорости и утечек там не встречал никаких.

    #12
    18:28, 7 апр. 2014

    leonardo98
    Примеры кода в нулевом посте есть.
    MATov
    > stb_image который и юзает SOIL
    Вот я прогнал сравнительные тесты с libjpeg и libpng и ужаснулся. Всё-таки скорость загрузки спрайтов очень важна, а прирост в пять раз - это не шутки. Не стоит оно того, да ещё и ограничения на прогрессивный jpeg и png только 32 битные можно грузить.

    #13
    19:26, 7 апр. 2014

    RPG
    А тестов не осталось? просто не верю в "прирост в пять раз" ибо тоже как-то давно мерял. Ну либо SOIL там что-то мутит, ибо мерил я stb_image, и показал он себя более чем достойно

    #14
    19:34, 7 апр. 2014

    RPG
    > Хочу поделиться очень неприятными впечатлениями от SOIL: крайне медленная (в 10
    > раз) загрузка изображений.
    PNG грузит долго, да, остальные не пробовал. Но не обязательно ставить сразу все флаги, вроде инвертирования по Y и т.д.
    DDS грузит очень быстро, особенно с флагом SOIL_FLAG_DDS_LOAD_DIRECT.

    Страницы: 1 2 3 Следующая »
    ПроектыФорумУтилиты

    Тема в архиве.