Домены arhivach.top и arhivach.site временно не функционируют! Используйте домен ARHIVACH.XYZ.
24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Кроме меня и пары анонов пробовали лов2д. По мне так штука прикольная. Тут, кстати, можно не задумываться %о всякой хуйне% и сразу приступить к алгоритму самой игры. Нравится этот фреймворк, очень классный. Расскажите че написали то на нем, аноны!
>>305515 Я пилю просто вид сверху, а отображать буду просто с некоторыми преобразованиями (координата Y сжата в 2 раза, отрисовка определенных спрайтов на определенные углы поворота и прочее).
Ну, катаю на love всякую хуиту. Есть кучка прототипов с крайне хуёвой структурой, написанные б-г знает когда, после этого я застрял в тренировке на кошкак ака библиотечно-модульном состоянии. Накатал кучу библиотек, от векторных на 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, получая прямой доступ: когда игрок выбирает сетевую игру, игра логинится в данной софтине, и с её помощью находятся новые игроки. Такие дела.
>>305832 Нихуево так мутишь там. Где-то можно глянуть код всего этого, или лично для себя все делаешь? У тебя, кстати, проверка IP не совсем правильная, она будет позволять делать номера > 255.
>>305832 Продолжение. В целом, если ОП нуб, очень не советую ему лове. Тут реально нихуя нет, и всё приходится делать ручками. С одной стороны, это идеально для маленьких игрушек, потому что не подгребается двести мегабайт лишних библиотек и прочего говна, плюс полная свобода. Во втором констракте, например, свободы нет от слова нихуя: только марио или спейс инвейдерс, только хардкор. Начинал с него, охуел от попыток хоть какой-то процедурной генерации. С другой стороны, лове и не позиционирует себя как движок. Это фреймворк. Набор функций, апишка для вызовов команд OpenGL/OpenAL/2dBOX и прочей херни. И так и надо, не для слабаков чай строят. Зато код легко портируется куда угодно без изменений (разве что на мобилки надо адаптировать шейдеры на GLSL ES), плюс скорость (FFI/Jit) даст фору яве и прочей хуйне. Быстрее только C++, и то не каждый раз.
>>305834 Есть проверки но позднее. Мутю для себя, гитами не пользуюсь, только гугл-драйв для синхронизации/бекапов. Могу покидать всякую фигню, плюс есть группка ВК 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
>>305836 >Мутю для себя Так ты игровые проекты какие-то делаешь, или просто всякие штуки реализовываешь на лове? Мб можно было бы скооперироваться, велосипедить вместе.
>>305843 Да, игровые проекты. Велосипедю для них же, ничто не просто так, всё для дела. В данный момент, скооперирован с художником, пилим ведро-дрочильню. Образцы графона на пиках. Тут в другом вопрос: насколько ты знаешь lua, love2d, FFI, JIT, паттерны проектирования, паттерны ООП, алгоритмы (типа коллизий/пространственной индексации), а так же линал, матстат и прочую хуету. Без этого, просто, нет большого смысла пилить что-то на love, потому что изучил новый паттерн - тут же хочется всё переписать. Я третий год непрерывно кодю, поэтому у меня приличный запас знаний, плюс оконченная математическая вышка, которая что-то да дала. Так, ежели чо, могу помогать чем угодно, благо написана тонна говна, которую можно использовать где угодно, и накоплен приличный багаж инфы.
>>305844 >нет большого смысла СОВМЕСТНО пилить что-то на love Фикс.
В одиночку - есть смысл, за милую душу. а годик сделать пяток змеек/тетрисов/астероидсов/понгов, залезть в сетевой код (Сетевая змейка, о да. Кстати, отличный старт), попутно вызубрив ООП, основные паттерны, научившись в сишку и собственные подрубаемые dll-библиотеки с наборами функций для luastate.
>>305844 Да, я согласен, что лов и луа не для новичков. Особенно учитывая, что классы в луа реализуются своеобразно. У меня есть и опыт некоторый, и знания, и также тяга к знаниям, и желание раскуривать и запиливать что-то свое. Недавно как раз коллизии на SAT написал для боксов с углом (делаю аркадную физику, пробовал бокс2д закостылить, но некоторые моменты мне не понравились). А сейчас в процессе запиливания Entity Component Systems.
>>305849 Вай малаца. На тему классов. Самая короткая либа классов с наследованием на пике. Моя. Любимая. Мне просто лень подгребать файл с ООП на очередную крошечную прожку, предпочту скопипастить функцию. На совсем крошечные либы с полутором классов, на класс-таблицу просто вешается setmetatable(class, {__call = function(self, ...) local o = {} o.x, o.y = 10, 20 self.__index = self return setmetatable(o, self) end}), этого достаточно для обычного ООП. Не, это просто и можно не заострять внимание на специфичности ООП в lua. Оно ничем особо не отличается от питонового/жаваскриптового.
>>305844 >ведро-дрочильню Только сейчас у меня в голове сработал триггер, что ты пилишь под мобилки на лов2д (я же правильно понял?) Как оно вообще с производительностью и стабильностью? Андроид же вроде пока еще не "официально" разрабами поддерживается?
Расскажите вообще в двух словах, что это и почему я должен посмотреть это, а не продолжать с безумным смехом ковыряться в Construct 2 с его драгндроп программированием
>>306089 love2d это мультимедийный фреймворк общего назначения, обёртка на lua для сишной sdl2 и некоторых других вещей. На нём можно написать что угодно вообще. Если к тому же знаешь сишечку, то можно дописывать себе модули на ней и втыкивать их в своё поделие без проблем вообще. В частности, полагаю, что к стимворксу там обращение можно запилить без всяких прокладок за 5 минут.
Но это не игровой движок по сути, чтобы в нём появились сцены, камеры, твининги и прочая хуета, можно взять, например, hump, который по сути дефолтный уже чисто игровой движок для love2d.
констракт2 это не про программирование, это про что-то другое, я так не умею, мне проще кодом описать что я хочу, чем мышкой накликивать. Меня даже юнити в ступор вводит.
>>306092 HUMP - не движок, это чисто набор тулзов: Камера, векторы, состояния, ООП и сигналы а ля ивенты. Движок - это готовая для наполнения контентом система. На love сделан GRID, и это уже движок, с энтити-менеджерами, анимациями, клиент-серверной моделью и прочей фигнёй. Читать тут: https://love2d.org/forums/viewtopic.php?f=5&t=80115
>>306092 Обращения к SteamAPI через FFI. 1. Грузим steamapi.dll. 2. Дефайним функции. 3. Дёргаем методы. 4. ????? 5. PROFIT. Подробнее тут: http://luajit.org/ext_ffi_tutorial.html Кстати, игровые тайловые карты значительно эффективнее хранить в виде статических сишных массивов или массивов из сишных структур. Пример векторной FFI-библиотеки, где каждый вектор - cdata: http://pastebin.com/i7qC1aKn
>>306146 Не совсем. Это баланс между сахарной и супер-удобной высокоуровневой Lua и супер-быстрыми и экономичными сишными биндингами. Обёртка вокруг сишной фигни делает её такой же сахарной и высокоуровневой как Lua, вместе с собтвенной скоростью и экономичностью. Где-то валялся генератор сишных cтруктур любой размерности, с итераторами по этим самым размерностям для Lua. Да, к ним подрубаются метатаблицы, поэтому ООП тоже можно мутить.
>>305497 (OP) Решил запилить свою реализацию ЕЦС. Функционала пока минимально, да и оптимизации никакой, решил сначала спроектировать удобное использование. Собственно, дошел до такого кода простейшего компонента и простейшей системы (причем в самом "движке" ничего дополнительного не надо указывать):
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
>>308740 Попробуй изучить ООП. Ты пишешь похоже на ООП, но не совсем. Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code] obj = {} function obj.add(self, value) table.insert(self, value) end это то же самое что funtion obj:add(value) table.insert(self, value) end
Вот тебе пример класса с объектом: [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
>>308762 Это не совсем ООП, потому что ты создаёшь полные копии объектов. Смотри в чём суть: методы объекта хранятся не в нём самом, а в классе. У тебя же - каждый объект хранит в себе весь набор "методов". Не могу сказать что это плохо для синглтонов, но это неимоверное засирание памяти для массовых штук. Плюс объекты создаются дольше: провесить одну ссылку на класс значительно дороже чем создавать ещё одну функцию, выделять ей память и так далее. В подобных замыканиях есть смысл, если тебе нужны приватные методы/поля, и то, старайся их минимизировать.
>>308767 P.S. Освой мета-таблицы уже наконец. Работать с lua не используя самый мощный её механизм - пустая трата времени. Я сам, осваивал в три захода, с перерывами в пару месяцев. До этого делал процедурные штуки, которые имели довольно стрёмную структуру, просто потому что чтобы сделать процедурами что-то сложное и притом расширяемое - приходится быть самим Кнутом или Дейкстрой, предварительно рисуя кучу UML-ек, чтобы из головы не вылетала структура. ООП (с несколькими дополнительными приёмами, типа чистых модулей, составления структуры директорий и дерева модулей, вызывающих друг друга) позволяет делать хуяк-хуяк и в продакшн, всего по паре-тройке предварительных макетов архитектуры. Хех, сейчас работаю программистом на lua. Довольно весело.
>>308767 Да, памяти действительно больше отжирает, и создаются долго, но зато по скорости в самом использовании вроде как получше даже: http://lua-users.org/wiki/ObjectOrientationClosureApproach Ну и из плюсов все-таки приватные поля. >приватные методы/поля, и то, старайся их минимизировать Обычно вроде наоборот стараются загнать все в приватные и делать геттеры-сеттеры, чтобы в будущем при использовании класса не напортачить чего лишнего. >>308769 >Освой мета-таблицы уже наконец. Недавно-таки раскуривал, написал свой класс для 2д вектора со всеми арифметическими функциями, правда все равно пока еще не совсем уверенно владею (всякие индексы, ньюиндексы и прочее). >Хех, сейчас работаю программистом на lua. О чем работка? Вообще недавно только подумал о всяких оптимизациях кода на луа (для игр), и обнаружил много всяких интересных моментов этого языка, что прям захотелось поглубже изучить луа.
>>308772 Работка - прямо сейчас - хайлоад-платформа для микросервисов. Потом будут сами микросервисы. Ну там, логгирование в бд, с пиками в 100к запросов в секунду. Не love2d, чистая lua с несколькими либами типа lanes для многопоточности.
>>308778 Прикольно, видимо луа все-таки еще огого (хотя, наверное, в таких вещах больше используется как обертка над Си, нежели полностью самостоятельный язык, потипу питона или еще чего). >lanes для многопоточности Вот это интересно кстати, планировал свой ECS фреймворк попробовать распараллелить (там как раз системы для обработки сущностей должны хорошо параллелиться).
>>308781 У Lua прикол в том, что она встраивается проще чем питон, сама по себе быстрая и лёгкая: единственные скрипты, которые реально используются в дохлых микроконтроллерах без особой памяти, плюс FFI, которая даёт возможность фактически писать на C на Lua, заодно, подключая совершенно любые сишные библиотеки, даже не адаптированные. Фактически, это скриптовый и сахарный вариант няшной сишки с портабельностью и прочими шлюхами. Просто не распиарено, и как следствие - мало либ и сравнительно небольшое комьюнити. Так - очень универсальная штука, которая ещё и приятно выглядит и хорошо работает.
>>308785 Ты чего то не понимаешь, а именно того что луа не полноценный язык а скриптопараша. Его дохуя где используют, особенно если нужна поддержка моддинга. Но сколько бы ты говна не навесил на скриптопарашу, она скриптопарашей и останется, для выполнения своих узких целей, и сишку при всем твоем желании она не заменит.
>>308804 А, методы в энтити от старого кода остались, действительно. На счет того, что и где хранить - пока еще думаю (в системах сейчас вроде только ссылки на сущности хранятся). По идеи в идеале энтити надо преобразовать в айдишник, и где-то хранить массивы только лишь компонентов.
>>308805 >что и где хранить - пока еще думаю Представь, что ты в рантайме добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом. Забыл одну - привет, неведомые баги. Представь, что ты решил делать игру, где битвы происходят на отдельной карте (ну, или гуи руками делаешь). Теперь при переходе на экран боя (или меню) надо из систем выковыривать сохранённые энтити и где-то их хранить до конца боя. А можно было просто свапнуть менеджер энтитей, и всё само бы работало.
>>308809 >добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом Логически, эти вещи как раз должны вместе идти по идеи. Например, какой-то ответ на коллизию должен быть - добавляем компонент этой коллизии и тут же подписываем сущность на нужную систему, которая именно эту коллизию обрабатывает. Да, на счет какого-то менеджера сущностей и подумывал. На счет хранения больше волнует вопрос об оптимальности по объему памяти и по скорости обработки. Если, например, делать массивы компонентов по их типах (массив позиций, массив скоростей и т.д.), то могут быть 2 варианта хранения: 1) когда в массиве индекс компонента строго соответствует айди энтити, но тогда будут "дыры" в массиве; 2) хранить компоненты "плотно", но вводить еще какие-то дополнительные связки индексов или ссылок. Однако я сейчас только додумал о том, что однотипных компонентов может быть несколько, например за один такт обработки физики было нанесено сразу несколько дамагов одному энтити, тогда надо делать для каждого дамага свой компонент с именем того, кто нанес, и само кол-во дамага, и все эти компоненты далее должны будут системой дамага обрабатываться. Тогда надо либо хранить по 2-му варианту, либо в менеджере сущностей делать двумерный массив, т.е. хранить массив под сущности, а уже в том массиве конкретной сущности хранить все экземпляры компонентов.
>>308812 Имхо, идея параллельных массивов довольно дурацкая. Если тебе действительно Очень Нужна Экономия Памяти - используй FFI-структуры. http://luajit.org/ext_ffi_tutorial.html Это в сотни и тысячи раз уменьшает расход памяти и даёт быстрый доступ. Другое дело что оно статичное, поэтому максимальное количество объектов приходится рассчитывать заранее, или хранить в lua-таблице.
>>308834 Я подумал, что все-таки не буду углубляться в дикую оптимизацию того, что пока еще вообще не до конца допилено. Но все-таки хочу в итоге организовать все более-менее рационально и удобно средствами Луа. В статье выше все-таки делается расчет на десятки тысяч объектов, мне же сойдет и пару сотен на первое время.
Собственно, сделал энтити идентификаторов, и разделил список всех сущностей и список подписавшихся. Я подозревал, что при изменении структуры на более правильную и наращивании функционала вся структура кода будет идти немного косо, но не думал, что настолько рано. Однако схему создания компонентов и систем в моей реализации удалось сохранить. Заодно пришлось разобраться с итераторами и запилить собственный.
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
>>309374 Десятки тысяч упаковываются в одну lua-таблицу, как ffi-структуры. Вкури это уже и не еби себе моск. Как правило, чем проще решение тем лучше.
>>309375 Да дело не столько в структурках, сколько в их организации. И мне кажется писать для каждого компонента что-то типа ffi.cdef[[typedef struct { double x, y; } point_t;]] только лишь для того, чтобы данные чуть компактнее были, заместо привычного луа-кода, оно не стоит того, притом что нужда в компактности не такая большая. Если уж ударяться в харкдор, тогда все на Си надо писать. А так мне больше интересно сам луа поковырять.
>>309379 Простых организаций сущностей и так сделано дохрена. Чем тебе коллекции с ключами-id не угодили, кстати? Ну там, сущность: entity[id] = obj = {x, y, sprite, update, draw, owner = playerN}, где update/draw - функции с колбеками и прочей дрянью. Ну, и унификация этих же сущностей, мол, каждая должна иметь методы update/draw, а если не имеет того же draw - вместо отрисовки сущности используется рисование прямоугольника. Достаточно просто же! Спавн сущности - добавление элемента в табличку, доступ и удаление по id - простое. Чтобы не париться с уникальностью id - генератор UUID. Всё что можно на ссылках. Да, все ссылки на сущность (например, ссылка у владельца Меча Тысячи Истин) должны быть со слабыми ключами, чтобы удалив сущность из коллекции, она же удалилась у владельца.
>>309384 Так у меня практически тоже самое и реализовано. Создание сущности: function self.newEntity() table.insert(entities, {}) return #entities end Возвращается по сути ID этой сущности, по которому потом можно нацеплять компоненты и подписывать на системы. А системы имеют список subscribers, в котором содержатся ID тех, кто подписан на эту систему. Одна из защит от обращения к несуществующим сущностям реализована в самом итераторе.
Избавление от прямого наличия методов update и draw - по сути одна из фич ECS да и вообще дата-ориентированного подхода. За счет замены тех методов на системы достигается избавление от всяких наследований и получается гибкость конструирования сущностей.
>>309389 Ладно, как знаешь. С ООП на замыканиях, ты создаёшь кучу дубликатов и в целом, странных вещей, но это твоё дело, хех. Просто попробуй различные варианты, и действуй исходя из практичности, а не хуярь всё подряд "золотым молотком".
>>309390 Я думал какие-то из классов все-таки переписать без замыканий, но потом понял, что в данном случае это на самом деле мало что изменит: все системы всегда будут иметь один единственный экземпляр, и сам менеджер также используется в единичном количестве (ну или может пару их можно создать для разных состояний игры, например, но это не существенно). В текущей реализации вроде вариантов больше никаких нет, или я не вижу их. В дальнейшем если еще что-то буду делать или эту архитектуру переделывать, то уже буду смотреть каким методом лучше запиливать ООП.
И я-таки продолжаю трахаться со своим убер-фреймворком ЕЦС. Уже хочется переделать все с нуля, но я планирую еще до конца разобраться где какие косяки будут (мб смогу нормально вставить костыли чтобы все работало). Завел себе репозиторий, вынес код фреймворка в разные файлы. Правда системы и компоненты оставил "по-деревенски", т.е. в одном файле куча компонентов или систем, но пока их немного - и так норм, легче отлаживать.
Решил проверить реализацию ивентов, выскочило несколько проблем: опять же существование несколько однотипных компонентов у одного энтити (наверное все-таки введу айдишники), еще как выше обсуждали - ручное или автоматические подписывание на системы - ручное дает гибкость, а автоматическое позволяет меньше задумываться над этими вещами (я не уверен, но возможно в любой задаче можно будет обойтись без той гибкости), добавление/удаление компонентов, подписка/отписка от систем из других систем (пока сделал не очень красивое решение, но лучше хз как).
В общем использовать примерно так: 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д.
>>310791 А, еще забыл про проблему приоритетов систем. Я сначала думал, что как они объявлены, так они и будут храниться в списке систем, но это совершенно так, и они даже ни в каком не обратном порядке. Не знаю, понадобиться все-таки эта приоритезация, т.к. в продолжительном времени они все равно все циклически будут обрабатываться, но если по-хорошему делать, то это надо.
>>310791 Box2d неимоверно тяжёл. Для задач платформеров/леталок-стрелялок даже с худо-бедной физикой его слишком много. Из пушки по воробьям. Особенно если ты хочешь заставлять прыгать персонажей через applyForce.
>>310802 Да, согласен, если какие-то аркадные штучки делать, при придется костылить. Но в данном случае я хочу подключить его для теста своей архитектуры, т.е. смогу ли я прямо в эти системы и компоненты вписать внешнюю библиотеку (потом может и гуи какой-то придется вписывать). Одна из проблем, которую я вижу, это добавление в бокс2дшный мир новые тела (т.к. у меня системы никак вручную не инициализируются, и не получится организовать везде свободный доступ к созданному миру); предполагаю, что придется решать через дополнительные сущности и системы (например, сущность - бокс2д мир, и компоненты, прикрепляемые к нему - описания новых тел, а какая-то система будет заниматься добавлением этих тел в физ. мир, другая же система будет делать как и положено world:update(dt) ). Другая проблема - описание и добавление новых коллбеков в физ. мир при коллизиях. Решение, наверное, аналогичное.
>>310804 В отсутствии свободного доступа к миру изначальная проблема твоей архитектуры. Костылей не наберёшься, и наткнёшься на большие сложности расширяемости. Я предупредил.
>>310807 P.S. Я писал МНОГО вещей на love2d, пробуя разные варианты. Наиболее эффективный - набор коллекций для всех персонажей имеющих ИИ, снарядов, сущностей и карта. Каждый элемент имеет свои методы update/draw. Проходим по списку, обновляем, отрисовываем. Даже если объекты очень разные - они тем не менее обновляются и отрисовываются, ровно так как тебе хочется. Всякие сложные объекты, вроде каких-нибудь снарядов в виде вращающихся лезвий, которые зависают в воздухе или липнут к поверхностям - конечными автоматами, где вместо update/draw подставляются соответствующие методы из текущего состояния (перегрузка __index, например), и методы взаимодействия с другими коллекциями, которые дёргаются в update. Получается наиболее открыто, и легко добавлять что угодно.
>>310807 Ну я пока и щупаю проблемные места. >>310808 У тебя одна сущность имеет один update в котором всё-всё-всё, или набор update с разными предназначениями? Если второе, то эти апдейты можно случайно (по какому-то случаю) нацеплять/отцеплять от сущностей? И как ты все-таки физику реализовал? Ведь она не в самих сущностях, а над ними. И нужно определенным образом еще итерировать по ним, если это самописная физика, либо придерживаться некоторых внешний правил, если это готовая библиотека.
>>310812 Физика - итерируем по объектам. Смотрим с чем сталкиваются (sweep & prune/quadtree/регулярная сетка в помощь). То с чем кажется что сталкиваемся - проверяем. Если и правда столкнулись - выполняем разрешение коллизии для обоих объектов. Изич же! Если использовать внешнюю систему - они, как правило, возвращают ссылку на физический интерфейс объекта. Хранишь в сущности ссылку на физоновый объект, применяешь к нему его методы, узнаёшь координаты/списки столкновений/прочую хуету. Для этого дела, советую либу Hardon Collider. Она не решает коллизию автоматически, только выдаёт ссылки на объекты, с которыми произошло столкновение и dx/dy как вектор ближайшего разрешения коллизий. Это удобнее чем всё остальное, благо прямо таки объекты, возвращаемые либой можно пичкать параметрами и методами (главное - не оверрайдить уже имеющиеся), получая минимум затрат памяти.
>>310814 Хм, окей, идею понял. Больше похоже на то, что я раньше делал, ну у меня попримитивнее было, когда основное понятие - это объект, т.е. данные+методы достаточно жестко связаны. Фича ECS как раз в том, что можно практически "на горячую" менять отдельные детали поведения и содержимого компонентов. На счет твоей идеи сейчас не могу сразу сказать на сколько может быть удобно относительно ECS использовать, надо подумать над разными примерчиками.
>>310815 Либа, кстати, интересная, спасибо за подсказку. Правда я уже свою запилил для OBB, но может чего подгляжу или интегрирую коллизии в свою физику.
>>310818 >на сколько может быть удобно относительно ECS использовать Я делал а) локальное пространство самого объекта, а ля глобал внутри self, б) локальное пространство внутри состояния, обращение по __index-перенаправлению на currentstate или метод self:getState().key = value. Просто и неимоверно эффективно. На мой взгляд. Lua гибкая.
>>310791 >подписка/отписка от систем Делай, чтобы системы у твоего менеджера запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные). Чем меньше состояния хранится вне компонентов, тем лучше и проще. >>310793 >они даже ни в каком не обратном порядке У тебя просто хеш-таблица вместо массивов/списков. Я себе делал приоритет для каждой системы, потом менеджер этого всего при добавлении новой сортировал все системы по этому приоритету. Позже я заметил, что всё равно стараюсь их размещать так, чтобы они регистрировались в том порядке в каком будут исполняться, и сами приоритеты я нигде не меняю, поэтому отказался от них вообще. >>310804 >добавление в бокс2дшный мир новые тела Делаешь систему физики. Далее, вместо прямого добавления и удаления тел, добавляешь энтите компоненты AddBody или RemoveBody, которые уже системой физики обрабатываются так, как она хочет.
>>310913 >запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные) Я вот на счет этой автоматизации пока и сомневаюсь. Теоретически возможно такое, что компоненты все идентичны, но поведение разное (ну, навскидку, 2 бота, один добрый, другой злой, один просто гуляет, другой нападает на игрока). Можно, конечно, какие-то теги или компоненты с "описаниями" ввести, но хз.
На счет приоритета - у меня сейчас менеджер сам подбирает все системы из таблицы Systems и инициализирует их у себя, т.е. у меня нет такого, типа manager.addSystem(drawing_system). Хотя это в общем-то интересная замена приоритетам, когда самостоятельно подключаешь системы в определенном порядке, надо подумать.
На счет физики и компонентов новых тел так и подумывал. С ручной подпиской на системы, правда, еще несколько моментов придется продумывать.
>>310963 >Теоретически возможно такое, что компоненты все идентичны, но поведение разное Такого быть не может. Разное поведение получается не магически же, а ты как-то их различаешь и запускаешь разный код. Различать можно тремя способами: 1. Разные компоненты. 2. Разные значения в каком-нибудь компоненте (AiComponent.isHostile или что-то подобное) 3. По имени энтити. Очевидно, что третий способ долбоёбский, а для первых двух нифига не изменится, если ты будешь запрашивать, а не подписываться. Единственное, зачем нужна эта подписка - производительность (да и тут ещё вопрос, что будет быстрее, потому что в реальной игре каждая система добавляет/удаляет десятки/сотни компонентов - в зависимости от размера игры), но на первый раз лучше сделать "как правильно", а потом уже смотреть, если будет нехватать.
>>311091 Хм, да, согласен, компоненты все-таки легче отслеживать и они не такие "низкоуровневые" в отличие от ручных подписок на системы, т.е. юзабельность повысится даже если придется делать компоненты-теги, или совсем-совсем частные типы компонентов, а гибкость останется примерно на том же уровне.
В общем реализовал добавление систем вручную, решил сделать именно методами addSystem, т.к. мне кажется так более наглядно? плюс можно строить разные ECS менеджеры с разным функционалом. Запилил выбор подписчиков в системах через новый самописный итератор, который внутри проверяет requirements (возможно стоит оптимизировать, и обновлять существующий список по добавлению новых компонентов к сущностям).
Ну и решил проблему со множественными компонентами: как я подумал, если каких-то компонентов может быть много, то они, скорее всего, являются событиями. Собственно, поэтому сделал 2 разные функции: addComponent и addEventComponent. Отличие второго в том, что по обращению к entity[component.name] будет возвращаться массив компонентов типа component.name. Единственное, что теперь системы, обрабатывающие ивенты, стали несколько толще, ибо приходится еще перебирать сам массив ивентов (подумываю на счет того, чтобы автоматизировать выборку сущностей и компонентов, т.е. перенести циклы из систем в менеджер, а в системах работать только с выданной сущностью/компонентами типа update(entity, dt), но тогда хз как физику запиливать).
Потихоньку накапливаются вещи для оптимизации (в хорошем смысле) и для налаживания безопасности (удаление сущностей/компонентов/систем), но они пока не в приоритете, ибо хочу уже запилить полный функционал фреймворка. По плану все еще реализация физики.
>>311667 Еще щас подумал. Например, реализацию движения (Systems.Moving), т.е. обновление координат, можно (гипотетически) запилить через ивенты, которые будут возникать на каждом такте, а т.к. оно сейчас реализовано без них, значит и систему событий можно теоретически развернуть в обычное обновление. В таком случае, наверное, надо будет просто добавлять дополнительные флаги и счетчики в определенные компоненты, а в системах их обсчитывать, и обрабатывать только тогда, когда какие-то условия срабатывают. Т.о., если нанесение урона происходило бы по ивенту, то в новом варианте можно сделать компонент Damage (и он будет в единственном кол-ве в энтити) с полем health_damage, и если никто не наносил урон, то это поле = 0. А в системе Damaging можно просто без всяких условий делать entity.health = entity.health - damage.health_damage Но пока хз на счет гибкости и юзабилити такого подхода.
>>305497 (OP) Начал свою игру про вселенную где можно делать ВСЁ ещё во времена 8, в 9 аесь апи поменяли пришлось переделывать, подзаебало стал простаивать, потом к 10 опять всё переделывать уже забросил. Вообще то что там нихуя нет хорошо - если где-то криво сам правишь не надо чужой сортир копать.
>>311671 андроид порт только в 0.10 добавили, норм ретину только в 0.11 завезут. впрочем я хз что там надо было такого нахуевертить, чтобы переделывание под новую версию заняло больше 1 выходных.
>>311667 Запилил свою физику в свой фреймворк. Пришлось подумать как реорганизовать цельную обработку коллизий (нашли одно-разрешили одно) в поэтапную (нашли все - разрешили все). Решил, что пускай сначала в виде ивентов у энтити будут накапливаться коллизии, а потом в другой системе, если тела все еще пересекаются, то разрешать их. Т.е. у меня сейчас 2 системы на это: проверка коллизий, и разрешение коллизий, но сейчас понял, что это минимум, и систему разрешения надо заменить скорее на систему определения типа коллизий (или все-таки прикрутить это к самой проверке), а далее, само разрешение (расталкивание) будет одним из этих типов (и будет отдельная система под это). Еще приходится в ивентах постоянно следить, чтобы они удалялись после обработки, мб оптимизировать это как-то. В целом могу сказать, что фреймворк работает, надо только немного перестроить мышление под обработку компонентов системами (а не объектов апдейтами), и можно будет получать кайф от модульного кодинга всего функционала игры.
Блять, луа - самый уебанский язык на планете земля. Какого хуя, блять? Половина копируется по ссылке, половина по значению, никаких стандартных функций нет, пишите все с нуля. Сука, ассемблер удобнее.
>>319904 Инты и булы по значению, таблицы и строки по ссылки, что непонятного? Какие функции тебе нужны? Комьюнити луа хоть и относительно мертвое по сравнению с другими языками, но все-таки умельцы делают достаточно всяких либ, которые покрывают большинство возникающих потребностей, надо только поискать. Так-то язык довольно прикольный и легкий, со своими фичами.
>>319967 Да я просто охуел, что таблицы копируются по ссылке и нет стандартной функции клонирования, но уже загуглил. Просто не очень интуитивная шняга, переписать бы этот фреймворк под православный руби.
>>305497 (OP) >я по умолчанию подразумеваю, что рисуешь ты на том же уровне, что и в тысячу раз лучше и удобнее, если бы им можно было юзать всё как раньше, но размеры указывать в пикселях.
>>409659 Ну так, более-менее. Время от времени что-то пилится, например, сейчас таки замутил систему сущностей на HC с тегированием и блекджеком. Там что-то такое.
>>409747 Ну, это простейший тестовый ИИ, который нужен только чтобы узнать, работает ли система ИИ, так что ничего страшного. Мне другое интересно: как нормально впиливать поиск путей, который будет работать с комплектами полигонов, и не проще ли при создании карты заранее построить графы путей, по которым можно двигаться как по ключевым точкам. И да, игра должна проходить на замкнутом пространстве, с ключевыми точками вроде зон захвата (нет, это не wot2d), точками спавна бонусов и всего такого, и с временно недоступными зонами, вроде открывающихся/закрывающихся ворот. Алгоритмы ИИ должны учитывать, что прежде чем проходить ворота, их нужно открыть.
>>409854 Каркас двигла замутил? Просто без этого, разработка затянется, ибо вместо наполнения контентом, будет разработка базовых инструментов. Хотя, конечно, можно взять GRID.
P.S. Сам не хочу слезать со своих проектов, надо закончить хоть что-то.
>>409880 Свой убер-ECS фреймворк как раз писал для этого. Не знаю, придется ли его еще допиливать, но простой прототип со своим физоном и простой ГУИ на кнопочках достаточно легко получилось сделать.
Попробовал леху в сравнении с годотом. Заебато то, что все очень просто, даже с физоном не трахался, в отличие от годота (хотя там тоже, в принципе, ничего сложного нет, но с редактором можно словить нехилых идиотизмов). Единственное, что не нравится, нет менеджеров сцен и полноценного (или хотя бы минимального) гуя из коробки, поэтому придется либо сторонние модули подключать либо писать велосипед (но они меня сильно подзаебали, так что уже хочется чего-то готового). Пробовал нарколыжить в HaxeFlixel еще, но что-то он меня пиздец вымораживает со своими обновлениями хитбоксов и прочего при изменении свойств объектов. Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
>>409996 >Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю Там по сути от ООП вообще ничего нет, кроме двоеточия для передачи "self" в качестве первого параметра метода. Но если раскуришь суть таблиц, метатаблиц, замыканий в lua, то, как мне кажется, становится даже интересненько. В общем в луа много чего занятного можно найти.
>>409996 Короче, залез в колхоз еще глубже. Есть у меня сцена, в общем, на ней тайловая карта, даже не важно откуда. Так вот в чем дело, отрисовать саму карту, в принципе, сложности не составляет, даже регион, элементарно. Только вот что делать с объектами. Допустим, у меня тысячи их, естественно, отрисовывать объекты, находящиеся вне области видимости смысла нет, поэтому нужно использовать либо сетку размещения (или как это дерьмо называется) или квадрантные деревья. Или это леха сам делает?
>>410176 По-моему для отрисовки ничего такого не применяют. В буфер отрисовки записывается только видимая часть, и занимается этим OpenGL/DirectX, которые используются в SDL (Love2D вроде на нем основан). Разбиение пространства обычно для расчет физона используется, ибо считать столкновения для 1000 объектов действительно проблематично. А для ускорения отрисовки, особенно тайловой карты, используют батчинг (sprite batch), т.е. по сути составление одной большой картинки из тайлов, которая за один вызов функции сразу вся отрисовывается.
>>410205 Про батчинг я знаю. Вот именно проблема в том, что именно отрисовывать, не буду же я перебирать 10000 объектов (в поисках тех, которые попадают в экран), скажем, если на экране в области видимости только 30 из них, например. Или все же сделать простым перебором всех сущностей и отрисовывать только те, которые появляются на экране.
>>410207 Разбей карту на кусочки NxM тайлов, рисуй только те чанки, которые влезают в камеру. Один батч на один чанк. Идеально - прорисовка четырёх-девяти чанков квадратом. Подгони размеры чанков под камеру, или, если есть зум, вычисляй область видимости. Да и в памяти обычно не нужно держать всю карту, выгружай ненужные куски. Ясен хрен что ближайшую область надо держат ь, чтобы не тормозило га чтении Так даже легко мутить бесконечные карты как в майнкрафтике. Ничего сложного, просто арифметика.
>>410207 Дополнение: Аналогично можно поступить с игровыми объектами, спавня их в нужном чанке. В чанк пихать список ссылок на нпс, а у нпс - хранить ссылку на чанк в котором он сидит. При перемещении, нпс самоудаляется из чанка в котором был, добавляется в чанк в котором оказался, и меняет свою ссылку на текущий чанк. И так - с любыми объектами.
Почаны, а можно ли как-то сделать следующее: - требуется обсчитать что-то ресурсоемкое, но его нужно обсчитать не ПРЯМО СИЙЧАС, а на низком приоритете и по готовности сгенерить евент. То есть не в текущем update, который должен длиться доли секунды, а вообще в принипе. Можно ли добавить как-то фоновую задачу? - предположим некропека не выдерживает эти ваши 60фпс или даже консольные смус 30фпс. Как мне дропать фреймы? Завести счетчик, который будет обновляться в update и в draw уже просчитывать когда скипнуть, а когда нет? нужно ли при этом делеить или задержка и так генериться между каждым update?
и еще вопрос. есть у меня ПОДОЗРЕНИЕ, что вывод было бы неплохо буферизировать вместу тупого вызова draw на каждый фрейм. Попробую пояснить.
предположим есть у нас буфер в котором отражен слой из тайлов - задников. Ну чтобы совсем проще выразиться. Предположим у нас клон террарии и есть несколько буферов-слоев. Задник, тайлы с водичкой, землей и прочим песком и тайл с монстрами поверх них (тот же червь-пидор что атакует под землей). Не суть. Если делать все по-еблански то на каждый чих надо будет все рисовать заново, что подозреваю, будет крайне медленно. Вместо этого генерим в буфер на область в 2-3 экрана с каждой стороны один раз тайлы и потом лишь меняем (копнули землицу, убрали тайл, перерисовали лишь эту небольшую область (ну и слои за ней) вместо генерации всего экрана. Или это сложно реализуемо/нереализуемо вообще? Я наверняка изобретаю велосипед, но ведь лубовь 2д и есть один большой велосипед, разве что можно где-то спиздить готовое решение.
Кстати по-поводу пиздинга - как потом можно сныкать свой ШЕДЕВР? на ум приходит лишь обсфускация наподобие минимизаторов для яваскриптов. Где все преобразуется в трудновоспринимаемую мешанину из односимвольных переменных и функций.
>>425542 >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.
Ну в общем остается вопрос как правильно делать КЛОН ТИРАРИИ. С трудом верю что тупо прорисовывать весь экран на каждый чих. Предположим для простоты это пошаговая игрулька, но с эфектами/анимацией. Зачем мне перерисовывать все, если достаточно перегенерить лишь слой с эффектами, который накладывается поверх всех? ну там искорки, огонек или еще какая пежня.
>>410207 могу ошибаться, но в том же don't starve, там по-моему все реализованно именно тупым перебором сущностей с вычислением расстояния до игрока. Игрок всегда в центре, поэтому можно понять, попадает в кадр или нет.
>>425556 Ну смари кароч. В тёрке вообще нужно только набор канвасов на каждый чанк. Один раз отрисовал канвас с тайлами, и дальше его дорисовываешь (заменил тайл с A на B, или удалил, это более чем реально). Ну и теням свой канвас. А эффекты партиклов и так работают. Мобам - да, берём батч и рисуем однотипных мобов в нём. Можно автоматизировать, мол, если данный моб заспавнен но для него нет спрайтбатча - создать для него батч. С love v0.11 будет проще, ибо там это будет полуавтоматизировано.
>>425959 а загнать все в один батч, а потом копировать лишь то что видно низя? слишком большой расход памяти?
если чесна то нихуй не понил. чанк - группа тайлов из которой составляется текущий экран?
лучши ткни ссылкой где почитать терминологию с картинками если знаишь. все же интересно как зделоли в римворлде, там размеры жестко ограничены и карта может выводиться полностью на экран. Неужели и там трахаются склеивая области вместо одной большой?
>>426135 спасибо, Аноний, реально помогло. метатаблицы тут используешь для эмуляции наследования "классов"? или оно же необходимо для определения методов тоже, иначе при создании нового объекта Chunk пришлось бы создавать все методы заново, я правильно понимаю?
алсо я правильно понял что у тебя чанк - это 4 тайла в одном, типа квад в терминологии любви2д? т.е. по-сути лишних тайлов за камерой тут может быть лишь по одному по горизонтали и/или вертикали.
Если это так, то тут интереснее как ты эти чанки хранишь и видимо уничтожаешь. Ведь если игрок, скажем, будет постоянно двигаться влево, то рано или поздно надо будет мочить самый правый чанк, иначе пожно так всю память засрать ими.
Или похуй и все эти квады-хуяды занимают копейки памяти?
вообще я нихуя не понял зачем вообще эти квады нужны. как я себе наивно представляю использование тайлов: - грузим в память (видеопамять?) тайл, а то и атлас. получаем некий дескриптор и потом используем его для вставки вместо загрузки каждый раз.
Все эти рогалики-хуялики используют не так много тайлов чтобы обосраться с памятью. Да бля, у меня в скуйриме наверно 4к труселя моей вагини с нормалью занимали больше чем все эти пиксельные обмылки.
Если еще юзать атласы и определять тайлы через них, так вообще должна быть дружбомагия с точки зрения перфоманса.
я просто не пойму это навязчивую идею везде юзать квады. чем блять 2х2тайла так прям лучше чем один.
>>426155 Метатаблица - да, чтобы дёргать методы 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. Квад = трафарет, по которому мы вырезаем из картинки прямоугольный кусочек, и добавляем в список того, как рисовать весь атлас.
>>426281 >их циклом, типа такого: > >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. Т.е. можно переключаться между качественными текстурками или лоу для нищебродов.
>>426346 Да, вместо батча можно использовать канвас. Типа при загрузке чанка, мы создаём этому чанку канвас (12864 х 12864 = 8192x8192 пикселя, многовато будет, лучше несколько мелких канвасов чем один огромный, поэтому размерность чанкосетки уменьшишь). При копании руды - перезатираешь этот квадратик чем-нибудь ещё: делаешь прозрачным при раскопке, рисуешь сверху другой тайл при строительстве и т.п. Но канвасы сложнее хендлить.
SDL - это куча кроссплатформенных либ, а ля opengl + openal + системные прерывания для клавомышигейпада и кучка оболочек (таймеры, события, всё говно). А love2d - оболочка над SDL, чтобы из lua можно было дёргать методы.
Большое количество кириллов с форума - не умеют в спрайтбатчи, полностью прогружают гигантские вещи и просто не умеют в оптимизацию. Лове может быть быстрым, но нужно уметь, это не юнька где за тебя всё уже оптимизировали "для сферической задачи".
>>426357 За качеством текстурок - смотри 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
Кстати, не понимаю как это может упрощать текстурки, за исключением уровня мипмепа.
>>426481 >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. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
>>426513 Если мир - тайловый, то нужны, потому что от этого идёт перенос координат с мировых в тайловые, например. Ну, или плодить каждый тайл отдельной сущностью, с параметрами x/y/w/h, что совсем не круто, ибо жрётся бешеное пространство. Зато в тайловом мире так можно спавнить сущности (кусты/игровые объекты/выброшенные предметы и т.п.) Но их в идеале должно быть сравнительно немного. Если ты заметил, даже в террарии однотипное говно объединяется в стаки при вываливании на землю, ибо жрёт немеряно места. Ну, выбросил ты 9000 кирпичиков земли. Их все надо бы физически обсчитать, или заморозить их физон, разморозить если что-то их касающееся изменилось, например кирпич под ними сломали (для этого нужна мелкая пространственная сетка и эвенты), но если выбросишь слишком много - привет, резкие просадки fps! Но рисовать их всё равно надо всей кучей, и ту же коллизию калькулировать.
>>426513 Ты вообще заметил, что тайловые миры оказываются значительно быстрее/экономичнее по памяти миров, основанных на векторных объектах (особенно с физоном для каждого)?
>>426508 Демка - вот эта? https://love2d.org/forums/viewtopic.php?t=82562 Это потому что каждая зверюшка - элемент батча. Просто этот товарищ умеет в спрайтбатчи, и даже суть демки - показать автоматический батч. Эту штуку впихнут в следующую версию love2d, тогда можно будет рисовать циклом кучу говна, и оно будет полуоптимально рендерится. Это относится к картинкам и векторным примитивам (не к тексту, увы).
>>426525 в террарии, что-то просрали в последних версиях, там есть ощутимый лаг в одних и техже местах карты (видимо как раз граница загруженных чанков-панков и делая шаг в сторону все это начинает подгружаться) реньше такого не было. А проблему 9000 кирпичей они вроде решили куда проще - там вроде как есть лимит на количество отображаемых объектов. После которого новые тупо не отобразятся пока не подберешь старое. Ну и плюс они там не валяются вечно а со временем исчезают.
По-поводу отдельных тредов/потоков я спрашивал тоже с огдядкой на террарию. Например, там corruption/hollow постепенно расрастался по всей карте, независимо от положения игрока. Добавь сюда расчет перелива жидкостей и рост травки - ну ни как такое не обработать за один цикл update. Уверен что там это как-то просчитывается параллельно.
>>426531 На тему corruption/hollow, смотри в чём прекол: 1. У нас есть некоторая функция, по которой генерируется/распространяется биом. 2. Каждый чанк имеет некоторое "время с начала мира". 3. Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти. Это читерный способ. То же самое можно с растениями: запоминаем время посадки и выгружаем чанк. Когда чанк загружается снова - рассчитываем разницу во времени между предыдущим состоянием и текущим, добавляем рандома и вот, наше растение выросло пока нас не было. Аналогичным образом работают всякие куки-кликеры, в которых печеньки копятся даже при закрытом браузере (но в webstorage есть время выхода!)
>>426531 Пардон, дополню ещё раз. Перелив жидкостей - это вообще отдельная тема. Жидкости динамические по сути своей. Считай что жидкость считает последний загруженный чанк твёрдой границей, и не льётся дальше. Сам проверь, попыткой слить океан в ад. Когда ты в аду, вода сверху перестаёт течь потому что чанк с бесконечной водой выгружен, а те которые активны в данный момент - уже слили воду.
И да, держать в памяти стоит чуть больше чанков: условно, если рендерим мы девять штук, то в памяти, чтобы не было лагов, держим штук двадцать-тридцать, на всяк случ. И можно предугадывать загрузку при движении: игрок падает вниз -> предполагаем что он будет падать ещё некоторое время -> загружаем сразу пачку чанков снизу, но рисовать продолжаем только те, которые влезают в камеру.
Кстати, для исследования террарии советую собрать нищеноутбук с очень медленным хардом. При падении с высоты, можно заметить насколько далеко прогружаются и рендерятся чанки: видно как из пустоты возникает почва, когда прогружается. С ранними билдами старбаунда - та же фигня.
>>426530 да она, правда с дефолтным количество котов в 4000 некропека выдает 6фпс, но с "всего лишь" 1000ю уже 24. Для меня такое количество в любом случае оверкил, поэтому и впечатлило.
>>426562 И это ещё не самый оптимальный способ применения батчей. Можно быстрее, правда, вокруг этого придётся мутить весь рендер. а) батч, при добавлении спрайта, возвращает его ID. Это позволяет модифицировать то что мы рендерили без перезагрузки всех данных в видеокарту. Ну там, кадры менять, или двигать или и то и то. б) Батчи имеют несколько режимов оптимизаций (static/dynamic/stream). Угадай, какой самый эффективный для тайловой карты. в) Товарищ в своей либе, после каждого draw выдаёт batch:flush. Это сжирает приличное время.
>>426543 >Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти. В донтстарве так и делают, все, что за пределами текущего экрана и по 2-3 экрана с каждой стороны - спит. Потом когда подходишь к усыпленной сущности, то вызывается longupdate.
кстати, а использование png как-то отражается на рендере? или там при загрузке тайла все преобразуется в какой-то свой распакованный формат и не занимаются херней?
в том же DS позволенно лишь использовать текстуру в определенном формате. Все эти пнг идут лесом.
>>426578 Свой формат, раньше можно было грузить джипеги, а сейчас нет (хз почему, мб лицензии). Для канвасов - отдельный набор форматов: https://love2d.org/wiki/CanvasFormat Это сделано для оптимизаций размеров/занимаемой памяти.
Его суть в том, что из этой фигни можно генерить картинки, а ещё, писать свои упаковщики/распаковщики произвольного формата в данный: функцией mapPixel можно грузить картинки, например, из rgba8. На пике пример.
ох так он там еще с котами и тень рисовал для каждого. если убрать, то еще +10 фпс.
еще странно что он размер картинки кота зачем-то вычисляет внутри цикла 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. И все кросплатформенно, бесплатно и шустро.
>>426709 v8 с webgl не обосрутся от тысячи звёзд на i7 если есть видеокарта :3 Но да, ловка примерно в пять-десять раз быстрее, хотя бы за счёт отсутствия бешеного количества прослоек жаваскрипт/браузер/opengl. С лове похожая ситуация (lua/c-core/opengl), но оптимизация на месте, плюс luajit откровенно не даёт оверхеда на переключение между контекстами, это охренительная прибавка.
>>426786 вангую, что там будет еще нехилое различие по потребляемой памяти. если еще учесть, что луа запустится даже на кофемолке с мегабайтом памяти (на самом деле вроде даже килобайтах), то хипстерское js-поделие уже в аутсайдерах.
так что любовь победит и тут.
Особенно если учитывать как в js на каждый чих создается объект и отсутствие integer в принципе. итого дикий оверхед для простого массива.
У луа жи есть это ваше FFI, которое мне надо будет вкурить, но подозреваю что это чит, реализующий строгую типизацию и убирающий тот самый оверхед из-за нестрогой.
>>426790 ffi = "пишем на луа на сишке", со всеми профитами, плюс подрубание произвольных сишных библиотек, с прописыванием хедера в cdef, с отсутствием оверхеда и прочей милотой. Рекомендую.
>>426790 Оу, кстати, у меня где-то валялась ffi-векторная либка. https://pastebin.com/i7qC1aKn В качестве вектора используется сишная структура (x, y), к которой прицеплена метатаблица для перегрузки арифметики/методов. Мгновенно создаются и обсчитываются сотни и тысячи векторов, плюс сахарок.
Ох щит, так у луа тоже целых нету. На массив типа намбер 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, который хуй пойми какого типа. Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
>>427189 Ну тип ты можешь сделать так: buf = ffi.new('unsigned char[?]', 4) for i = 0, 3 do buf = math.random(255) end И это будет Тру char'ы. Что сложного?
>>427189 Да, конечно, числа будут приведены к соответствующему сишному типу. Тогда если ты прибавишь единичку к 255 char'а, оно примет значение 1. Ты давай не выёбывайся и не бомби, а изучай и ебош.
>>427220 я в си совершенно не бум бум, но равзе 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 и поиметь ВЫИГРЫШ в производительности, т.к. ничего не требуется преобразовывать?
>>427257 Да, в нуль скатится, меня подглюкивает. Луашные 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, рассказали что можно сделать нормальную оболочку над сишкой и дёргать её из луа. Радовался бы, так нет, надо флудить и бомбить, как будто тебе десять лет.
>>427318 сравни большие числа, там где мантисса присутсвует. не сможешь, ты сможешь лишь проверить, что их разница меньше некоторой заданной константы (точность) аля 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) {} все, еба. И память не расходуется и битики можно гонять и все довольны. вместо деления/умножения на степерь двойки - битовый сдвиг и тп.
>>427326 >Integer в lua 5.3 - 64-битные, занимает те же восемь байт. Так что можешь упороться. даже если так - похуй. можно легко вытащить требуемый байт двумя арифметическими сдвигами, которые потребляют 1 или пару тактов проца.
>boolean в луа - отдельный тип, он как раз (как ни странно) однобайтный, по моему, не знаю точно. хуй там плавал. Создаешь табличку и загоняешь туда одни лишь true. Результат - те же 8 байт на ячейку. Спецом замерял этим вашим гарбадж коллектором.
>>427329 когда массив занимает в 8 раз больше чем требуется, то это не бесполезный дроч, особенно когда предполагается большая размерность и массив далеко не один.
>>427342 Тебе три, блять, раза рассказали и даже показали как писать на сишке на луа, со всеми профитами сишных структур, переносимостью и скоростью исполнения. FFI ещё и включает в себя либу битовых операций, обмазывайся сколько влезет.
А в js/php инты - занимают столько же места сколько флоаты (64 бита), там аналогичная хуйня.
>>427369 Это то, что не надо "пытаться" сделать. Попытка подразумевает шанс провала. Это нужно просто взять и сделать. Взять книжку K&C, почитать, сделать мелкую хуёвину (типа крестиков-ноликов в консоли), понять как работают разные типы данных и всё тут, дальше можно продолжать. И да, что непонятного в использовании ffi? Ты объявляешь переменную/массив так же как это было бы в луа или в сишке, и точно так же с ним работаешь. Это не рокет-саенс, тут всё очень тупо даже для пхпшника который почитал про типы данных.
>>427424 це древний нетбук, так что норм >>427421 да гифка не отражает последовательность кадров. мне просто надо было посмотреть как оно будет ворочаться под "нагрузкой", вроде нормич.
>>427444 батчи-квады если еще ту библиотечку подрубить, то пара фпс проебется somehow
теперь мой внутренний Кирилл говорит мне, что надо замутить очередь задач. Тип есть несколько параметров, влияющих на производительность: - собственно fps, тут все понятно. Лимитуем, появляется больше ресурсов для расчетиков в update() - допустимое количество итераций update(), для генерации следующего состояния игры. Ну там мобье аналайзит свое окружение, агрится на вражин, расчет пасфиндинга и прочая пежня. На примере игры в жизть экспериментально получил от 5 до 15 тактов. Дальше уже как-то грустна. - размер карты (массива), где это все обсчитывается. С игрой в жизть тут не читернешь с длинными апдейтами чанков за пределами камеры, нужно все обсчитывать.
Зойчем вообще это все нужна. Мой внутренний Кирилл глаголит - предположим что необходимо сгенерить новый эвент НОЧЬ ДЛИННЫХ НОЖЕЙ. А это значит надо подгрузить тайлы, музяку и еще какую пежню, которая может быть далеко не копеешной. Вместо того, чтобы загрузить все разом и пролагаться - предполагается все загрузить за X итераций, расчитать что необходимо и по готовности начать эвент.
>>428228 Меньше швабодки но есть встроенный admob, не надо пересобирать двигло с прописыванием бриджа от lua до java. И многое упрощено. Если в лове - ничего нет, то в короне есть куча всякой лабуды. Мне предлагали работу в короне: там есть проект портирования её на luajit.
Есть к этому чуду хоть минимально нерукожопая GUI библиотечка? Только не на уровне рисования квадратных чёрных кнопок, а что-нибудь посерьёзнее. Я заебался велосипеды педалить
>>434106 Хочешь оФФициальную? Пиши сам, продвигай чтобы использовали, собирай инфу на тему "что подправить чтобы было зашибись", поддерживай, обновляй до новых версий love2d и т.д.
>>436224 Вот в этом и проблема LOVE как движка. Нихуя нет, кроме самой базы, всё работает на языке, в котором тоже нихуя нет кроме самой базы. Всё как в JS, только коммьюнити на порядки меньше, поэтому и либы все - древнее говно. Короче, не ебитесь с этим лавом, переезжайте на Godot, там грядёт эпик вин в виде 3.0 версии. Я кончил. Год ебался с LOVE-кун
>>436267 Движок? Опачки, а где тут хоть одно слово "engine"? Ни одного не видно. Ой, а что это за незнакомое слово "framework"? Опачки, а это и не движок! В этом и прелесть LOVE как фреймворка: ничего нет, ничто не привязывает тебя к конкретной структуре/архитектуре, хуярь как хочешь, ошибайся, делай новое только лучше, потом становишься мастером дзен и уходишь в программисты с зп >100к. Так и сделал.
>>436267 Ты просто мамкин неосилятор, который не умеет в архитектуру приложений сложнее чем helloworld. Простые вещи тут делать в три раза быстрее чем на годоте, а для чуть более сложных - нужно мутить движок. Движок - это как раз система связей между объектами, рендером, звучками и всем прочим. > Ждва года ебался, понял что к чему, начал охуенно ебошить.
>>436303 >вот картинку нарисовать на экране проще, чем в годоте! >а вот для более сложных вещей нужно запилить свою плохую версию годота! >ты просто не понимаешь всех преимуществ этого чудесного не движка ты сам понимаешь, что ты несешь?
>>436389 я не годотфанатик, но после этого высера >Если домашние директории лежат на дисках, подмонтированных по NFS (одна абстракция) читать не стал. Единсвенная причина так делать - бесдисковая станция, да и то там проще будет по rdp-like протоколу работать. NFS жи - локалочка, DMZ между серверами, порою с резервированием каналов (X сетевушечек как одна для предотвращения проблем с илнками/портами/и тп) Только полный даун будет использовать NFS прост для домашн директории ))). Так как работа с мелкими файлами там будет существенно медленней чем с неторопливым 5000rpm IDE
Лучше по топику задам вопросец: как местные гуру генерят карты с тайлами? Хранят в массивах (json/xml)? В картинках, где цвет пикселя определяет тайл. Или еще как?
https://www.youtube.com/watch?v=S6jqR7wmnw4 асло пример как человек ебется с тайлами в годоте. а шо, если я захочу бесконечную карту с генерящимеся/подгружающимеся на ходу тайлами? в луа тебя ограничивает лишь твоя фантазия и лень. В годоте - похоже невозможно в принципе.
>>436403 Алё, дядь, ноды в годоте можно и из кода инстансить. Вешаешь на карту какой-нибудь MapGenerator, которому прописываешь инстансить новые локации в зависимости от положения игрока. Старые не забываешь удалять, если не 100 гигов оперативы. >>436402 https://love2d.org/wiki/Tiled
>>436398 В 3.0 можешь ебаться в уютненьком Godot'е с любым ЯП. Гугли GDNative. И поясни, где ты нашел такую хуйню >который еще согасно докам умудряется работать >медленее с массивами одного типа Искренне твой, годот пидор
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.
>>436428 >Написано же - пользуй только для больших массивов, чтобы избежать фрагментации. Медленнее они из-за оверхеда на проверку типа и избежания этой самой фрагментации.
>>436535 ох лол, там написанно про падение производительности для массивом со статической типизацией. Какую ты проверку типов должен делать для них? они ебанутые? Далее там в примере сказанно про десятки-сотни тысяч элементов. На секундочку это в пределах одного-двух сегментов 64к для однобайтового-двубайтового массива. С такими даже DOS справлялся. На секунодочку, для копирования, заполнения подобных массивов данными есть даже специальные команды аля movsb или stosw, которые работают на порядки быстрее простого перебора и заполнения по одному элементу как было бы в случае обычных ассоциативных с динамической типизацией.
>>436538 Бля, ну ты тупой. Если ты из динамического ГДСкрипта напихиваешь в статически типизированный массив, кто должен проверять, че ты туда напихиваешь?
Заебошил систему состояний со стаком. Табличка override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака".
>>411408 (OP) >>438065 >override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака" а нахуя это надо?
В том году для девджема делал на Love2D простенькую игрушку с бесконечной на ходу генерируемой тайловой картой - очень даже интересный процесс. Упёрся в скорость отрисовки, и только тут в треде вычитал какие там ещё возможности есть с хранением текстурок newSpriteBath в видеопамяти и быстрой отрисовкой, надо будет добраться и переделать, да и FFI тоже может пригодиться.
>>442738 >Упёрся в скорость отрисовки хуясе, а что с ней случилось? рисует же SDL2, если не ошибаюсь обычо такая хуита начинается, когда в отрисовку логику пихают, или наоборот, лал
да я тупо 100500 маленьких картинок выводил, потом сделал чтобы не всегда всё перерисовывать, а только изменения, но сделал криво - через сохранение текущей картинки в текстурку в каждом кадре (что не хило так кушало память, если её не чистить принудительно в каждом кадре, что как-то не очень хорошо). Переделаю как руки дойдут на SpriteBatch ну и там в принципе можно убрать принудительное стирание старой картинки каждый кадр на уровне фреймворка, тогда даже мой исходный вариант будет шустрее, не говоря уже про раздельную прорисовку кусков карты.
но для прототипов love очень даже хорош, как для чего-то более законченного - пока не знаю :)
>>446359 Сам по себе Love2D пиздат, но специфичен в целом. Алсо, если это адаптация лова для раста, то возможно еще не все фичи реализованы, и выход новой версии будет задерживаться, хотя это менее критично. Ну если чувствуешь в себе силы, то можешь какие-нибудь простые демки запиливать.
Сделал Hello_button и задумался. https://anotepad.com/notes/ti57jh А если у меня будет несколько кнопок\объектов на экране, мне что каждый проверять на границы по очереди? Или есть какой-то неизъебский способ?
>>454140 Можешь натянуть на экран сетку пространственной индексации, заполнять её кнопками которые попадают в ячейки сетки, делить координаты мыши на шаг сетки в пикселях и пробегать только по кнопкам, которые касаются ячейки в которой есть мышь. Это - быстрее всего для обработки, но чуть медленнее в загрузке.
Посоны, немного тупой вопрос. Я копаюсь под капотом у love2djam2018 и скачал например gift. Разархивировал love файл, а там main.lua, который моим сублимом открывается чисто как hex. Но екзешником love2d съедается как миленький. Может кто-нибудь предположить что это за метод сокрытия информации? Decode в другую кодировку не помог. File signature 1b4c 4a01 02 нигде не нахожу.
>>487573 Луа-код можно компилить в байткод, это нормально. И любая луа-машина (в т.ч. love2d) будет с ней работать. Правда, у разных версий lua разный байткод, поэтому версии 5.1 и 5.3, например, несовместимы.
В love2d используется luajit, и байткод соответствующий.
>>540776 >пусть сделает 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 Подозреваю, решил упростить математическое преобразование в гамме для платформы в целом. Чтобы работа пользовательских шейдеров была быстрее.
>>540822 >сознательно избавляются от глючно работающего кода Глючно работающий код? Да ты теоретик!
Там просто функция window внезапно меняется на screen drawq - сделали в следующей версии ее уже нет, но вы можете просто убрать букву q и все заработает!
Нахрена??? Сокращение кода, оптимизация бла бла бла. Сделайте так что внутри черной коробки drawq была равна draw, раз ввели в предыдущих версиях.
>>540822 > что 11.1.2 и 11.1.1 имеют между собой общего 99 процентов кода и естественно они будут почти соместимы, а версия лоадера скажем 12.1 и программы 9.1.2 могут иметь еще раз ты теоретик!
Почему тогда он с 0.10.2 версии скакнул до 11.0 ? Это вообще охуенные изменения?
>>540918 Между draw и drawq чуть больше изменений, чем просто буква. Нахера тащить легаси код, если так захотел какой-то васян? Проект можно допилить и на старой версии, если сильно надо, просто через какие-то костыли будет. Синтаксис уточняется, унифицируется, становится более красивым, а старое и некрасивое нет смысла тащить. Если сильно приспичит, можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
>>540933 >можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде. Да именно это я и сделал, а тысячи новичков забили на это и пошли пилить свои игры в другие платформы. Почему рубится сук на котором сидят? Из за изменения с цветом не совместимы игры написанные <0.10 и >11.0 Этож сплошное отпугивание новичков, я взял прример и у меня ничего не работает.
>>540943 Когда-то все равно придется исправлять ошибки прошлого. Сначала посчитали, что удобно будет 0..255 использовать, и это в принципе привычно. Но потом, видимо, стали чаще использовать фичи опенгла и шейдеров, а там удобнее 0,0..1,0. Относительно недавно еще какие-то фичи для более легкого 3д подвезли. То что туторы на официальном сайте не апдейтят, это плохо, хотя документация там топовая. Да и уроки посвежее и более полные есть от юзеров, на хабре или еще где-то можно найти.
Отдельного треда по box2d я как-то не нашел. Поэтому спрошу прямо здесь: Я с физикой как-то никогда не работал, поэтому на box2d смотрю как на черта в табакерке. Сейчас появилось желание сделать вернее идиотская привычка проводить новогодние вечера делая никому ненужную херню для себя небольшую игру, с физикой: А именно лабиринт по которому нужно будет катать шарик. То есть шарик должен отскакивать от стенок, катиться по инерции, расталкивать препятствия и прочие Но ещё на стадии прикидки в голове и чтения мануалов я понял одну вещь: У меня будет довольно большой и сложный лабиринт, и все его части должны быть физическими препятствиями. Логично сделать каждый "тайл" отдельным прямоугольным физическим объектом - но очевидно что их будет дохуя. И собственно вопрос - как можно сделать в box2d объект сложным по структуре но при этом считающим одним объектом при расчётах?
>>542187 Сотню статических боксов он должен легко сожрать, тем более что динамический будет только один объект. То что ты объединишь множество боксов в один полигон выигрыша не даст. Сложный объект сложнее проверять на столкновение.
>>542190 Будут еще динамические препядствия но не много. Даже если сотню сожрёт без проблем, я сам перфекционист и не люблю пустой траты ресурсов. Пока придумал что на этапе генерации лабиринта собирать соседние "клетки" в более большие прямоугольники и создавать физические обьекты только для них уже. Но сделать алгоритм нормальным не получаеться.
Вопрос уроня - идиот: Сам фресворк поддерживает оптимизацию отрисовки того что не попадает в текущий кадр. Или при прорисовки объекта нужно сначала самому проверять его фактическую видимость?
>>540930 Потому что в обновке много изменений и сильная несовместимость с предыдущей версией. Первая цифра означает мажорный релиз, вторая - багфиксы. 10.0 => 11.0 => 11.1 => 11.2. Оно не сразу скакало, очевидно были промежуточные.
>>540943 Есть polyamory (https://github.com/megagrump/polyamory) Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
>>542305 Сам запилишь. По мне, эффективной методикой является использование чего-то вроде регулярной сетки, в которой располагаются объектики. На гифке, например, я использовал библиотеку hardon collider для коллизии, и оттуда же - регулярную сетку. Из неё вырезается некоторая область (список объектов по AABB), и рендерится. Соответственно, объектов может быть сколько угодно, не попавшие в экран мы даже не проверяем.
Если у тебя ну прям до жопы одинаковых объектов, то уже эффективнее пихать в батчи и рисовать сразу всё через батч (например, вытаскивать объекты из большой области и пихать в батч). Развлекалова много, в общем.
>>542513 >Есть polyamory (https://github.com/megagrump/polyamory) >Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
Есть, не боюсь. Но вот вопрос, если сторонние умельцы делают ланчер для запуска всего множества версий, то это востребовано?
Так почему бы создателям, не сделать единый экзешник для всего подмножества версий 0.0.1 - 0.10.2 и так уж и быть если прям нереально еще один 11.0-15.0. (а лучше love2d.exe вообще для всех)? Версию сами просили в conf.lua записывать, какие команды на что меняли тоже знают.
>>542706 Ты предлагаешь им запаковать все версии love в одну? Ты бы ещё предложил запихнуть все версии какого-нибудь дистра линукса в один дистр, или все-все версии питона в один питон.
>>544376 Гы? Че там запоковывать то? Там всего то надо принимать команды в двух - трех форматах, запоковать внутренние приравнивания что screen = windows если что, drawq = draw и так далее. +1000-30000 байт смотря сколько раз они команды меняли безосновательно.
>>537039 >button = 1 или 2 было хуево, стало пиздато. С интежерами поди по-проще будет, чем бесполезные где button ='l' или 'r' кстати а mousewheel нажатие там обрабатывается?
и вообще чего доебался. Найди хоть один более-менее популярный продукт, где бы не менялся API.
>>490081 этот самый байт код можно "дизассемблировать" до удобочитаемого и понятного lua, т.е. реально использовать для соркытия СУПИРСИКРЕТНАГО кода игры? Вообще что юзают перед тем как выкладывать в тот же стим, какие-нибудь обфускация кода с добавлением кучи воды и бесполезных функция с переменными, чтобы запутать? Или всем просто похуй?
>>545615 я смотрел, популярные офусцируют. А вот на ресурсе где дайте 2$ или просто скачайте, и где переодическит и с кодом выкладывают, не обфусцируют.
я попробовал свой тестовый гейм оф лайф запустить на мобилочке, результат как бы немного разочировал, все эти банчи-хуянчи оно обрабатывало медленее чем на древнем сабноуте. Но, если все в пределах экрана, то 60 фпс на изичах.
Правда чому-то офицальной любви 11.2 даже нет в планах, 11.1 приходится ставить руками без маркета. Чувстую придется свою собирать и ебаться с манифестами и плейсторе.
>>551452 зойчем ты мне показал скрин с кудахтера, писечка именно в сборке под ондроед. А make install я и на фришечке осилил. >>551469 в стиме как минимум пара релизнутых, но там все совсем простые.
я же хотеть делать рпгешечки/хиросы под ондроед без донатов и банеов. Бесплатная демка и платная фулл за бакс.
Алсо обратил внимание как в плейсторе донатопораша пытается пролезть в топ. Делают донатопорашу и ставят ей минимальную цену, потом делают скидку в 100% и вуаля - ты в топах премиум игр по скидке.
>>551501 >зойчем ну вот тоже руками ПОД СЕБЯ, а не из бинарного пакета, это же лёвы тред. а под ондроед .apk небось проще сбилдить даже из линупса и фришки, тока сдк/ндк доставить
>>551549 ну опять же имеет смысл только при распространении линупс/макос версии. Для шинды достаточно прикрепить лов файл в конец стандартного екзешника.
к этому можно еще запилить мультик на вебсокетах вебморду логин/пасс + база юзеров, их ачивок, статистика онлаен и т.п. типа свой стим, лал >Publishing as a HTML5 or JavaScript game is possible
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д, довольно простые квесты и локации. ЛЕВИЛДИЗИГН уровня кирилла. Разве что стори неплохая и текст самих квестов.
>>551582 >читай я не читал пока, увидел легаси и решил посмотреть позже, все равно при ~200kbps эти сдк/ндк тянуть неохота и свежих доков нет вроде, внизу там висит линк на типа апдейт, но я и его не читал а вот рпгешки помню прикольные на j2me под нокию были, причем брендовые, мож даже от близзардов. там нужно было в локациях выполнять квесты, гулять по глобалу и пиздить нпц. экономику вот только вроде не завозили туда. а жаль. единственно именно экономическим был клон серии Anno или Port Royale, но тоже поверхностно и тема была не раскрыта и вообще не рпг, а тайкун кокойто
>>551596 из тайги капчую. ну почти: паблик вайфай хотспот с плавающим сигналом, который иногда вообще теряется.
игрухи то да, код смотреть не запрещают же, ну или не все, но вот захочется например шейдоры задрочить, а в новой версии двигла у них например синтаксис сломан. я штото переписывал шейдорное с 8 на 9ку вроде, так после этого ни с кем неделю не разговаривал. причем и в документации никуя об этом не было
Тестю bump. Очень крутая штука, если хорошо организовать проект. Никаких лишних коллизий, объекты ровно без реакции пролезают в дырки, размером ровно с эти объекты, очень круто. Ну, и все объекты являются "пулями", при попытке перемещения, быстродвижущиеся снаряды не пролетают.
>>305497 (OP) Думаю, куда бы перекатиться с геймейкера. Устал в первую очередь от его ебучего языка gml, в котором нельзя даже создать свою структуру данных. Ну и в целом хочется выйти на более ненубский уровень, чтобы движок не определял за меня архитектуру игры. Так вот, как говорят в годот треде, почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец?
love2d - это, если быть точным, обертка над sdl+opengl.
sdl и прочие - это низкоуровневые графические библиотеки, единственной высокоуровневой фичей которых является абстракция платформо-OS-зависимых API.
инструменты и сущности высокого порядка тебе придется велосипедить самому.
Если ты не демосценер/любитель подрочить байты ради собственного удовлетворения или просто хочешь научится в низкоуровневое дрочерство/не программист крупной игровой студии, а хочешь просто делать игори - то выбираемое тобой направление сомнительно - ты 90% всего времени потратишь на велосипединг кривых велосипедов и их отладку. Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун. И только после этого ты сможешь заниматься непосредственно игрой, в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи и ты раз за разом будешь срываться с написания геймплейной логики в написание фич двигуна, а твоему мозгу будет все сложнее и сложнее держать всё это в голове одновременно и работать в таком ритме.
В крупных студиях такой проблемы нет - у них есть четкое понимание зачем им велосипеды, какой профит (более лучший графоний c инновационными техниками и номинации за графон на ежегодной VGA, инструменты для разработчиков в рамках заданной концепции игры, успешная борбьба с собственной соснульной платформой) они с них получат, четкий план как и чего они пилят, большая команда разработчиков, разделение разработки по командам, допилка фич в соответствии с планом и.т.д.
>>554572 > почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец? У всех свои особенности. love2d - он на lua, и в этом его прикол. sdl - на чистом си, а sfml - на c++, и он объекто-ориентирован. Allegro, ClanLib, HGE и подобные - на с++, и как я понимаю, и них более богатый функционал, т.е. больше полезных фич для геймдева из коробки можно найти. Какой язык ближе - такой и выбирай. Дополнительный функционал, на самом деле, не обязательно самому писать, можно найти другие сторонние библиотеки, их куча в опенсорсе.
>>554621 >Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун. По моему скромному опыту могу несколько вещей добавить. Во-первых, какие-то сложные вещи можно найти в инете. Если тайловая игра, можно присобачить Tiled. Хотя для не-тайловых хз, есть ли подобное. Во-вторых, не обязательно вообще сложно писать. Можно максимально упрощать, делать только необходимое - это ключ к успеху. Только при надобности - делать более абстрактно, расширяя функционал и рефакторя код. В-третьих, первый проект да, можно дохуя всего с нуля написать. Но если будешь более-менее аккуратно писать, то наберется парочка полезных собственных либ, которые можно потом переиспользовать.
Это все очень интересно и дает много опыта. Но с практической точки зрения - я хз как на это будут смотреть потенциальные работодатели, которые 90% используют юнити под мобилки. Адекватные наверное оценят опыт, но хорошее знание нужного им инструмента это не заменит полностью.
>>554621 >инструменты и сущности высокого порядка тебе придется велосипедить самому.
Ты так говоришь как что-то плохое. В любом случае придется тратить время либо на велосипеды, либо на изучение юнити-хуюнити. Но вот с последним ты можешь упереться в непреодолимую стену ограничений. А так тебе полная свобода сделать свое говно. Я так это вижу.
Ну и упоминание крупных студий тут совсем не к месту. Любовь как бы занимает совершенно другую нишу. Это для одиночек или пары человек, которые могут в кодинг, но не хотят мышевозить в юнитях и гейммейкерах.
>в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи В моем случае пердак уже давно подготовлен, я не питаю иллюзий и просто сделаю максимально просто. Тут есть другой момент, в отличие от юнитей, мне не надо изучать инструмент, тот же реадктор что ты упомянул, по-сути можно сразу ваять свой ААА ШИДЕВР. А самое главное есть отличные примеры на чем можно поучиться, а то и откровенно спиздить - Don't starve, ToME4 и тп. Кстати, читая исходнки DS я ПОНИЛ как именно там реализуется анимация, со всеми этими стейтграфами, как реализован AI, как вообще все правильно ЗДЕЛОТЬ. С префабами и поэтэссами.
>>554636 Вот это манямир. Юнити больше 10 лет в разработке. Конечно же, это только плюс, что нужно все самому делать, ведь у тебя есть 10+ лет чтобы сделать движок
>>554621 >Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей Проблема то в том, что со временем понимаешь, что стандартные фичи гамака не очень нужны (а их кстати не так уж и много). Физику сам рассчитываю, столкновения сам считаю, поиск пути свой писать приходится, даже спрайты для некоторых нужд приходится в ручном режиме анимировать, а не в стандартном автоматическом, редактор уровней неудобный. В итоге от гамака нужна только возможность рисовать спрайты на экране. А вот при попытке что-то навелосипедить натыкаешься на внутренние ограничения движка.
>>554648 Чтобы сделать игру, не нужно 10 лет тратить на движок. За пол года, если без сильных выебонов, можно сделать норм игрушку практически с нуля. Люди за сутки или за неделю без юнитей пилят годные прототипы игр на джемах. Остальное время уходит на допиливание, контент и прочее.
>>554635 >Какой язык ближе - такой и выбирай. Мне никакой из этих языков не ближе. Важнее, чтобы движок не был заброшен и стабильно работал. Я так понимаю sdl тут лидирует.
>>554648 Простой вопрос - чому Klei такие идиоты и не зделоли все на юнити?
Асло, юнити для меня - синоним тормозов, быстрой растраты батарейки на мобиле. А вот внезапно нечто на самописном движке работает бодрячком (рпгшечка).
>>554658 Все, которые на слуху, так или иначе разрабатываются и достаточно стабильно работают. Попробуй посмотреть туториалы по каждому, как запиливается какая-нибудь простая игра, глянь код, выбери более приемлемый для тебя вариант по синтаксису/апи.
Время разработки складывается из времени написания движка, времени создания редакторов и время создания контента.
Ты можешь, например, взять кривой tiled, и времени на создание в нем контента ты убьешь в разы больше, чем если ты будешь делать тайловые карты в юнити. Тебе будет нехватать возможностей tiled, и ты будешь писать костыли, и еще больше затягивать разработку.
>>554663 >Klei >2013 неголодайка на крестах и луа >2014 Invisible на чужом фреймворке с крестами и луа >2018 HOT Lava на UE4 с крестами. В процессе движок апгрейдится до Юнити >2017 Oxygen Not Included на юнити. Без крестов и луа.
>>554679 Заметь, что кроме DS - все шлак и вроде как без модов. А именно на них держится его популярность. Как там с модами под юнити, бтв?
Алсо DS и DST - это своего рода TES у беседки или ФИФА у ЕА, которую доить можно еще долго. DLC выпускают каждые два года и их всегда раскупают. У меня большие сомнения, что юнити поделия обладают такой же кустомабельностью. Под DS вон даже DnD запилили. Там вообще по-сути конструктор, ваяй что хочешь.
>>554771 >хотя еще далеко Так неголодайка и вышла пораньше. Ну и покупается лучше, всё-таки 40 рублей это не 250. >превед конпеляция и лишь под венду Ну во-первых, платформа-то одна. На линупсах в эти ваши игры не играют. А во-вторых, игровой код в открытом виде, ilSpy в руки и погнал пилить под себя. Да и нахуя Клей давать тебе модкит уровня беседковского такой же глючный, но дающий дофига контроля если они сами по себе пилят "моды" ради подъёма продаж. Но мы уже уходим в строну, что хотел я уже сказал.
>>554621 >love2d - это, если быть точным, обертка над sdl+opengl. Объясни подробнее, разве sdl в свою очередь не обертка над opengl и directx, чтобы самому в эти апи не лезть? Зачем love2d в opengl лезет?
>>554838 Шейдеры, например, в любом случае пишутся на glsl. Плюс кусочек оптимизаций вывода графена. SDL - не всеобъемлющая обёртка над графикой, хотя там и много всего полустандартного.
>>571468 а насколько там важные отличия? порта на ведроид скорее всего не будет в ближайшем будущем вот и думал чтоб все на одной 11.1 базе делать свои ААА прожекты.
>>573721 Юнити потребует бабло за комерч. исп. На юнити особо не повелосипедишь, юзай что дают и не выебывайся. А на луа я могу хоть по сети передать все - от текстурки до полного префаба очередного монстрика со своими стайтграфами, мозгами и прочим.
В общем не мешай тут кирилить, пили очередной раннер, платформир и прочее тормозное говно для мобил.
>>573724 Да вы только на словах львы толстые, а на деле хуи велосипедные. Пока очередной костыль пилите весь ваш настрой улетучивается. На ваших говнодвижках вообще игр нету, балаболки пиздливые.
>>305497 (OP) Имеет ли смысл писать все велосипеды и прочее на C/SDL или сразу переходить на LOVE? Сильно ли последний сжирает лишних ресурсов? Единственная ссылка по теме ведёт на давно закрытый форум
>>599824 Если собираешься пилить 2д, то хватит за глаза. Да и 3д есть возможность сделать, и скорее всего успешно, если пилить по уму. Луа на самом деле не такой уж жирный (не зря ж его во встраиваемых системаю юзают и как скриптовый язык часто). А какие-то критичные части можно перевести на плюсы (FFI). С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними. Короче лёв скорее для энтузиастов. Если нравится луа+лёв и есть желание повозиться, то не вижу проблем.
>>599828 >Луа на самом деле не такой уж жирный проблема луа в отсутствии низкоуровневых типов данных. любой мало-мальски сложный алгоритм будет нещадно тормозить из-за таблиц.
>>599828 >С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними. Любительские поделки, которые не обновлялись годами. Я бы на это серьезно не рассчитывал при создании игры, так как будет не очень приятно в конце разработки обнаружить какую-нибудь ошибку при использовании порта
>>599831 Таблицы в целом довольно оптимизированы, даже если будут дырки в массиве. Для числовой индексации там обычный массив используется, для доступа по ключу - хэш-таблица, там особо нечему тормозить если совсем жирно не растрачиваться на использование памяти. Есть некоторые фишки, которые стоит учитывать для оптимального кода https://www.lua.org/gems/sample.pdf http://lua-users.org/wiki/OptimisationCodingTips Можно подрубить FFI и на Сях запилить какую тебе угодно plain old data структуру. >>599832 Тут да, гарантий никаких. Если хочешь беззаботно покорять мир своей поделкой на всех возможных устройствах, то скорее надо смотреть в сторону чего-то более весомого.
>>599824 С/С++ и SDL2 - это уже почти стандарт в гейдеве, та что все равно пригодиться использовать ли Love - это уже зависит от проекта: 2d игры на компы и андроиды, несложные графические навороты.. если похоже на требуемое, то можно брать сам lua мало тормозить работоспособность проекта, все же самый быстрый скриптовый язык, поэтому его и используют в большинстве игр в том или ином виде
>>601415 Не совсем. К геймплею относятся общие компоненты и алгоритмы. Контроллер персонажа, инвентарь, логика скиллов, заклинаний, поиск пути и т.д.
А скрипты это скорее конкретные сценарии поведения для разных объектов. Активировать дверь при нажатии кнопнки с определенным ID, показать диалог с конкретными NPC. Задать NPC какое-то поведения для определенного квеста. Такие мелкие поведения очень удобно писать в скриптах, и очень неудобно писать в нормально геймплейном C++ коде.
>>601430 То есть скрипт это как правило небольшой, одноразовый кусок кода, который используется только в одном месте игры и больше не используется нигде. Поэтому так легко писать такой код на высокоуровневых скриптах: просто когда тебе нужно новое поведение, то создаешь новый скрипт и все. В С++ либо хардкодить это все нужно, либо пытаться параметризировать все в какой-то общий для всех объектов компонент.
>>601430 Инвентарь, поиск пути и прочее - это не геймплей, а скорее движковые фичи. Их да, имеет смысл на языке самого движка делать. Все остальное - нормально реализуется в скриптах. Проблема скриптов на с++ не в том, что неудобно писать, а в том, что надо перекомпилировать код при любых изменениях, и это довольно затяжное дело в больших проектах.
>>601590 >что надо перекомпилировать код при любых изменениях Сразу видно человека, никогда не писавшего на плюсах. Перекомпилируется только отдельный измененный объектный файл, т.е. если у тебя 100 cpp файлов и ты меняешь один, компилируется только один измененный, и это проходит быстро. Вот если ты меняешь заголовок, который подключен в 100 файлах, тогда будет печаль, но на практике такое редко бывает, т.к. один заголовочник в 100 файлах это признак говнокода.
>>601595 Это очевидно. Но плюсы все равно не так быстро компилятся, зависит же еще от самого кода в файле. Я к тому, что подхватить на лету скриптовый файлик проще, особенно если это нужно делать не программеру.
>>601411 И для того и для того, не только как конфигурационные файлы, но и более крупные куски геймплея: minetest, dst.. тысячи их. >>601430 Ну приблизительно так, только игра не всегда проектируется как монолитный проект, поэтому в скрипты еще уходит та логика, которая может быть модифицирована игроками и мододелами. >>601590 Нет, так поступают по другим причинам. Данные выкидывают в скрипты в проектам, потому что часто ядром геймплейной логики, которая пишется на плюсах, занимается одни кодеры, а сам контент с его тонким поведением описывают другие кодеры или вообще те, кто далековат от программирования.
>>599826 ондроед есть (нестандартная репа) шинда есть линупс с фрибсд есть про гейос только неуверен, да и хуй с ней. С ней даже стим не особо заморачивается.
Ананасы, раньше кодил немного на луа (делал аддоны и всякие скрипты для варкрафта). Потом как-то забросил это дело, а некоторое время назад занялся играми и написал несколько на с++ и sfml. Здорово, конечно, но всё это делалось довольно не быстро. Недавно попробовал луа снова (не для игр), оказалось очень здорово и быстро. Так вот, с чего начать разбираться в love2d?
>>615734 Скорость разработки с лёвом - неоднозначный вопрос. Хотя сейчас все больше библиотек появляется, в чем-то становится попроще. Начинай с вики, она очень годная. Там же и список известных либ можно найти. Какие-то вещи можно на форуме найти. Если сам кумекаешь нормально, то этого хватит. А так, на хабре и на ютубчике еще можно найти серию уроков на русском
>>615734 С вики, плюс на ютубе можешь найти приличное количество туториалов. Не советую замахиваться на что-то сложное, начни с крестиков-ноликов, змеек и понгов.
Нужно хоть расшевелить и поднять наш тред, а то что мы. Кто какие библиотеки использует в проектах и почему? Или может чем-то не зашли и писали свое намного лучше? Animation: anim8, Walt ... Localization: utf8, i18n ... ECS: concord, knife, nata, tiny-ecs ...
>>645730 Один проект полностью на своем, в т.ч. ECS , физон и небольшая GUI либа, потому что ебанутый. На самом деле очень тяжело каждую систему самостоятельно пилить. Другой проект решил заюзать готовые решения, для GUI - SUIT, ибо заебался. От того же автора собираюсь для твининга hump.timer использовать. SUIT своеобразный довольно, и достаточно лоу-левельный, приходится все равно свои надстройки придумывать. Но среди всего это, наверное, самый простой варик, чтобы сел и поехал. Есть imgui и nuklear, но их еще компилить надо.
Да, с gui сложно определяться. Особенно когда мультиплатформу надо и пытаешься сдружить какой-нибудь imgui под андроид.
>Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д. >https://github.com/love2d-community/awesome-love2d Эту подборку как раз недавно потыкал почти всю. И оказалось, что ей новичков только пугать. Там почти все либо устаревшее либо гораздо хуже альтернатив, которые там даже не представлены. Надо тоже какую-то такую подборку сделать, только в каждом пункте по несколько вариантов с пояснениями для этих самых новичков, что вот берите это если надо это или берите то - если то.
>>645752 Тот списочек вроде как даже обновляется. Только видимо устаревшие линки никто не хочет убирать. Что сам юзаешь? Что пилишь? Как сейчас с компиляцией под андроид? Сильно надо надрываться, чтобы адекватно работало?
>>645759 Нет, под андроид сейчас довольно удобно, все есть даже для последней актуальной версии ловки. Юзаю обычно из несамописного только i18n и imgui. Но тоже хочется каких-то уже готовых стандартных библиотек, принятых и поддержиаемых сообществом. Для игр так вообще вроде есть ряд основных задач, которые хорошо было бы прямо в сам движок уже изначально встроить, те же состояния. А то пишут все зоопарк кода, потом выкладывают просто так, потом новички лезут и путаются. Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
>>645762 Лёв изначально как биндинг над SDL задумывался, так что вряд ли в него будут игроспецифичные вещи добавлять. Так-то вообще можно конструктор на ловке запилить. И уже были какие-то попытки, например Grid https://love2d.org/forums/viewtopic.php?f=5&t=80115 Вообще есть мысли под ECS намутить какой-то просмотрщик-редактор, чтобы можно было сущности проектировать, смотреть какие компоненты с данными есть, автоматически генерить системы с нужной оболочкой и просто писать в них поведение. >Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное. Круто. Я свои поделки все никак не доведу до нормального состояния. Хотелось бы в стим как-нибудь релизнуться. Но на горизонте событий этого пока не предвидится.
Поясните про терминологию ECS: вот есть компонент, например, позиция в пространстве (условно мечника) сущность - это уже созданный экземпляр (один из 10 мечников в игре) или это как некий класс этот мечник, а экземпляры называются другим словом? Вроде везде создают что-то типа World, куда пихают сущности уже как экземпляры.
>>645793 В ЕЦС сущность - это то, под чем объединяется набор компонентов. Набор компонентов не фиксированный, поэтому условный мечник может стать условным лучником, если удалить/добавить какие-то компоненты. С одной стороны сущность - это абстракция в ЕЦС подходе, типа в игре есть игровые сущности, они все разные, но механизм один и тот же (т.е. что-то типа класса, но на самом деле его нет явно). С другой стороны сущность - это уже айдишник в каком-то конкретном менеджере ЕЦС, к которому как раз привязываются компоненты, и тут оно ближе к экземпляру.
>>645795 Ну т.е. сущность - это все же уже созданный экземпляр некого "объекта"? Ну вот в игре допустим в каком-то файлике хранится "name = волк, hp = 100", а в другом "name = злой волк, hp = 150" Под это дело есть компоненты. Конкретный экземпляр волка из первого файлика - это и будет Сущность по ECS? Т.е. уже конкретный волк где-то в мире с конкретными жизнями, который был заспавнен со 100 hp.
Знаю что спрашиваю не там, но кто нибудь знает какой программой можно рисовать полигонами (желательно что бы можно было их потом разукрасить) Векторные редакторы так могут? Вот картинка по типу этого
Хотелось бы сделать такую графику в своём love2d проекте, и желательно так что бы при зуме не пропадало качество. Было бы ещё лучше если бы картинка такого формата была бы просто набором координат как obj форматы, но забейте про это, я потом может что то своё такое напишу. Сейчас просто прошу помочь найти программу которая может подобное
>>647222 Тебе нужен векторный редактор. Вообще вроде от адоби лучший, но я очень люблю аниме студию, она проще и быстрее гораздо делать, но функций меньше, что-то суперсложное не сделаешь. Но такую бошку запросто.
Вечер добрый. Можно ли на лёве реализовать простенький мультиплеер, шобработало? Или это херня идея? Уровень функционала, который я хочу от этого: не более шести игроков, пошаг, геймплей неторопливый, но динамичный, на уровне карточных игор. Просто люблю Луа, посему выбор у меня невелик - лёва, всякие короны там и крафтстудио.
Сделал почти 3д проекцию в love2d но есть проблема с полигонами, некоторые полигоны отрисовываются на других из-за чего происходит странная непонятная хрень, есть ли способ сортировать по переменной в таблице? table.sort сортирует только если значение число а не таблица, по сути это bubble sort
Мне подойдёт даже пример с сортировкой 2д спрайтов по координатам (есть ведь алгоритмы где рисуют слева направо сверху вниз)
>>653010 Погуглил за тебя Можно кастомный компаратор написать 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)) Или вообще свою сортировку какую хочешь, хотя в луа квиксорт используется.
>>305852 Мас. Рэндом, лол А що будет если звезды сойдутся и будет два одинаковых номера? Асло библиотеку классов давным-давно навасянили и без этого велосипеда.
куда надо пихать игру, когда собираешь по андроид? вроде указано, что в app/src/assets, создал, кидаю туда и все равно запускает дефолтное окошечко с шариком
>>653010 Тут проблема для z-буфера, причём она глубже чем кажется: для такого программного рендеринга, нужно из треугольника выпиливать видимую часть (многоугольник, не пересекающийся с другими полигонами более переднего плана), и рендерить уже его.
Прикреплённая картинка - это rarjpeg с Настоящим Хардварным 3d на ловке, переименуй в .love и чекни.
>>659174 Уточнение: тут же простейший пример хардварной трёхмерной графики через шейдер: 1. Два канваса: рендертаржет + Z-буфер 2. Слегка модифицированные меши, с координатами точек по Z-оси, 3. Кастомный шейдер, который принимает матрицы view (камера) и model (матрица модельки)
>>659174 Если будут вопросы по распаковке - из rarjpeg'а достаточно отпилить часть с картинкой (см пик), и можно открывать как zip-архив с исходным кодом.
>>659848 А в чем там проблема-то, немного переписать рендер под 3D. А так ловка это же тонкая прослойка над SDL2, так что вообще ограничений особо никаких.
>>661962 Дополню: плюс в 11 версии добавили кучу трёхмерных фишек опенгла, вроде того же z-буфера нормального, и возможности нормально кастомить меши в произвольные массивы данных на видеокарте: запилить модель + цвета вершин + кости + шейдеры по отношению к конкретным костям - как нехуй делать.
Памахите научится в z-буферАноним10/09/20 Чтв 06:05:16#415№697969
Тут сверху есть пару слов об этом, но я тупой и нихера не понял. Мой 3д проект который я хочу сделать тупо стоит на месте как раз из-за того что я не умею в глубину, сортирую полигоны по расстоянию, но это затратно. Вроде как уже и больше понимать стал, пытаюсь просто нарисовать 2 меша треугольника так что бы было видно что буфер глубины работает, но сколько я видосов не смотрел я всё равно нихуя не понимаю + тут як понял именно на шейдере всё можно сделать, как в OpenGL ( смотрел в видосах ), но повторюсь что я нихуя не пойму. Может я и сам когда нибудь всё выясню но хотелось бы ускорить этот прогресс, т.к. сейчас зависаю в месте без интернета и от скуки делаю всякую парашу в ловке (на андроиде, гыг) СПАСИТЕ МЕНЯ и простите за всю хуйню которую я ща написал, два дня не спал мозг не работает
>>697969 Самое главное забыл - хотелось бы избежать использование сторонних/чужих библиотек, ибо хочу именно всё сам делать научится, так сказать склад велосипедов пополнить
Луа-куны, нытик-кун вернулся. Глядите, чо нашел. Это ведь почти лёв2д, но с функционалом среды разработки и всяких плюшек! Плюс обещают много чего искаропки. https://store.steampowered.com/app/1386180/Bitty_Engine/ Меня смущает цена. Позволить-то себе могу, хуле. Сэкономлю на завтракахбензине разобью свинью-копилку. Вопрос 1) взлетить ли и не забьет ли разраб 2) буду ли пилить игоры, а то ляжет ненужным грузом, как RPGmaker на аккаунте. Но это скорее вопросы для самокопания. Я сюда не спрашивать пришел, а поныть сообщить, что в кои-то веки кто-то делает ДВИЖОК с луашечкой.
>>716726 Купил это чудо. Пока мне действительно нравится. Нечто среднее между love2d и юнети. Триде вроде не завезли, но мне оно особо не надо пока. В отличие от юнети ничего лишнего и lua искаропки.
>>717287 >Оставил тебе (и всем луа-кунам) пост в срачетреде юнетикам пора уяснить, что луа-куны принципиально в писькомерстве не участвуют, ибо взрослые и обеспеченные люди, не нуждающиеся в самоутверждении
Сижу в данный момент на некро нетбуке win7-32 При запуске даже просто love.exe (да, качаю 32-битную) получаю ошибку пикрил. Аналогично на 10 версии. 9 работает, т.к. она еще была без ентих ваших джиэлей. В системных требованиях ловки gl 2.1+, на этом ноуте gl 3.0 Куда еще потыкаться?
>>718116 Ну в целом как бы драйверы, но возможно, придётся накатать какой-нибудь шейдер а ля local shader = love.graphics.newShader[[ #pragma language glsl1 #ifdef VERTEX vec4 position( mat4 transform_projection, vec4 vertex_position ) { return transform_projection vertex_position; } #endif
>>718310 шейдер не помог, собственно он валится уже на этапе, даже если просто движок запустить без проекта. Драйверы максимально возможные тут уже стоят. Ну видимо старше 9 ловки на этом некроноуте не побалуешься.
>>718315 Да при запуске без проекта, оно такое запускает проект "по умолчанию" с настройками по умолчанию же, который как раз рисует тебе экран no-game. Но опять таки похоже на дрова.
>>718374 МИНИМАЛЬНЫЕ: ОС: Windows 7/8/10 (32/64bit) (плюс есть под мак и лин) Процессор: 1.5GHz Оперативная память: 512 MB ОЗУ Видеокарта: Intel HD Место на диске: 150 MB Только не говори, что у тебя на нетбуке не взлетит
>>716890 Уже сделал, но у меня всё сводится к тому что я хреначу код до тех пор пока у меня не выйдет что то похожее на то что я хочу, а мне ещё парсер obj файлов писать, и много другого. Я бы хотел просто именно понять как это работает, что бы мне было с первого взгляда ясно что и куда пихать, а не что бы потом вспоминать что я сделал в прошлый раз что бы повторить, вместо того что мне нужно сделать в этот раз. Никаких чужих библиотек и строк кода я в своём коде не использую, разве что смотрю на них что бы понять как они работают, а всё своё пишу сам, ибо лучшее понимание приходит когда ты не только знаешь как это сделать, но и знаешь как это работает. БТВ рад что тред ожил
Что за хуйня у меня происходит при использовании шейдера с кастомной матрицей? Наверное я просто тупой.
Разве матрица допустим Представим у меня есть вектор 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 как у хлебушка
>>735522 Прочитал. Но именно о том о чём я написал там ни слова. Скачал библиотеку 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
Здраст. сорян что оффтоп, но вот я видел парочку симуляторов логики (логические вентили) И вот как бы такой вот вопрос, если я хочу сделать себе такой же симулятор, но у меня получается так что обновление схемы происходит каждый игровой тик, как мне сделать так что бы схема полностью обновлялась за один игровой тик? Просто если я сделаю цепь из 5 ворот то активировав первое она полностью активируется через 4 тика. Есть пара примеров. Garrys Mod с модом Wiremod (там есть logic gates) Scrap mechanic Digital Logic Sim от какого то ютубера NandGame В последних двух задержки либо нет либо она очень низкая, хотя вот в NandGame игра тебе говорит если ты замкнул схему, так что мне кажется что в DigitalLogicSim задержка есть но очень маленькая. Так же, если вдруг делать такую же симуляцию как в NandGame то как мне сделать проверку замыкания? Что бы не было бесконечного цикла
>>745385 Быстро фикс Сорян, в Garrys Mod с Wiremod на логических вентилях я тоже не заметил задержки, а она на Lua, вот и хочу узнать как я могу сделать свой симулятор без задержки
>>745385 Юзай алгоритмы на графах. Просто берешь и обходишь граф сети, включаешь то, что должно быть включено. Остальное отключено. При обходе помечаешь пройденные вершины, если наткнулся на уже пройденную - значит у тебя цикл. Обойти граф из пары десятков элементов ничего не стоит практически.
>>744673 Плюсы: - При изменении класса, все "объекты" под ним не меняются; - Чуть-чуть быстрее доступ (при редком дёргании методов); - Как бы можно делать "приватные поля". Минусы: - На каждый объект оверхед не только в виде таблички с данными, но и функциями, которые надо сгенерировать, поддерживать а потом выкинуть со смертью объекта; - При пакетной обработке кучи идентичных объектов не включается JIT, скорость исполнения падает в тысячи раз (касается только PC и android); - Невозможность организовать нормальных изменяемых общих полей всех объектов; - Лишняя визуальная вложенность кода.
Чем плох __index? Ты его не понимаешь? Чем плохи либы-генераторы классов?
>>745385 Удваиваю этого >>745392. Запоминаешь положение генераторов сигнала (какие-нибудь условные кнопки-рычаги), это твои начальные точки графов. Поиском в ширину проходишь по всем затронутым элементам, переключая их состояние в зависимости от сигналов, запоминая уже пройденные вершины как защита от циклов.
У элементов с несколькими входами, желательно обновлять их состояние за тик в зависимости от количества входов, максимум столько раз, сколько у них входов.
Да, в том же миникруфте не просто так сделана система перегорания элементов при слишком активном переключении.
Объясните, что за хуйня. В какой-то момент генерировал мир, процесс потреблял 400MB памяти, после этого все данные были записаны на диск из процесса все переменные были выкинуты, ради эксперимента запущен сборщик мусора в принудительном порядке. Итог сборщик мусора lua говорит, что потребляется около десяти мегабайт памяти (вообще там пустое окно, в которое выводиться статистика о памяти), а вот ОС говорит, что процесс LOVE всё ещё использует ~400MB памяти. Кто из них пиздит? Или lua не освобождает фактически, освобождённую память?
>>747946 Хуй знает, может у тебя какие-то еще текстурки куда-то были загружены, может файл какой-то был открыт, может ты си код вызывал и там что-нибудь не очистил. Луа наверное только свое считает, переменные, таблицы, функции и все такое.
>>747946 >ОС говорит, что процесс LOVE всё ещё использует ~400MB памяти Как именно она тебе это говорит? Может, это не реально используемая память, а просто зарезервированная под процесс? Я тоже со своими программами (на паскале) подобное наблюдаю: сначала раздуваются, а потом плюс-минус сохраняют состояние, лишь со временем медленно теряя объём (но сборщик мусора в паскале срабатывает мгновенно, дело не в нём, а в ОС).
Если любишь экспериментировать, попробуй создать и запустить отдельную программу, которая займёт собой максимум оперативной памяти. Только файл подкачки отключи. В какой-то момент винда начнёт сжимать в памяти всё что только можно сжать, и закрывать все лишние процессы, включая даже explorer.exe (рабочий стол может исчезнуть, просто открой explorer из командной строки). Вот в такой ситуации, по идее, у твоей игры должны отобрать все резервные ресурсы. Если игра "сжалась" в памяти - то всё в порядке. Если так и осталось висеть 400 МБ ни за что - то у тебя явно какая-то утечка.
Также попробуй повторно создать всё то, что у тебя заняло 400 МБ. Если утечки нет, то будет плюс-минус столько же, если утечка - будет около 800 МБ.
Если всё-таки утечка, нужно смотреть где выделяется память в куче (любые динамические структуры данных) и каждый раз принудительно её освобождать. Нельзя просто "выкинуть переменные", нужно сказать ОС, что тебе эта область памяти больше не нужна. Сборщик мусора должен делать это сам, но кто его знает как он устроен.
>>747946 ОС портит тебе лафу. Когда ты запрашиваешь память, ОС выделяет тебе под приложение кучу свободного места. Заберёт обратно когда-нибудь потом, когда потребуется и если потребуется.
>>748927 После долгого разбора выяснилось, что память выделяется (вот эти 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 вообще пустая. Я даже уже не знаю куда смотреть теперь.
>>751174 ОС может выделять память в зависимости от скорости её потребления. Например, ты разом запросил пол гига - и она выделяет лишний гиг, потому что ты сразу схомячил здоровый кусок. Или ты запрашиваешь те же пол гига маленькими кусочками растянуто, тогда лишний гиг не будет выделяться, или выделится но сильно меньше.
Мой персональный совет: не еби себе мозги всей этой чушью. Пока память не начала бесконтрольно расти не высвобождаясь - тебе похер на всё что там происходит. ОС тебя переиграет и уничтожит все попытки заткнуть фонтан выделяемой памяти, пока она есть, и это нормально и даже хорошо: память должна использоваться. Освобождать незанятое начнёт только когда памяти начнёт не хватать.
Бумп. Лованы, как успехи? Скоро уже скоро запилю свой ААА прожект на базе этого. Основная цель - ондроед, там где луаджит нормально не пашет в лове. Я буду успешен!
Ну охуеть, вчера только нашел сайт по love2d с последней активностью в 2016 году, теперь еще и это. Такими темпами может и могилу разраба вчерашней давности откопаю где-нибудь.
>>884896 А в чем сейчас профит использовать движки на скритпоязыках типа love2d или pygame, когда есть javascript? Работает в вебе, везде поддерживается, быстрый (среди скриптовых), оптимизированный.
>>885675 А че с того что он не новый? Я лишь отметил что в последнее время часто встречаю источники по этой теме с угасшей активностью. Иди умойся, "айсикью"шный.
И насколько вообще второй вариант корректен? Просто разницы в рабоет не обнаружил, но для чего тогда городят эти ":" или передачу self первым аргументом?
>>917747 > 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
>>917769 Через точку получается статик метод, обращение к M - обращение к классу, обращение к self - обращение к экземпляру класса, всё как в обычных языках.