Стандарт ещё толком не используется, но уже найдены уязвимости. Забавно звучит.
Хотя в принципе, это хорошо, что такие вещи выявляются до массового ввода в эксплуатацию.
Дело не в камере, а как раз в высокой скорости, из-за которой персонаж пролетает все блоки, «не успев» проверить коллизию с ними. И тут, да, либо ограничивать скорость, либо проверять столкновения иными способами, учитывающими скорость.
В проектах, идущих дальше обычных примеров, обычно пишется ещё файл conf.lua с таблицей параметров, где среди всего прочего можно указать версию LOVE, для которой это пишется. Правда, это только выдает предупреждение, мол, ваша версия LOVE неверная и это может повлечь за собой ошибки во время работы.
Можно, конечно, сделать проверку версии на запуске и несколько вариаций поведения, подходящих под разные версии API, но такое решение может быть слишком избыточным, да и я пока ни разу такого не встречал. Обычно либо всё пишется под последнюю версию и время от времени обновляется, либо опять же, указывается требуемая для адекватной работы версия (в документации, описании, или всё том же conf.lua), либо код просто уже никем не поддерживается и приходится переделывать места с ошибками вручную. Благо, что такими являются только места, где идет обращение к устаревшим love.* функциям, но иногда и там бывают свои проблемы, из-за которых приходится переделывать часть логики.
Я и сам им пользуюсь уже относительно длительное время, начиная с версии 0.7.2. После перехода движка на LuaJIT вообще пока нет желания куда-либо переходить, ибо производительности хватает на всё, так ещё и официальный порт на Android есть, что вдвойне хорошо.
Удачи вам в разработках и последующих статьях, с интересом почитаю ещё.
Тут, скорее, не разобрали, а написали и чуть-чуть описали — какой кусок кода что делает. В коде ни единого комментария. У людей, не знающих ни LÖVE, ни Lua, некоторые куски кода вызовут одно лишь непонимание и скорее всего, приведут к копипасту. Лично я так первое время и делал, когда читал статьи, а потом уже знающие знакомые и более подробные статьи смогли рассказать — почему именно так, а не иначе. Если же статья ориентирована на умеющих работать с данным движком, тогда все слишком просто.
Не лучше ли было бы описать подробнее некоторые элементы и добавить комментариев?
Странно, что вас не смутил факт, что камера находится у одного края стола, а микрофон на другом.
И, кажется, смотрит она не в камеру.
Хотя в принципе, это хорошо, что такие вещи выявляются до массового ввода в эксплуатацию.
Ну, как уже было написано в статье — держать в памяти весь массив пикселей было, мягко говоря, затратно.
Можно, конечно, сделать проверку версии на запуске и несколько вариаций поведения, подходящих под разные версии API, но такое решение может быть слишком избыточным, да и я пока ни разу такого не встречал. Обычно либо всё пишется под последнюю версию и время от времени обновляется, либо опять же, указывается требуемая для адекватной работы версия (в документации, описании, или всё том же conf.lua), либо код просто уже никем не поддерживается и приходится переделывать места с ошибками вручную. Благо, что такими являются только места, где идет обращение к устаревшим love.* функциям, но иногда и там бывают свои проблемы, из-за которых приходится переделывать часть логики.
Удачи вам в разработках и последующих статьях, с интересом почитаю ещё.
Тут, скорее, не разобрали, а написали и чуть-чуть описали — какой кусок кода что делает. В коде ни единого комментария. У людей, не знающих ни LÖVE, ни Lua, некоторые куски кода вызовут одно лишь непонимание и скорее всего, приведут к копипасту. Лично я так первое время и делал, когда читал статьи, а потом уже знающие знакомые и более подробные статьи смогли рассказать — почему именно так, а не иначе. Если же статья ориентирована на умеющих работать с данным движком, тогда все слишком просто.
Не лучше ли было бы описать подробнее некоторые элементы и добавить комментариев?