Комментарии 32
Глянул в очередной раз на сайт. Не понял до конца — можно на мобилки билдить или нет? Там есть какая-то Android version, но это вроде сам редактор.
И наверное общий вопрос: чем принципиально отличаются Lua движки типа Defold / Corona / Love? На что в первую очередь обратить внимание при выборе?
И наверное общий вопрос: чем принципиально отличаются Lua движки типа Defold / Corona / Love? На что в первую очередь обратить внимание при выборе?
- Билдить на мобилки — можно, хоть и с некоторыми телодвижениями. Модуль touch и фунции вроде vibrate из вики — ориентированы на мобильные телефоны.
Для тестирования, в google play есть порт, с яблоками слегка сложнее, но, вроде, тоже цепляет. С ПК всё гораздо проще, подробнее можно посмотреть тут. - Принципиальные различия — defold является движком, со всеми причитающимися: менеджеры сцен, сущности, коллизии (без box2d) и т.п. Он заставляет отвлекаться от программирования в сторону изучения самой движковой технологии. Corona SDK — тоже набор функций/библиотек, на начале своего развития, частично списывалась с LÖVE, а потом пошла куча своих (сложных) ништяков. Это хорошо, если твоя задача — быстро-быстро делать игры, пока солнце ещё высоко и ты уже знаешь технологию, но не очень, если ты хочешь учиться/учить, или иметь почти полностью своё приложение без чьих-либо претензий на «использование чужого кода», хоть корона и бесплатна, код закрыт, и расширять/фиксить не всегда получится. Ну, я не использую потому, что нет LuaJIT, без этого — медленно, и я не могу делать игровые тайловые карты 100500х9000 пикселей битмапой, как с FFI.
В заключение, могу сказать что сравнение LÖVE и Defold/Corona, аналогично сравнению Lua и Python: Python старается дать всё что можно, Lua даёт всё что необходимо.
НЛО прилетело и опубликовало эту надпись здесь
Фреймворк развивается, без одной недели, десять лет.
Тут дело не в названии или ещё чём-то, а в простоте и комфорте применения, с чем тут всё хорошо. Есть несколько игрушек в Steam/GooglePlay, крупных проектов немного, но это не очень страшно.
Фреймворк делался и назывался «по приколу», и этим он тоже цепляет, как зацепил меня, четыре года назад, когда я не задумывался чтобы вообще стать программистом. Названия пользовательских библиотек — тоже забавные (но не всегда цензурные, всё таки love-тематика), и это тоже вклад в развитие общества.
Цитируя Спольски:
В данном случае, LÖVE «утирает нос конкурентам» своим дружелюбием, взаимопомощью комьюнити, не в последнюю очередь — отличной документацией и возможностью повлиять на развитие забавного и жизнеспособного опенсурс-проекта с десятилетней историей.
Не стоит цепляться к мелочам, вроде «Нелатинских символов», они не играют роли в сравнении со всем остальным.
Тут дело не в названии или ещё чём-то, а в простоте и комфорте применения, с чем тут всё хорошо. Есть несколько игрушек в Steam/GooglePlay, крупных проектов немного, но это не очень страшно.
Фреймворк делался и назывался «по приколу», и этим он тоже цепляет, как зацепил меня, четыре года назад, когда я не задумывался чтобы вообще стать программистом. Названия пользовательских библиотек — тоже забавные (но не всегда цензурные, всё таки love-тематика), и это тоже вклад в развитие общества.
Цитируя Спольски:
В 2003 году Nullsoft выпустили новую версию плеера Winamp, сопроводив выпуск вот такими комментариями на веб-сайте:
- Клевый новый дизайн!
- Навороченные фичи!
- Большинство функций таки работает!
Я о последнем… «Большинство функций таки работает!» — это забавно. И все счастливы, довольны плеером, используют его, говорят всем своим знакомым и друзьям. И они полагают, что Winamp — это хороший продукт, потому что они таки взяли и написали на своем сайте: «Большинство функций таки работает». Круто, да?
…
Вот такие вещи и заставили нас влюбиться в Winamp.
А с тех пор, как корпоративные слизняки из AOL Time Warner прибрали эту штуку к рукам, весь юмор с сайта исчез. Вы теперь просто-таки явно можете представить их себе, этих сальери, убийственно подавляющих малейшие признаки творческого подхода, который может отпугнуть какую-нибудь немолодую даму из Минессоты. Ценой уничтожения всего того, что заставило людей реально полюбить этот продукт.
В данном случае, LÖVE «утирает нос конкурентам» своим дружелюбием, взаимопомощью комьюнити, не в последнюю очередь — отличной документацией и возможностью повлиять на развитие забавного и жизнеспособного опенсурс-проекта с десятилетней историей.
Не стоит цепляться к мелочам, вроде «Нелатинских символов», они не играют роли в сравнении со всем остальным.
то ли гуглить инфу про это в разы сложнее
Как правило, можно заменить нелатинскую букву на схожую латинскую.
По LÖVE, запросы составляются как «love2d spartial hash map», или похожим образом.
В обиходе, применяется название «love» или «love2d», это нормально.
По LÖVE, запросы составляются как «love2d spartial hash map», или похожим образом.
В обиходе, применяется название «love» или «love2d», это нормально.
Ну как сказать — на том же маке такие символы набираются практически без лишних телодвижений, как и на iOS с Android.
API до смешного прост, почему love2d до сих пор не стал мейнстримом?
Потому что есть Unity и Unreal
но они компилят громоздкие билды, а тут — аккуратненько и емко, особенно это критично для мобильных платформ.
Для того чтобы написать что чуть более крупное на LÖVE и не превратить это в кашу, необходим высокий уровень навыков программирования и проектирования приложений, а так же значительно больше усилий: API прост и позволяет вытворять сногсшибательные штуки, но все инструменты придется или брать у сообщества, или писать самостоятельно. Это все равно что делать адаптивные веб-сайты, с ajax'ом на каждый чих, без движков и библиотек: маленькие получаются сравнительно быстро и просто, но что-то крупное, при лимитах по времени, растягивается на всю твою жизнь (требуя высоких навыков проектирования), и или ты берешь библиотеки/фреймворки, или ты впихиваешь готовый движок.
Ну, не такие уж и громоздкие билды. Просто сами Unity и Unreal весят по несколько гигабайт. А Lua- интерпретатор с sdl2 компактный. Если вдруг захотелось странного, например закодить прототип на подручном телефоне, то Love или Instead весьма кстати будут.
Кстати, и Unity и Unreal, в 2d-играх, тем не менее работают в трёхмерном пространстве. Там просто отсутствует двухмерный режим, поэтому 2d эмулируется через 3d, у которого камера перемещается по одной плоскости.
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
P. S. В версии LÖVE 0.11.x должна появиться система перевода SDL-OpenGL в трёхмерный режим, со всеми сопутствующими фичами.
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
P. S. В версии LÖVE 0.11.x должна появиться система перевода SDL-OpenGL в трёхмерный режим, со всеми сопутствующими фичами.
поэтому 2d эмулируется через 3d, у которого камера перемещается по одной плоскости.
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
Для GPU, кстати, вообще нет понятия «2Д» — она в любом случае рисует трёхмерные примитивы (меши). Именно такой способ «ускоренного» рендеринга (через «эмуляцю» 2Д через 3Д) позволяет существенно увеличить производительность, особенно на телефонах. Именно таким ускорением (переводом рендеринга с CPU на GPU) в своё время занимались Adobe с их Molehill (Stage3D). И скорее всего именно так уже работает Love, если посмотреть на love.graphics API (например вот — явный отсыл к графическому Stencil Buffer love2d.org/wiki/love.graphics.setInvertedStencil) Точнее сказать не могу, т.к. уже написал выше что сам не пробовал Love. Но очень советую поглубже копнуть в эту тему, интересно уточнить как именно работает рендеринг в Love
Помнится, для GPU нет понятия 2d или 3d, она просто выдаёт фреймбуфер требуемого размера с произвольными вычислениями посередине.
Стандартный pipeline выглядит примерно так:
В love2d это выглядит следующим образом:
То есть, передаём видеокарте на растеризацию набор вершин/полигонов и/или текстур через шейдер.
Это, насколько я знаю, двухмерный режим OpenGL, трёхмерный чуть иначе работает: там посылаем кучу всякой фигни, отсекаем невидимые камерой грани, строим z-буфер, по нему рисуем плоскости с натянутой текстурой, хитро обсчитанной… Это значительно медленнее двухмерной графики, хотя бы из-за минимизации расчётов в трёхмерном пространстве.
Ускорение, особенно на телефонах, может появиться в случае если мы пытаемся рисовать кучу всего «за камерой» благодаря отсечению невидимых граней, но когда я что-то пишу на love2d, я ручками проверяю видимость объектов и не рендерю их в случае чего (спасибо, пространственные индексации).
Стандартный pipeline выглядит примерно так:
В love2d это выглядит следующим образом:
function love.load()
-- default pixel shader
local pixelcode = [[
vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords )
{
vec4 texcolor = Texel(texture, texture_coords);
return texcolor * color;
}
]]
-- default vertex shader
local vertexcode = [[
vec4 position( mat4 transform_projection, vec4 vertex_position )
{
return transform_projection * vertex_position;
}
]]
-- "copy" of default shader
shader = love.graphics.newShader(pixelcode, vertexcode)
end
function love.draw()
love.graphics.setShader(shader)
-- draw things
love.graphics.setShader()
-- draw more things
end
То есть, передаём видеокарте на растеризацию набор вершин/полигонов и/или текстур через шейдер.
Это, насколько я знаю, двухмерный режим OpenGL, трёхмерный чуть иначе работает: там посылаем кучу всякой фигни, отсекаем невидимые камерой грани, строим z-буфер, по нему рисуем плоскости с натянутой текстурой, хитро обсчитанной… Это значительно медленнее двухмерной графики, хотя бы из-за минимизации расчётов в трёхмерном пространстве.
Ускорение, особенно на телефонах, может появиться в случае если мы пытаемся рисовать кучу всего «за камерой» благодаря отсечению невидимых граней, но когда я что-то пишу на love2d, я ручками проверяю видимость объектов и не рендерю их в случае чего (спасибо, пространственные индексации).
Помнится, для GPU нет понятия 2d или 3d
Да, именно об отсутствии понятия 2Д для GPU я написал выше. Все вершины считаются трёхмерными, вся математика с положением — в трёхмерном пространстве.
Пайплайн со скриншота как раз явно содержит передачу массива вершин — input geometry and attributes, которые определяют трёхмерные объекты (даже если они плоские)
Более интересен ваш пример с шейдерами — это и есть обычный режим работы OpenGL. Расчёт экранных координат переданных вершин расчитывается в vertex shader — там где умножается матрица 4х4 на четырёхмерный вектор. Мерность матрицы и положения вершины как бы намекает на трёхмерную природу — вектор вершины хранит её положение в трёхмерном пространстве (в гомогенном виде — четвёртая составляющая), а матрица — обычная матрица трансформации в трёхмерном пространстве (translate — rotate — scale). То есть Love тоже работает как «эмулятор 2Д в 3Д пространстве», и это крайне эффективно.
Отсечение невидимой геометрии за пределами камеры — это пользовательский код, которого нет в графическом драйвере по умолчанию. То есть если вы будете использовать сырой OpenGL для отрисовки 3Д геометрии, там тоже не будет фильтрации геометрии, выходящей за границы камеры (неважно — перспективной или ортографической, либо вообще камеры с кастомной матрицей проекции) пока её не напишешь вручную (frustum culling)
Но это же просто матрица, квантерион как бы «вне контекста».
Трёхмерное пространство или двухмерное — не важно.
Конкретно translate — rotate — scale — это в т.ч. двухмерные операции.
Тут есть ещё shear, который «искажает перспективу» как бы трёхмерной плоскости того что сейчас рисуем, и операции как бы с четырёхмерными матрицами, но само пространство — не трёхмерно, это данные для нескольких умножений/смещение вершинок, и всё, ничто не выстраивается относительно чего-то другого в пространстве. Хотя с другой стороны, в таком случае, видяха вообще не умеет работать ни с каким пространством, только с текстурами, векторами и матрицами. Хм.
Я не очень умный в данной области, ибо не было практики ковыряния голого OpenGL.
Трёхмерное пространство или двухмерное — не важно.
Конкретно translate — rotate — scale — это в т.ч. двухмерные операции.
Тут есть ещё shear, который «искажает перспективу» как бы трёхмерной плоскости того что сейчас рисуем, и операции как бы с четырёхмерными матрицами, но само пространство — не трёхмерно, это данные для нескольких умножений/смещение вершинок, и всё, ничто не выстраивается относительно чего-то другого в пространстве. Хотя с другой стороны, в таком случае, видяха вообще не умеет работать ни с каким пространством, только с текстурами, векторами и матрицами. Хм.
Я не очень умный в данной области, ибо не было практики ковыряния голого OpenGL.
ибо не было практики ковыряния голого OpenGL.
Очень советую, крайне полезный опыт, большинство вопросов сразу пропадут :)
Благодарю. Если честно, я брал Love2d как раз для того чтобы не ковыряться в голом OpenGL, но это было несколько лет назад, когда всё сишное казалось страшным, отсутствовала математическая база и всё такое. Сейчас уже можно пробовать, найти бы время. Как раз Love2d привлёк возможностью сразу что-то быстро натыкать в «детском OpenGL» и пощупать, вместо того чтобы разбираться в движках и технологиях. Могу сказать что при должной усидчивости, полный профан (со средними способностями) который делает маленькие игрушки на Love2d, с повышением сложности архитектур приложений, изобретением инструментов для себя и т.п, за три-пять лет может стать неплохим программистом, способным делать движки и довольно крупное ПО. На самом деле с тем же успехом можно было бы взять сишку и OpenGL, но это пугает профанов, сами потом подтянут если понадобится. В общем, голь на выдумку хитра.
После Lua + Love2d, я вполне себе работаю мультиязычным (в основном, та же Lua, хех) скриптовым бекенд-программистом с большим объёмом бизнес-логики, и могу строить архитектуры таких штук. С любым «полноценным движком» этого бы не было, я был бы узко заточен ровно под него.
После Lua + Love2d, я вполне себе работаю мультиязычным (в основном, та же Lua, хех) скриптовым бекенд-программистом с большим объёмом бизнес-логики, и могу строить архитектуры таких штук. С любым «полноценным движком» этого бы не было, я был бы узко заточен ровно под него.
Это, насколько я знаю, двухмерный режим OpenGL, трёхмерный чуть иначе работает: там посылаем кучу всякой фигни, отсекаем невидимые камерой грани, строим z-буфер, по нему рисуем плоскости с натянутой текстурой, хитро обсчитанной
У OpenGL нет «двухмерного режима», есть только API команды, которые описывают текущий вариант использования механизма отсечения невидимых граней (glCullFace), либо использования z-buffer (glDepthFunc). В случае если он не используется — мы просто пишем что не используем его (просто не включаем его в текущий render buffer). Но это не значит что его нельзя включить для 2Д рендеринга.
Опять же — OpenGL не знает что вы через него пытаетесь рисовать, он всё считает трёхмерной геометрией.
2Д обычно рисовать быстрее просто потому, что не нужно считать попиксельное освещение. Но при этом 2Д может быть медленнее в случае если оно рисуется через alpha-blend с огромным количеством накладывающихся слоёв. Хороший пример — закрытие игрового «мира» чёрной подложкой и рисование чего-то другого поверх (например экрана опций). В случае, если появляется такое большое количество «перерисовок» (overdraw) мобилки начинают сильно захлёбываться из-за «физического» ограничения на количество отрисовываемых пикселей за кадр — fillrate. ПК от этого обычно меньше стадают из-за большей общей производительности.
Прошу прощения за двоепостие, я сейчас напишу в комментариях ещё одну статью, мда.
Стенсил у love2d — это чисто двухмерная фиговина.
Фактически, это маска отрисовки:
мы как бы рисуем на одном фреймбуфере произвольную фигню функцией стенсила, и на скрин-фреймбуфер уже рисуем уже то что хотели нарисовать изначально, через «фильтр» фреймбуфера-стенсила по какой-то методике.
Инверсия — это значит фильтровать пиксели «в обратную» сторону.
Это больше похоже на режимы смешивания, только с пометкой «рисовать данный пиксель или нет, а если да — с какой прозрачностью»:
Стенсил у love2d — это чисто двухмерная фиговина.
Фактически, это маска отрисовки:
мы как бы рисуем на одном фреймбуфере произвольную фигню функцией стенсила, и на скрин-фреймбуфер уже рисуем уже то что хотели нарисовать изначально, через «фильтр» фреймбуфера-стенсила по какой-то методике.
Инверсия — это значит фильтровать пиксели «в обратную» сторону.
Это больше похоже на режимы смешивания, только с пометкой «рисовать данный пиксель или нет, а если да — с какой прозрачностью»:
А есть список игр, написанных на LÖVE?
Как всегда жду подобные статьи, с более глубоким погружением в дебри LOVE.
Почему-то во всех этих статьях использут Саблайм/Блокнот/и тому подобные редакторы общего назначения, хотя есть замечательный ZeroBrane Studio с отладчиком и live-кодингом.
Лично я пользуюсь notepad++ потому, что привык с самого начала.
В моём варианте, когда постоянно переключаешься между lua/python/C(малые модули)/json/xml и т.п. — проще пользоваться одним инструментом, у которого уже помнишь все шорткаты, всё настроено и уже написаны все необходимые аддоны.
Zerobrane — хорош и восхитителен, в своей узкой области — lua-программирование. Но где ты найдёшь lua-разработчиков, которые пишут только и исключительно на Lua?
Хоть я таких и знаю, сам таким был пару лет назад, но с тех пор многое изменилось, notepad++ и lua/LÖVE просто оказались для меня первыми попавшимися ЯП/редактором/игровым фреймворком, за исключением DevC++ (мои самые первые попытки что-то писать), который я тогда не осилил. Утка? Ну что поделать, зато хорошо выучился.
Но вот к чему всё: редакторов много, люди выбирают под свой вкус или потребности.
Я даю описание того с чем работаю сам (жутко популярная фигня на венде, сложно найти машинку разработчика без NP++), и ссылку на крайне известную альтернативу.
Если хочешь инструкций для своей среды — можешь или загуглить, или отдельно спросить, это нормально.
В моём варианте, когда постоянно переключаешься между lua/python/C(малые модули)/json/xml и т.п. — проще пользоваться одним инструментом, у которого уже помнишь все шорткаты, всё настроено и уже написаны все необходимые аддоны.
Zerobrane — хорош и восхитителен, в своей узкой области — lua-программирование. Но где ты найдёшь lua-разработчиков, которые пишут только и исключительно на Lua?
Хоть я таких и знаю, сам таким был пару лет назад, но с тех пор многое изменилось, notepad++ и lua/LÖVE просто оказались для меня первыми попавшимися ЯП/редактором/игровым фреймворком, за исключением DevC++ (мои самые первые попытки что-то писать), который я тогда не осилил. Утка? Ну что поделать, зато хорошо выучился.
Но вот к чему всё: редакторов много, люди выбирают под свой вкус или потребности.
Я даю описание того с чем работаю сам (жутко популярная фигня на венде, сложно найти машинку разработчика без NP++), и ссылку на крайне известную альтернативу.
Если хочешь инструкций для своей среды — можешь или загуглить, или отдельно спросить, это нормально.
Love еще жив?
Когда я последний раз его пробовал он жутко тупил при трех-четырех одновременных касаниях экрана на ipad, после чего был сразу выкинут
Когда я последний раз его пробовал он жутко тупил при трех-четырех одновременных касаниях экрана на ipad, после чего был сразу выкинут
Боюсь что ты использовал не love а что-то ещё (на ipad довольно сложно билдить, сомневаюсь что ради одной пробы кто-то будет этим морочиться), плюс, на моей памяти (всеобъемлющей), love2d никогда не тупил на тачскринах в т.ч. ipad. Или это было особо специфичное использование фреймворка, тут, как на сишке — за корректность и скорость исполнения отвечает программист.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка на LÖVE