>Тут, кстати, нихуя нет и надо велосипедить все самому
Пофиксил
Пилю изометрическую 2д рпг. Велосипедю свой физон и компонентную архитектуру.
Я пилю просто вид сверху, а отображать буду просто с некоторыми преобразованиями (координата Y сжата в 2 раза, отрисовка определенных спрайтов на определенные углы поворота и прочее).
Скинь потом заготовки, когда провалишься. Просто хочу сам разобраться, как это все в коде выглядит.
Имею ввиду, как на уровне архитектуры всё организуется, модули там и структура.
Я просто всё всегда во одном файле держу. Жутко неудобно, когда код достигает тысячи строк, уже просто сложно ориентироваться по нему становится.
>когда провалишься
Нахуй пошел, пидор.
Я и так планировал выложить часть исходничков на форум лова.
Есть кучка прототипов с крайне хуёвой структурой, написанные б-г знает когда, после этого я застрял в тренировке на кошкак ака библиотечно-модульном состоянии.
Накатал кучу библиотек, от векторных на ffi (риальне быстрые, скорость и память на уровне C), только что запилил анимационную, со спрайтбатчами (тысячи и миллионы анимированных чуваков на экране за один вызов love.graphiccs.draw, видяха минимально грузится) и переиспользованием спрайтов (спрайтбатчи не поддерживают явное удаление, поэтому лишний буфер "удалённых" спрайтов, которым указан нулевой размер) и обрезка по видимому пространству (то что не влезает в экран - обнуляет высоту/ширину, в результате разгружается видяха) и ленивыми вычислениями текущего кадра. Кривоватая система анимированных объектов, которые могут состоять сразу из кучи спрайтов, а ля персонажи старбача, состоящие из тушки/рук/ног/башки/оружия/обвеса, масштабирующиеся, вращающиеся и сдвигающиеся корректной группой, и с теми же спрайтбатчами, даже если состоит из нескольких атласов (один спрайтбатч на атлас).
Сейчас принялся за сеть.
Либу сетевого взаимодействия с сервером (UDP), следящим за отваливающимися клиентами, колбекающим на каждый чих, добавляющим/удаляющим клиентов, считающим пинг и потерянные пакеты уже замутил.
Мутю софтину (можно и на чистой lua + luasocket), которая работает как "DNS"-сервер: серверы посылают ему запросы типа "добавь меня по такому-то имени", и эта штука добавляет их в список, периодически пингуя, чтобы NAT не проваливался. Клиенты посылают запрос, мол, "Дай чуваков с таким-то именем по маске", и софтина возвращает.
Пример запрос-ответа:
сервак с адресом '11.11.1.1:1488': 'set 2ch', ответ 'OK'
сервак с адресом '22.22.2.2:228': 'set 4chan', ответ 'OK'
клиент: 'get ch' (маска)
Ответ: '2ch 11.11.1.1:1488
4chan 22.22.2.2:228'
Да, отвечать на пинги от софтины обязательно, иначе отрубит.
Ответы от софтины могут быть в различных форматах, от json до csv, выбор произвольный.
Мне норм. Основная цель - связывать всякие мобилки которые сидят за NAT, получая прямой доступ: когда игрок выбирает сетевую игру, игра логинится в данной софтине, и с её помощью находятся новые игроки.
Такие дела.
Нихуево так мутишь там. Где-то можно глянуть код всего этого, или лично для себя все делаешь?
У тебя, кстати, проверка IP не совсем правильная, она будет позволять делать номера > 255.
Продолжение.
В целом, если ОП нуб, очень не советую ему лове. Тут реально нихуя нет, и всё приходится делать ручками.
С одной стороны, это идеально для маленьких игрушек, потому что не подгребается двести мегабайт лишних библиотек и прочего говна, плюс полная свобода. Во втором констракте, например, свободы нет от слова нихуя: только марио или спейс инвейдерс, только хардкор. Начинал с него, охуел от попыток хоть какой-то процедурной генерации.
С другой стороны, лове и не позиционирует себя как движок.
Это фреймворк. Набор функций, апишка для вызовов команд OpenGL/OpenAL/2dBOX и прочей херни.
И так и надо, не для слабаков чай строят.
Зато код легко портируется куда угодно без изменений (разве что на мобилки надо адаптировать шейдеры на GLSL ES), плюс скорость (FFI/Jit) даст фору яве и прочей хуйне.
Быстрее только C++, и то не каждый раз.
Есть проверки но позднее.
Мутю для себя, гитами не пользуюсь, только гугл-драйв для синхронизации/бекапов.
Могу покидать всякую фигню, плюс есть группка ВК https://vk.com/club61441078, в которой время от времени что-то появляется
1. Система состояний с референсом, специально для этого ушлёпка (>>305544)
http://pastebin.com/9rgH4BAj
Новые состояния можно загружать сразу из файла типа того: "gamestate:new('main menu', require 'main_menu')", файл main_menu.lua должен возвращать таблицу с функциями load/update/draw/keypressed/keyreleased и прочими любыми колбеками. А можно и просто таблицу хуярить. Состояния переключаются синглтоном из либы. Охуительно удобно, благо каждое состояние имеет своё пространство имён под ключом self.
2. Просто конечные автоматы, из которых можно делать другие конечные автоматы. Фактически, объект с системой состояний, который делает произвольные штуки.
Колбеки - load/update/unload, плюс своё пространство имён, очевидно.
http://pastebin.com/Fsd9YTb0
3. Вариант либы анимаций. Довольно специфическая и недопилен референс, но работает.
http://pastebin.com/XAQWxdud
>Мутю для себя
Так ты игровые проекты какие-то делаешь, или просто всякие штуки реализовываешь на лове?
Мб можно было бы скооперироваться, велосипедить вместе.
Да, игровые проекты.
Велосипедю для них же, ничто не просто так, всё для дела.
В данный момент, скооперирован с художником, пилим ведро-дрочильню. Образцы графона на пиках.
Тут в другом вопрос: насколько ты знаешь lua, love2d, FFI, JIT, паттерны проектирования, паттерны ООП, алгоритмы (типа коллизий/пространственной индексации), а так же линал, матстат и прочую хуету. Без этого, просто, нет большого смысла пилить что-то на love, потому что изучил новый паттерн - тут же хочется всё переписать. Я третий год непрерывно кодю, поэтому у меня приличный запас знаний, плюс оконченная математическая вышка, которая что-то да дала.
Так, ежели чо, могу помогать чем угодно, благо написана тонна говна, которую можно использовать где угодно, и накоплен приличный багаж инфы.
>нет большого смысла СОВМЕСТНО пилить что-то на love
Фикс.
В одиночку - есть смысл, за милую душу.
а годик сделать пяток змеек/тетрисов/астероидсов/понгов, залезть в сетевой код (Сетевая змейка, о да. Кстати, отличный старт),
попутно вызубрив ООП, основные паттерны, научившись в сишку и собственные подрубаемые dll-библиотеки с наборами функций для luastate.
Да, я согласен, что лов и луа не для новичков. Особенно учитывая, что классы в луа реализуются своеобразно.
У меня есть и опыт некоторый, и знания, и также тяга к знаниям, и желание раскуривать и запиливать что-то свое.
Недавно как раз коллизии на SAT написал для боксов с углом (делаю аркадную физику, пробовал бокс2д закостылить, но некоторые моменты мне не понравились). А сейчас в процессе запиливания Entity Component Systems.
Вай малаца.
На тему классов. Самая короткая либа классов с наследованием на пике. Моя. Любимая.
Мне просто лень подгребать файл с ООП на очередную крошечную прожку, предпочту скопипастить функцию. На совсем крошечные либы с полутором классов, на класс-таблицу просто вешается
setmetatable(class, {__call =
function(self, ...)
local o = {}
o.x, o.y = 10, 20
self.__index = self
return setmetatable(o, self)
end}),
этого достаточно для обычного ООП.
Не, это просто и можно не заострять внимание на специфичности ООП в lua.
Оно ничем особо не отличается от питонового/жаваскриптового.
тут есть и про структурирование и про всё остальное.
>ведро-дрочильню
Только сейчас у меня в голове сработал триггер, что ты пилишь под мобилки на лов2д (я же правильно понял?)
Как оно вообще с производительностью и стабильностью? Андроид же вроде пока еще не "официально" разрабами поддерживается?
Всё охуенно и с тем и с другим, проблем не было вообще, ну только шейдерный диалект чуть другой.
>>306042
Вы оба долбоёбы чтоль? Дают же бесплатный ZeroBrane, в котором есть и дебаг и лайвкодинг. Как вы блять вообще игры без лайвкодинга пишете?
И лове, и твой констракт - это одинаковые хуйни без задач, можешь успокоиться.
love2d это мультимедийный фреймворк общего назначения, обёртка на lua для сишной sdl2 и некоторых других вещей. На нём можно написать что угодно вообще. Если к тому же знаешь сишечку, то можно дописывать себе модули на ней и втыкивать их в своё поделие без проблем вообще. В частности, полагаю, что к стимворксу там обращение можно запилить без всяких прокладок за 5 минут.
Но это не игровой движок по сути, чтобы в нём появились сцены, камеры, твининги и прочая хуета, можно взять, например, hump, который по сути дефолтный уже чисто игровой движок для love2d.
констракт2 это не про программирование, это про что-то другое, я так не умею, мне проще кодом описать что я хочу, чем мышкой накликивать. Меня даже юнити в ступор вводит.
HUMP - не движок, это чисто набор тулзов:
Камера, векторы, состояния, ООП и сигналы а ля ивенты.
Движок - это готовая для наполнения контентом система.
На love сделан GRID, и это уже движок, с энтити-менеджерами, анимациями, клиент-серверной моделью и прочей фигнёй.
Читать тут: https://love2d.org/forums/viewtopic.php?f=5&t=80115
>Как вы блять вообще игры без лайвкодинга пишете?
Легко.
Самурай без меча подобен самураю с мечом.
Только без меча.
Обращения к SteamAPI через FFI.
1. Грузим steamapi.dll.
2. Дефайним функции.
3. Дёргаем методы.
4. ?????
5. PROFIT.
Подробнее тут: http://luajit.org/ext_ffi_tutorial.html
Кстати, игровые тайловые карты значительно эффективнее хранить в виде статических сишных массивов или массивов из сишных структур.
Пример векторной FFI-библиотеки, где каждый вектор - cdata:
http://pastebin.com/i7qC1aKn
Не совсем.
Это баланс между сахарной и супер-удобной высокоуровневой Lua и супер-быстрыми и экономичными сишными биндингами.
Обёртка вокруг сишной фигни делает её такой же сахарной и высокоуровневой как Lua, вместе с собтвенной скоростью и экономичностью.
Где-то валялся генератор сишных cтруктур любой размерности, с итераторами по этим самым размерностям для Lua. Да, к ним подрубаются метатаблицы, поэтому ООП тоже можно мутить.
Да, пример работы векторов.Они неплохо цепочатся, кстати.
Решил запилить свою реализацию ЕЦС. Функционала пока минимально, да и оптимизации никакой, решил сначала спроектировать удобное использование.
Собственно, дошел до такого кода простейшего компонента и простейшей системы (причем в самом "движке" ничего дополнительного не надо указывать):
function Component_Position(_x, _y)
local self = {
name = "position",
x = _x or 0,
y = _y or 0 }
return self
end
function Systems.Drawing()
local self = Systems.Base()
self.name = "drawing"
function self.draw()
local entities = self.get_entities()
for i, e in pairs(entities) do
local p = e.position
love.graphics.circle("fill", p.x, p.y, 10)
end
end
return self
end
Весь код: http://pastebin.com/7de48LxW (пока в одном файлике, ибо тестирую)
Попробуй изучить ООП.
Ты пишешь похоже на ООП, но не совсем.
Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code]
obj = {}
function obj.add(self, value)
table.insert(self, value)
end
это то же самое что
funtion obj:add(value)
table.insert(self, value)
end
Вызывать аналогично:
obj.add(obj, 30)
obj:add(30)
[/code]
Вот тебе пример класса с объектом:
[code]
Class = {}
function Class:new(x, y, r)
local o = {x = x or 0, y = y or 0, r or 30}
self.index = __self
return setmetatable(o, self)
end
function Class:draw()
love.graphics.circle('line', self.x, self.y, self.r)
end
object = Class:new(10, 20, 30)
object:draw()
[/code]
Почитай эту штуку:
http://tylerneylon.com/a/learn-lua/
Я использую замыкания. Не знаю почему, но такой вариант ООП как-то больше нравится.
http://lua-users.org/wiki/ObjectOrientationTutorial
Это не совсем ООП, потому что ты создаёшь полные копии объектов.
Смотри в чём суть: методы объекта хранятся не в нём самом, а в классе.
У тебя же - каждый объект хранит в себе весь набор "методов". Не могу сказать что это плохо для синглтонов, но это неимоверное засирание памяти для массовых штук.
Плюс объекты создаются дольше: провесить одну ссылку на класс значительно дороже чем создавать ещё одну функцию, выделять ей память и так далее.
В подобных замыканиях есть смысл, если тебе нужны приватные методы/поля, и то, старайся их минимизировать.
P.S. Освой мета-таблицы уже наконец.
Работать с lua не используя самый мощный её механизм - пустая трата времени.
Я сам, осваивал в три захода, с перерывами в пару месяцев. До этого делал процедурные штуки, которые имели довольно стрёмную структуру, просто потому что чтобы сделать процедурами что-то сложное и притом расширяемое - приходится быть самим Кнутом или Дейкстрой, предварительно рисуя кучу UML-ек, чтобы из головы не вылетала структура.
ООП (с несколькими дополнительными приёмами, типа чистых модулей, составления структуры директорий и дерева модулей, вызывающих друг друга) позволяет делать хуяк-хуяк и в продакшн, всего по паре-тройке предварительных макетов архитектуры.
Хех, сейчас работаю программистом на lua.
Довольно весело.
Да, памяти действительно больше отжирает, и создаются долго, но зато по скорости в самом использовании вроде как получше даже: http://lua-users.org/wiki/ObjectOrientationClosureApproach
Ну и из плюсов все-таки приватные поля.
>приватные методы/поля, и то, старайся их минимизировать
Обычно вроде наоборот стараются загнать все в приватные и делать геттеры-сеттеры, чтобы в будущем при использовании класса не напортачить чего лишнего.
>>308769
>Освой мета-таблицы уже наконец.
Недавно-таки раскуривал, написал свой класс для 2д вектора со всеми арифметическими функциями, правда все равно пока еще не совсем уверенно владею (всякие индексы, ньюиндексы и прочее).
>Хех, сейчас работаю программистом на lua.
О чем работка?
Вообще недавно только подумал о всяких оптимизациях кода на луа (для игр), и обнаружил много всяких интересных моментов этого языка, что прям захотелось поглубже изучить луа.
Работка - прямо сейчас - хайлоад-платформа для микросервисов.
Потом будут сами микросервисы. Ну там, логгирование в бд, с пиками в 100к запросов в секунду.
Не love2d, чистая lua с несколькими либами типа lanes для многопоточности.
Прикольно, видимо луа все-таки еще огого (хотя, наверное, в таких вещах больше используется как обертка над Си, нежели полностью самостоятельный язык, потипу питона или еще чего).
>lanes для многопоточности
Вот это интересно кстати, планировал свой ECS фреймворк попробовать распараллелить (там как раз системы для обработки сущностей должны хорошо параллелиться).
У Lua прикол в том, что она встраивается проще чем питон, сама по себе быстрая и лёгкая: единственные скрипты, которые реально используются в дохлых микроконтроллерах без особой памяти, плюс FFI, которая даёт возможность фактически писать на C на Lua, заодно, подключая совершенно любые сишные библиотеки, даже не адаптированные.
Фактически, это скриптовый и сахарный вариант няшной сишки с портабельностью и прочими шлюхами. Просто не распиарено, и как следствие - мало либ и сравнительно небольшое комьюнити. Так - очень универсальная штука, которая ещё и приятно выглядит и хорошо работает.
Ты чего то не понимаешь, а именно того что луа не полноценный язык а скриптопараша. Его дохуя где используют, особенно если нужна поддержка моддинга. Но сколько бы ты говна не навесил на скриптопарашу, она скриптопарашей и останется, для выполнения своих узких целей, и сишку при всем твоем желании она не заменит.
А, методы в энтити от старого кода остались, действительно.
На счет того, что и где хранить - пока еще думаю (в системах сейчас вроде только ссылки на сущности хранятся). По идеи в идеале энтити надо преобразовать в айдишник, и где-то хранить массивы только лишь компонентов.
>что и где хранить - пока еще думаю
Представь, что ты в рантайме добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом. Забыл одну - привет, неведомые баги.
Представь, что ты решил делать игру, где битвы происходят на отдельной карте (ну, или гуи руками делаешь). Теперь при переходе на экран боя (или меню) надо из систем выковыривать сохранённые энтити и где-то их хранить до конца боя. А можно было просто свапнуть менеджер энтитей, и всё само бы работало.
>добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом
Логически, эти вещи как раз должны вместе идти по идеи. Например, какой-то ответ на коллизию должен быть - добавляем компонент этой коллизии и тут же подписываем сущность на нужную систему, которая именно эту коллизию обрабатывает.
Да, на счет какого-то менеджера сущностей и подумывал.
На счет хранения больше волнует вопрос об оптимальности по объему памяти и по скорости обработки. Если, например, делать массивы компонентов по их типах (массив позиций, массив скоростей и т.д.), то могут быть 2 варианта хранения: 1) когда в массиве индекс компонента строго соответствует айди энтити, но тогда будут "дыры" в массиве; 2) хранить компоненты "плотно", но вводить еще какие-то дополнительные связки индексов или ссылок.
Однако я сейчас только додумал о том, что однотипных компонентов может быть несколько, например за один такт обработки физики было нанесено сразу несколько дамагов одному энтити, тогда надо делать для каждого дамага свой компонент с именем того, кто нанес, и само кол-во дамага, и все эти компоненты далее должны будут системой дамага обрабатываться.
Тогда надо либо хранить по 2-му варианту, либо в менеджере сущностей делать двумерный массив, т.е. хранить массив под сущности, а уже в том массиве конкретной сущности хранить все экземпляры компонентов.
Тут есть еще статейка про организацию памяти для ES, мб кому еще интересно: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
Имхо, идея параллельных массивов довольно дурацкая.
Если тебе действительно Очень Нужна Экономия Памяти - используй FFI-структуры.
http://luajit.org/ext_ffi_tutorial.html
Это в сотни и тысячи раз уменьшает расход памяти и даёт быстрый доступ.
Другое дело что оно статичное, поэтому максимальное количество объектов приходится рассчитывать заранее, или хранить в lua-таблице.
Я подумал, что все-таки не буду углубляться в дикую оптимизацию того, что пока еще вообще не до конца допилено. Но все-таки хочу в итоге организовать все более-менее рационально и удобно средствами Луа. В статье выше все-таки делается расчет на десятки тысяч объектов, мне же сойдет и пару сотен на первое время.
Собственно, сделал энтити идентификаторов, и разделил список всех сущностей и список подписавшихся. Я подозревал, что при изменении структуры на более правильную и наращивании функционала вся структура кода будет идти немного косо, но не думал, что настолько рано. Однако схему создания компонентов и систем в моей реализации удалось сохранить. Заодно пришлось разобраться с итераторами и запилить собственный.
local entities = self.get_entities()
for i, e in iter_select(entities) do
local p = e.position
love.graphics.circle("fill", p.x, p.y, 10)
end
http://pastebin.com/QZzf2Uwh
Десятки тысяч упаковываются в одну lua-таблицу, как ffi-структуры.
Вкури это уже и не еби себе моск.
Как правило, чем проще решение тем лучше.
Да дело не столько в структурках, сколько в их организации.
И мне кажется писать для каждого компонента что-то типа ffi.cdef[[typedef struct { double x, y; } point_t;]] только лишь для того, чтобы данные чуть компактнее были, заместо привычного луа-кода, оно не стоит того, притом что нужда в компактности не такая большая.
Если уж ударяться в харкдор, тогда все на Си надо писать. А так мне больше интересно сам луа поковырять.
Простых организаций сущностей и так сделано дохрена.
Чем тебе коллекции с ключами-id не угодили, кстати?
Ну там, сущность:
entity[id] = obj = {x, y, sprite, update, draw, owner = playerN}, где update/draw - функции с колбеками и прочей дрянью.
Ну, и унификация этих же сущностей, мол, каждая должна иметь методы update/draw, а если не имеет того же draw - вместо отрисовки сущности используется рисование прямоугольника.
Достаточно просто же!
Спавн сущности - добавление элемента в табличку, доступ и удаление по id - простое. Чтобы не париться с уникальностью id - генератор UUID.
Всё что можно на ссылках.
Да, все ссылки на сущность (например, ссылка у владельца Меча Тысячи Истин) должны быть со слабыми ключами, чтобы удалив сущность из коллекции, она же удалилась у владельца.
UPD: Или наоборот, ссылки в коллекции сущностей слабые, а у владельцев - сильные.
Если владелец - игровой мир - рисуем её в игровом мире.
Так у меня практически тоже самое и реализовано.
Создание сущности:
function self.newEntity()
table.insert(entities, {})
return #entities
end
Возвращается по сути ID этой сущности, по которому потом можно нацеплять компоненты и подписывать на системы.
А системы имеют список subscribers, в котором содержатся ID тех, кто подписан на эту систему.
Одна из защит от обращения к несуществующим сущностям реализована в самом итераторе.
Избавление от прямого наличия методов update и draw - по сути одна из фич ECS да и вообще дата-ориентированного подхода. За счет замены тех методов на системы достигается избавление от всяких наследований и получается гибкость конструирования сущностей.
>return #entities
На самом деле это не всегда правда будет, но это потом допилю.
Ладно, как знаешь.
С ООП на замыканиях, ты создаёшь кучу дубликатов и в целом, странных вещей, но это твоё дело, хех.
Просто попробуй различные варианты, и действуй исходя из практичности, а не хуярь всё подряд "золотым молотком".
Я думал какие-то из классов все-таки переписать без замыканий, но потом понял, что в данном случае это на самом деле мало что изменит: все системы всегда будут иметь один единственный экземпляр, и сам менеджер также используется в единичном количестве (ну или может пару их можно создать для разных состояний игры, например, но это не существенно). В текущей реализации вроде вариантов больше никаких нет, или я не вижу их.
В дальнейшем если еще что-то буду делать или эту архитектуру переделывать, то уже буду смотреть каким методом лучше запиливать ООП.
Завел себе репозиторий, вынес код фреймворка в разные файлы. Правда системы и компоненты оставил "по-деревенски", т.е. в одном файле куча компонентов или систем, но пока их немного - и так норм, легче отлаживать.
Решил проверить реализацию ивентов, выскочило несколько проблем:
опять же существование несколько однотипных компонентов у одного энтити (наверное все-таки введу айдишники),
еще как выше обсуждали - ручное или автоматические подписывание на системы - ручное дает гибкость, а автоматическое позволяет меньше задумываться над этими вещами (я не уверен, но возможно в любой задаче можно будет обойтись без той гибкости),
добавление/удаление компонентов, подписка/отписка от систем из других систем (пока сделал не очень красивое решение, но лучше хз как).
В общем использовать примерно так:
ecs.addComponent(e2, Component_Timer_Event(1.0, "change_direction", Component_New_Direction, {vx=love.math.random(-1, 1)30, vy=love.math.random(-1,1)30}))
ecs.subscribe(e2, "timer_handling")
Следующим шагом планирую запилить физику, в идеале в двух вариантах: интегрировать самописную и внедрить бокс2д.
Репа: https://gitlab.com/m1tch/ecs_on_lua/tree/master
А, еще забыл про проблему приоритетов систем. Я сначала думал, что как они объявлены, так они и будут храниться в списке систем, но это совершенно так, и они даже ни в каком не обратном порядке.
Не знаю, понадобиться все-таки эта приоритезация, т.к. в продолжительном времени они все равно все циклически будут обрабатываться, но если по-хорошему делать, то это надо.
Box2d неимоверно тяжёл.
Для задач платформеров/леталок-стрелялок даже с худо-бедной физикой его слишком много. Из пушки по воробьям.
Особенно если ты хочешь заставлять прыгать персонажей через applyForce.
Да, согласен, если какие-то аркадные штучки делать, при придется костылить.
Но в данном случае я хочу подключить его для теста своей архитектуры, т.е. смогу ли я прямо в эти системы и компоненты вписать внешнюю библиотеку (потом может и гуи какой-то придется вписывать).
Одна из проблем, которую я вижу, это добавление в бокс2дшный мир новые тела (т.к. у меня системы никак вручную не инициализируются, и не получится организовать везде свободный доступ к созданному миру); предполагаю, что придется решать через дополнительные сущности и системы (например, сущность - бокс2д мир, и компоненты, прикрепляемые к нему - описания новых тел, а какая-то система будет заниматься добавлением этих тел в физ. мир, другая же система будет делать как и положено world:update(dt) ).
Другая проблема - описание и добавление новых коллбеков в физ. мир при коллизиях. Решение, наверное, аналогичное.
В отсутствии свободного доступа к миру изначальная проблема твоей архитектуры.
Костылей не наберёшься, и наткнёшься на большие сложности расширяемости.
Я предупредил.
P.S. Я писал МНОГО вещей на love2d, пробуя разные варианты.
Наиболее эффективный - набор коллекций для всех персонажей имеющих ИИ, снарядов, сущностей и карта.
Каждый элемент имеет свои методы update/draw.
Проходим по списку, обновляем, отрисовываем.
Даже если объекты очень разные - они тем не менее обновляются и отрисовываются, ровно так как тебе хочется.
Всякие сложные объекты, вроде каких-нибудь снарядов в виде вращающихся лезвий, которые зависают в воздухе или липнут к поверхностям - конечными автоматами, где вместо update/draw подставляются соответствующие методы из текущего состояния (перегрузка __index, например), и методы взаимодействия с другими коллекциями, которые дёргаются в update.
Получается наиболее открыто, и легко добавлять что угодно.
Ну я пока и щупаю проблемные места.
>>310808
У тебя одна сущность имеет один update в котором всё-всё-всё, или набор update с разными предназначениями? Если второе, то эти апдейты можно случайно (по какому-то случаю) нацеплять/отцеплять от сущностей?
И как ты все-таки физику реализовал? Ведь она не в самих сущностях, а над ними. И нужно определенным образом еще итерировать по ним, если это самописная физика, либо придерживаться некоторых внешний правил, если это готовая библиотека.
Эмм. Отцеплять окончательно нельзя.
Знаешь что такое конечный автомат?
Кароч.
object = {}
object.states = {iddle = {update, draw}, walk = {update, draw}}
object.currentstate = object.states.iddle
function object:update()
self.currentstate.update(self)
end
function object:draw()
self.currentstate.draw(self)
end
Примерно так, но с мета-таблицами можно в несколько раз лаконичнее.
Учитывай что таблицы записываюся в переменные как ссылки на них.
Физика - итерируем по объектам. Смотрим с чем сталкиваются (sweep & prune/quadtree/регулярная сетка в помощь). То с чем кажется что сталкиваемся - проверяем. Если и правда столкнулись - выполняем разрешение коллизии для обоих объектов.
Изич же!
Если использовать внешнюю систему - они, как правило, возвращают ссылку на физический интерфейс объекта.
Хранишь в сущности ссылку на физоновый объект, применяешь к нему его методы, узнаёшь координаты/списки столкновений/прочую хуету.
Для этого дела, советую либу Hardon Collider.
Она не решает коллизию автоматически, только выдаёт ссылки на объекты, с которыми произошло столкновение и dx/dy как вектор ближайшего разрешения коллизий. Это удобнее чем всё остальное, благо прямо таки объекты, возвращаемые либой можно пичкать параметрами и методами (главное - не оверрайдить уже имеющиеся), получая минимум затрат памяти.
Хм, окей, идею понял. Больше похоже на то, что я раньше делал, ну у меня попримитивнее было, когда основное понятие - это объект, т.е. данные+методы достаточно жестко связаны. Фича ECS как раз в том, что можно практически "на горячую" менять отдельные детали поведения и содержимого компонентов.
На счет твоей идеи сейчас не могу сразу сказать на сколько может быть удобно относительно ECS использовать, надо подумать над разными примерчиками.
Либа, кстати, интересная, спасибо за подсказку. Правда я уже свою запилил для OBB, но может чего подгляжу или интегрирую коллизии в свою физику.
>на сколько может быть удобно относительно ECS использовать
Я делал
а) локальное пространство самого объекта, а ля глобал внутри self,
б) локальное пространство внутри состояния, обращение по __index-перенаправлению на currentstate или метод self:getState().key = value. Просто и неимоверно эффективно.
На мой взгляд.
Lua гибкая.
>подписка/отписка от систем
Делай, чтобы системы у твоего менеджера запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные). Чем меньше состояния хранится вне компонентов, тем лучше и проще.
>>310793
>они даже ни в каком не обратном порядке
У тебя просто хеш-таблица вместо массивов/списков. Я себе делал приоритет для каждой системы, потом менеджер этого всего при добавлении новой сортировал все системы по этому приоритету. Позже я заметил, что всё равно стараюсь их размещать так, чтобы они регистрировались в том порядке в каком будут исполняться, и сами приоритеты я нигде не меняю, поэтому отказался от них вообще.
>>310804
>добавление в бокс2дшный мир новые тела
Делаешь систему физики. Далее, вместо прямого добавления и удаления тел, добавляешь энтите компоненты AddBody или RemoveBody, которые уже системой физики обрабатываются так, как она хочет.
>запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные)
Я вот на счет этой автоматизации пока и сомневаюсь. Теоретически возможно такое, что компоненты все идентичны, но поведение разное (ну, навскидку, 2 бота, один добрый, другой злой, один просто гуляет, другой нападает на игрока). Можно, конечно, какие-то теги или компоненты с "описаниями" ввести, но хз.
На счет приоритета - у меня сейчас менеджер сам подбирает все системы из таблицы Systems и инициализирует их у себя, т.е. у меня нет такого, типа manager.addSystem(drawing_system). Хотя это в общем-то интересная замена приоритетам, когда самостоятельно подключаешь системы в определенном порядке, надо подумать.
На счет физики и компонентов новых тел так и подумывал. С ручной подпиской на системы, правда, еще несколько моментов придется продумывать.
>Теоретически возможно такое, что компоненты все идентичны, но поведение разное
Такого быть не может. Разное поведение получается не магически же, а ты как-то их различаешь и запускаешь разный код. Различать можно тремя способами:
1. Разные компоненты.
2. Разные значения в каком-нибудь компоненте (AiComponent.isHostile или что-то подобное)
3. По имени энтити.
Очевидно, что третий способ долбоёбский, а для первых двух нифига не изменится, если ты будешь запрашивать, а не подписываться. Единственное, зачем нужна эта подписка - производительность (да и тут ещё вопрос, что будет быстрее, потому что в реальной игре каждая система добавляет/удаляет десятки/сотни компонентов - в зависимости от размера игры), но на первый раз лучше сделать "как правильно", а потом уже смотреть, если будет нехватать.
Хм, да, согласен, компоненты все-таки легче отслеживать и они не такие "низкоуровневые" в отличие от ручных подписок на системы, т.е. юзабельность повысится даже если придется делать компоненты-теги, или совсем-совсем частные типы компонентов, а гибкость останется примерно на том же уровне.
Запилил выбор подписчиков в системах через новый самописный итератор, который внутри проверяет requirements (возможно стоит оптимизировать, и обновлять существующий список по добавлению новых компонентов к сущностям).
Ну и решил проблему со множественными компонентами: как я подумал, если каких-то компонентов может быть много, то они, скорее всего, являются событиями. Собственно, поэтому сделал 2 разные функции: addComponent и addEventComponent. Отличие второго в том, что по обращению к entity[component.name] будет возвращаться массив компонентов типа component.name. Единственное, что теперь системы, обрабатывающие ивенты, стали несколько толще, ибо приходится еще перебирать сам массив ивентов (подумываю на счет того, чтобы автоматизировать выборку сущностей и компонентов, т.е. перенести циклы из систем в менеджер, а в системах работать только с выданной сущностью/компонентами типа update(entity, dt), но тогда хз как физику запиливать).
Потихоньку накапливаются вещи для оптимизации (в хорошем смысле) и для налаживания безопасности (удаление сущностей/компонентов/систем), но они пока не в приоритете, ибо хочу уже запилить полный функционал фреймворка. По плану все еще реализация физики.
Еще щас подумал. Например, реализацию движения (Systems.Moving), т.е. обновление координат, можно (гипотетически) запилить через ивенты, которые будут возникать на каждом такте, а т.к. оно сейчас реализовано без них, значит и систему событий можно теоретически развернуть в обычное обновление.
В таком случае, наверное, надо будет просто добавлять дополнительные флаги и счетчики в определенные компоненты, а в системах их обсчитывать, и обрабатывать только тогда, когда какие-то условия срабатывают.
Т.о., если нанесение урона происходило бы по ивенту, то в новом варианте можно сделать компонент Damage (и он будет в единственном кол-ве в энтити) с полем health_damage, и если никто не наносил урон, то это поле = 0. А в системе Damaging можно просто без всяких условий делать entity.health = entity.health - damage.health_damage
Но пока хз на счет гибкости и юзабилити такого подхода.
Начал свою игру про вселенную где можно делать ВСЁ ещё во времена 8, в 9 аесь апи поменяли пришлось переделывать, подзаебало стал простаивать, потом к 10 опять всё переделывать уже забросил.
Вообще то что там нихуя нет хорошо - если где-то криво сам правишь не надо чужой сортир копать.
Можно было продолжать на 8 или 9 пилить если ты мог на них пилить, какая разница какая версия?
Там толи какая-то хуйня с производительностью была от каких-то функций толи ещё что-то не работало, не помню уже.
андроид порт только в 0.10 добавили, норм ретину только в 0.11 завезут. впрочем я хз что там надо было такого нахуевертить, чтобы переделывание под новую версию заняло больше 1 выходных.
не бойся у твоего 3-в-ряд с донатом конкурентов нет
Запилил свою физику в свой фреймворк.
Пришлось подумать как реорганизовать цельную обработку коллизий (нашли одно-разрешили одно) в поэтапную (нашли все - разрешили все). Решил, что пускай сначала в виде ивентов у энтити будут накапливаться коллизии, а потом в другой системе, если тела все еще пересекаются, то разрешать их. Т.е. у меня сейчас 2 системы на это: проверка коллизий, и разрешение коллизий, но сейчас понял, что это минимум, и систему разрешения надо заменить скорее на систему определения типа коллизий (или все-таки прикрутить это к самой проверке), а далее, само разрешение (расталкивание) будет одним из этих типов (и будет отдельная система под это).
Еще приходится в ивентах постоянно следить, чтобы они удалялись после обработки, мб оптимизировать это как-то.
В целом могу сказать, что фреймворк работает, надо только немного перестроить мышление под обработку компонентов системами (а не объектов апдейтами), и можно будет получать кайф от модульного кодинга всего функционала игры.
https://love2d.org/forums/viewtopic.php?f=5&t=83158
И до этого можно было.
https://love2d.org/forums/viewtopic.php?f=5&t=78943
>андроид порт только в 0.10 добавили
пора на дифолд перекатываться уже. ничем не хуже хуюнити, базарю
http://www.defold.com/manuals/lua/
Вроде туторы норм есть, какие-то игры сделаны, компил под разные платформы, но комьюнити че-то никакое, лов2д как-то поживее.
Инты и булы по значению, таблицы и строки по ссылки, что непонятного?
Какие функции тебе нужны? Комьюнити луа хоть и относительно мертвое по сравнению с другими языками, но все-таки умельцы делают достаточно всяких либ, которые покрывают большинство возникающих потребностей, надо только поискать.
Так-то язык довольно прикольный и легкий, со своими фичами.
Да я просто охуел, что таблицы копируются по ссылке и нет стандартной функции клонирования, но уже загуглил. Просто не очень интуитивная шняга, переписать бы этот фреймворк под православный руби.
У нормальных людей уже давно свой пак либ-на-все-случаи-жизни, чтобы не пердолиться с мелкой фигнёй.
Есть ли у отписавшихся тут какой-либо прогресс и успехи?
Или свалили в итоге на что-то еще?
Ну так, более-менее.
Время от времени что-то пилится, например, сейчас таки замутил систему сущностей на HC с тегированием и блекджеком.
Там что-то такое.
прикольно, если бы они еще не трахали его и держали дистанцию и что-то делали по idle.
в этом плане было интересно изучать Don't starve. Там подобное относится к 'мозгам'. Советую глянуть как там реализовано.
Ну, это простейший тестовый ИИ, который нужен только чтобы узнать, работает ли система ИИ, так что ничего страшного.
Мне другое интересно: как нормально впиливать поиск путей, который будет работать с комплектами полигонов, и не проще ли при создании карты заранее построить графы путей, по которым можно двигаться как по ключевым точкам. И да, игра должна проходить на замкнутом пространстве, с ключевыми точками вроде зон захвата (нет, это не wot2d), точками спавна бонусов и всего такого, и с временно недоступными зонами, вроде открывающихся/закрывающихся ворот.
Алгоритмы ИИ должны учитывать, что прежде чем проходить ворота, их нужно открыть.
Каркас двигла замутил?
Просто без этого, разработка затянется, ибо вместо наполнения контентом, будет разработка базовых инструментов. Хотя, конечно, можно взять GRID.
P.S. Сам не хочу слезать со своих проектов, надо закончить хоть что-то.
Свой убер-ECS фреймворк как раз писал для этого.
Не знаю, придется ли его еще допиливать, но простой прототип со своим физоном и простой ГУИ на кнопочках достаточно легко получилось сделать.
Единственное, что не нравится, нет менеджеров сцен и полноценного (или хотя бы минимального) гуя из коробки, поэтому придется либо сторонние модули подключать либо писать велосипед (но они меня сильно подзаебали, так что уже хочется чего-то готового).
Пробовал нарколыжить в HaxeFlixel еще, но что-то он меня пиздец вымораживает со своими обновлениями хитбоксов и прочего при изменении свойств объектов.
Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
>Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
Там по сути от ООП вообще ничего нет, кроме двоеточия для передачи "self" в качестве первого параметра метода.
Но если раскуришь суть таблиц, метатаблиц, замыканий в lua, то, как мне кажется, становится даже интересненько.
В общем в луа много чего занятного можно найти.
Короче, залез в колхоз еще глубже.
Есть у меня сцена, в общем, на ней тайловая карта, даже не важно откуда. Так вот в чем дело, отрисовать саму карту, в принципе, сложности не составляет, даже регион, элементарно. Только вот что делать с объектами. Допустим, у меня тысячи их, естественно, отрисовывать объекты, находящиеся вне области видимости смысла нет, поэтому нужно использовать либо сетку размещения (или как это дерьмо называется) или квадрантные деревья.
Или это леха сам делает?
По-моему для отрисовки ничего такого не применяют. В буфер отрисовки записывается только видимая часть, и занимается этим OpenGL/DirectX, которые используются в SDL (Love2D вроде на нем основан).
Разбиение пространства обычно для расчет физона используется, ибо считать столкновения для 1000 объектов действительно проблематично.
А для ускорения отрисовки, особенно тайловой карты, используют батчинг (sprite batch), т.е. по сути составление одной большой картинки из тайлов, которая за один вызов функции сразу вся отрисовывается.
Про батчинг я знаю. Вот именно проблема в том, что именно отрисовывать, не буду же я перебирать 10000 объектов (в поисках тех, которые попадают в экран), скажем, если на экране в области видимости только 30 из них, например.
Или все же сделать простым перебором всех сущностей и отрисовывать только те, которые появляются на экране.
Попробуй сначала отрисовать вообще все и посмотреть хватает ли фпс. Потом уже оптимизировать.
Разбей карту на кусочки NxM тайлов, рисуй только те чанки, которые влезают в камеру. Один батч на один чанк. Идеально - прорисовка четырёх-девяти чанков квадратом. Подгони размеры чанков под камеру, или, если есть зум, вычисляй область видимости. Да и в памяти обычно не нужно держать всю карту, выгружай ненужные куски. Ясен хрен что ближайшую область надо держат
ь, чтобы не тормозило га чтении Так даже легко мутить бесконечные карты как в майнкрафтике. Ничего сложного, просто арифметика.
Дополнение:
Аналогично можно поступить с игровыми объектами, спавня их в нужном чанке. В чанк пихать список ссылок на нпс, а у нпс - хранить ссылку на чанк в котором он сидит. При перемещении, нпс самоудаляется из чанка в котором был, добавляется в чанк в котором оказался, и меняет свою ссылку на текущий чанк. И так - с любыми объектами.
- требуется обсчитать что-то ресурсоемкое, но его нужно обсчитать не ПРЯМО СИЙЧАС, а на низком приоритете и по готовности сгенерить евент. То есть не в текущем update, который должен длиться доли секунды, а вообще в принипе.
Можно ли добавить как-то фоновую задачу?
- предположим некропека не выдерживает эти ваши 60фпс или даже консольные смус 30фпс. Как мне дропать фреймы? Завести счетчик, который будет обновляться в update и в draw уже просчитывать когда скипнуть, а когда нет? нужно ли при этом делеить или задержка и так генериться между каждым update?
сам себе отвечу на второй вопрос - наверно проще как-то задать фпс, если он вообще задается?
зачем оно вообще нужно? ну например для пошаговой игрульки 60фпс НИНУЖНА, а скажем 5 хватит на анимацию.
предположим есть у нас буфер в котором отражен слой из тайлов - задников. Ну чтобы совсем проще выразиться. Предположим у нас клон террарии и есть несколько буферов-слоев. Задник, тайлы с водичкой, землей и прочим песком и тайл с монстрами поверх них (тот же червь-пидор что атакует под землей). Не суть. Если делать все по-еблански то на каждый чих надо будет все рисовать заново, что подозреваю, будет крайне медленно.
Вместо этого генерим в буфер на область в 2-3 экрана с каждой стороны один раз тайлы и потом лишь меняем (копнули землицу, убрали тайл, перерисовали лишь эту небольшую область (ну и слои за ней) вместо генерации всего экрана. Или это сложно реализуемо/нереализуемо вообще?
Я наверняка изобретаю велосипед, но ведь лубовь 2д и есть один большой велосипед, разве что можно где-то спиздить готовое решение.
Кстати по-поводу пиздинга - как потом можно сныкать свой ШЕДЕВР? на ум приходит лишь обсфускация наподобие минимизаторов для яваскриптов. Где все преобразуется в трудновоспринимаемую мешанину из односимвольных переменных и функций.
Проще перерисовать.
В мобилках попадалась луа у пары игор, зашифрованы хз чем, ключ скорее всего в бинарнике.
Premature optimization is the root of all evil.
>coroutine.yield
у меня от этого PHPшный ИТЕРАТОР.
а что, если нельзя вот так вот разбить на части? может там будет вызов какой-то одной функции которая будет выполняться 5-10с? И не вижу установку приоритета, ведь будет одинаково тормозить и бороться за цпу наряду с главным циклом, что приведет к "лагам".
Если у тебя основная задача будет полностью выжирать цпу, то может и будут проблемы. Но скорее всего всё будет ок.
No, love's threads are real operating system threads - concurrent, parallel, and preemptive (when the system is capable.) They aren't really like Lua's coroutines, which have other uses.
ох лол, так вот же что я искал. осталось понять как этот самый батчинг делать.
а по-поводу всей карты, интересно в Rimworld она вся в памяти? Или тоже подгружается по необходимости.
могу ошибаться, но в том же don't starve, там по-моему все реализованно именно тупым перебором сущностей с вычислением расстояния до игрока. Игрок всегда в центре, поэтому можно понять, попадает в кадр или нет.
Ну смари кароч. В тёрке вообще нужно только набор канвасов на каждый чанк. Один раз отрисовал канвас с тайлами, и дальше его дорисовываешь (заменил тайл с A на B, или удалил, это более чем реально). Ну и теням свой канвас. А эффекты партиклов и так работают. Мобам - да, берём батч и рисуем однотипных мобов в нём. Можно автоматизировать, мол, если данный моб заспавнен но для него нет спрайтбатча - создать для него батч. С love v0.11 будет проще, ибо там это будет полуавтоматизировано.
а загнать все в один батч, а потом копировать лишь то что видно низя? слишком большой расход памяти?
если чесна то нихуй не понил. чанк - группа тайлов из которой составляется текущий экран?
лучши ткни ссылкой где почитать терминологию с картинками если знаишь.
все же интересно как зделоли в римворлде, там размеры жестко ограничены и карта может выводиться полностью на экран. Неужели и там трахаются склеивая области вместо одной большой?
У одного батча лимит на ~35к спрайтов (или вообще столько сколько влезают в память видяхи, не знаю точно). Маловато будет для тёрки.
Терминология - моя собственная и майнкрафто-тёрочная.
Тут есть пара опечаток и "неочевидностей", но как-нибудь разберёшься.
спасибо, Аноний, реально помогло.
метатаблицы тут используешь для эмуляции наследования "классов"?
или оно же необходимо для определения методов тоже, иначе при создании нового объекта Chunk пришлось бы создавать все методы заново, я правильно понимаю?
асло не сейджи, бро, итс хартс май филлингз
ух ебать разумисты все это придумали.
Или похуй и все эти квады-хуяды занимают копейки памяти?
как я себе наивно представляю использование тайлов:
- грузим в память (видеопамять?) тайл, а то и атлас.
получаем некий дескриптор и потом используем его для вставки вместо загрузки каждый раз.
Все эти рогалики-хуялики используют не так много тайлов чтобы обосраться с памятью. Да бля, у меня в скуйриме наверно 4к труселя моей вагини с нормалью занимали больше чем все эти пиксельные обмылки.
Если еще юзать атласы и определять тайлы через них, так вообще должна быть дружбомагия с точки зрения перфоманса.
я просто не пойму это навязчивую идею везде юзать квады.
чем блять 2х2тайла так прям лучше чем один.
Метатаблица - да, чтобы дёргать методы Chunk'а не пересоздавая каждый раз кучу методов, ибо куча времени тратится/куча пространства жрётся. А чанков может быть МНОГО.
>>426157
Ничего не понял. Чанк, в "коде" - 128х128 тайлов.
Тайл - элемент атласа спрайтов. Без какого либо физона, просто отображение.
На каждый чанк выдаётся по батчу. Батч содержит полный атлас тайлов и двухмерный массив тайлов данного чанка (кстати, лучше бы его линеаризовать, типа, переделать из двухмерного в одномерный. Тогда вычисление элемента по координатам будет примерно такое: pos = (y - 1) * chunksize + x; chunk[pos] = N, и с полной картой сделать то же самое).
>>426158
>>426163
Чанки хранятся и уничтожаются, допустим, проверкой при переходе игрока из одного чанка в другой - сохраняем на хард разницу между сгенерированным и измененниями от игрока в чанке на хард, и удаляем из памяти. С другой стороны соответственно загрузили/сгенерировали. Это же просто!
Квад - это "трафарет", по которому из картинки вырезается прямоугольник. Ну тип у тебя атлас спрайтов (как на пике), и ты нарезаешь его на кучу мелких картинок, точнее - запихиваешь в спрайтбатч весь атлас, и при добавлении нового спрайта в батч - указываешь, каким трафаретом эту картинку обрезать (допустим, x/y/w/h: 64х64-128х64, вторая картинка). Это - стандартная тактика opengl.
Чанк - это наша абстракция определения на карте некоторой тайловой области.
Карта - совокупность чанков. Что не так?
Ещё дополню цитатой себя любимого:
Суть: когда у тебя много-много одинаковых спрайтов (или спрайтов, помещённых на одну картинку) - бесполезно рисовать их циклом, типа такого:
for i = 0, map.width - 1 do
for j = 0, map.height - 1
love.graphics.draw(image, imap.tilesize, j map.tilesize)
end
end
Это реально полный трындец: каждый раз когда вызывается love.graphics.draw, новая копия картинки отправляется видеокарте, вместе с параметрами, где и как её рисовать.
spritebatch - это такая хитрая штука, которая выглядит как "одна картинка + много мест где её рисовать".
function love.load()
— Мутим спрайтбатч, с картинкой игровой карты
tilemap = love.graphics.newSpriteBath(img, map.width map.height, 'static')
for i = 0, map.width - 1 do
for j = 0, map.height - 1 do
— добавляем в неё позиции спрайта игровой карты
tilemap:add([quad,] imap.tilesize, j * map.tilesize)
end
end
end
function love.draw()
— Передаём видеокарте одну картинку в spritebatch,
— и кучу мест, где её надо нарисовать
love.graphics.draw(tilemap)
end
Таким образом получается в 100500 раз быстрее.
Квадами можно вырезать из картинки с тайлами, типа той что приведена внизу, отдельные квадратики, и тоже добавлять в spritebatch. Квад = трафарет, по которому мы вырезаем из картинки прямоугольный кусочек, и добавляем в список того, как рисовать весь атлас.
>их циклом, типа такого:
>
>for i = 0, map.width - 1 do
> for j = 0, map.height - 1
> love.graphics.draw(image, imap.tilesize, j map.tilesize)
> end
>end
глупость сморожу, но что если в цикле их загонять в канвас, а уже потом один раз рисовать канвас.
love.graphics.setCanvas(canvas)
цикл
love.graphics.setCanvas()
в draw:
love.graphics.setColor(255, 255, 255, 255)
love.graphics.setBlendMode("alpha", "premultiplied")
love.graphics.draw(canvas)
или все равно сосну?
алсо ты сказал про опенжеэль, а как оно раньше работало (вроде с 0.9 стали требовать SDL с OpenGL)? Все загоняли в фреймбуфер?
просто эта gl пежня ужасно тормозит на некропека, в то время как веснот работает как ошпаренный даже на машинах с vesa вместо нормальных драйверов.
подумал попробовать откатиться на старые версии. Потому как примеры что я смотрел на фуреме любви практически все тормозили безбожно, впрочем там местные кириллы вообще не парились ни с фпс ни с какой-либо буферизаций, тупо драв и все.
ладно буду въезжать.
Но вообще странно зделоли.
Например в Don't starve позиция и размер тайла из атласа задается не в пикселях в относительных размерах.
Что позволяет не парится от размере текстуры атласа. (будет работать и для 256х256 и для 2048х2048. Т.е. можно переключаться между качественными текстурками или лоу для нищебродов.
Да, вместо батча можно использовать канвас.
Типа при загрузке чанка, мы создаём этому чанку канвас (12864 х 12864 = 8192x8192 пикселя, многовато будет, лучше несколько мелких канвасов чем один огромный, поэтому размерность чанкосетки уменьшишь).
При копании руды - перезатираешь этот квадратик чем-нибудь ещё: делаешь прозрачным при раскопке, рисуешь сверху другой тайл при строительстве и т.п. Но канвасы сложнее хендлить.
SDL - это куча кроссплатформенных либ, а ля opengl + openal + системные прерывания для клавомышигейпада и кучка оболочек (таймеры, события, всё говно). А love2d - оболочка над SDL, чтобы из lua можно было дёргать методы.
Большое количество кириллов с форума - не умеют в спрайтбатчи, полностью прогружают гигантские вещи и просто не умеют в оптимизацию. Лове может быть быстрым, но нужно уметь, это не юнька где за тебя всё уже оптимизировали "для сферической задачи".
За качеством текстурок - смотри mipmap, это есть в лове.
Ничто не мешает тебе брать относительные координаты. Допустим, вычисляем квад для атласа:
function getRelativeSizedQuad(img, x, y, w, h)
local px, py = img:getDimensions()
return love.graphics.newQuad(px x, py y, pw ( w, ph * h, px, py)
end
Кстати, не понимаю как это может упрощать текстурки, за исключением уровня мипмепа.
Хм, символы умножения просираются. Тут можно в code?
[code]
function getRelativeSizedQuad(img, x, y, w, h)
local px, py = img:getDimensions()
return love.graphics.newQuad(px ✶ x, py ✶ y, px ✶ w, py ✶ h, px, py)
end
q = getRelativeSizedQuad(image, 0, 0, 0.2, 0.3)
[/code]
>SDL - это куча кроссплатформенных либ
это понятно, вот например что требует wesnoth:
wesnoth-1.12.6_4,1:
pango-1.40.6
fontconfig-2.12.1,1
sdl_net-1.2.8_3
python27-2.7.13_6
sdl_ttf-2.0.11_7
sdl_image-1.2.12_10
png-1.6.29
sdl-1.2.15_10,2
glib-2.50.2_4,1
gettext-runtime-0.19.8.1_1
dbus-1.10.16_1
boost-libs-1.64.0
fribidi-0.19.7
sdl_mixer-1.2.12_12
libvorbis-1.3.5_1,3
при этом sdl можно собрать без поддержки opengl и все будет работать.
любовь же работает со вторым SDL и там в требованиях наличие поддержки opengl
love-0.10.2_2:
freetype2-2.8
libtheora-1.1.1_7
shared-mime-info-1.8
luajit-2.0.5
mesa-libs-17.1.5
libGLU-9.0.0_3
sdl2-2.0.5_2
physfs-2.0.3
desktop-file-utils-0.23
openal-soft-1.17.2_2
mpg123-1.25.4
libvorbis-1.3.5_1,3
libogg-1.3.2_2,4
libmodplug-0.8.9.0
что автоматом шлет нахуй vesa драйвер.
печально, непоиграть на 1u ксеонах :((
однако требование наличия opengl придумали лишь с определенной версии. Я даже одно время думал обойтись без любви и юзать luasdl напрямую. Но там все как-то все печально и умерло. И слишком много велосипедить чтобы выйти на уровень любви.
Такие pierogi. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
эм в том-то и дело что не надо ничего писать и вычислять.
тым было на уровне
image = asset('atlas.tex',0.12323,0.1234,0.02323,0.022323)
А дальше саму текстуру можно было уменьшить или вообще один раз задать другой путь для всех ассетов, где валялись уменьшенные текстуры.
Оче удобно. Не нужны никакие магические константы с размерами тайлов. Вообще.
Если мир - тайловый, то нужны, потому что от этого идёт перенос координат с мировых в тайловые, например. Ну, или плодить каждый тайл отдельной сущностью, с параметрами x/y/w/h, что совсем не круто, ибо жрётся бешеное пространство. Зато в тайловом мире так можно спавнить сущности (кусты/игровые объекты/выброшенные предметы и т.п.) Но их в идеале должно быть сравнительно немного. Если ты заметил, даже в террарии однотипное говно объединяется в стаки при вываливании на землю, ибо жрёт немеряно места. Ну, выбросил ты 9000 кирпичиков земли. Их все надо бы физически обсчитать, или заморозить их физон, разморозить если что-то их касающееся изменилось, например кирпич под ними сломали (для этого нужна мелкая пространственная сетка и эвенты), но если выбросишь слишком много - привет, резкие просадки fps!
Но рисовать их всё равно надо всей кучей, и ту же коллизию калькулировать.
Ты вообще заметил, что тайловые миры оказываются значительно быстрее/экономичнее по памяти миров, основанных на векторных объектах (особенно с физоном для каждого)?
Демка - вот эта? https://love2d.org/forums/viewtopic.php?t=82562
Это потому что каждая зверюшка - элемент батча. Просто этот товарищ умеет в спрайтбатчи, и даже суть демки - показать автоматический батч.
Эту штуку впихнут в следующую версию love2d, тогда можно будет рисовать циклом кучу говна, и оно будет полуоптимально рендерится. Это относится к картинкам и векторным примитивам (не к тексту, увы).
в террарии, что-то просрали в последних версиях, там есть ощутимый лаг в одних и техже местах карты (видимо как раз граница загруженных чанков-панков и делая шаг в сторону все это начинает подгружаться) реньше такого не было.
А проблему 9000 кирпичей они вроде решили куда проще - там вроде как есть лимит на количество отображаемых объектов. После которого новые тупо не отобразятся пока не подберешь старое. Ну и плюс они там не валяются вечно а со временем исчезают.
По-поводу отдельных тредов/потоков я спрашивал тоже с огдядкой на террарию. Например, там corruption/hollow постепенно расрастался по всей карте, независимо от положения игрока. Добавь сюда расчет перелива жидкостей и рост травки - ну ни как такое не обработать за один цикл update. Уверен что там это как-то просчитывается параллельно.
На тему corruption/hollow, смотри в чём прекол:
1. У нас есть некоторая функция, по которой генерируется/распространяется биом.
2. Каждый чанк имеет некоторое "время с начала мира".
3. Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти.
Это читерный способ. То же самое можно с растениями: запоминаем время посадки и выгружаем чанк. Когда чанк загружается снова - рассчитываем разницу во времени между предыдущим состоянием и текущим, добавляем рандома и вот, наше растение выросло пока нас не было. Аналогичным образом работают всякие куки-кликеры, в которых печеньки копятся даже при закрытом браузере (но в webstorage есть время выхода!)
Пардон, дополню ещё раз.
Перелив жидкостей - это вообще отдельная тема. Жидкости динамические по сути своей.
Считай что жидкость считает последний загруженный чанк твёрдой границей, и не льётся дальше. Сам проверь, попыткой слить океан в ад. Когда ты в аду, вода сверху перестаёт течь потому что чанк с бесконечной водой выгружен, а те которые активны в данный момент - уже слили воду.
И да, держать в памяти стоит чуть больше чанков: условно, если рендерим мы девять штук, то в памяти, чтобы не было лагов, держим штук двадцать-тридцать, на всяк случ. И можно предугадывать загрузку при движении: игрок падает вниз -> предполагаем что он будет падать ещё некоторое время -> загружаем сразу пачку чанков снизу, но рисовать продолжаем только те, которые влезают в камеру.
Кстати, для исследования террарии советую собрать нищеноутбук с очень медленным хардом. При падении с высоты, можно заметить насколько далеко прогружаются и рендерятся чанки: видно как из пустоты возникает почва, когда прогружается. С ранними билдами старбаунда - та же фигня.
да она, правда с дефолтным количество котов в 4000 некропека выдает 6фпс, но с "всего лишь" 1000ю уже 24. Для меня такое количество в любом случае оверкил, поэтому и впечатлило.
И это ещё не самый оптимальный способ применения батчей. Можно быстрее, правда, вокруг этого придётся мутить весь рендер.
а) батч, при добавлении спрайта, возвращает его ID. Это позволяет модифицировать то что мы рендерили без перезагрузки всех данных в видеокарту. Ну там, кадры менять, или двигать или и то и то.
б) Батчи имеют несколько режимов оптимизаций (static/dynamic/stream). Угадай, какой самый эффективный для тайловой карты.
в) Товарищ в своей либе, после каждого draw выдаёт batch:flush. Это сжирает приличное время.
>Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти.
В донтстарве так и делают, все, что за пределами текущего экрана и по 2-3 экрана с каждой стороны - спит. Потом когда подходишь к усыпленной сущности, то вызывается longupdate.
или там при загрузке тайла все преобразуется в какой-то свой распакованный формат и не занимаются херней?
в том же DS позволенно лишь использовать текстуру в определенном формате. Все эти пнг идут лесом.
Свой формат, раньше можно было грузить джипеги, а сейчас нет (хз почему, мб лицензии).
Для канвасов - отдельный набор форматов:
https://love2d.org/wiki/CanvasFormat
Это сделано для оптимизаций размеров/занимаемой памяти.
Есть тип данных ImageData:
https://love2d.org/wiki/ImageData
Его суть в том, что из этой фигни можно генерить картинки, а ещё, писать свои упаковщики/распаковщики произвольного формата в данный:
функцией mapPixel можно грузить картинки, например, из rgba8. На пике пример.
еще странно что он размер картинки кота зачем-то вычисляет внутри цикла
for y = 0, 3 do
for x = 0, 7 do
local w, h = catImage:getDimensions()
local q = love.graphics.newQuad(x w / 8, y h / 4, w / 8, h / 4, w, h)
table.insert(frames, q)
end
end
достаточно же лишь один раз определить и за пределами двух циклов.
но чувак реально рулит. Взял да и переопределил стандартный объект, а значит для кириллов достаточно лишь подключить файл.
Забавно, его почти никто не юзает....
Ну, это же вызывается один раз, а не каждый кадр, так что всё пучком.
прикрутил туда ограничение на fps - просто песня. 1000 звезд вращается и перемещается, 15фпс (на удивление сносно выглядит без дерганий, 25-30 конечно лучше) , меньше 40% загрузки некропроца(900мгц) и он вырубает активное охлаждение. В результате тишина.
10/10
Осталось лишь запилить шедевр и грести зимбабвийские баксы лопатой.
Ну вообще-то любовь годна не только для игрушек. Оче просто сделать визуализацию чего-то полезного. Например наглядную историю изменений в git/svn и тп. Яваскрипт бы обосрался от 1000 звезд даже на i7.
И все кросплатформенно, бесплатно и шустро.
v8 с webgl не обосрутся от тысячи звёзд на i7 если есть видеокарта :3
Но да, ловка примерно в пять-десять раз быстрее, хотя бы за счёт отсутствия бешеного количества прослоек жаваскрипт/браузер/opengl. С лове похожая ситуация (lua/c-core/opengl), но оптимизация на месте, плюс luajit откровенно не даёт оверхеда на переключение между контекстами, это охренительная прибавка.
вангую, что там будет еще нехилое различие по потребляемой памяти.
если еще учесть, что луа запустится даже на кофемолке с мегабайтом памяти (на самом деле вроде даже килобайтах), то хипстерское js-поделие уже в аутсайдерах.
так что любовь победит и тут.
Особенно если учитывать как в js на каждый чих создается объект и отсутствие integer в принципе.
итого дикий оверхед для простого массива.
У луа жи есть это ваше FFI, которое мне надо будет вкурить, но подозреваю что это чит, реализующий строгую типизацию и убирающий тот самый оверхед из-за нестрогой.
ffi = "пишем на луа на сишке", со всеми профитами, плюс подрубание произвольных сишных библиотек, с прописыванием хедера в cdef, с отсутствием оверхеда и прочей милотой.
Рекомендую.
Оу, кстати, у меня где-то валялась ffi-векторная либка. https://pastebin.com/i7qC1aKn
В качестве вектора используется сишная структура (x, y), к которой прицеплена метатаблица для перегрузки арифметики/методов. Мгновенно создаются и обсчитываются сотни и тысячи векторов, плюс сахарок.
Применение примерно такое.
Карочи, посоны, мне стало лень делать кучу всего, поэтому вот тут есть что-то похожее на движок. Как раз те самые танчики. Система сущностей, колбеки на столкновения и всё говно.
Заодно можно посмотреть как риальные поцоны делают проекты.
https://bitbucket.org/MainTomato/tank-o-box/src/67a4bc1def45708424f9facc09b8b04102c36433/?at=develop
На массив типа намбер 1000х1000 тратится 8000К
то есть по 8 байт на ячейку, еба. Значит ебашут флоат.
ну ебана, хотеть однобайтовый массив.
асло если пыриться в collectgarbage('count'), то каждую секунду проебывается по килобайту. Одно радует 'collect' мгновенно.
А вообще чому течет? уничтожение локальных переменных/функций внутри других функций выполняется отложенно? Я прост не понимаю откуда вообще взяться 'утечкам'.
Пошел пыриться в FFI. Ебал я в рот столько тратить на массив 1-2битовых значений.
local mapWidth = 1000
local mapHeight = 1000
local buffersize = 1 # (mapHeight + 1)
local buffer = nil
function setupMap()
memstart = GetMemoryUsage()
map = {}
for x=1,mapWidth do
map[x] = ffi.new("uint8_t[?]", buffersize)
for y=1,mapHeight do
map[x][y] = love.math.random(0,3)
end
end
memarray = GetMemoryUsage()
end
вместо 8М стало потребляться 2М. Но чому 2 а не 1? Это ж 1 байт.
можно было конечно еще сделать один большой одномерный массив и ебаться с вычислением индекса, но я пока положил хуй.
И вообще так можно пользовать? lua же будет пытаться впихнуть свой number, который хуй пойми какого типа.
Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
>И вообще так можно пользовать? lua же будет пытаться впихнуть свой number, который хуй пойми какого типа.
http://luajit.org/ext_ffi_semantics.html
Кстати да, я особо ничего не имею против сусеки, но давай аккуратнее.
все равно нихрена не понял
Conversions from Lua objects to C types
number → double
то есть при присвоении ffi-массиву оно будет использовать double значение, а С потом приведет к uint8?
что произойдет если lua-значение превысит допустимый диапозон, скажем будет 256?
еще как можно юзать битовые маски? ведь интежер не завезли.
если для тру интежер будет сгенерен кода наподобие
and EAX, 0xFF
то с вещественными хуй пойми как он там оперирует и насколько это будет тормозить для эмуляции целого.
или все битовые операции лучше проводить силами того же FFI используя сишные операторы?
как же бесит, ну вот кому пришла замечательная идея избавиться от integer.
тут пишут что в 5.3 добавили
https://stackoverflow.com/questions/4484437/lua-integer-type
Но love использует luajit, который в свою очередь - 5.1. SOOOOOQAAA
Ну тип ты можешь сделать так:
buf = ffi.new('unsigned char[?]', 4)
for i = 0, 3 do buf = math.random(255) end
И это будет Тру char'ы.
Что сложного?
Да, конечно, числа будут приведены к соответствующему сишному типу. Тогда если ты прибавишь единичку к 255 char'а, оно примет значение 1.
Ты давай не выёбывайся и не бомби, а изучай и ебош.
я в си совершенно не бум бум, но равзе int8 - не восьмибитное целое?
char, так char, прост думал это строго символы, а не байты.
а с битами как работать?
допустим есть флаги
fUnpassable = 0
fWater = 0b00000001
fGround = 0b00000010
fWall = 0b00000100
fCorrupted = 0b00001000
в массиве заданны атрибуты ячейки аля buf[x][y]=fWall | fCorrupted
нужно проверить соответвует ли значение маске
if buf[x][y] & mask == mask then sooqa(); end
в луа 5.1 гроб кладбище пидр, целых не завезли.
может как-то замутить через ffi и поиметь ВЫИГРЫШ в производительности, т.к. ничего не требуется преобразовывать?
> ты прибавишь единичку к 255 char'а, оно примет значение 1.
ващет должно обнулиться, но продолжу ебошить.
а если бы понадобилось однобайтовое со знаком, то що? char уже не катит.
Да, в нуль скатится, меня подглюкивает.
Луашные float'ы нормально преобразуются в сишные типы при загонянии соответствующего значения.
А если тебе нужен со знаком - тогда просто char же.
Ну ёпт.
В char можно запихивать луашные флоаты -128-127,
в unsigned можно пихать те же флоаты в диапазоне 0-255, и т.п.
Тот факт что в луа все числа флоатами - напротив довольно неплохо: вычисления стоит проводить с максимальной точностью, когда хранить - с пониженной. Знаешь что такое накапливающиеся ошибки?
P.S. В сях - все значения это числа. Просто char часто используют в качестве строк, но это всё равно числа 0-255. И с ними можно производить арифметику. Там нет строк в классическом смысле, но при строковой интерпретации, массив байтов НЕОЖИДАННО оказывается строчкой. Главное - не забывать про терминатор.
дык в том-то и дело, что точность - не конек float
одно дело 32bit int или 64bit int
и совсем другое дело когда часть этих 64бит уходит под мантиссу(внезапно и float и 64bit int юзают по восемь байт), а из-за преобразований в двоичный формат может все проебаться из-за дробей с бесконечным периодом.
поэтому у меня и нет восторга от отсутствия строго типизации, особенно там где она пиздец как нужна.
ну вот какой прок от этого вашего boolean, если на него по-прежнему потратиться 8 байт. 8 БАЙТ, КАРЛ.
В результате все эти изъебства с ffi. А главное непонятно нахуа оно нужно. В JS/Похапе это оправданно автоматическим преобразованием (приведением) к типу. Тут же один хуй тебе нужно tostring/tonumber. Так в чем была проблема ввести integer изначально? Чому лишь в 5.3 осилили.
У чувака проблемы с точностью и одновременно - проблемы с занимаемым пространством.
>>427312
Смотри и учись, ёпта.
Integer в lua 5.3 - 64-битные, занимает те же восемь байт. Так что можешь упороться.
boolean в луа - отдельный тип, он как раз (как ни странно) однобайтный, по моему, не знаю точно.
Ну а ты чо? Дали тебе ffi, рассказали что можно сделать нормальную оболочку над сишкой и дёргать её из луа.
Радовался бы, так нет, надо флудить и бомбить, как будто тебе десять лет.
сравни большие числа, там где мантисса присутсвует.
не сможешь, ты сможешь лишь проверить, что их разница меньше некоторой заданной константы (точность) аля 0.00000001
>Смотри и учись, ёпта.
мантиса не занимает оставшиеся 32 бита, там 10 бит под мантиссу + знак
итого у 64бит int - диапазон без потерь : -2^63 .. 2^63-1
у double - 1 бит на знак самого числа а значит
-2^52 .. 2^52-1
с количеством бит под мантису мог забыть, но суть ты понел. Проблемы начнуться с 2^53 или 2^54
нет у меня проблем с точностью, проблемы в [возможных] бесполезных преобразованиях и занимаемой памятью.
Вместо простого присваивания будет тратиться время на проверку диапазона и преобразование.
Плюс непонятки с битовыми операциями. И все непонятно ради чего.
чому нельзя было ввести строгую типизацию, если она явно указанна?
local variable = (int) {}
все, еба. И память не расходуется и битики можно гонять и все довольны.
вместо деления/умножения на степерь двойки - битовый сдвиг и тп.
>Integer в lua 5.3 - 64-битные, занимает те же восемь байт. Так что можешь упороться.
даже если так - похуй. можно легко вытащить требуемый байт двумя арифметическими сдвигами, которые потребляют 1 или пару тактов проца.
>boolean в луа - отдельный тип, он как раз (как ни странно) однобайтный, по моему, не знаю точно.
хуй там плавал. Создаешь табличку и загоняешь туда одни лишь true. Результат - те же 8 байт на ячейку. Спецом замерял этим вашим гарбадж коллектором.
когда массив занимает в 8 раз больше чем требуется, то это не бесполезный дроч, особенно когда предполагается большая размерность и массив далеко не один.
15000х5000 тайлов в ванильной луа - генерится пять минут и занимает 9гб, когда как ffi - мгновенен и жрёт 150мб памяти.
Ну и катись отсюда, для тебя придумали сишку, асм и машинные коды.
Обмазывайся там своими байтоёбствами.
Тот факт что скриптовая луа имеет такие фичи - уже повод молиться на майка пола.
А ты иди нах )))
Тебе три, блять, раза рассказали и даже показали как писать на сишке на луа, со всеми профитами сишных структур, переносимостью и скоростью исполнения. FFI ещё и включает в себя либу битовых операций, обмазывайся сколько влезет.
А в js/php инты - занимают столько же места сколько флоаты (64 бита), там аналогичная хуйня.
Так что или учись или съеби, мудила.
дык я и пытаюсь, знал бы ебучий С, не выябывавлся бы :)
js/php совершенно другая песня. первый вообще не создан был для больших объемов, второй живет доли секунды и итераторов/мемкешей/субд хватает.
Это то, что не надо "пытаться" сделать. Попытка подразумевает шанс провала.
Это нужно просто взять и сделать.
Взять книжку K&C, почитать, сделать мелкую хуёвину (типа крестиков-ноликов в консоли), понять как работают разные типы данных и всё тут, дальше можно продолжать.
И да, что непонятного в использовании ffi? Ты объявляешь переменную/массив так же как это было бы в луа или в сишке, и точно так же с ним работаешь.
Это не рокет-саенс, тут всё очень тупо даже для пхпшника который почитал про типы данных.
Чего расселся? Иди баловаться, бля.
> дык я и пытаюсь, знал бы ебучий С, не выябывавлся бы
Из данной фразы следует вывод, что незнание плодит выебоны.
А чего так упорото? Я тоже успел написать gol, но там были классические правила.
це древний нетбук, так что норм
>>427421
да гифка не отражает последовательность кадров.
мне просто надо было посмотреть как оно будет ворочаться под "нагрузкой", вроде нормич.
батчи-квады
если еще ту библиотечку подрубить, то пара фпс проебется somehow
теперь мой внутренний Кирилл говорит мне, что надо замутить очередь задач.
Тип есть несколько параметров, влияющих на производительность:
- собственно fps, тут все понятно. Лимитуем, появляется больше ресурсов для расчетиков в update()
- допустимое количество итераций update(), для генерации следующего состояния игры. Ну там мобье аналайзит свое окружение, агрится на вражин, расчет пасфиндинга и прочая пежня. На примере игры в жизть экспериментально получил от 5 до 15 тактов. Дальше уже как-то грустна.
- размер карты (массива), где это все обсчитывается. С игрой в жизть тут не читернешь с длинными апдейтами чанков за пределами камеры, нужно все обсчитывать.
Зойчем вообще это все нужна. Мой внутренний Кирилл глаголит - предположим что необходимо сгенерить новый эвент НОЧЬ ДЛИННЫХ НОЖЕЙ. А это значит надо подгрузить тайлы, музяку и еще какую пежню, которая может быть далеко не копеешной. Вместо того, чтобы загрузить все разом и пролагаться - предполагается все загрузить за X итераций, расчитать что необходимо и по готовности начать эвент.
Мой внутренний Кирилл - уебан?
Меньше швабодки но есть встроенный admob, не надо пересобирать двигло с прописыванием бриджа от lua до java.
И многое упрощено. Если в лове - ничего нет, то в короне есть куча всякой лабуды. Мне предлагали работу в короне: там есть проект портирования её на luajit.
1. https://github.com/SSYGEN/yaoui
2. https://love2d.org/wiki/Easy_GUI_System
3. https://love2d.org/wiki/Gsp%C3%B6t
4. https://love2d.org/wiki/SUIT
5. https://love2d.org/wiki/LUIGI
Достаточно?
Хоть одну сам использовал? Большинство по виду какие то васяноподелия, да ещё и попахивающие
Бери имгуй и не выебывайся. На оффициальном форуме целый трендж есть.
Хочешь оФФициальную? Пиши сам, продвигай чтобы использовали, собирай инфу на тему "что подправить чтобы было зашибись", поддерживай, обновляй до новых версий love2d и т.д.
Вот в этом и проблема LOVE как движка. Нихуя нет, кроме самой базы, всё работает на языке, в котором тоже нихуя нет кроме самой базы. Всё как в JS, только коммьюнити на порядки меньше, поэтому и либы все -
древнее говно.
Короче, не ебитесь с этим лавом, переезжайте на Godot, там грядёт эпик вин в виде 3.0 версии.
Я кончил.
Год ебался с LOVE-кун
Движок?
Опачки, а где тут хоть одно слово "engine"? Ни одного не видно. Ой, а что это за незнакомое слово "framework"? Опачки, а это и не движок!
В этом и прелесть LOVE как фреймворка: ничего нет, ничто не привязывает тебя к конкретной структуре/архитектуре, хуярь как хочешь, ошибайся, делай новое только лучше, потом становишься мастером дзен и уходишь в программисты с зп >100к. Так и сделал.
Ты просто мамкин неосилятор, который не умеет в архитектуру приложений сложнее чем helloworld. Простые вещи тут делать в три раза быстрее чем на годоте, а для чуть более сложных - нужно мутить движок. Движок - это как раз система связей между объектами, рендером, звучками и всем прочим.
> Ждва года ебался, понял что к чему, начал охуенно ебошить.
>вот картинку нарисовать на экране проще, чем в годоте!
>а вот для более сложных вещей нужно запилить свою плохую версию годота!
>ты просто не понимаешь всех преимуществ этого чудесного не движка
ты сам понимаешь, что ты несешь?
Тебя просто опустили а ты кукарекаешь.
Вот, старого педика почитай, что ли на досуге, дельные вещи графоманит:
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
>в программисты с зп >100к
а шо, есть вакансии с LUA-погромистами?
я не годотфанатик, но после этого высера
>Если домашние директории лежат на дисках, подмонтированных по NFS (одна абстракция)
читать не стал. Единсвенная причина так делать - бесдисковая станция, да и то там проще будет по rdp-like протоколу работать.
NFS жи - локалочка, DMZ между серверами, порою с резервированием каналов (X сетевушечек как одна для предотвращения проблем с илнками/портами/и тп)
Только полный даун будет использовать NFS прост для домашн директории ))). Так как работа с мелкими файлами там будет существенно медленней чем с неторопливым 5000rpm IDE
Уж лучше с FFI поебстись.
как местные гуру генерят карты с тайлами? Хранят в массивах (json/xml)? В картинках, где цвет пикселя определяет тайл. Или еще как?
асло пример как человек ебется с тайлами в годоте.
а шо, если я захочу бесконечную карту с генерящимеся/подгружающимеся на ходу тайлами? в луа тебя ограничивает лишь твоя фантазия и лень.
В годоте - похоже невозможно в принципе.
Алё, дядь, ноды в годоте можно и из кода инстансить. Вешаешь на карту какой-нибудь MapGenerator, которому прописываешь инстансить новые локации в зависимости от положения игрока. Старые не забываешь удалять, если не 100 гигов оперативы.
>>436402
https://love2d.org/wiki/Tiled
В 3.0 можешь ебаться в уютненьком Godot'е с любым ЯП. Гугли GDNative.
И поясни, где ты нашел такую хуйню
>который еще согасно докам умудряется работать >медленее с массивами одного типа
Искренне твой, годот пидор
http://docs.godotengine.org/en/stable/learning/scripting/gdscript/gdscript_basics.html
GDScript arrays are allocated linearly in memory for speed. Very large arrays (more than tens of thousands of elements) may however cause memory fragmentation. If this is a concern special types of arrays are available. These only accept a single data type. They avoid memory fragmentation and also use less memory but are atomic and tend to run slower than generic arrays. They are therefore only recommended to use for very large data sets:
ByteArray: An array of bytes (integers from 0 to 255).
IntArray: An array of integers.
FloatArray: An array of floats.
StringArray: An array of strings.
Vector2Array: An array of Vector2 objects.
Vector3Array: An array of Vector3 objects.
ColorArray: An array of Color objects.
тутачки. я даж не знаю как можно было умудриться сделать slower.
>Написано же - пользуй только для больших массивов, чтобы избежать фрагментации. Медленнее они из-за оверхеда на проверку типа и избежания этой самой фрагментации.
ох лол, там написанно про падение производительности для массивом со статической типизацией. Какую ты проверку типов должен делать для них? они ебанутые?
Далее там в примере сказанно про десятки-сотни тысяч элементов.
На секундочку это в пределах одного-двух сегментов 64к для однобайтового-двубайтового массива. С такими даже DOS справлялся.
На секунодочку, для копирования, заполнения подобных массивов данными есть даже специальные команды аля movsb или stosw, которые работают на порядки быстрее простого перебора и заполнения по одному элементу как было бы в случае обычных ассоциативных с динамической типизацией.
Бля, ну ты тупой. Если ты из динамического ГДСкрипта напихиваешь в статически типизированный массив, кто должен проверять, че ты туда напихиваешь?
и что значит динамический гдскрипт? это какой-то новый уровень фантазий? скрипт сам себя пишет или что?
там где-то говориться о твоих фантазиях по перемещению данных из динамически типизированного массива в статически типизированный?
там просто говориться о медленной работе, там где она наоборот должна быть быстрой.
Схуяль типизированный массив должен быть быстрее, если он решает задачу фрагментации памяти?
> задачу фрагментации памяти
забавно, не знал что такие задачи существуют, но ладно
еще раз. там в примере сказанно от тысячах элементов. А это копейки. У тебя обоссаная текстура/меш займет как 5-10 таких массивов и никто не умрет.
Табличка override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака".
>>438065
>override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака"
а нахуя это надо?
Ну ты смотри. Игровая пауза продолжает рендерить игровое состояние, но запрещает ему получать нажатия на кнопки/обновляться.
Упёрся в скорость отрисовки, и только тут в треде вычитал какие там ещё возможности есть с хранением текстурок newSpriteBath в видеопамяти и быстрой отрисовкой, надо будет добраться и переделать, да и FFI тоже может пригодиться.
>Упёрся в скорость отрисовки
хуясе, а что с ней случилось? рисует же SDL2, если не ошибаюсь
обычо такая хуита начинается, когда в отрисовку логику пихают, или наоборот, лал
Переделаю как руки дойдут на SpriteBatch ну и там в принципе можно убрать принудительное стирание старой картинки каждый кадр на уровне фреймворка, тогда даже мой исходный вариант будет шустрее, не говоря уже про раздельную прорисовку кусков карты.
но для прототипов love очень даже хорош, как для чего-то более законченного - пока не знаю :)
Рисует - opengl, конечно.
Скорость отрисовки в данном плане - скорость заливки данных в видеокарту, ибо куча говна дублируется.
Какие подводные?
Ну issue если что создать всегда можно. Не велика проблема. Меня больше инетересует что анон думает за сам love2d
Сам по себе Love2D пиздат, но специфичен в целом.
Алсо, если это адаптация лова для раста, то возможно еще не все фичи реализованы, и выход новой версии будет задерживаться, хотя это менее критично.
Ну если чувствуешь в себе силы, то можешь какие-нибудь простые демки запиливать.
https://anotepad.com/notes/ti57jh
А если у меня будет несколько кнопок\объектов на экране, мне что каждый проверять на границы по очереди? Или есть какой-то неизъебский способ?
Суешь в массив. При маусмув/мауспрессд пробегаешься по всем.
А не удобнее будет заставить объекты следить за мышью, и реагировать, если она рядом?
Можешь натянуть на экран сетку пространственной индексации, заполнять её кнопками которые попадают в ячейки сетки, делить координаты мыши на шаг сетки в пикселях и пробегать только по кнопкам, которые касаются ячейки в которой есть мышь.
Это - быстрее всего для обработки, но чуть медленнее в загрузке.
Я копаюсь под капотом у love2djam2018 и скачал например gift. Разархивировал love файл, а там main.lua, который моим сублимом открывается чисто как hex.
Но екзешником love2d съедается как миленький.
Может кто-нибудь предположить что это за метод сокрытия информации?
Decode в другую кодировку не помог.
File signature 1b4c 4a01 02 нигде не нахожу.
>байткод
И шо, лове2д может с ним напрямую сработать? После интерпретации?
Луа-код можно компилить в байткод, это нормально.
И любая луа-машина (в т.ч. love2d) будет с ней работать.
Правда, у разных версий lua разный байткод, поэтому версии 5.1 и 5.3, например, несовместимы.
В love2d используется luajit, и байткод соответствующий.
Народ вкатился в LOVE2D.
Посмотрел небольшую кучу примеров и игр, добрался до
Zerobrain Studio.
Что еще нужно для комфортного гейм дева и есть ли хорошие книги по LUA ? love2D ?
https://www.lua.org/pil/contents.html
https://love2d.org/wiki/Main_Page
Документашки просто топ, закачаешься.
Также чекай всякие либы для лов2д на той же вики или на форумах/гитхабах, много чего полезного можно найти.
Зачем тебе книги по Луа? Там язык в полчаса изучения, достаточно одной табл урока на утубе, если не трогать метатаблицы и все с ними.
Почему создатели Love2d переписывали функции каждую подверсию???
зачем drawq превращатьв draw
screen в window
love.mousepressed( x, y, button ) в
где button ='l' или 'r'
а в 0.10.2
уже
love.mousepressed( x, y, button, istouch )
button = 1 или 2
!!!!
Еще раз, я же.
Я новичок в Love2d.
То что игру реально написать это круто! Скачал кучу примеров, исходников.
Но вот то что автор программы наплодил версии не сильно совместимые между собой это МИНУС!
пусть сделает love 12 запускающий любой код от love 0.1.1 до love 11.2 .
И кстати никто не знает почему он в 11 версии ушел в установке цвета от 255, 255,255 к 1,1,1 (0.444, 0.111, 0,888)? В чем смысл?
>пусть сделает love 12 запускающий любой код от love 0.1.1 до love 11.2 .
Ты, похоже, новичок во всем? Ты еще Торвальдсу скажи сделой мне МакВиндовс, штобы все летало. Просто это нагло. Разработчики (если не ошибаюсь, л2д разрабатывает тоже не один человек) сознательно избавляются от глючно работающего кода, кода, вызывающего конфликты и прочее. Делать универсалку для развивающегося любительского движка, это значит нагружать исполняющий файл. Если какой-нибудь Автодеск может себе позволить (да и им это в кассу, ибо этим они отличаются от всяких конкурентов) и поддерживать одновременно дохуялиард версий.
Еще раз, почитай про обозначения версий. В большинстве систем версификации софта считается, что 11.1.2 и 11.1.1 имеют между собой общего 99 процентов кода и естественно они будут почти соместимы, а версия лоадера скажем 12.1 и программы 9.1.2 могут иметь (и имеют право иметь) кардинальные различия, вплоть до полностью переписанного с нуля кода. Совместимость двух дохуялиарда версий стоит дохуялиард денег, времени и кода. Ты готов оплатить их труд? Нет?
>И кстати никто не знает почему он в 11 версии ушел в установке цвета от 255, 255,255
Подозреваю, решил упростить математическое преобразование в гамме для платформы в целом. Чтобы работа пользовательских шейдеров была быстрее.
>сознательно избавляются от глючно работающего кода
Глючно работающий код?
Да ты теоретик!
Там просто функция window внезапно меняется на screen
drawq - сделали в следующей версии ее уже нет, но вы можете просто убрать букву q и все заработает!
Нахрена???
Сокращение кода, оптимизация бла бла бла.
Сделайте так что внутри черной коробки drawq была равна draw, раз ввели в предыдущих версиях.
> что 11.1.2 и 11.1.1 имеют между собой общего 99 процентов кода и естественно они будут почти соместимы, а версия лоадера скажем 12.1 и программы 9.1.2 могут иметь
еще раз ты теоретик!
Почему тогда он с 0.10.2 версии скакнул до 11.0 ?
Это вообще охуенные изменения?
>Почему тогда он с 0.10.2 версии скакнул до 11.0 ?
вот тут хуй знает, я за л2д не слежу, если честно. Просто луашник и мимокрокодил.
Между draw и drawq чуть больше изменений, чем просто буква.
Нахера тащить легаси код, если так захотел какой-то васян? Проект можно допилить и на старой версии, если сильно надо, просто через какие-то костыли будет.
Синтаксис уточняется, унифицируется, становится более красивым, а старое и некрасивое нет смысла тащить.
Если сильно приспичит, можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
>можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
Да именно это я и сделал, а тысячи новичков забили на это и пошли пилить свои игры в другие платформы.
Почему рубится сук на котором сидят?
Из за изменения с цветом не совместимы игры написанные <0.10 и >11.0
Этож сплошное отпугивание новичков, я взял прример и у меня ничего не работает.
Когда-то все равно придется исправлять ошибки прошлого. Сначала посчитали, что удобно будет 0..255 использовать, и это в принципе привычно. Но потом, видимо, стали чаще использовать фичи опенгла и шейдеров, а там удобнее 0,0..1,0. Относительно недавно еще какие-то фичи для более легкого 3д подвезли.
То что туторы на официальном сайте не апдейтят, это плохо, хотя документация там топовая. Да и уроки посвежее и более полные есть от юзеров, на хабре или еще где-то можно найти.
Речь про 3D в love2d
https://www.youtube.com/watch?v=x8k3vaPRXd4
Сейчас появилось желание сделать вернее идиотская привычка проводить новогодние вечера делая никому ненужную херню для себя небольшую игру, с физикой: А именно лабиринт по которому нужно будет катать шарик. То есть шарик должен отскакивать от стенок, катиться по инерции, расталкивать препятствия и прочие Но ещё на стадии прикидки в голове и чтения мануалов я понял одну вещь: У меня будет довольно большой и сложный лабиринт, и все его части должны быть физическими препятствиями. Логично сделать каждый "тайл" отдельным прямоугольным физическим объектом - но очевидно что их будет дохуя. И собственно вопрос - как можно сделать в box2d объект сложным по структуре но при этом считающим одним объектом при расчётах?
Сотню статических боксов он должен легко сожрать, тем более что динамический будет только один объект.
То что ты объединишь множество боксов в один полигон выигрыша не даст. Сложный объект сложнее проверять на столкновение.
Будут еще динамические препядствия но не много. Даже если сотню сожрёт без проблем, я сам перфекционист и не люблю пустой траты ресурсов. Пока придумал что на этапе генерации лабиринта собирать соседние "клетки" в более большие прямоугольники и создавать физические обьекты только для них уже. Но сделать алгоритм нормальным не получаеться.
Сам фресворк поддерживает оптимизацию отрисовки того что не попадает в текущий кадр. Или при прорисовки объекта нужно сначала самому проверять его фактическую видимость?
Потому что в обновке много изменений и сильная несовместимость с предыдущей версией. Первая цифра означает мажорный релиз, вторая - багфиксы.
10.0 => 11.0 => 11.1 => 11.2.
Оно не сразу скакало, очевидно были промежуточные.
Есть polyamory (https://github.com/megagrump/polyamory)
Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
Сам запилишь.
По мне, эффективной методикой является использование чего-то вроде регулярной сетки, в которой располагаются объектики.
На гифке, например, я использовал библиотеку hardon collider для коллизии, и оттуда же - регулярную сетку. Из неё вырезается некоторая область (список объектов по AABB), и рендерится. Соответственно, объектов может быть сколько угодно, не попавшие в экран мы даже не проверяем.
Если у тебя ну прям до жопы одинаковых объектов, то уже эффективнее пихать в батчи и рисовать сразу всё через батч (например, вытаскивать объекты из большой области и пихать в батч). Развлекалова много, в общем.
> polyamory ланчер для love2d
Ахаха, кое-кто знает толк в игре слов.
>Есть polyamory (https://github.com/megagrump/polyamory)
>Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
Есть, не боюсь.
Но вот вопрос, если сторонние умельцы делают ланчер для запуска всего множества версий, то это востребовано?
Так почему бы создателям, не сделать единый экзешник для всего подмножества версий 0.0.1 - 0.10.2 и так уж и быть если прям нереально еще один 11.0-15.0. (а лучше love2d.exe вообще для всех)? Версию сами просили в conf.lua записывать, какие команды на что меняли тоже знают.
Ты предлагаешь им запаковать все версии love в одну? Ты бы ещё предложил запихнуть все версии какого-нибудь дистра линукса в один дистр, или все-все версии питона в один питон.
За время развития love2d, менялись версии динамических библиотек (хотя бы версии SDL), ты плохо понимаешь цену того что хочешь.
Гы?
Че там запоковывать то?
Там всего то надо принимать команды в двух - трех форматах, запоковать внутренние приравнивания что screen = windows если что, drawq = draw и так далее. +1000-30000 байт смотря сколько раз они команды меняли безосновательно.
Игнорируйте его, такие люди должны стучаться в службу поддержки Микрософт с просьбой портировать легаси-код из win 3.1.
>button = 1 или 2
было хуево, стало пиздато. С интежерами поди по-проще будет, чем бесполезные где button ='l' или 'r'
кстати а mousewheel нажатие там обрабатывается?
и вообще чего доебался. Найди хоть один более-менее популярный продукт, где бы не менялся API.
>>490081
этот самый байт код можно "дизассемблировать" до удобочитаемого и понятного lua, т.е. реально использовать для соркытия СУПИРСИКРЕТНАГО кода игры?
Вообще что юзают перед тем как выкладывать в тот же стим, какие-нибудь обфускация кода с добавлением кучи воды и бесполезных функция с переменными, чтобы запутать? Или всем просто похуй?
я смотрел, популярные офусцируют.
А вот на ресурсе где дайте 2$ или просто скачайте, и где переодическит и с кодом выкладывают, не обфусцируют.
я попробовал свой тестовый гейм оф лайф запустить на мобилочке, результат как бы немного разочировал, все эти банчи-хуянчи оно обрабатывало медленее чем на древнем сабноуте.
Но, если все в пределах экрана, то 60 фпс на изичах.
Правда чому-то офицальной любви 11.2 даже нет в планах, 11.1 приходится ставить руками без маркета. Чувстую придется свою собирать и ебаться с манифестами и плейсторе.
Может кто уже пытался?
>приходится ставить руками без маркета
так это не только в ондроеде
>60 фпс на изичах
сейм шит, бро
>фпс
шебм отклеилсо
Где список успешных игр на love2d?
через месяц опубликуют
https://itch.io/jam/7drl-challenge-2019
зойчем ты мне показал скрин с кудахтера, писечка именно в сборке под ондроед. А make install я и на фришечке осилил.
>>551469
в стиме как минимум пара релизнутых, но там все совсем простые.
я же хотеть делать рпгешечки/хиросы под ондроед без донатов и банеов. Бесплатная демка и платная фулл за бакс.
Алсо обратил внимание как в плейсторе донатопораша пытается пролезть в топ. Делают донатопорашу и ставят ей минимальную цену, потом делают скидку в 100% и вуаля - ты в топах премиум игр по скидке.
>зойчем
ну вот тоже руками ПОД СЕБЯ, а не из бинарного пакета, это же лёвы тред. а под ондроед .apk небось проще сбилдить даже из линупса и фришки, тока сдк/ндк доставить
ну опять же имеет смысл только при распространении линупс/макос версии. Для шинды достаточно прикрепить лов файл в конец стандартного екзешника.
А вот с дроедом чувствую та еще ебля.
https://love2d.org/wiki/Game_Distribution#Android
вот с нуля арк из под макоси и линупса билдят же вроде
а через АРК тулс как раз и есть ебля с манифестами
https://love2d.org/wiki/Game_Distribution/APKTool
к этому можно еще запилить мультик на вебсокетах вебморду логин/пасс + база юзеров, их ачивок, статистика онлаен и т.п. типа свой стим, лал
>Publishing as a HTML5 or JavaScript game is possible
ну и дев с битбакета вещает про легаси сборку, пакадж и деплой с адмобом, версия 0.10.x
https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/Home
читай внимательно
FIXME: This method is obsolete and shouldn't be used! New guide is needed if you plan distributing your game to Play Store. Google announces that all apps in Play Store must be compatible with API level 26, which can't be satisfied because LOVE APK limitation at the moment.
> версия 0.10.x
не хотеть
>адмоб
ну кириллу будет мягко говоря трудно конкурировать с остальными донато и баннеропарашами. Наоборот, поделок без баннеров и доната можно по пальцам пересчитать, этим и надо брать, имхо. Например, ровно ОДНУ вменяемую рпгешечку - Exiled kingdoms. А ведь если ПОДУМОТЬ, то там нет ничего особенного. Прередеренный псевдо 3д, довольно простые квесты и локации. ЛЕВИЛДИЗИГН уровня кирилла. Разве что стори неплохая и текст самих квестов.
>читай
я не читал пока, увидел легаси и решил посмотреть позже, все равно при ~200kbps эти сдк/ндк тянуть неохота
и свежих доков нет вроде, внизу там висит линк на типа апдейт, но я и его не читал
а вот рпгешки помню прикольные на j2me под нокию были, причем брендовые, мож даже от близзардов. там нужно было в локациях выполнять квесты, гулять по глобалу и пиздить нпц. экономику вот только вроде не завозили туда. а жаль. единственно именно экономическим был клон серии Anno или Port Royale, но тоже поверхностно и тема была не раскрыта и вообще не рпг, а тайкун кокойто
откуда ты друг с такой скоростью?
качай лучше небольшие игрухи запускай их и правь код.
из тайги капчую. ну почти: паблик вайфай хотспот с плавающим сигналом, который иногда вообще теряется.
игрухи то да, код смотреть не запрещают же, ну или не все, но вот захочется например шейдоры задрочить, а в новой версии двигла у них например синтаксис сломан. я штото переписывал шейдорное с 8 на 9ку вроде, так после этого ни с кем неделю не разговаривал. причем и в документации никуя об этом не было
Никаких лишних коллизий, объекты ровно без реакции пролезают в дырки, размером ровно с эти объекты, очень круто. Ну, и все объекты являются "пулями", при попытке перемещения, быстродвижущиеся снаряды не пролетают.
Думаю, куда бы перекатиться с геймейкера. Устал в первую очередь от его ебучего языка gml, в котором нельзя даже создать свою структуру данных. Ну и в целом хочется выйти на более ненубский уровень, чтобы движок не определял за меня архитектуру игры. Так вот, как говорят в годот треде, почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец?
love2d - это, если быть точным, обертка над sdl+opengl.
sdl и прочие - это низкоуровневые графические библиотеки, единственной высокоуровневой фичей которых является абстракция платформо-OS-зависимых API.
инструменты и сущности высокого порядка тебе придется велосипедить самому.
Если ты не демосценер/любитель подрочить байты ради собственного удовлетворения или просто хочешь научится в низкоуровневое дрочерство/не программист крупной игровой студии, а хочешь просто делать игори - то выбираемое тобой направление сомнительно - ты 90% всего времени потратишь на велосипединг кривых велосипедов и их отладку. Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун. И только после этого ты сможешь заниматься непосредственно игрой, в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи и ты раз за разом будешь срываться с написания геймплейной логики в написание фич двигуна, а твоему мозгу будет все сложнее и сложнее держать всё это в голове одновременно и работать в таком ритме.
В крупных студиях такой проблемы нет - у них есть четкое понимание зачем им велосипеды, какой профит (более лучший графоний c инновационными техниками и номинации за графон на ежегодной VGA, инструменты для разработчиков в рамках заданной концепции игры, успешная борбьба с собственной соснульной платформой) они с них получат, четкий план как и чего они пилят, большая команда разработчиков, разделение разработки по командам, допилка фич в соответствии с планом и.т.д.
Тебе же придется всё это делать в жало.
> почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец?
У всех свои особенности. love2d - он на lua, и в этом его прикол. sdl - на чистом си, а sfml - на c++, и он объекто-ориентирован. Allegro, ClanLib, HGE и подобные - на с++, и как я понимаю, и них более богатый функционал, т.е. больше полезных фич для геймдева из коробки можно найти.
Какой язык ближе - такой и выбирай. Дополнительный функционал, на самом деле, не обязательно самому писать, можно найти другие сторонние библиотеки, их куча в опенсорсе.
>>554621
>Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун.
По моему скромному опыту могу несколько вещей добавить.
Во-первых, какие-то сложные вещи можно найти в инете. Если тайловая игра, можно присобачить Tiled. Хотя для не-тайловых хз, есть ли подобное.
Во-вторых, не обязательно вообще сложно писать. Можно максимально упрощать, делать только необходимое - это ключ к успеху. Только при надобности - делать более абстрактно, расширяя функционал и рефакторя код.
В-третьих, первый проект да, можно дохуя всего с нуля написать. Но если будешь более-менее аккуратно писать, то наберется парочка полезных собственных либ, которые можно потом переиспользовать.
Это все очень интересно и дает много опыта. Но с практической точки зрения - я хз как на это будут смотреть потенциальные работодатели, которые 90% используют юнити под мобилки. Адекватные наверное оценят опыт, но хорошее знание нужного им инструмента это не заменит полностью.
>инструменты и сущности высокого порядка тебе придется велосипедить самому.
Ты так говоришь как что-то плохое.
В любом случае придется тратить время либо на велосипеды, либо на изучение юнити-хуюнити. Но вот с последним ты можешь упереться в непреодолимую стену ограничений. А так тебе полная свобода сделать свое говно. Я так это вижу.
Ну и упоминание крупных студий тут совсем не к месту. Любовь как бы занимает совершенно другую нишу. Это для одиночек или пары человек, которые могут в кодинг, но не хотят мышевозить в юнитях и гейммейкерах.
>в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи
В моем случае пердак уже давно подготовлен, я не питаю иллюзий и просто сделаю максимально просто.
Тут есть другой момент, в отличие от юнитей, мне не надо изучать инструмент, тот же реадктор что ты упомянул, по-сути можно сразу ваять свой ААА ШИДЕВР. А самое главное есть отличные примеры на чем можно поучиться, а то и откровенно спиздить - Don't starve, ToME4 и тп.
Кстати, читая исходнки DS я ПОНИЛ как именно там реализуется анимация, со всеми этими стейтграфами, как реализован AI, как вообще все правильно ЗДЕЛОТЬ. С префабами и поэтэссами.
Вот это манямир.
Юнити больше 10 лет в разработке.
Конечно же, это только плюс, что нужно все самому делать, ведь у тебя есть 10+ лет чтобы сделать движок
>Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей
Проблема то в том, что со временем понимаешь, что стандартные фичи гамака не очень нужны (а их кстати не так уж и много). Физику сам рассчитываю, столкновения сам считаю, поиск пути свой писать приходится, даже спрайты для некоторых нужд приходится в ручном режиме анимировать, а не в стандартном автоматическом, редактор уровней неудобный. В итоге от гамака нужна только возможность рисовать спрайты на экране. А вот при попытке что-то навелосипедить натыкаешься на внутренние ограничения движка.
Чтобы сделать игру, не нужно 10 лет тратить на движок.
За пол года, если без сильных выебонов, можно сделать норм игрушку практически с нуля.
Люди за сутки или за неделю без юнитей пилят годные прототипы игр на джемах. Остальное время уходит на допиливание, контент и прочее.
>Какой язык ближе - такой и выбирай.
Мне никакой из этих языков не ближе. Важнее, чтобы движок не был заброшен и стабильно работал. Я так понимаю sdl тут лидирует.
Простой вопрос - чому Klei такие идиоты и не зделоли все на юнити?
Асло, юнити для меня - синоним тормозов, быстрой растраты батарейки на мобиле. А вот внезапно нечто на самописном движке работает бодрячком (рпгшечка).
Все, которые на слуху, так или иначе разрабатываются и достаточно стабильно работают. Попробуй посмотреть туториалы по каждому, как запиливается какая-нибудь простая игра, глянь код, выбери более приемлемый для тебя вариант по синтаксису/апи.
А ты что, klei?
Время разработки складывается из времени написания движка, времени создания редакторов и время создания контента.
Ты можешь, например, взять кривой tiled, и времени на создание в нем контента ты убьешь в разы больше, чем если ты будешь делать тайловые карты в юнити.
Тебе будет нехватать возможностей tiled, и ты будешь писать костыли, и еще больше затягивать разработку.
>Klei
>2013 неголодайка на крестах и луа
>2014 Invisible на чужом фреймворке с крестами и луа
>2018 HOT Lava на UE4 с крестами. В процессе движок апгрейдится до Юнити
>2017 Oxygen Not Included на юнити. Без крестов и луа.
Пргресс, ёптаблядь.
Заметь, что кроме DS - все шлак и вроде как без модов.
А именно на них держится его популярность.
Как там с модами под юнити, бтв?
Алсо DS и DST - это своего рода TES у беседки или ФИФА у ЕА, которую доить можно еще долго. DLC выпускают каждые два года и их всегда раскупают. У меня большие сомнения, что юнити поделия обладают такой же кустомабельностью. Под DS вон даже DnD запилили. Там вообще по-сути конструктор, ваяй что хочешь.
Хуй знает, объективно оксиген лучшее, что было у клей.
>НЕДАВНИЕ ОБЗОРЫ: Очень положительные (359)
>ВСЕ ОБЗОРЫ: Очень положительные (15,946)
>Там вообще по-сути конструктор, ваяй что хочешь.
https://forums.kleientertainment.com/forums/topic/88186-mods05-oni-modloader/
Кек. У оксигена модкит есть и глобальные моды.
>DLC выпускают каждые два года
На оксиген раз в месяц выходит обнова, которая расширяет геймплей, добавляет новые фичи и ресурсы.
ну ок, сравнимо
хотя еще далеко
> It allows to load mods contained in independent dll files
лол
превед конпеляция и лишь под венду
спасибо,я этого овна уже под римворлд поел
>хотя еще далеко
Так неголодайка и вышла пораньше. Ну и покупается лучше, всё-таки 40 рублей это не 250.
>превед конпеляция и лишь под венду
Ну во-первых, платформа-то одна. На линупсах в эти ваши игры не играют. А во-вторых, игровой код в открытом виде, ilSpy в руки и погнал пилить под себя. Да и нахуя Клей давать тебе модкит уровня беседковского такой же глючный, но дающий дофига контроля если они сами по себе пилят "моды" ради подъёма продаж. Но мы уже уходим в строну, что хотел я уже сказал.
>love2d - это, если быть точным, обертка над sdl+opengl.
Объясни подробнее, разве sdl в свою очередь не обертка над opengl и directx, чтобы самому в эти апи не лезть? Зачем love2d в opengl лезет?
Шейдеры, например, в любом случае пишутся на glsl. Плюс кусочек оптимизаций вывода графена. SDL - не всеобъемлющая обёртка над графикой, хотя там и много всего полустандартного.
Просвети, чем именно крив Tiled и чего в нём тебе не хватает?
а насколько там важные отличия?
порта на ведроид скорее всего не будет в ближайшем будущем вот и думал чтоб все на одной 11.1 базе делать свои ААА прожекты.
Юнити потребует бабло за комерч. исп. На юнити особо не повелосипедишь, юзай что дают и не выебывайся. А на луа я могу хоть по сети передать все - от текстурки до полного префаба очередного монстрика со своими стайтграфами, мозгами и прочим.
В общем не мешай тут кирилить, пили очередной раннер, платформир и прочее тормозное говно для мобил.
>ыыы юнитя для шкальникав, ыыыы, пили платформиры, пока я тут гташку заебашу на говне, ыыы
Ну удачи тебе
Тредик не про говноюнити. Иди метйся говном с уе4 и годотами. Там тебе рады.
А тут суровые дивилопиры. Это все равно как сидиезник сунулся бы к ассемблеровщикам.
Да вы только на словах львы толстые, а на деле хуи велосипедные. Пока очередной костыль пилите весь ваш настрой улетучивается. На ваших говнодвижках вообще игр нету, балаболки пиздливые.
>вообще игр нету
как минимум две в стиме, с положительным рейнтингом.
так что ИЗВИНИСЬ.
ДА и вообще можно подумОть тут хоть один успешный дивилопир на этом твоем лагунити.
а на 11.1 есть? мне основные введения 11 части надо, 10 не подходит
Билд для тестов (льём сурц игры в ~/sdcard/lovegame)
https://bitbucket.org/rude/love/downloads/love-11.1-android.apk
Как билдить полноценные приложения - есть инструкции же, и там есть 11.1 и по моему даже 11.2.
а сами пробовали эти инструкции, все нормально работало, если делать по ним?
Имеет ли смысл писать все велосипеды и прочее на C/SDL или сразу переходить на LOVE? Сильно ли последний сжирает лишних ресурсов? Единственная ссылка по теме ведёт на давно закрытый форум
>Сильно ли последний сжирает лишних ресурсов?
сильно. на love2d сейчас смысла писать нет. нет поддержки платформ
Если собираешься пилить 2д, то хватит за глаза. Да и 3д есть возможность сделать, и скорее всего успешно, если пилить по уму.
Луа на самом деле не такой уж жирный (не зря ж его во встраиваемых системаю юзают и как скриптовый язык часто). А какие-то критичные части можно перевести на плюсы (FFI).
С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними.
Короче лёв скорее для энтузиастов. Если нравится луа+лёв и есть желание повозиться, то не вижу проблем.
Пара списков игр на лёве:
https://store.steampowered.com/curator/32659238-L%C3%96VE-Games/
https://itch.io/games/platform-android/tag-love2d
>Луа на самом деле не такой уж жирный
проблема луа в отсутствии низкоуровневых типов данных.
любой мало-мальски сложный алгоритм будет нещадно тормозить из-за таблиц.
>С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними.
Любительские поделки, которые не обновлялись годами. Я бы на это серьезно не рассчитывал при создании игры, так как будет не очень приятно в конце разработки обнаружить какую-нибудь ошибку при использовании порта
Таблицы в целом довольно оптимизированы, даже если будут дырки в массиве. Для числовой индексации там обычный массив используется, для доступа по ключу - хэш-таблица, там особо нечему тормозить если совсем жирно не растрачиваться на использование памяти. Есть некоторые фишки, которые стоит учитывать для оптимального кода
https://www.lua.org/gems/sample.pdf
http://lua-users.org/wiki/OptimisationCodingTips
Можно подрубить FFI и на Сях запилить какую тебе угодно plain old data структуру.
>>599832
Тут да, гарантий никаких. Если хочешь беззаботно покорять мир своей поделкой на всех возможных устройствах, то скорее надо смотреть в сторону чего-то более весомого.
С/С++ и SDL2 - это уже почти стандарт в гейдеве, та что все равно пригодиться
использовать ли Love - это уже зависит от проекта: 2d игры на компы и андроиды, несложные графические навороты.. если похоже на требуемое, то можно брать
сам lua мало тормозить работоспособность проекта, все же самый быстрый скриптовый язык, поэтому его и используют в большинстве игр в том или ином виде
Вот только используют его для простого скриптинга поведения объектов, а не для программирования геймплея.
Не совсем. К геймплею относятся общие компоненты и алгоритмы. Контроллер персонажа, инвентарь, логика скиллов, заклинаний, поиск пути и т.д.
А скрипты это скорее конкретные сценарии поведения для разных объектов. Активировать дверь при нажатии кнопнки с определенным ID, показать диалог с конкретными NPC. Задать NPC какое-то поведения для определенного квеста. Такие мелкие поведения очень удобно писать в скриптах, и очень неудобно писать в нормально геймплейном C++ коде.
То есть скрипт это как правило небольшой, одноразовый кусок кода, который используется только в одном месте игры и больше не используется нигде.
Поэтому так легко писать такой код на высокоуровневых скриптах: просто когда тебе нужно новое поведение, то создаешь новый скрипт и все.
В С++ либо хардкодить это все нужно, либо пытаться параметризировать все в какой-то общий для всех объектов компонент.
Инвентарь, поиск пути и прочее - это не геймплей, а скорее движковые фичи. Их да, имеет смысл на языке самого движка делать. Все остальное - нормально реализуется в скриптах.
Проблема скриптов на с++ не в том, что неудобно писать, а в том, что надо перекомпилировать код при любых изменениях, и это довольно затяжное дело в больших проектах.
>что надо перекомпилировать код при любых изменениях
Сразу видно человека, никогда не писавшего на плюсах. Перекомпилируется только отдельный измененный объектный файл, т.е. если у тебя 100 cpp файлов и ты меняешь один, компилируется только один измененный, и это проходит быстро.
Вот если ты меняешь заголовок, который подключен в 100 файлах, тогда будет печаль, но на практике такое редко бывает, т.к. один заголовочник в 100 файлах это признак говнокода.
Это очевидно. Но плюсы все равно не так быстро компилятся, зависит же еще от самого кода в файле.
Я к тому, что подхватить на лету скриптовый файлик проще, особенно если это нужно делать не программеру.
И для того и для того, не только как конфигурационные файлы, но и более крупные куски геймплея: minetest, dst.. тысячи их.
>>601430
Ну приблизительно так, только игра не всегда проектируется как монолитный проект, поэтому в скрипты еще уходит та логика, которая может быть модифицирована игроками и мододелами.
>>601590
Нет, так поступают по другим причинам. Данные выкидывают в скрипты в проектам, потому что часто ядром геймплейной логики, которая пишется на плюсах, занимается одни кодеры, а сам контент с его тонким поведением описывают другие кодеры или вообще те, кто далековат от программирования.
ондроед есть (нестандартная репа)
шинда есть
линупс с фрибсд есть
про гейос только неуверен, да и хуй с ней. С ней даже стим не особо заморачивается.
шо еще надо?
Потом как-то забросил это дело, а некоторое время назад занялся играми и написал несколько на с++ и sfml.
Здорово, конечно, но всё это делалось довольно не быстро.
Недавно попробовал луа снова (не для игр), оказалось очень здорово и быстро.
Так вот, с чего начать разбираться в love2d?
Скорость разработки с лёвом - неоднозначный вопрос. Хотя сейчас все больше библиотек появляется, в чем-то становится попроще.
Начинай с вики, она очень годная. Там же и список известных либ можно найти. Какие-то вещи можно на форуме найти.
Если сам кумекаешь нормально, то этого хватит. А так, на хабре и на ютубчике еще можно найти серию уроков на русском
С вики, плюс на ютубе можешь найти приличное количество туториалов. Не советую замахиваться на что-то сложное, начни с крестиков-ноликов, змеек и понгов.
> оказалось очень здорово и быстро.
и вечно
В каком смысле быстро? В плане чего? Скорости работы, скорости написания программ?
К концу декабря запилю свой ШИДЕВР. Всем пиздеЦ!
Ну а если серьезно, то очевидно жи что можно кодить прямо в активном игоре, правя и дописывая на лету. Без конпеляций и смс.
Кто какие библиотеки использует в проектах и почему? Или может чем-то не зашли и писали свое намного лучше?
Animation: anim8, Walt ...
Localization: utf8, i18n ...
ECS: concord, knife, nata, tiny-ecs ...
Один проект полностью на своем, в т.ч. ECS , физон и небольшая GUI либа, потому что ебанутый. На самом деле очень тяжело каждую систему самостоятельно пилить.
Другой проект решил заюзать готовые решения, для GUI - SUIT, ибо заебался. От того же автора собираюсь для твининга hump.timer использовать.
SUIT своеобразный довольно, и достаточно лоу-левельный, приходится все равно свои надстройки придумывать. Но среди всего это, наверное, самый простой варик, чтобы сел и поехал. Есть imgui и nuklear, но их еще компилить надо.
Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д.
https://github.com/love2d-community/awesome-love2d
По поводу ECS есть такой бенчмарк от создателя одного из них (Concord):
https://github.com/Tjakka5/love-ecs-benchmarks
только в нем наиболее используемого tiny-ecs нет, думаю запилить, как время будет
Да, с gui сложно определяться. Особенно когда мультиплатформу надо и пытаешься сдружить какой-нибудь imgui под андроид.
>Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д.
>https://github.com/love2d-community/awesome-love2d
Эту подборку как раз недавно потыкал почти всю. И оказалось, что ей новичков только пугать. Там почти все либо устаревшее либо гораздо хуже альтернатив, которые там даже не представлены. Надо тоже какую-то такую подборку сделать, только в каждом пункте по несколько вариантов с пояснениями для этих самых новичков, что вот берите это если надо это или берите то - если то.
Тот списочек вроде как даже обновляется. Только видимо устаревшие линки никто не хочет убирать.
Что сам юзаешь? Что пилишь?
Как сейчас с компиляцией под андроид? Сильно надо надрываться, чтобы адекватно работало?
Нет, под андроид сейчас довольно удобно, все есть даже для последней актуальной версии ловки.
Юзаю обычно из несамописного только i18n и imgui. Но тоже хочется каких-то уже готовых стандартных библиотек, принятых и поддержиаемых сообществом. Для игр так вообще вроде есть ряд основных задач, которые хорошо было бы прямо в сам движок уже изначально встроить, те же состояния. А то пишут все зоопарк кода, потом выкладывают просто так, потом новички лезут и путаются.
Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
Лёв изначально как биндинг над SDL задумывался, так что вряд ли в него будут игроспецифичные вещи добавлять.
Так-то вообще можно конструктор на ловке запилить. И уже были какие-то попытки, например Grid https://love2d.org/forums/viewtopic.php?f=5&t=80115
Вообще есть мысли под ECS намутить какой-то просмотрщик-редактор, чтобы можно было сущности проектировать, смотреть какие компоненты с данными есть, автоматически генерить системы с нужной оболочкой и просто писать в них поведение.
>Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
Круто.
Я свои поделки все никак не доведу до нормального состояния. Хотелось бы в стим как-нибудь релизнуться. Но на горизонте событий этого пока не предвидится.
вот есть компонент, например, позиция в пространстве (условно мечника)
сущность - это уже созданный экземпляр (один из 10 мечников в игре) или это как некий класс этот мечник, а экземпляры называются другим словом?
Вроде везде создают что-то типа World, куда пихают сущности уже как экземпляры.
В ЕЦС сущность - это то, под чем объединяется набор компонентов. Набор компонентов не фиксированный, поэтому условный мечник может стать условным лучником, если удалить/добавить какие-то компоненты.
С одной стороны сущность - это абстракция в ЕЦС подходе, типа в игре есть игровые сущности, они все разные, но механизм один и тот же (т.е. что-то типа класса, но на самом деле его нет явно).
С другой стороны сущность - это уже айдишник в каком-то конкретном менеджере ЕЦС, к которому как раз привязываются компоненты, и тут оно ближе к экземпляру.
Ну т.е. сущность - это все же уже созданный экземпляр некого "объекта"?
Ну вот в игре допустим в каком-то файлике хранится "name = волк, hp = 100", а в другом "name = злой волк, hp = 150"
Под это дело есть компоненты.
Конкретный экземпляр волка из первого файлика - это и будет Сущность по ECS? Т.е. уже конкретный волк где-то в мире с конкретными жизнями, который был заспавнен со 100 hp.
А как вот то, что в файле называется в ECS, из чего создаются этим сущности?
Не встречал где-либо разделение на общий класс сущности и ее экзепляр в игре, поэтому скорее всего тоже сущностью можно называть.
Бля я еблан, сорян
Кину ссылкой
https://2ch.hk/pr/res/1620402.html
Нет, в ECS "сущность" это просто айдишник, обычно integer.
Вот картинка по типу этого
Хотелось бы сделать такую графику в своём love2d проекте, и желательно так что бы при зуме не пропадало качество.
Было бы ещё лучше если бы картинка такого формата была бы просто набором координат как obj форматы, но забейте про это, я потом может что то своё такое напишу. Сейчас просто прошу помочь найти программу которая может подобное
Тебе нужен векторный редактор. Вообще вроде от адоби лучший, но я очень люблю аниме студию, она проще и быстрее гораздо делать, но функций меньше, что-то суперсложное не сделаешь. Но такую бошку запросто.
Уровень функционала, который я хочу от этого: не более шести игроков, пошаг, геймплей неторопливый, но динамичный, на уровне карточных игор.
Просто люблю Луа, посему выбор у меня невелик - лёва, всякие короны там и крафтстудио.
table.sort сортирует только если значение число а не таблица, по сути это bubble sort
Мне подойдёт даже пример с сортировкой 2д спрайтов по координатам (есть ведь алгоритмы где рисуют слева направо сверху вниз)
Погуглил за тебя
Можно кастомный компаратор написать
local t = {"file001_abc_10.txt", "file001_abc_2.txt", "file001_bcd_4.txt", "file001_bcd_12.txt"}
function compare(a, b)
----local function padnum(n, rest) return ("%03d"..rest):format(tonumber(n)) end
----return tostring(a):gsub("(%d+)(%.)",padnum) < tostring(b):gsub("(%d+)(%.)",padnum)
end
table.sort(t, compare)
print(unpack(t))
Или вообще свою сортировку какую хочешь, хотя в луа квиксорт используется.
Мас. Рэндом, лол
А що будет если звезды сойдутся и будет два одинаковых номера?
Асло библиотеку классов давным-давно навасянили и без этого велосипеда.
В общем спасибо тебе что погуглил, всё равно полезная хрень, но я нашёл объяснение создание функции для table.sort
Век живи век учись, блять
В общем я попробую отсортировать грани по тому что я нашёл, для этого я скорее всего опять буду 3 дня дрочить код
вроде указано, что в app/src/assets, создал, кидаю туда и все равно запускает дефолтное окошечко с шариком
Тут проблема для z-буфера, причём она глубже чем кажется: для такого программного рендеринга, нужно из треугольника выпиливать видимую часть (многоугольник, не пересекающийся с другими полигонами более переднего плана), и рендерить уже его.
Прикреплённая картинка - это rarjpeg с Настоящим Хардварным 3d на ловке, переименуй в .love и чекни.
Уточнение: тут же простейший пример хардварной трёхмерной графики через шейдер:
1. Два канваса: рендертаржет + Z-буфер
2. Слегка модифицированные меши, с координатами точек по Z-оси,
3. Кастомный шейдер, который принимает матрицы view (камера) и model (матрица модельки)
Если будут вопросы по распаковке - из rarjpeg'а достаточно отпилить часть с картинкой (см пик), и можно открывать как zip-архив с исходным кодом.
зойчем?
Ого, спасибо за развёрнутый ответ, я попытаюсь что то из этого понять
Мне по фану, да и мне это действительно помогает, чем глубже копаю тем больше понимаю
А в чем там проблема-то, немного переписать рендер под 3D. А так ловка это же тонкая прослойка над SDL2, так что вообще ограничений особо никаких.
Дополню: плюс в 11 версии добавили кучу трёхмерных фишек опенгла, вроде того же z-буфера нормального, и возможности нормально кастомить меши в произвольные массивы данных на видеокарте: запилить модель + цвета вершин + кости + шейдеры по отношению к конкретным костям - как нехуй делать.
Мой 3д проект который я хочу сделать тупо стоит на месте как раз из-за того что я не умею в глубину, сортирую полигоны по расстоянию, но это затратно.
Вроде как уже и больше понимать стал, пытаюсь просто нарисовать 2 меша треугольника так что бы было видно что буфер глубины работает, но сколько я видосов не смотрел я всё равно нихуя не понимаю + тут як понял именно на шейдере всё можно сделать, как в OpenGL ( смотрел в видосах ), но повторюсь что я нихуя не пойму.
Может я и сам когда нибудь всё выясню но хотелось бы ускорить этот прогресс, т.к. сейчас зависаю в месте без интернета и от скуки делаю всякую парашу в ловке (на андроиде, гыг)
СПАСИТЕ МЕНЯ и простите за всю хуйню которую я ща написал, два дня не спал мозг не работает
Самое главное забыл - хотелось бы избежать использование сторонних/чужих библиотек, ибо хочу именно всё сам делать научится, так сказать склад велосипедов пополнить
Глядите, чо нашел. Это ведь почти лёв2д, но с функционалом среды разработки и всяких плюшек! Плюс обещают много чего искаропки.
https://store.steampowered.com/app/1386180/Bitty_Engine/
Меня смущает цена. Позволить-то себе могу, хуле. Сэкономлю на завтраках бензине разобью свинью-копилку. Вопрос 1) взлетить ли и не забьет ли разраб 2) буду ли пилить игоры, а то ляжет ненужным грузом, как RPGmaker на аккаунте. Но это скорее вопросы для самокопания. Я сюда не спрашивать пришел, а поныть сообщить, что в кои-то веки кто-то делает ДВИЖОК с луашечкой.
А хардверное 3д не хочешь? Шейдерчиком, с автоматическим збуфером?
Купил это чудо. Пока мне действительно нравится. Нечто среднее между love2d и юнети.
Триде вроде не завезли, но мне оно особо не надо пока.
В отличие от юнети ничего лишнего и lua искаропки.
> Луа-куны, нытик-кун вернулся.
Оставил тебе (и всем луа-кунам) пост в срачетреде: >>717286 →
>Оставил тебе (и всем луа-кунам) пост в срачетреде
юнетикам пора уяснить, что луа-куны принципиально в писькомерстве не участвуют, ибо взрослые и обеспеченные люди, не нуждающиеся в самоутверждении
Ибо кому кроме нас еще в голову придет постоянно колесо изобретать
При запуске даже просто love.exe (да, качаю 32-битную) получаю ошибку пикрил. Аналогично на 10 версии. 9 работает, т.к. она еще была без ентих ваших джиэлей.
В системных требованиях ловки gl 2.1+, на этом ноуте gl 3.0
Куда еще потыкаться?
Ну в целом как бы драйверы, но возможно, придётся накатать какой-нибудь шейдер а ля
local shader = love.graphics.newShader[[
#pragma language glsl1
#ifdef VERTEX
vec4 position( mat4 transform_projection, vec4 vertex_position )
{
return transform_projection vertex_position;
}
#endif
#ifdef PIXEL
vec4 effect( vec4 color, Image tex, vec2 texture_coords, vec2 screen_coords )
{
vec4 texcolor = Texel(tex, texture_coords);
return texcolor color;
}
]]
love.graphics.setShader(shader)
И типа всё, дальше этим шейдером всё рисовать.
шейдер не помог, собственно он валится уже на этапе, даже если просто движок запустить без проекта. Драйверы максимально возможные тут уже стоят. Ну видимо старше 9 ловки на этом некроноуте не побалуешься.
Да при запуске без проекта, оно такое запускает проект "по умолчанию" с настройками по умолчанию же, который как раз рисует тебе экран no-game.
Но опять таки похоже на дрова.
МИНИМАЛЬНЫЕ:
ОС: Windows 7/8/10 (32/64bit) (плюс есть под мак и лин)
Процессор: 1.5GHz
Оперативная память: 512 MB ОЗУ
Видеокарта: Intel HD
Место на диске: 150 MB
Только не говори, что у тебя на нетбуке не взлетит
Уже сделал, но у меня всё сводится к тому что я хреначу код до тех пор пока у меня не выйдет что то похожее на то что я хочу, а мне ещё парсер obj файлов писать, и много другого. Я бы хотел просто именно понять как это работает, что бы мне было с первого взгляда ясно что и куда пихать, а не что бы потом вспоминать что я сделал в прошлый раз что бы повторить, вместо того что мне нужно сделать в этот раз. Никаких чужих библиотек и строк кода я в своём коде не использую, разве что смотрю на них что бы понять как они работают, а всё своё пишу сам, ибо лучшее понимание приходит когда ты не только знаешь как это сделать, но и знаешь как это работает.
БТВ рад что тред ожил
Есть старый асус еее 900 с встроенной интел, под 32бит freebsd, love2d работает, но нужно указать
LOVE_GRAPHICS_USE_GL2 = 1
в переменных окружения и все работает.
Для 64бит hd4800 под ту же фрюшечку все работает и без переменных.
Разве матрица допустим
Представим у меня есть вектор 1 1 1 (1)
ну или посложнее, полигон
0 0 0
1 0 0
0 1 0
Треугольник получается
И матрица
X = 1
Y = 1
Z = 1
1 0 0 1 = (X1)+(Y0)(Z0)+(W1) = 2
0 1 0 0 = (X0)+(Y1)(Z0)+(W0) = 1
0 0 1 0 = (X0)+(Y0)(Z1)+(W0) = 1
0 0 0 1 = (X0)+(Y0)(Z0)+(W1) = 1
(получается из точки 1 1 1 мы получили 2 1 1) (смещение по иксу)
но при использовании mat4 vec4 у меня выходит какая то ересь, все точки по оси X будто бы смещаются ближе к центру
Вообще я в шейдерах не сильно шарю, но мне сейчас хотя бы матрицы нужно научится применять
Вот допустим для разрешения 1920 1080 что бы левый верхний угол был началом координат для XY я должен использовать матрицу
1/1920 0 0 -1
0 1/1080 0 -1
0 0 1 0 (можно и 0 0 0 0, наверное)
0 0 0 1
Если я хочу нарисовать кубик от левого угла экрана то с матрицей
1 0 0 1
0 1 0 1
0 0 1 0
0 0 0 1
то у меня просто пустой экран, все вершины непонятно куда пропали
Я ничего не понимаю, может ли мне это кто обьяснить?
Я просто хочу сделать 3д графику, потихоньку узнаю что-то новое, но в чём проблема этой матрицы?
Для начала я хочу попробовать
Model to World
World to View
View to Projection
И вот ещё несколько вопросов. Меш хранит в себе координаты вершин, а крутит и перемещает эти вершины уже шейдер. Но что если я захочу рисовать один и тот же меш в разных вариантах? Что мне нужно будет сделать? (естественнно я говорю о love2d)
у меня допустим есть меш кролика, и я хочу нарисовать три кролика в разных координатах, мне придётся создавать таблицу с координатами, и делать три разных меш-объекта? Или я могу перед отрисовкой меша передавать шейдеру матрицу перемещения?
Допустим
krolik = newMesh(bla bla)
setshader(3d)
for k, v in pairs(таблица с крооликами) do
3d:send("modetoworld", v["МАТРИЦА ОБЪЕКТА С ИНФОРМАЦИЕЙ О ЕГО КООРДИНАТАХ, РАЗМЕРЕ, ВРАЩЕНИЯХ'])
draw(krolik)
end
естественно с буфером глубины (его я не так давно научился делать) и прочей хуетой
Ну я слишком туп. Но всё же очень сильно хочу научится делать 3д собственноручно. Пока что на Lua, OpenGL для меня сложноват
Итоговые вопросы:
1. Как мне рисовать несколько объектов из одной модельки (меша) но с разными координатами, вращением и размером (все это же матрица, не?)
2. Что не так у меня с матрицей?
Вопросы просто по фану
1. Могу ли я сделать тасселяцию?
2. Могу ли я для каждой вершины делать какое нибудь смещение? (представь куб только что каждая его вершина смещена на рандомное значение от -1 о 1 * (1/20))
3. Могу ли я изменять координаты uv развёртки во время отрисовки меша? Допустим что бы сделать кадровую анимацию текстуры. Представь что uv.x у каждой вершины меняется на +1 каждую секунду. хз. говорю же не шарю
Teach me sensei
Пожалуйста если используете трудные слова, или хорошо шарите в шейдерах, то распишите это всё так будто бы для ребёнка, а то у меня iq как у хлебушка
Я даун как шизоид всё расписал, извините. Спешил и мысли путаются
Прочитай хотя бы теоретически https://learnopengl.com/
Или найди на хабре перевод
В голове хоть структура какая-то появится
Прочитал. Но именно о том о чём я написал там ни слова.
Скачал библиотеку cpml, создал матрицу, переместил через функцию mat4.transate допустим на вектор (1 1 1 )
И опять изменились элементы таблицы 13 14 и 15
В итоге вершина x = x / (x + y + z + 1), y = (x + y + z + 1) z = z (x + y + z + 1)
помогает функция mat4.to_vec4s_cols
тогда матрица действительно переходит в матрицу смещения
НО Я ВСЁ РАВНО НЕ ПОЙМУ ПОЧЕМУ ОНИ ИМЕННО ТАК СОЗДАЮТСЯ
пикрил - то что у меня получилось сделать
Наверное мне было бы уже проще на C++ и OpenGL пересесть, но нет. Я хочу добить себя на love2D
Зачем насиловать 2Д фреймворк 3д потугами?
Есть же годоты с юнитями для этого.
чем то мне полюбился Lua, но мысль попробовать godot была, вот только боюсь к языку опять привыкать да синтаксис учить
В целом, для полноценного 3d неплохо заходит Defold.
Но и ловка неплохо заходит. А зачем делать translate через умножения вершин? Есть же вершинный шейдер.
Если анимировать - да, оно понадобится. За примерами анимаций советую посмотреть демку love3d и IQM-формат, можно передрать оттуда.
__index не предлагать.
Да, норм тема. Есть свои плюсы и минусы
http://lua-users.org/wiki/ObjectOrientationTutorial
Есть варианты запила ООП через специальные промежуточные классы, в чем-то мб удобнее
http://lua-users.org/wiki/SimpleLuaClasses
https://github.com/kikito/middleclass
И вот как бы такой вот вопрос, если я хочу сделать себе такой же симулятор, но у меня получается так что обновление схемы происходит каждый игровой тик, как мне сделать так что бы схема полностью обновлялась за один игровой тик?
Просто если я сделаю цепь из 5 ворот то активировав первое она полностью активируется через 4 тика. Есть пара примеров. Garrys Mod с модом Wiremod (там есть logic gates)
Scrap mechanic
Digital Logic Sim от какого то ютубера
NandGame
В последних двух задержки либо нет либо она очень низкая, хотя вот в NandGame игра тебе говорит если ты замкнул схему, так что мне кажется что в DigitalLogicSim задержка есть но очень маленькая. Так же, если вдруг делать такую же симуляцию как в NandGame то как мне сделать проверку замыкания? Что бы не было бесконечного цикла
Быстро фикс
Сорян, в Garrys Mod с Wiremod на логических вентилях я тоже не заметил задержки, а она на Lua, вот и хочу узнать как я могу сделать свой симулятор без задержки
Юзай алгоритмы на графах.
Просто берешь и обходишь граф сети, включаешь то, что должно быть включено. Остальное отключено.
При обходе помечаешь пройденные вершины, если наткнулся на уже пройденную - значит у тебя цикл.
Обойти граф из пары десятков элементов ничего не стоит практически.
Плюсы:
- При изменении класса, все "объекты" под ним не меняются;
- Чуть-чуть быстрее доступ (при редком дёргании методов);
- Как бы можно делать "приватные поля".
Минусы:
- На каждый объект оверхед не только в виде таблички с данными, но и функциями, которые надо сгенерировать, поддерживать а потом выкинуть со смертью объекта;
- При пакетной обработке кучи идентичных объектов не включается JIT, скорость исполнения падает в тысячи раз (касается только PC и android);
- Невозможность организовать нормальных изменяемых общих полей всех объектов;
- Лишняя визуальная вложенность кода.
Чем плох __index? Ты его не понимаешь? Чем плохи либы-генераторы классов?
Удваиваю этого >>745392.
Запоминаешь положение генераторов сигнала (какие-нибудь условные кнопки-рычаги), это твои начальные точки графов. Поиском в ширину проходишь по всем затронутым элементам, переключая их состояние в зависимости от сигналов, запоминая уже пройденные вершины как защита от циклов.
У элементов с несколькими входами, желательно обновлять их состояние за тик в зависимости от количества входов, максимум столько раз, сколько у них входов.
Да, в том же миникруфте не просто так сделана система перегорания элементов при слишком активном переключении.
Кто из них пиздит? Или lua не освобождает фактически, освобождённую память?
Хуй знает, может у тебя какие-то еще текстурки куда-то были загружены, может файл какой-то был открыт, может ты си код вызывал и там что-нибудь не очистил. Луа наверное только свое считает, переменные, таблицы, функции и все такое.
>ОС говорит, что процесс LOVE всё ещё использует ~400MB памяти
Как именно она тебе это говорит? Может, это не реально используемая память, а просто зарезервированная под процесс? Я тоже со своими программами (на паскале) подобное наблюдаю: сначала раздуваются, а потом плюс-минус сохраняют состояние, лишь со временем медленно теряя объём (но сборщик мусора в паскале срабатывает мгновенно, дело не в нём, а в ОС).
Если любишь экспериментировать, попробуй создать и запустить отдельную программу, которая займёт собой максимум оперативной памяти. Только файл подкачки отключи. В какой-то момент винда начнёт сжимать в памяти всё что только можно сжать, и закрывать все лишние процессы, включая даже explorer.exe (рабочий стол может исчезнуть, просто открой explorer из командной строки). Вот в такой ситуации, по идее, у твоей игры должны отобрать все резервные ресурсы. Если игра "сжалась" в памяти - то всё в порядке. Если так и осталось висеть 400 МБ ни за что - то у тебя явно какая-то утечка.
Также попробуй повторно создать всё то, что у тебя заняло 400 МБ. Если утечки нет, то будет плюс-минус столько же, если утечка - будет около 800 МБ.
Если всё-таки утечка, нужно смотреть где выделяется память в куче (любые динамические структуры данных) и каждый раз принудительно её освобождать. Нельзя просто "выкинуть переменные", нужно сказать ОС, что тебе эта область памяти больше не нужна. Сборщик мусора должен делать это сам, но кто его знает как он устроен.
ОС портит тебе лафу.
Когда ты запрашиваешь память, ОС выделяет тебе под приложение кучу свободного места. Заберёт обратно когда-нибудь потом, когда потребуется и если потребуется.
После долгого разбора выяснилось, что память выделяется (вот эти 400 лишних мб) во время обращения вызова примерно такого кода:
for x = 1, w do
for y = 1, h do
f(x + (y - 1) * w)
end
end
Причем как показали эксперименты, чем больше w и h тем больше выделяется памяти, хотя функция f может быть любой, даже пустой. Чем больше её вызовов тем больше памяти потребляется.
Как будто этого было мало, сейчас оказалось, что если сначала вызывать этот же кусок кода с значениями w и h равными 64, а потом с 1024 то никакой лишней памяти не вызывается. А вот если сразу 1024 то будет дополнительные 500мб, причем если функция f вообще пустая.
Я даже уже не знаю куда смотреть теперь.
ОС может выделять память в зависимости от скорости её потребления. Например, ты разом запросил пол гига - и она выделяет лишний гиг, потому что ты сразу схомячил здоровый кусок. Или ты запрашиваешь те же пол гига маленькими кусочками растянуто, тогда лишний гиг не будет выделяться, или выделится но сильно меньше.
Мой персональный совет: не еби себе мозги всей этой чушью. Пока память не начала бесконтрольно расти не высвобождаясь - тебе похер на всё что там происходит. ОС тебя переиграет и уничтожит все попытки заткнуть фонтан выделяемой памяти, пока она есть, и это нормально и даже хорошо: память должна использоваться. Освобождать незанятое начнёт только когда памяти начнёт не хватать.
Может уже поздно, но попробуй почитать это: https://love2d.org/wiki/MatrixLayout
Использует, лавка норм. Взаимопомощь проще получить в соцсетях/телеге.
Лованы, как успехи?
Скоро уже скоро запилю свой ААА прожект на базе этого.
Основная цель - ондроед, там где луаджит нормально не пашет в лове.
Я буду успешен!
Сайт love2d не показатель, у них вся активность в дискорд ушла сейчас
А в чем сейчас профит использовать движки на скритпоязыках типа love2d или pygame, когда есть javascript? Работает в вебе, везде поддерживается, быстрый (среди скриптовых), оптимизированный.
В глобальном плане — никакого, большей частью дело привычки/удобства.
у тебя видимо айсикью однозначное и ты не смог найти разницу в закрепленных темах и новых?
а шо, хтмл5 ужо смогло не тормозить и не грузить гпу на 100% на сценках уровня первой кваки?
А че с того что он не новый? Я лишь отметил что в последнее время часто встречаю источники по этой теме с угасшей активностью. Иди умойся, "айсикью"шный.
local M = {}
function M:foo(bar)
self.bar = bar
end
и
function M.foo(bar)
M.bar = bar
end
И насколько вообще второй вариант корректен? Просто разницы в рабоет не обнаружил, но для чего тогда городят эти ":" или передачу self первым аргументом?
> The colon syntax is used to emulate methods, adding an implicit extra parameter self to the function. Thus, the statement
> function t.a.b.c:f (params) body end
> is syntactic sugar for
> t.a.b.c.f = function (self, params) body end
>но для чего тогда городят эти ":" или передачу self первым аргументом?
Как написано выше, чтобы эмулировать методы. Отличия методов от просто функций в том, что они зачастую работают с объектом, которому принадлежат.
Пример из JavaScript:
const myCounter = { count: 0, increase() { this.count += 1 } }
myCounter.increase() // myCounter.count равен 1
myCounter.increase() // myCounter.count равен 2
Обрати внимание на "this" для обращения к вызывающему объекту изнутри метода. В функциях JavaScript он есть "из коробки" и называется контекстом вызова. В Lua такого нет.
Аналогичный пример на Lua:
local myCounter = { count = 0, increase = function(self) self.count = self.count + 1 end }
myCounter.increase(myCounter) -- myCounter.count равен 1
myCounter.increase(myCounter) -- myCounter.count равен 2
Так вот чтобы не писать так длинно, придумали сахарок в виде вызова через двоеточие.
myCounter:increase() -- тут мы передаём первым аргументом в функцию increase таблицу myCounter
Ты мне ответил про разницу M.foo(self) и M:foo().
А я спрашивал про использование M вместо self. Тоесть обращение к самой переменной внутри ее "метода"
Через точку получается статик метод, обращение к M - обращение к классу, обращение к self - обращение к экземпляру класса, всё как в обычных языках.
```
local M = {}
function M:good_foo(value) self.good_inner = value end
function M.bad_foo(value) M.bad_inner = value end
local N ={}
N.good_foo = M.good_foo
N.bad_foo = M.bad_foo
N:good_foo(10)
N.bad_foo(10)
print(N.good_inner, N.bad_inner)
```