Это та самая версия, которую требует mari0? Т.е теперь не надо искать чужеродный .deb на далеких ppa?

Класс.

Жаль только что желания запустить mari0 еще раз это не вызывает.

Неплохо!

Движок в принципе неплохой.

Достоинства - прост. Использует правильный язык. Один бинарник. Под фенду умеет укладывать всю игру в один exe.

Недостатки

Не хватает документации. Вики слаб, неполон.

Куча несовместимостей по версиям, отчего игрушки работают только под определенной версией. Понятно, что один бинарник, можно класть рядом с игрой, но это довольно странно, когда игрушка не работает с более новой версией движка.

Игрушек, соответственно, тоже, считай, нет.

Думаю, что пока нет 1.0, APi ещё будет устаканиваться.

Игры, написанные с использованием LÖVE, одинаково запустятся на Linux, Win и Mac

В линуксе при сборке этого движка устанешь пыль глотать - правильная технология.

У меня как-то и не было проблем - всегда собирал сам. А в убунте он вообще в репах есть.

Не буду я ставить ни убунту ни уните ради какого-то Mari0 в который на денди сыграл столько, сколько смог, проще обойтись вайном.

ради какого-то Mari0 в который на денди сыграл

это уже не тот Марио

Этот марио другой.

Не буду я ставить ни убунту ни уните ради какого-то Mari0

Под Дебианом тоже есть LOVE ;)

Радость то какая! Движков такого и повыше уровня, куча, толковых игр только мало. А из дебиана лучше прихватизировать недостающие либы, в этом плане он хорош:)

полностью на языке lua

wikipedia:

Lua ([лу́а], порт. «луна») — интерпретируемый язык программирования

ненужно

Я только один аналогичный знаю. Большинство игр опенсорса пишется вообще без движков со свойственной медлительностью.

Пока вы на плюсах будете крестики-нолики делать за это же время на love можно платформер накидать:)

Во первых, сам движок компилируется.

А во вторых, для lua есть и Git и компиляторы.

Я только один аналогичный знаю.

Какой?

Большинство игр опенсорса пишется вообще без движков со свойственной медлительностью.

Вот влезешь в дебри ИИ и прощай скорость.

just-in-time

Припозднились вы с новостью, если честно (: релиз был полмесяца назад.

А вообще, штука неплохая, как мне показалось. С производительностью все в порядке.

Движок на плюсах вообще-то, а вот писать игры на этом движке надо на luaю

хорошая новость. марио мне понравился

Scrupp. Тот же LOVE но на си.

Вот влезешь в дебри ИИ и прощай скорость.

Делаю ИИ на луа. Никто пока не жалуется:)

Да я почему-то не заметил новость на их сайте. У меня такое ощущение, что админ её только вчера прилепил как объявление.

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

Вообще там довольно странный механизм.

Пишется функция love.draw, которая должна все выводить и эта функция выполняется как можно чаще.

Как я понял предполагается, что игродел создает свое представление состояния игры и функцию его визуализации в текущий момент.

А вторая функция выполняется с аргументом delta, тоже как можно чаще и в ней предлагается вносить изменения в сцену, поскольку можно хоть оценить, как давно вносились предыдцщие изменения.

Еще есть разного рода хелперы, камеры, даже система частиц, но они крайне хреново документированны.

Согласен.

https://love2d.org/forums/viewtopic.php?f=5&t=2570

just-in-time

да jit, конечно, а не git.

На самом деле непонятно, как происходит оптимизация вывода на экран объектов. Как движок поведет себя на сотнях или тысячах объектов?

Я попробовал пропускать в функции draw рисование неизменившихся объектов и получил совсем не то, эти объекты вообще пропали. Каждый раз надо прорисовывать всю сцену.

Я сам использую граф сцены для оптимизации. Тысячи объектов одновременно бывают редко, поэтому я скрываю/отображаю целые ветки графа, в итоге в среднем 100 объектов на сцене.

Для огромного кол-ва однотипных объектов там есть батч.

На 1000 объектов движок чувствует себя хорошо:)

Если пропускать что-то в draw - конечно этих объектов не будет на экране. В OpenGL перерисовка всего экрана - нормальная практика, поэтому объекты все нужно рисовать каждый раз. Но за счёт аппаратного ускорения тормоза начнутся только на гигантских сценах. Можно обсчитывать позиции объектов не каждый кадр, но это излишне.

В OpenGL перерисовка всего экрана - нормальная практика,

Не в OpenGL а в 3D, т.к. там хрен, что отклипаешь то, что на экране и не изменилось. А в 2D сам бох велел делать mark dirty область и её только перерисовывать. OpenGL, аппаратное ускорение хорошо, а производительность лишней не бывает.

вики

было бы совсем не плохо, чтобы страничка данного движка появилась в вики

Не в OpenGL а в 3D, т.к. там хрен, что отклипаешь то, что на экране и не изменилось. А в 2D сам бох велел делать mark dirty область и её только перерисовывать. OpenGL, аппаратное ускорение хорошо, а производительность лишней не бывает.

вот-вот. Хоть в функции update помечать, что там изменилось.

А то ведь лагает же в том же марио. Хороший экшен должен быть максимально быстрым, а тут такая нагрузка на элементарные вещи.

Да ладно, хоть бы можно было пропускать циклы перерисовки всего экрана полностью, если на экране ничего не изменилось. Но ведь даже такого флага нет, чтобы, например, в функции update вернул false, значит перерисовывать нечего.

> Т.е теперь не надо искать чужеродный .deb на далеких ppa?

