Помнится, для GPU нет понятия 2d или 3d, она просто выдаёт фреймбуфер требуемого размера с произвольными вычислениями посередине.
Стандартный 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, я ручками проверяю видимость объектов и не рендерю их в случае чего (спасибо, пространственные индексации).
Кстати, и Unity и Unreal, в 2d-играх, тем не менее работают в трёхмерном пространстве. Там просто отсутствует двухмерный режим, поэтому 2d эмулируется через 3d, у которого камера перемещается по одной плоскости.
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
P. S. В версии LÖVE 0.11.x должна появиться система перевода SDL-OpenGL в трёхмерный режим, со всеми сопутствующими фичами.
Боюсь что ты использовал не love а что-то ещё (на ipad довольно сложно билдить, сомневаюсь что ради одной пробы кто-то будет этим морочиться), плюс, на моей памяти (всеобъемлющей), love2d никогда не тупил на тачскринах в т.ч. ipad. Или это было особо специфичное использование фреймворка, тут, как на сишке — за корректность и скорость исполнения отвечает программист.
Лично я пользуюсь notepad++ потому, что привык с самого начала.
В моём варианте, когда постоянно переключаешься между lua/python/C(малые модули)/json/xml и т.п. — проще пользоваться одним инструментом, у которого уже помнишь все шорткаты, всё настроено и уже написаны все необходимые аддоны.
Zerobrane — хорош и восхитителен, в своей узкой области — lua-программирование. Но где ты найдёшь lua-разработчиков, которые пишут только и исключительно на Lua?
Хоть я таких и знаю, сам таким был пару лет назад, но с тех пор многое изменилось, notepad++ и lua/LÖVE просто оказались для меня первыми попавшимися ЯП/редактором/игровым фреймворком, за исключением DevC++ (мои самые первые попытки что-то писать), который я тогда не осилил. Утка? Ну что поделать, зато хорошо выучился.
Но вот к чему всё: редакторов много, люди выбирают под свой вкус или потребности.
Я даю описание того с чем работаю сам (жутко популярная фигня на венде, сложно найти машинку разработчика без NP++), и ссылку на крайне известную альтернативу.
Если хочешь инструкций для своей среды — можешь или загуглить, или отдельно спросить, это нормально.
Для того чтобы написать что чуть более крупное на LÖVE и не превратить это в кашу, необходим высокий уровень навыков программирования и проектирования приложений, а так же значительно больше усилий: API прост и позволяет вытворять сногсшибательные штуки, но все инструменты придется или брать у сообщества, или писать самостоятельно. Это все равно что делать адаптивные веб-сайты, с ajax'ом на каждый чих, без движков и библиотек: маленькие получаются сравнительно быстро и просто, но что-то крупное, при лимитах по времени, растягивается на всю твою жизнь (требуя высоких навыков проектирования), и или ты берешь библиотеки/фреймворки, или ты впихиваешь готовый движок.
Вот тут я попробовал слегка погрузиться в ООП и способы хранения игровых объектов. В "похожих публикациях" есть более простые примеры, так что это — лёгкое нарастание сложности.
Как правило, можно заменить нелатинскую букву на схожую латинскую.
По LÖVE, запросы составляются как «love2d spartial hash map», или похожим образом.
В обиходе, применяется название «love» или «love2d», это нормально.
Фреймворк развивается, без одной недели, десять лет.
Тут дело не в названии или ещё чём-то, а в простоте и комфорте применения, с чем тут всё хорошо. Есть несколько игрушек в Steam/GooglePlay, крупных проектов немного, но это не очень страшно.
Фреймворк делался и назывался «по приколу», и этим он тоже цепляет, как зацепил меня, четыре года назад, когда я не задумывался чтобы вообще стать программистом. Названия пользовательских библиотек — тоже забавные (но не всегда цензурные, всё таки love-тематика), и это тоже вклад в развитие общества.
Цитируя Спольски:
В 2003 году Nullsoft выпустили новую версию плеера Winamp, сопроводив выпуск вот такими комментариями на веб-сайте:
Клевый новый дизайн!
Навороченные фичи!
Большинство функций таки работает!
Я о последнем… «Большинство функций таки работает!» — это забавно. И все счастливы, довольны плеером, используют его, говорят всем своим знакомым и друзьям. И они полагают, что Winamp — это хороший продукт, потому что они таки взяли и написали на своем сайте: «Большинство функций таки работает». Круто, да?
…
Вот такие вещи и заставили нас влюбиться в Winamp.
А с тех пор, как корпоративные слизняки из AOL Time Warner прибрали эту штуку к рукам, весь юмор с сайта исчез. Вы теперь просто-таки явно можете представить их себе, этих сальери, убийственно подавляющих малейшие признаки творческого подхода, который может отпугнуть какую-нибудь немолодую даму из Минессоты. Ценой уничтожения всего того, что заставило людей реально полюбить этот продукт.
В данном случае, LÖVE «утирает нос конкурентам» своим дружелюбием, взаимопомощью комьюнити, не в последнюю очередь — отличной документацией и возможностью повлиять на развитие забавного и жизнеспособного опенсурс-проекта с десятилетней историей.
Не стоит цепляться к мелочам, вроде «Нелатинских символов», они не играют роли в сравнении со всем остальным.
Билдить на мобилки — можно, хоть и с некоторыми телодвижениями. Модуль touch и фунции вроде vibrate из вики — ориентированы на мобильные телефоны.
Для тестирования, в google play есть порт, с яблоками слегка сложнее, но, вроде, тоже цепляет. С ПК всё гораздо проще, подробнее можно посмотреть тут.
Принципиальные различия — defold является движком, со всеми причитающимися: менеджеры сцен, сущности, коллизии (без box2d) и т.п. Он заставляет отвлекаться от программирования в сторону изучения самой движковой технологии. Corona SDK — тоже набор функций/библиотек, на начале своего развития, частично списывалась с LÖVE, а потом пошла куча своих (сложных) ништяков. Это хорошо, если твоя задача — быстро-быстро делать игры, пока солнце ещё высоко и ты уже знаешь технологию, но не очень, если ты хочешь учиться/учить, или иметь почти полностью своё приложение без чьих-либо претензий на «использование чужого кода», хоть корона и бесплатна, код закрыт, и расширять/фиксить не всегда получится. Ну, я не использую потому, что нет LuaJIT, без этого — медленно, и я не могу делать игровые тайловые карты 100500х9000 пикселей битмапой, как с FFI.
В заключение, могу сказать что сравнение LÖVE и Defold/Corona, аналогично сравнению Lua и Python: Python старается дать всё что можно, Lua даёт всё что необходимо.
Подобные автоматические преобразования отваживают меня от жаваскрипта. Тут или пользоваться обёртками-трансляторами вроде typescript, или не писать вовсе.
Предпочитаю писать программы, а не разбираться в тонкостях синтаксиса, ибо слишком много потенциальных и действительных факапов, и не хотел бы быть нинздей языка, если это — исключительно суровая необходимость, чтобы не писать бешено медленную/постоянно ломающуюся фигню, чисто по незнанию россыпи мелких тонкостей.
Лично мне кажется, что жаваскрипту пора завязывать с обратной совместимостью, ибо пора бы уже перелопачивать. В сторону того же typescript, хотя бы.
В качестве решения проблемы обратной совместимости, на первое время, можно указывать браузеру версию js, вроде этого: #javascriptX.X.
Ну, а если и правда окажется здорово — то и фреймворки будут переписаны под последнюю версию. Конечно, возможна проблема как с python2/3, но только на первое время. В зависимости от форса новых стандартов/их фич.
Хм, мечты.
В многопоточных штуках, остаётся привязка к количеству физических/виртуальных ядер среды. Если наплодить 100 000 000 потоков, то уже сами таски окажутся в очереди между ядрами процессора. Когда-то делал сервер логирования, который был должен пережёвывать 100-500к логирующих сообщений в секунду, с учётом того что буфер входящих UDP-сообщений всего 64кб на всё про всё. Вот там, правда, я непрерывно перегонял сообщения из буфера сокета в буфер языковой структуры, для дальнейшей обработки, и пытался скомпенсировать скорость обработки количеством потоков. Но при кол-ве потоков более «N ядер — 1» (один — на поток приёма-записи в очередь), скорость всей системы снижается, ибо издержки на обслуживание каждого потока.
Закончил языковую школу в Москве. Из 60 человек — полтора программиста.
В соседней, математической школе того же выпуска — целых три. В соседней спортивной — ноль. В ещё одной английской — два. Я смотрю на то, куда поступали выпускники, и кем они стали.
Программистов мало. И собираются они в специализированных учебных учреждениях. И я совершенно не понимаю, зачем давать что-то сложнее игрушки из трёх команд тем, кто будет экономистом, юристом, актёром или менеджером среднего звена. Им это не нужно, напротив, испугаются и будут вспоминать как страшный сон. За полтора часа, нужно успеть сделать минимум, чтобы вытащить действительно заинтересовавшихся, проведя отсев всех остальных, которым это не нужно. Но чтобы и им тоже было интересно, потому что мало ли что.
Представь что ты — полный гуманитарий, у которого в голове не укладывается, что такое массив.
Ну не помещается и всё тут!
Полуторачасовая программа должна быть рассчитана и на таких тоже, чтобы понятно было вообще всем. Ибо из гуманитариев иногда тоже вырастают программисты, и неплохие. Если заинтересовались и всё таки вкурили.
Так три команды: update, mouse position и draw circle, допустим. С кружочками уже интересно баловаться, особенно если они реагируют на мышку. Заодно, сразу можно пощупать результат, и увидеть, что «всё не так бессмысленно, как подсчёт процентов и вывод суммы a и b». Ребёнок, который никогда не занимался — поймёт. А вот void/int/float — будут доходить ещё долго.
Чем меньше слов тем лучше для детей. C# для этого избыточен, особенно учитывая тотальное ООП: слишком много абстракций.
И если к десятому классу они ещё не занимались программированием, то 90% из них точно не пойдёт в программисты, и им точно не надо знать чем int отличается от char, что такое void, cin и cout. Имхо, проще подошло бы вообще не столько программирование, сколько написание простейшей игры из трёх функций на pygame (с дополнительной упрощающе оболочкой) или love2d (и так сойдёт), учитывая что там python/lua, минимум слов/особенностей фреймворков, и максимум предметной области.
За полтора часа, стоит объяснить, что такое переменная/функция/массив, и написать простейшую «игру» с кликаньем на кружочки, которые перемещаются по экрану. Это же значительно сильнее заинтересует десятиклассников, чем унылое «введите число, вот вам работа по формуле». Преподавание не должно быть унылым, это основное правило для преподавателя, любящего свой предмет.
В ВУЗе можно выпендриваться со скучными ханойскими башнями и всякими алгоритмами Монте-Карло, а в школе извольте подавать игрушки.
В принципе, организация компании без начальника возможна только в том случае, если кто-то пишет жизнеспособные спецификации. Иначе каждый работник будет заниматься только тем что ему интересно, оставляя «рутину» — на потом. В результате, окажется огромное количество малосвязанных фич, и продукт окажется особо никому не нужен, только потому что у кого-то плохо с приоритетами. Мало того, у хороших программистов регулярно бывают проблемы с приоритетами, и это нормально: это не менеджеры, это программисты.
Без начальника, который держит в голове временные рамки и срезы того что должно получиться, участнику проекта бывает довольно сложно определить, чем стоит заниматься в данный момент, ибо все офигенные идеи могут оказаться не так уж и необходимыми, по крайней мере, на данной стадии продукта. В Joel on software есть отличные статьи на эту тему.
Если проводить аналогии — мальчики работают скальпелями, которые хорошо делают всякие сложные финты но мало что помнят, а девочки — справочниками, которые много что помнят, но редко когда могут делать сложные финты из-за избытка информации.
Ну, плюс различия в знании теории и применении её на практике.
В данный момент, есть две сотрудницы-программистки. И они хороши.
Начитанные девочки, которые очень быстро разбираются со сравнительно простыми задачами.
Возможно, это особенности мышления, мол, девочки стараются охватить задачу целиком во всех подробностях, когда как мальчики — вычленяют несколько конкретных объектов в задаче, абстрагируясь от остального. Я, в основном, обращаюсь к девушкам с вопросами на тему «где что расположено» и «как в общих чертах работает та или иная штука». Из них получаются отличные помощники.
Тестировщики, кстати, тоже: пробовал тестировать ПО, где в голове нужно постоянно держать сразу штук десять документов подробной спецификации, по 20-40 страниц каждый. Не влезают, плюс очищаю кеш в голове каждый раз как выхожу из офиса. Но абстрагируясь от всего прочего, делаю довольно мощные инструменты, которые встраиваются в общую систему. Мне всё равно как работает система, если мой модуль выполняет задачи. И я забуду про него на следующий день. А есть девочка-тестировщик, которая помнит вообще всё. Правда, с большим количеством матлогики и абстракций у неё проблемы, и программировать она не может совсем.
Я про то, что девочки с мальчиками скорее дополняют друг друга, по особенностям мышления.
Рыбак — тот кто рыбачит, тот кто охотится — охотник.
Программист — тот кто пишет программы. Пока пишет программы — программист. Пока управляет другими программистами — менеджер или глава проекта. Не надо цепляться за слово или ярлык, это всё изменяется в течение дня. Но при этом невозможно найти «настоящего программиста», как и «настоящего мужчину», потому что тут только повод для спекуляций.
Стандартный pipeline выглядит примерно так:
В love2d это выглядит следующим образом:
То есть, передаём видеокарте на растеризацию набор вершин/полигонов и/или текстур через шейдер.
Это, насколько я знаю, двухмерный режим OpenGL, трёхмерный чуть иначе работает: там посылаем кучу всякой фигни, отсекаем невидимые камерой грани, строим z-буфер, по нему рисуем плоскости с натянутой текстурой, хитро обсчитанной… Это значительно медленнее двухмерной графики, хотя бы из-за минимизации расчётов в трёхмерном пространстве.
Ускорение, особенно на телефонах, может появиться в случае если мы пытаемся рисовать кучу всего «за камерой» благодаря отсечению невидимых граней, но когда я что-то пишу на love2d, я ручками проверяю видимость объектов и не рендерю их в случае чего (спасибо, пространственные индексации).
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
P. S. В версии LÖVE 0.11.x должна появиться система перевода SDL-OpenGL в трёхмерный режим, со всеми сопутствующими фичами.
В моём варианте, когда постоянно переключаешься между lua/python/C(малые модули)/json/xml и т.п. — проще пользоваться одним инструментом, у которого уже помнишь все шорткаты, всё настроено и уже написаны все необходимые аддоны.
Zerobrane — хорош и восхитителен, в своей узкой области — lua-программирование. Но где ты найдёшь lua-разработчиков, которые пишут только и исключительно на Lua?
Хоть я таких и знаю, сам таким был пару лет назад, но с тех пор многое изменилось, notepad++ и lua/LÖVE просто оказались для меня первыми попавшимися ЯП/редактором/игровым фреймворком, за исключением DevC++ (мои самые первые попытки что-то писать), который я тогда не осилил. Утка? Ну что поделать, зато хорошо выучился.
Но вот к чему всё: редакторов много, люди выбирают под свой вкус или потребности.
Я даю описание того с чем работаю сам (жутко популярная фигня на венде, сложно найти машинку разработчика без NP++), и ссылку на крайне известную альтернативу.
Если хочешь инструкций для своей среды — можешь или загуглить, или отдельно спросить, это нормально.
Для того чтобы написать что чуть более крупное на LÖVE и не превратить это в кашу, необходим высокий уровень навыков программирования и проектирования приложений, а так же значительно больше усилий: API прост и позволяет вытворять сногсшибательные штуки, но все инструменты придется или брать у сообщества, или писать самостоятельно. Это все равно что делать адаптивные веб-сайты, с ajax'ом на каждый чих, без движков и библиотек: маленькие получаются сравнительно быстро и просто, но что-то крупное, при лимитах по времени, растягивается на всю твою жизнь (требуя высоких навыков проектирования), и или ты берешь библиотеки/фреймворки, или ты впихиваешь готовый движок.
Тут вопрос про лёгкость гуглинга, а не про простоту набора символов.
Вот тут я попробовал слегка погрузиться в ООП и способы хранения игровых объектов. В "похожих публикациях" есть более простые примеры, так что это — лёгкое нарастание сложности.
По LÖVE, запросы составляются как «love2d spartial hash map», или похожим образом.
В обиходе, применяется название «love» или «love2d», это нормально.
Тут дело не в названии или ещё чём-то, а в простоте и комфорте применения, с чем тут всё хорошо. Есть несколько игрушек в Steam/GooglePlay, крупных проектов немного, но это не очень страшно.
Фреймворк делался и назывался «по приколу», и этим он тоже цепляет, как зацепил меня, четыре года назад, когда я не задумывался чтобы вообще стать программистом. Названия пользовательских библиотек — тоже забавные (но не всегда цензурные, всё таки love-тематика), и это тоже вклад в развитие общества.
Цитируя Спольски:
В данном случае, LÖVE «утирает нос конкурентам» своим дружелюбием, взаимопомощью комьюнити, не в последнюю очередь — отличной документацией и возможностью повлиять на развитие забавного и жизнеспособного опенсурс-проекта с десятилетней историей.
Не стоит цепляться к мелочам, вроде «Нелатинских символов», они не играют роли в сравнении со всем остальным.
Для тестирования, в google play есть порт, с яблоками слегка сложнее, но, вроде, тоже цепляет. С ПК всё гораздо проще, подробнее можно посмотреть тут.
В заключение, могу сказать что сравнение LÖVE и Defold/Corona, аналогично сравнению Lua и Python: Python старается дать всё что можно, Lua даёт всё что необходимо.
Предпочитаю писать программы, а не разбираться в тонкостях синтаксиса, ибо слишком много потенциальных и действительных факапов, и не хотел бы быть нинздей языка, если это — исключительно суровая необходимость, чтобы не писать бешено медленную/постоянно ломающуюся фигню, чисто по незнанию россыпи мелких тонкостей.
Лично мне кажется, что жаваскрипту пора завязывать с обратной совместимостью, ибо пора бы уже перелопачивать. В сторону того же typescript, хотя бы.
В качестве решения проблемы обратной совместимости, на первое время, можно указывать браузеру версию js, вроде этого:
#javascriptX.X
.Ну, а если и правда окажется здорово — то и фреймворки будут переписаны под последнюю версию. Конечно, возможна проблема как с python2/3, но только на первое время. В зависимости от форса новых стандартов/их фич.
Хм, мечты.
Мимо-луашник.
В соседней, математической школе того же выпуска — целых три. В соседней спортивной — ноль. В ещё одной английской — два. Я смотрю на то, куда поступали выпускники, и кем они стали.
Программистов мало. И собираются они в специализированных учебных учреждениях. И я совершенно не понимаю, зачем давать что-то сложнее игрушки из трёх команд тем, кто будет экономистом, юристом, актёром или менеджером среднего звена. Им это не нужно, напротив, испугаются и будут вспоминать как страшный сон. За полтора часа, нужно успеть сделать минимум, чтобы вытащить действительно заинтересовавшихся, проведя отсев всех остальных, которым это не нужно. Но чтобы и им тоже было интересно, потому что мало ли что.
Представь что ты — полный гуманитарий, у которого в голове не укладывается, что такое массив.
Ну не помещается и всё тут!
Полуторачасовая программа должна быть рассчитана и на таких тоже, чтобы понятно было вообще всем. Ибо из гуманитариев иногда тоже вырастают программисты, и неплохие. Если заинтересовались и всё таки вкурили.
И если к десятому классу они ещё не занимались программированием, то 90% из них точно не пойдёт в программисты, и им точно не надо знать чем int отличается от char, что такое void, cin и cout. Имхо, проще подошло бы вообще не столько программирование, сколько написание простейшей игры из трёх функций на pygame (с дополнительной упрощающе оболочкой) или love2d (и так сойдёт), учитывая что там python/lua, минимум слов/особенностей фреймворков, и максимум предметной области.
За полтора часа, стоит объяснить, что такое переменная/функция/массив, и написать простейшую «игру» с кликаньем на кружочки, которые перемещаются по экрану. Это же значительно сильнее заинтересует десятиклассников, чем унылое «введите число, вот вам работа по формуле». Преподавание не должно быть унылым, это основное правило для преподавателя, любящего свой предмет.
В ВУЗе можно выпендриваться со скучными ханойскими башнями и всякими алгоритмами Монте-Карло, а в школе извольте подавать игрушки.
Без начальника, который держит в голове временные рамки и срезы того что должно получиться, участнику проекта бывает довольно сложно определить, чем стоит заниматься в данный момент, ибо все офигенные идеи могут оказаться не так уж и необходимыми, по крайней мере, на данной стадии продукта. В Joel on software есть отличные статьи на эту тему.
Ну, плюс различия в знании теории и применении её на практике.
Начитанные девочки, которые очень быстро разбираются со сравнительно простыми задачами.
Возможно, это особенности мышления, мол, девочки стараются охватить задачу целиком во всех подробностях, когда как мальчики — вычленяют несколько конкретных объектов в задаче, абстрагируясь от остального. Я, в основном, обращаюсь к девушкам с вопросами на тему «где что расположено» и «как в общих чертах работает та или иная штука». Из них получаются отличные помощники.
Тестировщики, кстати, тоже: пробовал тестировать ПО, где в голове нужно постоянно держать сразу штук десять документов подробной спецификации, по 20-40 страниц каждый. Не влезают, плюс очищаю кеш в голове каждый раз как выхожу из офиса. Но абстрагируясь от всего прочего, делаю довольно мощные инструменты, которые встраиваются в общую систему. Мне всё равно как работает система, если мой модуль выполняет задачи. И я забуду про него на следующий день. А есть девочка-тестировщик, которая помнит вообще всё. Правда, с большим количеством матлогики и абстракций у неё проблемы, и программировать она не может совсем.
Я про то, что девочки с мальчиками скорее дополняют друг друга, по особенностям мышления.
Программист — тот кто пишет программы. Пока пишет программы — программист. Пока управляет другими программистами — менеджер или глава проекта. Не надо цепляться за слово или ярлык, это всё изменяется в течение дня. Но при этом невозможно найти «настоящего программиста», как и «настоящего мужчину», потому что тут только повод для спекуляций.