Но зачем извращаться с PPA? Скомпилируй в каталог пользователя, установив зависимости автоматически с помощью sudo apt-get build-dep love.

Адрес сайта намекает на то, что движок двумерный, да? Если так, то неплохо было бы внести это в текс новости.

Дык у меня Федора.

Когда вышла mari0, еще даже не было исходников этой версии движка. Был только собранный движок в каком-то ppa для бубунты.

Я опакетил для федоры, но эту программу нужно разделять по версиям с возможностью параллельной установки. Этого я пока не осилил.

Надо отписать об этом разработчикам:) Хотя у них есть и собственная вики.

вот-вот. Хоть в функции update помечать, что там изменилось.

LOVE по большей части фреймворк, программист может выбирать сам как ему что отрисовывать и в каком порядке.

А то ведь лагает же в том же марио. Хороший экшен должен быть максимально быстрым, а тут такая нагрузка на элементарные вещи.

Мари0 лагает из-за кривых шейдеров.

Да ладно, хоть бы можно было пропускать циклы перерисовки всего экрана полностью, если на экране ничего не изменилось. Но ведь даже такого флага нет, чтобы, например, в функции update вернул false, значит перерисовывать нечего.

Эта возможность там есть, но она очень хитровывернуто заныкана внутри апи. Есть два способа: тупо внедриться в менлуп и не вызывать love.graphics.present, а можно воспользоваться ножницами - slissor, обновлять только часть экрана. Открою секрет: мейнлуп можно перекроить по собственному хотению и делать там всё что нравится. Я это в своём фреймворке (lQuery) собственно и сделал.

А вообще, в нормальной 2D игре (тетрис не в счёт) практически постоянно весь экран обновляется, в скролл-шутерах - однозначно постоянно. А если игра графикой не насыщенная - это вообще экономия на спичках.

Box2D как бы намекает... Хотя да, есть косяк, но я не могу уже править новость.

configure не проверяет наличие библиотеки libxxf86vm-dev

Посему компиляция не идет.

Нехорошо это.

Куча несовместимостей по версиям, отчего игрушки работают только под определенной версией. Понятно, что один бинарник, можно класть рядом с игрой, но это довольно странно, когда игрушка не работает с более новой версией движка.

Блин, получается что под линухом существование этого движка только номинальное.

Что делать бедному linux-пользователю, если у него установлен love-0.8, и для одной игры требуется love-0.79? Постоянно переставлять пакеты читоли? Разламывать репозитарий? Что делать то а?

Вот, пожалуйста:

https://love2d.org/wiki/Category:Games

Ни одна игра не работает:

Error: main.lua:64:
attempt to call method 'setMeter' (a nil value)
stack traceback:
main.lua:64: in function 'load'
[string «boot.lua»]:378: in function <[string «boot.lua»]:373>
[C]: in function 'xpcall'

Нафиг так движки проектировать?

Да, старые игры не работают с новым love. Впрочем, у них всего две версии основных: 0.7.2 и 0.8. Внутри мажорных версий апи не меняется, а 0.8 от 0.7 отличается как пароход от паровоза.

Отписал им по поводу багов в сборке. Да, жаль что нет обратной совместимости. Я даже потихоньку стал отказываться от использования love:) Но сначала это было из-за отсутствия нормальной поддержки шрифтов, а сейчас уже есть свои наработки в этой области.

Да, жаль что нет обратной совместимости. Я даже потихоньку стал отказываться от использования love :)

Под виндой тебя бы это не волновало. Положил екзешник и длл нужной версии в каталог с игрой, и все работает. Тут дело не в Love, а в самой инфраструктуре линукса, которая не предназначена для людей.

На самом деле у меня например другая политика - .so вкладывается как раз рядом с игрой, поскольку мейнтенейры слабо реагируют на игровые движки. Если ты программист и некому мейнтейнить твой код, то тут два пути - либо распространять бинарики под все платформы (так делает большинство игроделов) и исходники для тех кому нужно собрать под себя, либо вообще самому сидеть и под все дистры клепать пакеты:)

Что делать бедному linux-пользователю, если у него установлен love-0.8, и для одной игры требуется love-0.79? Постоянно переставлять пакеты читоли? Разламывать репозитарий? Что делать то а?

веь пакет, это один бинарник /usr/bin/love. достаточно сделать /usr/bin/love-0.8 и ставить пакеты параллельно.

Под виндой тебя бы это не волновало. Положил екзешник и длл нужной версии в каталог с игрой, и все работает. Тут дело не в Love, а в самой инфраструктуре линукса, которая не предназначена для людей.

а в линуксе тебе не дано положить «екзешник и длл нужной версии в каталог с игрой»?

а в линуксе тебе не дано положить «екзешник и длл нужной версии в каталог с игрой»?

Нет, линуховый бинарь работать не будет в овер 9000 дистрах, отличных от того, где он собран. Если подверсия ядра и libc не совпадет - дивяноста перцентов что будет сегфолт. Остальное упадет из-за несоответсвия подверсии какой-нить связанной либы, в которой что-то пофиксили и приделали новый баг, с котором работать не будет.

УМВРЧЯДНТ?

Нет, линуховый бинарь работать не будет в овер 9000 дистрах, отличных от того, где он собран. Если подверсия ядра и libc не совпадет - дивяноста перцентов что будет сегфолт. Остальное упадет из-за несоответсвия подверсии какой-нить связанной либы, в которой что-то пофиксили и приделали новый баг, с котором работать не будет.

Так ведь в венде тогда тем более работать не будет. Ведь там большинства связанных либ вообще не будет. А если даже случайно и будет, то кто сказал, что нужной подверсии?