Двач.hk не отвечает.
Вы видите копию треда, сохраненную 11 сентября в 14:25.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 11 сентября в 14:25.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1008 Кб, 1191x670Кроме меня и пары анонов пробовали лов2д. По мне так штука прикольная. Тут, кстати, можно не задумываться %о всякой хуйне% и сразу приступить к алгоритму самой игры. Нравится этот фреймворк, очень классный. Расскажите че написали то на нем, аноны!
>>305497 (OP)
Пилю изометрическую 2д рпг. Велосипедю свой физон и компонентную архитектуру.
Пилю изометрическую 2д рпг. Велосипедю свой физон и компонентную архитектуру.
>>305515
Я пилю просто вид сверху, а отображать буду просто с некоторыми преобразованиями (координата Y сжата в 2 раза, отрисовка определенных спрайтов на определенные углы поворота и прочее).
Я пилю просто вид сверху, а отображать буду просто с некоторыми преобразованиями (координата Y сжата в 2 раза, отрисовка определенных спрайтов на определенные углы поворота и прочее).
>>305518
Скинь потом заготовки, когда провалишься. Просто хочу сам разобраться, как это все в коде выглядит.
Имею ввиду, как на уровне архитектуры всё организуется, модули там и структура.
Я просто всё всегда во одном файле держу. Жутко неудобно, когда код достигает тысячи строк, уже просто сложно ориентироваться по нему становится.
Скинь потом заготовки, когда провалишься. Просто хочу сам разобраться, как это все в коде выглядит.
Имею ввиду, как на уровне архитектуры всё организуется, модули там и структура.
Я просто всё всегда во одном файле держу. Жутко неудобно, когда код достигает тысячи строк, уже просто сложно ориентироваться по нему становится.
>>305544
Нахуй пошел, пидор.
Я и так планировал выложить часть исходничков на форум лова.
>когда провалишься
Нахуй пошел, пидор.
Я и так планировал выложить часть исходничков на форум лова.
>>305544
Использовать 'require' внутренние убеждения не позволяют?
Использовать 'require' внутренние убеждения не позволяют?
59 Кб, 1145x733Ну, катаю на 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, получая прямой доступ: когда игрок выбирает сетевую игру, игра логинится в данной софтине, и с её помощью находятся новые игроки.
Такие дела.
Есть кучка прототипов с крайне хуёвой структурой, написанные б-г знает когда, после этого я застрял в тренировке на кошкак ака библиотечно-модульном состоянии.
Накатал кучу библиотек, от векторных на 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, получая прямой доступ: когда игрок выбирает сетевую игру, игра логинится в данной софтине, и с её помощью находятся новые игроки.
Такие дела.
59 Кб, 1145x733Ну, катаю на 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, получая прямой доступ: когда игрок выбирает сетевую игру, игра логинится в данной софтине, и с её помощью находятся новые игроки.
Такие дела.
Есть кучка прототипов с крайне хуёвой структурой, написанные б-г знает когда, после этого я застрял в тренировке на кошкак ака библиотечно-модульном состоянии.
Накатал кучу библиотек, от векторных на 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.
Нихуево так мутишь там. Где-то можно глянуть код всего этого, или лично для себя все делаешь?
У тебя, кстати, проверка IP не совсем правильная, она будет позволять делать номера > 255.
4,7 Мб, 300x205>>305832
Продолжение.
В целом, если ОП нуб, очень не советую ему лове. Тут реально нихуя нет, и всё приходится делать ручками.
С одной стороны, это идеально для маленьких игрушек, потому что не подгребается двести мегабайт лишних библиотек и прочего говна, плюс полная свобода. Во втором констракте, например, свободы нет от слова нихуя: только марио или спейс инвейдерс, только хардкор. Начинал с него, охуел от попыток хоть какой-то процедурной генерации.
С другой стороны, лове и не позиционирует себя как движок.
Это фреймворк. Набор функций, апишка для вызовов команд OpenGL/OpenAL/2dBOX и прочей херни.
И так и надо, не для слабаков чай строят.
Зато код легко портируется куда угодно без изменений (разве что на мобилки надо адаптировать шейдеры на GLSL ES), плюс скорость (FFI/Jit) даст фору яве и прочей хуйне.
Быстрее только C++, и то не каждый раз.
Продолжение.
В целом, если ОП нуб, очень не советую ему лове. Тут реально нихуя нет, и всё приходится делать ручками.
С одной стороны, это идеально для маленьких игрушек, потому что не подгребается двести мегабайт лишних библиотек и прочего говна, плюс полная свобода. Во втором констракте, например, свободы нет от слова нихуя: только марио или спейс инвейдерс, только хардкор. Начинал с него, охуел от попыток хоть какой-то процедурной генерации.
С другой стороны, лове и не позиционирует себя как движок.
Это фреймворк. Набор функций, апишка для вызовов команд OpenGL/OpenAL/2dBOX и прочей херни.
И так и надо, не для слабаков чай строят.
Зато код легко портируется куда угодно без изменений (разве что на мобилки надо адаптировать шейдеры на GLSL ES), плюс скорость (FFI/Jit) даст фору яве и прочей хуйне.
Быстрее только C++, и то не каждый раз.
>>305834
Есть проверки но позднее.
Мутю для себя, гитами не пользуюсь, только гугл-драйв для синхронизации/бекапов.
Могу покидать всякую фигню, плюс есть группка ВК https://vk.com/club61441078, в которой время от времени что-то появляется
Есть проверки но позднее.
Мутю для себя, гитами не пользуюсь, только гугл-драйв для синхронизации/бекапов.
Могу покидать всякую фигню, плюс есть группка ВК 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
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, потому что изучил новый паттерн - тут же хочется всё переписать. Я третий год непрерывно кодю, поэтому у меня приличный запас знаний, плюс оконченная математическая вышка, которая что-то да дала.
Так, ежели чо, могу помогать чем угодно, благо написана тонна говна, которую можно использовать где угодно, и накоплен приличный багаж инфы.
Да, игровые проекты.
Велосипедю для них же, ничто не просто так, всё для дела.
В данный момент, скооперирован с художником, пилим ведро-дрочильню. Образцы графона на пиках.
Тут в другом вопрос: насколько ты знаешь lua, love2d, FFI, JIT, паттерны проектирования, паттерны ООП, алгоритмы (типа коллизий/пространственной индексации), а так же линал, матстат и прочую хуету. Без этого, просто, нет большого смысла пилить что-то на love, потому что изучил новый паттерн - тут же хочется всё переписать. Я третий год непрерывно кодю, поэтому у меня приличный запас знаний, плюс оконченная математическая вышка, которая что-то да дала.
Так, ежели чо, могу помогать чем угодно, благо написана тонна говна, которую можно использовать где угодно, и накоплен приличный багаж инфы.
>>305844
Фикс.
В одиночку - есть смысл, за милую душу.
а годик сделать пяток змеек/тетрисов/астероидсов/понгов, залезть в сетевой код (Сетевая змейка, о да. Кстати, отличный старт),
попутно вызубрив ООП, основные паттерны, научившись в сишку и собственные подрубаемые dll-библиотеки с наборами функций для luastate.
>нет большого смысла СОВМЕСТНО пилить что-то на love
Фикс.
В одиночку - есть смысл, за милую душу.
а годик сделать пяток змеек/тетрисов/астероидсов/понгов, залезть в сетевой код (Сетевая змейка, о да. Кстати, отличный старт),
попутно вызубрив ООП, основные паттерны, научившись в сишку и собственные подрубаемые dll-библиотеки с наборами функций для luastate.
>>305844
Да, я согласен, что лов и луа не для новичков. Особенно учитывая, что классы в луа реализуются своеобразно.
У меня есть и опыт некоторый, и знания, и также тяга к знаниям, и желание раскуривать и запиливать что-то свое.
Недавно как раз коллизии на SAT написал для боксов с углом (делаю аркадную физику, пробовал бокс2д закостылить, но некоторые моменты мне не понравились). А сейчас в процессе запиливания Entity Component Systems.
Да, я согласен, что лов и луа не для новичков. Особенно учитывая, что классы в луа реализуются своеобразно.
У меня есть и опыт некоторый, и знания, и также тяга к знаниям, и желание раскуривать и запиливать что-то свое.
Недавно как раз коллизии на SAT написал для боксов с углом (делаю аркадную физику, пробовал бокс2д закостылить, но некоторые моменты мне не понравились). А сейчас в процессе запиливания Entity Component Systems.
156 Кб, 1280x720>>305849
Вай малаца.
На тему классов. Самая короткая либа классов с наследованием на пике. Моя. Любимая.
Мне просто лень подгребать файл с ООП на очередную крошечную прожку, предпочту скопипастить функцию. На совсем крошечные либы с полутором классов, на класс-таблицу просто вешается
setmetatable(class, {__call =
function(self, ...)
local o = {}
o.x, o.y = 10, 20
self.__index = self
return setmetatable(o, self)
end}),
этого достаточно для обычного ООП.
Не, это просто и можно не заострять внимание на специфичности ООП в lua.
Оно ничем особо не отличается от питонового/жаваскриптового.
Вай малаца.
На тему классов. Самая короткая либа классов с наследованием на пике. Моя. Любимая.
Мне просто лень подгребать файл с ООП на очередную крошечную прожку, предпочту скопипастить функцию. На совсем крошечные либы с полутором классов, на класс-таблицу просто вешается
setmetatable(class, {__call =
function(self, ...)
local o = {}
o.x, o.y = 10, 20
self.__index = self
return setmetatable(o, self)
end}),
этого достаточно для обычного ООП.
Не, это просто и можно не заострять внимание на специфичности ООП в lua.
Оно ничем особо не отличается от питонового/жаваскриптового.
https://github.com/love2d-community/awesome-love2d
тут есть и про структурирование и про всё остальное.
тут есть и про структурирование и про всё остальное.
>>305844
Только сейчас у меня в голове сработал триггер, что ты пилишь под мобилки на лов2д (я же правильно понял?)
Как оно вообще с производительностью и стабильностью? Андроид же вроде пока еще не "официально" разрабами поддерживается?
>ведро-дрочильню
Только сейчас у меня в голове сработал триггер, что ты пилишь под мобилки на лов2д (я же правильно понял?)
Как оно вообще с производительностью и стабильностью? Андроид же вроде пока еще не "официально" разрабами поддерживается?
Расскажите вообще в двух словах, что это и почему я должен посмотреть это, а не продолжать с безумным смехом ковыряться в Construct 2 с его драгндроп программированием
>>306089
love2d это мультимедийный фреймворк общего назначения, обёртка на lua для сишной sdl2 и некоторых других вещей. На нём можно написать что угодно вообще. Если к тому же знаешь сишечку, то можно дописывать себе модули на ней и втыкивать их в своё поделие без проблем вообще. В частности, полагаю, что к стимворксу там обращение можно запилить без всяких прокладок за 5 минут.
Но это не игровой движок по сути, чтобы в нём появились сцены, камеры, твининги и прочая хуета, можно взять, например, hump, который по сути дефолтный уже чисто игровой движок для love2d.
констракт2 это не про программирование, это про что-то другое, я так не умею, мне проще кодом описать что я хочу, чем мышкой накликивать. Меня даже юнити в ступор вводит.
love2d это мультимедийный фреймворк общего назначения, обёртка на lua для сишной sdl2 и некоторых других вещей. На нём можно написать что угодно вообще. Если к тому же знаешь сишечку, то можно дописывать себе модули на ней и втыкивать их в своё поделие без проблем вообще. В частности, полагаю, что к стимворксу там обращение можно запилить без всяких прокладок за 5 минут.
Но это не игровой движок по сути, чтобы в нём появились сцены, камеры, твининги и прочая хуета, можно взять, например, hump, который по сути дефолтный уже чисто игровой движок для love2d.
констракт2 это не про программирование, это про что-то другое, я так не умею, мне проще кодом описать что я хочу, чем мышкой накликивать. Меня даже юнити в ступор вводит.
>>306092
HUMP - не движок, это чисто набор тулзов:
Камера, векторы, состояния, ООП и сигналы а ля ивенты.
Движок - это готовая для наполнения контентом система.
На love сделан GRID, и это уже движок, с энтити-менеджерами, анимациями, клиент-серверной моделью и прочей фигнёй.
Читать тут: https://love2d.org/forums/viewtopic.php?f=5&t=80115
HUMP - не движок, это чисто набор тулзов:
Камера, векторы, состояния, ООП и сигналы а ля ивенты.
Движок - это готовая для наполнения контентом система.
На love сделан GRID, и это уже движок, с энтити-менеджерами, анимациями, клиент-серверной моделью и прочей фигнёй.
Читать тут: https://love2d.org/forums/viewtopic.php?f=5&t=80115
>>306082
Легко.
Самурай без меча подобен самураю с мечом.
Только без меча.
>Как вы блять вообще игры без лайвкодинга пишете?
Легко.
Самурай без меча подобен самураю с мечом.
Только без меча.
>>306092
Обращения к SteamAPI через FFI.
1. Грузим steamapi.dll.
2. Дефайним функции.
3. Дёргаем методы.
4. ?????
5. PROFIT.
Подробнее тут: http://luajit.org/ext_ffi_tutorial.html
Кстати, игровые тайловые карты значительно эффективнее хранить в виде статических сишных массивов или массивов из сишных структур.
Пример векторной FFI-библиотеки, где каждый вектор - cdata:
http://pastebin.com/i7qC1aKn
Обращения к 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. Да, к ним подрубаются метатаблицы, поэтому ООП тоже можно мутить.
Не совсем.
Это баланс между сахарной и супер-удобной высокоуровневой Lua и супер-быстрыми и экономичными сишными биндингами.
Обёртка вокруг сишной фигни делает её такой же сахарной и высокоуровневой как Lua, вместе с собтвенной скоростью и экономичностью.
Где-то валялся генератор сишных cтруктур любой размерности, с итераторами по этим самым размерностям для Lua. Да, к ним подрубаются метатаблицы, поэтому ООП тоже можно мутить.
>>306137
Да, пример работы векторов.Они неплохо цепочатся, кстати.
Да, пример работы векторов.Они неплохо цепочатся, кстати.
11 Кб, 385x361>>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
return self
end
Весь код: http://pastebin.com/7de48LxW (пока в одном файлике, ибо тестирую)
Решил запилить свою реализацию ЕЦС. Функционала пока минимально, да и оптимизации никакой, решил сначала спроектировать удобное использование.
Собственно, дошел до такого кода простейшего компонента и простейшей системы (причем в самом "движке" ничего дополнительного не надо указывать):
function Component_Position(_x, _y)
local self = {
name = "position",
x = _x or 0,
y = _y or 0 }
return self
end
function Systems.Drawing()
local self = Systems.Base()
self.name = "drawing"
function self.draw()
local entities = self.get_entities()
for i, e in pairs(entities) do
local p = e.position
love.graphics.circle("fill", p.x, p.y, 10)
end
end
return self
end
Весь код: http://pastebin.com/7de48LxW (пока в одном файлике, ибо тестирую)
11 Кб, 385x361>>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
return self
end
Весь код: http://pastebin.com/7de48LxW (пока в одном файлике, ибо тестирую)
Решил запилить свою реализацию ЕЦС. Функционала пока минимально, да и оптимизации никакой, решил сначала спроектировать удобное использование.
Собственно, дошел до такого кода простейшего компонента и простейшей системы (причем в самом "движке" ничего дополнительного не надо указывать):
function Component_Position(_x, _y)
local self = {
name = "position",
x = _x or 0,
y = _y or 0 }
return self
end
function Systems.Drawing()
local self = Systems.Base()
self.name = "drawing"
function self.draw()
local entities = self.get_entities()
for i, e in pairs(entities) do
local p = e.position
love.graphics.circle("fill", p.x, p.y, 10)
end
end
return self
end
Весь код: http://pastebin.com/7de48LxW (пока в одном файлике, ибо тестирую)
>>308740
Попробуй изучить ООП.
Ты пишешь похоже на ООП, но не совсем.
Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code]
obj = {}
function obj.add(self, value)
table.insert(self, value)
end
это то же самое что
funtion obj:add(value)
table.insert(self, value)
end
Вызывать аналогично:
obj.add(obj, 30)
obj:add(30)
[/code]
Вот тебе пример класса с объектом:
[code]
Class = {}
function Class:new(x, y, r)
local o = {x = x or 0, y = y or 0, r or 30}
self.index = __self
return setmetatable(o, self)
end
function Class:draw()
love.graphics.circle('line', self.x, self.y, self.r)
end
object = Class:new(10, 20, 30)
object:draw()
[/code]
Почитай эту штуку:
http://tylerneylon.com/a/learn-lua/
Попробуй изучить ООП.
Ты пишешь похоже на ООП, но не совсем.
Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code]
obj = {}
function obj.add(self, value)
table.insert(self, value)
end
это то же самое что
funtion obj:add(value)
table.insert(self, value)
end
Вызывать аналогично:
obj.add(obj, 30)
obj:add(30)
[/code]
Вот тебе пример класса с объектом:
[code]
Class = {}
function Class:new(x, y, r)
local o = {x = x or 0, y = y or 0, r or 30}
self.index = __self
return setmetatable(o, self)
end
function Class:draw()
love.graphics.circle('line', self.x, self.y, self.r)
end
object = Class:new(10, 20, 30)
object:draw()
[/code]
Почитай эту штуку:
http://tylerneylon.com/a/learn-lua/
>>308740
Попробуй изучить ООП.
Ты пишешь похоже на ООП, но не совсем.
Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code]
obj = {}
function obj.add(self, value)
table.insert(self, value)
end
это то же самое что
funtion obj:add(value)
table.insert(self, value)
end
Вызывать аналогично:
obj.add(obj, 30)
obj:add(30)
[/code]
Вот тебе пример класса с объектом:
[code]
Class = {}
function Class:new(x, y, r)
local o = {x = x or 0, y = y or 0, r or 30}
self.index = __self
return setmetatable(o, self)
end
function Class:draw()
love.graphics.circle('line', self.x, self.y, self.r)
end
object = Class:new(10, 20, 30)
object:draw()
[/code]
Почитай эту штуку:
http://tylerneylon.com/a/learn-lua/
Попробуй изучить ООП.
Ты пишешь похоже на ООП, но не совсем.
Двоеточие вместо точки, подставляет сам объект первым скрытым аргументом функции [code]
obj = {}
function obj.add(self, value)
table.insert(self, value)
end
это то же самое что
funtion obj:add(value)
table.insert(self, value)
end
Вызывать аналогично:
obj.add(obj, 30)
obj:add(30)
[/code]
Вот тебе пример класса с объектом:
[code]
Class = {}
function Class:new(x, y, r)
local o = {x = x or 0, y = y or 0, r or 30}
self.index = __self
return setmetatable(o, self)
end
function Class:draw()
love.graphics.circle('line', self.x, self.y, self.r)
end
object = Class:new(10, 20, 30)
object:draw()
[/code]
Почитай эту штуку:
http://tylerneylon.com/a/learn-lua/
>>308759
Я использую замыкания. Не знаю почему, но такой вариант ООП как-то больше нравится.
http://lua-users.org/wiki/ObjectOrientationTutorial
Я использую замыкания. Не знаю почему, но такой вариант ООП как-то больше нравится.
http://lua-users.org/wiki/ObjectOrientationTutorial
>>308762
Это не совсем ООП, потому что ты создаёшь полные копии объектов.
Смотри в чём суть: методы объекта хранятся не в нём самом, а в классе.
У тебя же - каждый объект хранит в себе весь набор "методов". Не могу сказать что это плохо для синглтонов, но это неимоверное засирание памяти для массовых штук.
Плюс объекты создаются дольше: провесить одну ссылку на класс значительно дороже чем создавать ещё одну функцию, выделять ей память и так далее.
В подобных замыканиях есть смысл, если тебе нужны приватные методы/поля, и то, старайся их минимизировать.
Это не совсем ООП, потому что ты создаёшь полные копии объектов.
Смотри в чём суть: методы объекта хранятся не в нём самом, а в классе.
У тебя же - каждый объект хранит в себе весь набор "методов". Не могу сказать что это плохо для синглтонов, но это неимоверное засирание памяти для массовых штук.
Плюс объекты создаются дольше: провесить одну ссылку на класс значительно дороже чем создавать ещё одну функцию, выделять ей память и так далее.
В подобных замыканиях есть смысл, если тебе нужны приватные методы/поля, и то, старайся их минимизировать.
>>308767
P.S. Освой мета-таблицы уже наконец.
Работать с lua не используя самый мощный её механизм - пустая трата времени.
Я сам, осваивал в три захода, с перерывами в пару месяцев. До этого делал процедурные штуки, которые имели довольно стрёмную структуру, просто потому что чтобы сделать процедурами что-то сложное и притом расширяемое - приходится быть самим Кнутом или Дейкстрой, предварительно рисуя кучу UML-ек, чтобы из головы не вылетала структура.
ООП (с несколькими дополнительными приёмами, типа чистых модулей, составления структуры директорий и дерева модулей, вызывающих друг друга) позволяет делать хуяк-хуяк и в продакшн, всего по паре-тройке предварительных макетов архитектуры.
Хех, сейчас работаю программистом на lua.
Довольно весело.
P.S. Освой мета-таблицы уже наконец.
Работать с lua не используя самый мощный её механизм - пустая трата времени.
Я сам, осваивал в три захода, с перерывами в пару месяцев. До этого делал процедурные штуки, которые имели довольно стрёмную структуру, просто потому что чтобы сделать процедурами что-то сложное и притом расширяемое - приходится быть самим Кнутом или Дейкстрой, предварительно рисуя кучу UML-ек, чтобы из головы не вылетала структура.
ООП (с несколькими дополнительными приёмами, типа чистых модулей, составления структуры директорий и дерева модулей, вызывающих друг друга) позволяет делать хуяк-хуяк и в продакшн, всего по паре-тройке предварительных макетов архитектуры.
Хех, сейчас работаю программистом на lua.
Довольно весело.
>>308767
Да, памяти действительно больше отжирает, и создаются долго, но зато по скорости в самом использовании вроде как получше даже: http://lua-users.org/wiki/ObjectOrientationClosureApproach
Ну и из плюсов все-таки приватные поля.
Обычно вроде наоборот стараются загнать все в приватные и делать геттеры-сеттеры, чтобы в будущем при использовании класса не напортачить чего лишнего.
>>308769
Недавно-таки раскуривал, написал свой класс для 2д вектора со всеми арифметическими функциями, правда все равно пока еще не совсем уверенно владею (всякие индексы, ньюиндексы и прочее).
О чем работка?
Вообще недавно только подумал о всяких оптимизациях кода на луа (для игр), и обнаружил много всяких интересных моментов этого языка, что прям захотелось поглубже изучить луа.
Да, памяти действительно больше отжирает, и создаются долго, но зато по скорости в самом использовании вроде как получше даже: http://lua-users.org/wiki/ObjectOrientationClosureApproach
Ну и из плюсов все-таки приватные поля.
>приватные методы/поля, и то, старайся их минимизировать
Обычно вроде наоборот стараются загнать все в приватные и делать геттеры-сеттеры, чтобы в будущем при использовании класса не напортачить чего лишнего.
>>308769
>Освой мета-таблицы уже наконец.
Недавно-таки раскуривал, написал свой класс для 2д вектора со всеми арифметическими функциями, правда все равно пока еще не совсем уверенно владею (всякие индексы, ньюиндексы и прочее).
>Хех, сейчас работаю программистом на lua.
О чем работка?
Вообще недавно только подумал о всяких оптимизациях кода на луа (для игр), и обнаружил много всяких интересных моментов этого языка, что прям захотелось поглубже изучить луа.
>>308772
Работка - прямо сейчас - хайлоад-платформа для микросервисов.
Потом будут сами микросервисы. Ну там, логгирование в бд, с пиками в 100к запросов в секунду.
Не love2d, чистая lua с несколькими либами типа lanes для многопоточности.
Работка - прямо сейчас - хайлоад-платформа для микросервисов.
Потом будут сами микросервисы. Ну там, логгирование в бд, с пиками в 100к запросов в секунду.
Не love2d, чистая lua с несколькими либами типа lanes для многопоточности.
>>308778
Прикольно, видимо луа все-таки еще огого (хотя, наверное, в таких вещах больше используется как обертка над Си, нежели полностью самостоятельный язык, потипу питона или еще чего).
Вот это интересно кстати, планировал свой ECS фреймворк попробовать распараллелить (там как раз системы для обработки сущностей должны хорошо параллелиться).
Прикольно, видимо луа все-таки еще огого (хотя, наверное, в таких вещах больше используется как обертка над Си, нежели полностью самостоятельный язык, потипу питона или еще чего).
>lanes для многопоточности
Вот это интересно кстати, планировал свой ECS фреймворк попробовать распараллелить (там как раз системы для обработки сущностей должны хорошо параллелиться).
>>308781
У Lua прикол в том, что она встраивается проще чем питон, сама по себе быстрая и лёгкая: единственные скрипты, которые реально используются в дохлых микроконтроллерах без особой памяти, плюс FFI, которая даёт возможность фактически писать на C на Lua, заодно, подключая совершенно любые сишные библиотеки, даже не адаптированные.
Фактически, это скриптовый и сахарный вариант няшной сишки с портабельностью и прочими шлюхами. Просто не распиарено, и как следствие - мало либ и сравнительно небольшое комьюнити. Так - очень универсальная штука, которая ещё и приятно выглядит и хорошо работает.
У Lua прикол в том, что она встраивается проще чем питон, сама по себе быстрая и лёгкая: единственные скрипты, которые реально используются в дохлых микроконтроллерах без особой памяти, плюс FFI, которая даёт возможность фактически писать на C на Lua, заодно, подключая совершенно любые сишные библиотеки, даже не адаптированные.
Фактически, это скриптовый и сахарный вариант няшной сишки с портабельностью и прочими шлюхами. Просто не распиарено, и как следствие - мало либ и сравнительно небольшое комьюнити. Так - очень универсальная штука, которая ещё и приятно выглядит и хорошо работает.
>>308785
Ты чего то не понимаешь, а именно того что луа не полноценный язык а скриптопараша. Его дохуя где используют, особенно если нужна поддержка моддинга. Но сколько бы ты говна не навесил на скриптопарашу, она скриптопарашей и останется, для выполнения своих узких целей, и сишку при всем твоем желании она не заменит.
Ты чего то не понимаешь, а именно того что луа не полноценный язык а скриптопараша. Его дохуя где используют, особенно если нужна поддержка моддинга. Но сколько бы ты говна не навесил на скриптопарашу, она скриптопарашей и останется, для выполнения своих узких целей, и сишку при всем твоем желании она не заменит.
>>308802
кококо нужно
кококо нужно
>>308804
А, методы в энтити от старого кода остались, действительно.
На счет того, что и где хранить - пока еще думаю (в системах сейчас вроде только ссылки на сущности хранятся). По идеи в идеале энтити надо преобразовать в айдишник, и где-то хранить массивы только лишь компонентов.
А, методы в энтити от старого кода остались, действительно.
На счет того, что и где хранить - пока еще думаю (в системах сейчас вроде только ссылки на сущности хранятся). По идеи в идеале энтити надо преобразовать в айдишник, и где-то хранить массивы только лишь компонентов.
>>308805
Представь, что ты в рантайме добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом. Забыл одну - привет, неведомые баги.
Представь, что ты решил делать игру, где битвы происходят на отдельной карте (ну, или гуи руками делаешь). Теперь при переходе на экран боя (или меню) надо из систем выковыривать сохранённые энтити и где-то их хранить до конца боя. А можно было просто свапнуть менеджер энтитей, и всё само бы работало.
>что и где хранить - пока еще думаю
Представь, что ты в рантайме добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом. Забыл одну - привет, неведомые баги.
Представь, что ты решил делать игру, где битвы происходят на отдельной карте (ну, или гуи руками делаешь). Теперь при переходе на экран боя (или меню) надо из систем выковыривать сохранённые энтити и где-то их хранить до конца боя. А можно было просто свапнуть менеджер энтитей, и всё само бы работало.
>>308809
Логически, эти вещи как раз должны вместе идти по идеи. Например, какой-то ответ на коллизию должен быть - добавляем компонент этой коллизии и тут же подписываем сущность на нужную систему, которая именно эту коллизию обрабатывает.
Да, на счет какого-то менеджера сущностей и подумывал.
На счет хранения больше волнует вопрос об оптимальности по объему памяти и по скорости обработки. Если, например, делать массивы компонентов по их типах (массив позиций, массив скоростей и т.д.), то могут быть 2 варианта хранения: 1) когда в массиве индекс компонента строго соответствует айди энтити, но тогда будут "дыры" в массиве; 2) хранить компоненты "плотно", но вводить еще какие-то дополнительные связки индексов или ссылок.
Однако я сейчас только додумал о том, что однотипных компонентов может быть несколько, например за один такт обработки физики было нанесено сразу несколько дамагов одному энтити, тогда надо делать для каждого дамага свой компонент с именем того, кто нанес, и само кол-во дамага, и все эти компоненты далее должны будут системой дамага обрабатываться.
Тогда надо либо хранить по 2-му варианту, либо в менеджере сущностей делать двумерный массив, т.е. хранить массив под сущности, а уже в том массиве конкретной сущности хранить все экземпляры компонентов.
>добавил компонент. Теперь нужно все системы, которые от него зависят, уведомить об этом
Логически, эти вещи как раз должны вместе идти по идеи. Например, какой-то ответ на коллизию должен быть - добавляем компонент этой коллизии и тут же подписываем сущность на нужную систему, которая именно эту коллизию обрабатывает.
Да, на счет какого-то менеджера сущностей и подумывал.
На счет хранения больше волнует вопрос об оптимальности по объему памяти и по скорости обработки. Если, например, делать массивы компонентов по их типах (массив позиций, массив скоростей и т.д.), то могут быть 2 варианта хранения: 1) когда в массиве индекс компонента строго соответствует айди энтити, но тогда будут "дыры" в массиве; 2) хранить компоненты "плотно", но вводить еще какие-то дополнительные связки индексов или ссылок.
Однако я сейчас только додумал о том, что однотипных компонентов может быть несколько, например за один такт обработки физики было нанесено сразу несколько дамагов одному энтити, тогда надо делать для каждого дамага свой компонент с именем того, кто нанес, и само кол-во дамага, и все эти компоненты далее должны будут системой дамага обрабатываться.
Тогда надо либо хранить по 2-му варианту, либо в менеджере сущностей делать двумерный массив, т.е. хранить массив под сущности, а уже в том массиве конкретной сущности хранить все экземпляры компонентов.
![es-datastructures-structured-megaarray-by-component[1].png](https://2ch.life//gd/src/305497/14787637879880.png)
64 Кб, 714x602>>308811
Тут есть еще статейка про организацию памяти для ES, мб кому еще интересно: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
Тут есть еще статейка про организацию памяти для ES, мб кому еще интересно: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
>>308812
Имхо, идея параллельных массивов довольно дурацкая.
Если тебе действительно Очень Нужна Экономия Памяти - используй FFI-структуры.
http://luajit.org/ext_ffi_tutorial.html
Это в сотни и тысячи раз уменьшает расход памяти и даёт быстрый доступ.
Другое дело что оно статичное, поэтому максимальное количество объектов приходится рассчитывать заранее, или хранить в lua-таблице.
Имхо, идея параллельных массивов довольно дурацкая.
Если тебе действительно Очень Нужна Экономия Памяти - используй FFI-структуры.
http://luajit.org/ext_ffi_tutorial.html
Это в сотни и тысячи раз уменьшает расход памяти и даёт быстрый доступ.
Другое дело что оно статичное, поэтому максимальное количество объектов приходится рассчитывать заранее, или хранить в lua-таблице.
20 Кб, 600x540>>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
http://pastebin.com/QZzf2Uwh
Я подумал, что все-таки не буду углубляться в дикую оптимизацию того, что пока еще вообще не до конца допилено. Но все-таки хочу в итоге организовать все более-менее рационально и удобно средствами Луа. В статье выше все-таки делается расчет на десятки тысяч объектов, мне же сойдет и пару сотен на первое время.
Собственно, сделал энтити идентификаторов, и разделил список всех сущностей и список подписавшихся. Я подозревал, что при изменении структуры на более правильную и наращивании функционала вся структура кода будет идти немного косо, но не думал, что настолько рано. Однако схему создания компонентов и систем в моей реализации удалось сохранить. Заодно пришлось разобраться с итераторами и запилить собственный.
local entities = self.get_entities()
for i, e in iter_select(entities) do
local p = e.position
love.graphics.circle("fill", p.x, p.y, 10)
end
http://pastebin.com/QZzf2Uwh
>>309374
Десятки тысяч упаковываются в одну lua-таблицу, как ffi-структуры.
Вкури это уже и не еби себе моск.
Как правило, чем проще решение тем лучше.
Десятки тысяч упаковываются в одну lua-таблицу, как ffi-структуры.
Вкури это уже и не еби себе моск.
Как правило, чем проще решение тем лучше.
>>309375
Да дело не столько в структурках, сколько в их организации.
И мне кажется писать для каждого компонента что-то типа ffi.cdef[[typedef struct { double x, y; } point_t;]] только лишь для того, чтобы данные чуть компактнее были, заместо привычного луа-кода, оно не стоит того, притом что нужда в компактности не такая большая.
Если уж ударяться в харкдор, тогда все на Си надо писать. А так мне больше интересно сам луа поковырять.
Да дело не столько в структурках, сколько в их организации.
И мне кажется писать для каждого компонента что-то типа 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.
Всё что можно на ссылках.
Да, все ссылки на сущность (например, ссылка у владельца Меча Тысячи Истин) должны быть со слабыми ключами, чтобы удалив сущность из коллекции, она же удалилась у владельца.
Простых организаций сущностей и так сделано дохрена.
Чем тебе коллекции с ключами-id не угодили, кстати?
Ну там, сущность:
entity[id] = obj = {x, y, sprite, update, draw, owner = playerN}, где update/draw - функции с колбеками и прочей дрянью.
Ну, и унификация этих же сущностей, мол, каждая должна иметь методы update/draw, а если не имеет того же draw - вместо отрисовки сущности используется рисование прямоугольника.
Достаточно просто же!
Спавн сущности - добавление элемента в табличку, доступ и удаление по id - простое. Чтобы не париться с уникальностью id - генератор UUID.
Всё что можно на ссылках.
Да, все ссылки на сущность (например, ссылка у владельца Меча Тысячи Истин) должны быть со слабыми ключами, чтобы удалив сущность из коллекции, она же удалилась у владельца.
>>309384
UPD: Или наоборот, ссылки в коллекции сущностей слабые, а у владельцев - сильные.
Если владелец - игровой мир - рисуем её в игровом мире.
UPD: Или наоборот, ссылки в коллекции сущностей слабые, а у владельцев - сильные.
Если владелец - игровой мир - рисуем её в игровом мире.
>>309384
Так у меня практически тоже самое и реализовано.
Создание сущности:
function self.newEntity()
table.insert(entities, {})
return #entities
end
Возвращается по сути ID этой сущности, по которому потом можно нацеплять компоненты и подписывать на системы.
А системы имеют список subscribers, в котором содержатся ID тех, кто подписан на эту систему.
Одна из защит от обращения к несуществующим сущностям реализована в самом итераторе.
Избавление от прямого наличия методов update и draw - по сути одна из фич ECS да и вообще дата-ориентированного подхода. За счет замены тех методов на системы достигается избавление от всяких наследований и получается гибкость конструирования сущностей.
Так у меня практически тоже самое и реализовано.
Создание сущности:
function self.newEntity()
table.insert(entities, {})
return #entities
end
Возвращается по сути ID этой сущности, по которому потом можно нацеплять компоненты и подписывать на системы.
А системы имеют список subscribers, в котором содержатся ID тех, кто подписан на эту систему.
Одна из защит от обращения к несуществующим сущностям реализована в самом итераторе.
Избавление от прямого наличия методов update и draw - по сути одна из фич ECS да и вообще дата-ориентированного подхода. За счет замены тех методов на системы достигается избавление от всяких наследований и получается гибкость конструирования сущностей.
>>309389
Ладно, как знаешь.
С ООП на замыканиях, ты создаёшь кучу дубликатов и в целом, странных вещей, но это твоё дело, хех.
Просто попробуй различные варианты, и действуй исходя из практичности, а не хуярь всё подряд "золотым молотком".
Ладно, как знаешь.
С ООП на замыканиях, ты создаёшь кучу дубликатов и в целом, странных вещей, но это твоё дело, хех.
Просто попробуй различные варианты, и действуй исходя из практичности, а не хуярь всё подряд "золотым молотком".
>>309390
Я думал какие-то из классов все-таки переписать без замыканий, но потом понял, что в данном случае это на самом деле мало что изменит: все системы всегда будут иметь один единственный экземпляр, и сам менеджер также используется в единичном количестве (ну или может пару их можно создать для разных состояний игры, например, но это не существенно). В текущей реализации вроде вариантов больше никаких нет, или я не вижу их.
В дальнейшем если еще что-то буду делать или эту архитектуру переделывать, то уже буду смотреть каким методом лучше запиливать ООП.
Я думал какие-то из классов все-таки переписать без замыканий, но потом понял, что в данном случае это на самом деле мало что изменит: все системы всегда будут иметь один единственный экземпляр, и сам менеджер также используется в единичном количестве (ну или может пару их можно создать для разных состояний игры, например, но это не существенно). В текущей реализации вроде вариантов больше никаких нет, или я не вижу их.
В дальнейшем если еще что-то буду делать или эту архитектуру переделывать, то уже буду смотреть каким методом лучше запиливать ООП.
15 Кб, 552x414И я-таки продолжаю трахаться со своим убер-фреймворком ЕЦС. Уже хочется переделать все с нуля, но я планирую еще до конца разобраться где какие косяки будут (мб смогу нормально вставить костыли чтобы все работало).
Завел себе репозиторий, вынес код фреймворка в разные файлы. Правда системы и компоненты оставил "по-деревенски", т.е. в одном файле куча компонентов или систем, но пока их немного - и так норм, легче отлаживать.
Решил проверить реализацию ивентов, выскочило несколько проблем:
опять же существование несколько однотипных компонентов у одного энтити (наверное все-таки введу айдишники),
еще как выше обсуждали - ручное или автоматические подписывание на системы - ручное дает гибкость, а автоматическое позволяет меньше задумываться над этими вещами (я не уверен, но возможно в любой задаче можно будет обойтись без той гибкости),
добавление/удаление компонентов, подписка/отписка от систем из других систем (пока сделал не очень красивое решение, но лучше хз как).
В общем использовать примерно так:
ecs.addComponent(e2, Component_Timer_Event(1.0, "change_direction", Component_New_Direction, {vx=love.math.random(-1, 1)30, vy=love.math.random(-1,1)30}))
ecs.subscribe(e2, "timer_handling")
Следующим шагом планирую запилить физику, в идеале в двух вариантах: интегрировать самописную и внедрить бокс2д.
Репа: https://gitlab.com/m1tch/ecs_on_lua/tree/master
Завел себе репозиторий, вынес код фреймворка в разные файлы. Правда системы и компоненты оставил "по-деревенски", т.е. в одном файле куча компонентов или систем, но пока их немного - и так норм, легче отлаживать.
Решил проверить реализацию ивентов, выскочило несколько проблем:
опять же существование несколько однотипных компонентов у одного энтити (наверное все-таки введу айдишники),
еще как выше обсуждали - ручное или автоматические подписывание на системы - ручное дает гибкость, а автоматическое позволяет меньше задумываться над этими вещами (я не уверен, но возможно в любой задаче можно будет обойтись без той гибкости),
добавление/удаление компонентов, подписка/отписка от систем из других систем (пока сделал не очень красивое решение, но лучше хз как).
В общем использовать примерно так:
ecs.addComponent(e2, Component_Timer_Event(1.0, "change_direction", Component_New_Direction, {vx=love.math.random(-1, 1)30, vy=love.math.random(-1,1)30}))
ecs.subscribe(e2, "timer_handling")
Следующим шагом планирую запилить физику, в идеале в двух вариантах: интегрировать самописную и внедрить бокс2д.
Репа: https://gitlab.com/m1tch/ecs_on_lua/tree/master
>>310791
А, еще забыл про проблему приоритетов систем. Я сначала думал, что как они объявлены, так они и будут храниться в списке систем, но это совершенно так, и они даже ни в каком не обратном порядке.
Не знаю, понадобиться все-таки эта приоритезация, т.к. в продолжительном времени они все равно все циклически будут обрабатываться, но если по-хорошему делать, то это надо.
А, еще забыл про проблему приоритетов систем. Я сначала думал, что как они объявлены, так они и будут храниться в списке систем, но это совершенно так, и они даже ни в каком не обратном порядке.
Не знаю, понадобиться все-таки эта приоритезация, т.к. в продолжительном времени они все равно все циклически будут обрабатываться, но если по-хорошему делать, то это надо.
>>310791
Box2d неимоверно тяжёл.
Для задач платформеров/леталок-стрелялок даже с худо-бедной физикой его слишком много. Из пушки по воробьям.
Особенно если ты хочешь заставлять прыгать персонажей через applyForce.
Box2d неимоверно тяжёл.
Для задач платформеров/леталок-стрелялок даже с худо-бедной физикой его слишком много. Из пушки по воробьям.
Особенно если ты хочешь заставлять прыгать персонажей через applyForce.
>>310802
Да, согласен, если какие-то аркадные штучки делать, при придется костылить.
Но в данном случае я хочу подключить его для теста своей архитектуры, т.е. смогу ли я прямо в эти системы и компоненты вписать внешнюю библиотеку (потом может и гуи какой-то придется вписывать).
Одна из проблем, которую я вижу, это добавление в бокс2дшный мир новые тела (т.к. у меня системы никак вручную не инициализируются, и не получится организовать везде свободный доступ к созданному миру); предполагаю, что придется решать через дополнительные сущности и системы (например, сущность - бокс2д мир, и компоненты, прикрепляемые к нему - описания новых тел, а какая-то система будет заниматься добавлением этих тел в физ. мир, другая же система будет делать как и положено world:update(dt) ).
Другая проблема - описание и добавление новых коллбеков в физ. мир при коллизиях. Решение, наверное, аналогичное.
Да, согласен, если какие-то аркадные штучки делать, при придется костылить.
Но в данном случае я хочу подключить его для теста своей архитектуры, т.е. смогу ли я прямо в эти системы и компоненты вписать внешнюю библиотеку (потом может и гуи какой-то придется вписывать).
Одна из проблем, которую я вижу, это добавление в бокс2дшный мир новые тела (т.к. у меня системы никак вручную не инициализируются, и не получится организовать везде свободный доступ к созданному миру); предполагаю, что придется решать через дополнительные сущности и системы (например, сущность - бокс2д мир, и компоненты, прикрепляемые к нему - описания новых тел, а какая-то система будет заниматься добавлением этих тел в физ. мир, другая же система будет делать как и положено world:update(dt) ).
Другая проблема - описание и добавление новых коллбеков в физ. мир при коллизиях. Решение, наверное, аналогичное.
>>310804
В отсутствии свободного доступа к миру изначальная проблема твоей архитектуры.
Костылей не наберёшься, и наткнёшься на большие сложности расширяемости.
Я предупредил.
В отсутствии свободного доступа к миру изначальная проблема твоей архитектуры.
Костылей не наберёшься, и наткнёшься на большие сложности расширяемости.
Я предупредил.
>>310807
P.S. Я писал МНОГО вещей на love2d, пробуя разные варианты.
Наиболее эффективный - набор коллекций для всех персонажей имеющих ИИ, снарядов, сущностей и карта.
Каждый элемент имеет свои методы update/draw.
Проходим по списку, обновляем, отрисовываем.
Даже если объекты очень разные - они тем не менее обновляются и отрисовываются, ровно так как тебе хочется.
Всякие сложные объекты, вроде каких-нибудь снарядов в виде вращающихся лезвий, которые зависают в воздухе или липнут к поверхностям - конечными автоматами, где вместо update/draw подставляются соответствующие методы из текущего состояния (перегрузка __index, например), и методы взаимодействия с другими коллекциями, которые дёргаются в update.
Получается наиболее открыто, и легко добавлять что угодно.
P.S. Я писал МНОГО вещей на love2d, пробуя разные варианты.
Наиболее эффективный - набор коллекций для всех персонажей имеющих ИИ, снарядов, сущностей и карта.
Каждый элемент имеет свои методы update/draw.
Проходим по списку, обновляем, отрисовываем.
Даже если объекты очень разные - они тем не менее обновляются и отрисовываются, ровно так как тебе хочется.
Всякие сложные объекты, вроде каких-нибудь снарядов в виде вращающихся лезвий, которые зависают в воздухе или липнут к поверхностям - конечными автоматами, где вместо update/draw подставляются соответствующие методы из текущего состояния (перегрузка __index, например), и методы взаимодействия с другими коллекциями, которые дёргаются в update.
Получается наиболее открыто, и легко добавлять что угодно.
>>310807
Ну я пока и щупаю проблемные места.
>>310808
У тебя одна сущность имеет один update в котором всё-всё-всё, или набор update с разными предназначениями? Если второе, то эти апдейты можно случайно (по какому-то случаю) нацеплять/отцеплять от сущностей?
И как ты все-таки физику реализовал? Ведь она не в самих сущностях, а над ними. И нужно определенным образом еще итерировать по ним, если это самописная физика, либо придерживаться некоторых внешний правил, если это готовая библиотека.
Ну я пока и щупаю проблемные места.
>>310808
У тебя одна сущность имеет один update в котором всё-всё-всё, или набор update с разными предназначениями? Если второе, то эти апдейты можно случайно (по какому-то случаю) нацеплять/отцеплять от сущностей?
И как ты все-таки физику реализовал? Ведь она не в самих сущностях, а над ними. И нужно определенным образом еще итерировать по ним, если это самописная физика, либо придерживаться некоторых внешний правил, если это готовая библиотека.
>>310812
Эмм. Отцеплять окончательно нельзя.
Знаешь что такое конечный автомат?
Кароч.
object = {}
object.states = {iddle = {update, draw}, walk = {update, draw}}
object.currentstate = object.states.iddle
function object:update()
self.currentstate.update(self)
end
function object:draw()
self.currentstate.draw(self)
end
Примерно так, но с мета-таблицами можно в несколько раз лаконичнее.
Учитывай что таблицы записываюся в переменные как ссылки на них.
Эмм. Отцеплять окончательно нельзя.
Знаешь что такое конечный автомат?
Кароч.
object = {}
object.states = {iddle = {update, draw}, walk = {update, draw}}
object.currentstate = object.states.iddle
function object:update()
self.currentstate.update(self)
end
function object:draw()
self.currentstate.draw(self)
end
Примерно так, но с мета-таблицами можно в несколько раз лаконичнее.
Учитывай что таблицы записываюся в переменные как ссылки на них.
>>310812
Физика - итерируем по объектам. Смотрим с чем сталкиваются (sweep & prune/quadtree/регулярная сетка в помощь). То с чем кажется что сталкиваемся - проверяем. Если и правда столкнулись - выполняем разрешение коллизии для обоих объектов.
Изич же!
Если использовать внешнюю систему - они, как правило, возвращают ссылку на физический интерфейс объекта.
Хранишь в сущности ссылку на физоновый объект, применяешь к нему его методы, узнаёшь координаты/списки столкновений/прочую хуету.
Для этого дела, советую либу Hardon Collider.
Она не решает коллизию автоматически, только выдаёт ссылки на объекты, с которыми произошло столкновение и dx/dy как вектор ближайшего разрешения коллизий. Это удобнее чем всё остальное, благо прямо таки объекты, возвращаемые либой можно пичкать параметрами и методами (главное - не оверрайдить уже имеющиеся), получая минимум затрат памяти.
Физика - итерируем по объектам. Смотрим с чем сталкиваются (sweep & prune/quadtree/регулярная сетка в помощь). То с чем кажется что сталкиваемся - проверяем. Если и правда столкнулись - выполняем разрешение коллизии для обоих объектов.
Изич же!
Если использовать внешнюю систему - они, как правило, возвращают ссылку на физический интерфейс объекта.
Хранишь в сущности ссылку на физоновый объект, применяешь к нему его методы, узнаёшь координаты/списки столкновений/прочую хуету.
Для этого дела, советую либу Hardon Collider.
Она не решает коллизию автоматически, только выдаёт ссылки на объекты, с которыми произошло столкновение и dx/dy как вектор ближайшего разрешения коллизий. Это удобнее чем всё остальное, благо прямо таки объекты, возвращаемые либой можно пичкать параметрами и методами (главное - не оверрайдить уже имеющиеся), получая минимум затрат памяти.
>>310814
Хм, окей, идею понял. Больше похоже на то, что я раньше делал, ну у меня попримитивнее было, когда основное понятие - это объект, т.е. данные+методы достаточно жестко связаны. Фича ECS как раз в том, что можно практически "на горячую" менять отдельные детали поведения и содержимого компонентов.
На счет твоей идеи сейчас не могу сразу сказать на сколько может быть удобно относительно ECS использовать, надо подумать над разными примерчиками.
Хм, окей, идею понял. Больше похоже на то, что я раньше делал, ну у меня попримитивнее было, когда основное понятие - это объект, т.е. данные+методы достаточно жестко связаны. Фича ECS как раз в том, что можно практически "на горячую" менять отдельные детали поведения и содержимого компонентов.
На счет твоей идеи сейчас не могу сразу сказать на сколько может быть удобно относительно ECS использовать, надо подумать над разными примерчиками.
>>310815
Либа, кстати, интересная, спасибо за подсказку. Правда я уже свою запилил для OBB, но может чего подгляжу или интегрирую коллизии в свою физику.
Либа, кстати, интересная, спасибо за подсказку. Правда я уже свою запилил для OBB, но может чего подгляжу или интегрирую коллизии в свою физику.
>>310818
Я делал
а) локальное пространство самого объекта, а ля глобал внутри self,
б) локальное пространство внутри состояния, обращение по __index-перенаправлению на currentstate или метод self:getState().key = value. Просто и неимоверно эффективно.
На мой взгляд.
Lua гибкая.
>на сколько может быть удобно относительно ECS использовать
Я делал
а) локальное пространство самого объекта, а ля глобал внутри self,
б) локальное пространство внутри состояния, обращение по __index-перенаправлению на currentstate или метод self:getState().key = value. Просто и неимоверно эффективно.
На мой взгляд.
Lua гибкая.
>>310791
Делай, чтобы системы у твоего менеджера запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные). Чем меньше состояния хранится вне компонентов, тем лучше и проще.
>>310793
У тебя просто хеш-таблица вместо массивов/списков. Я себе делал приоритет для каждой системы, потом менеджер этого всего при добавлении новой сортировал все системы по этому приоритету. Позже я заметил, что всё равно стараюсь их размещать так, чтобы они регистрировались в том порядке в каком будут исполняться, и сами приоритеты я нигде не меняю, поэтому отказался от них вообще.
>>310804
Делаешь систему физики. Далее, вместо прямого добавления и удаления тел, добавляешь энтите компоненты AddBody или RemoveBody, которые уже системой физики обрабатываются так, как она хочет.
>подписка/отписка от систем
Делай, чтобы системы у твоего менеджера запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные). Чем меньше состояния хранится вне компонентов, тем лучше и проще.
>>310793
>они даже ни в каком не обратном порядке
У тебя просто хеш-таблица вместо массивов/списков. Я себе делал приоритет для каждой системы, потом менеджер этого всего при добавлении новой сортировал все системы по этому приоритету. Позже я заметил, что всё равно стараюсь их размещать так, чтобы они регистрировались в том порядке в каком будут исполняться, и сами приоритеты я нигде не меняю, поэтому отказался от них вообще.
>>310804
>добавление в бокс2дшный мир новые тела
Делаешь систему физики. Далее, вместо прямого добавления и удаления тел, добавляешь энтите компоненты AddBody или RemoveBody, которые уже системой физики обрабатываются так, как она хочет.
>>310913
Я вот на счет этой автоматизации пока и сомневаюсь. Теоретически возможно такое, что компоненты все идентичны, но поведение разное (ну, навскидку, 2 бота, один добрый, другой злой, один просто гуляет, другой нападает на игрока). Можно, конечно, какие-то теги или компоненты с "описаниями" ввести, но хз.
На счет приоритета - у меня сейчас менеджер сам подбирает все системы из таблицы Systems и инициализирует их у себя, т.е. у меня нет такого, типа manager.addSystem(drawing_system). Хотя это в общем-то интересная замена приоритетам, когда самостоятельно подключаешь системы в определенном порядке, надо подумать.
На счет физики и компонентов новых тел так и подумывал. С ручной подпиской на системы, правда, еще несколько моментов придется продумывать.
>запрашивали список энтитей с нужными компонентами (или просто все, а потом сами фильтровали нужные)
Я вот на счет этой автоматизации пока и сомневаюсь. Теоретически возможно такое, что компоненты все идентичны, но поведение разное (ну, навскидку, 2 бота, один добрый, другой злой, один просто гуляет, другой нападает на игрока). Можно, конечно, какие-то теги или компоненты с "описаниями" ввести, но хз.
На счет приоритета - у меня сейчас менеджер сам подбирает все системы из таблицы Systems и инициализирует их у себя, т.е. у меня нет такого, типа manager.addSystem(drawing_system). Хотя это в общем-то интересная замена приоритетам, когда самостоятельно подключаешь системы в определенном порядке, надо подумать.
На счет физики и компонентов новых тел так и подумывал. С ручной подпиской на системы, правда, еще несколько моментов придется продумывать.
>>310963
Такого быть не может. Разное поведение получается не магически же, а ты как-то их различаешь и запускаешь разный код. Различать можно тремя способами:
1. Разные компоненты.
2. Разные значения в каком-нибудь компоненте (AiComponent.isHostile или что-то подобное)
3. По имени энтити.
Очевидно, что третий способ долбоёбский, а для первых двух нифига не изменится, если ты будешь запрашивать, а не подписываться. Единственное, зачем нужна эта подписка - производительность (да и тут ещё вопрос, что будет быстрее, потому что в реальной игре каждая система добавляет/удаляет десятки/сотни компонентов - в зависимости от размера игры), но на первый раз лучше сделать "как правильно", а потом уже смотреть, если будет нехватать.
>Теоретически возможно такое, что компоненты все идентичны, но поведение разное
Такого быть не может. Разное поведение получается не магически же, а ты как-то их различаешь и запускаешь разный код. Различать можно тремя способами:
1. Разные компоненты.
2. Разные значения в каком-нибудь компоненте (AiComponent.isHostile или что-то подобное)
3. По имени энтити.
Очевидно, что третий способ долбоёбский, а для первых двух нифига не изменится, если ты будешь запрашивать, а не подписываться. Единственное, зачем нужна эта подписка - производительность (да и тут ещё вопрос, что будет быстрее, потому что в реальной игре каждая система добавляет/удаляет десятки/сотни компонентов - в зависимости от размера игры), но на первый раз лучше сделать "как правильно", а потом уже смотреть, если будет нехватать.
>>311091
Хм, да, согласен, компоненты все-таки легче отслеживать и они не такие "низкоуровневые" в отличие от ручных подписок на системы, т.е. юзабельность повысится даже если придется делать компоненты-теги, или совсем-совсем частные типы компонентов, а гибкость останется примерно на том же уровне.
Хм, да, согласен, компоненты все-таки легче отслеживать и они не такие "низкоуровневые" в отличие от ручных подписок на системы, т.е. юзабельность повысится даже если придется делать компоненты-теги, или совсем-совсем частные типы компонентов, а гибкость останется примерно на том же уровне.
17 Кб, 582x467В общем реализовал добавление систем вручную, решил сделать именно методами addSystem, т.к. мне кажется так более наглядно? плюс можно строить разные ECS менеджеры с разным функционалом.
Запилил выбор подписчиков в системах через новый самописный итератор, который внутри проверяет requirements (возможно стоит оптимизировать, и обновлять существующий список по добавлению новых компонентов к сущностям).
Ну и решил проблему со множественными компонентами: как я подумал, если каких-то компонентов может быть много, то они, скорее всего, являются событиями. Собственно, поэтому сделал 2 разные функции: addComponent и addEventComponent. Отличие второго в том, что по обращению к entity[component.name] будет возвращаться массив компонентов типа component.name. Единственное, что теперь системы, обрабатывающие ивенты, стали несколько толще, ибо приходится еще перебирать сам массив ивентов (подумываю на счет того, чтобы автоматизировать выборку сущностей и компонентов, т.е. перенести циклы из систем в менеджер, а в системах работать только с выданной сущностью/компонентами типа update(entity, dt), но тогда хз как физику запиливать).
Потихоньку накапливаются вещи для оптимизации (в хорошем смысле) и для налаживания безопасности (удаление сущностей/компонентов/систем), но они пока не в приоритете, ибо хочу уже запилить полный функционал фреймворка. По плану все еще реализация физики.
Запилил выбор подписчиков в системах через новый самописный итератор, который внутри проверяет 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
Но пока хз на счет гибкости и юзабилити такого подхода.
Еще щас подумал. Например, реализацию движения (Systems.Moving), т.е. обновление координат, можно (гипотетически) запилить через ивенты, которые будут возникать на каждом такте, а т.к. оно сейчас реализовано без них, значит и систему событий можно теоретически развернуть в обычное обновление.
В таком случае, наверное, надо будет просто добавлять дополнительные флаги и счетчики в определенные компоненты, а в системах их обсчитывать, и обрабатывать только тогда, когда какие-то условия срабатывают.
Т.о., если нанесение урона происходило бы по ивенту, то в новом варианте можно сделать компонент Damage (и он будет в единственном кол-ве в энтити) с полем health_damage, и если никто не наносил урон, то это поле = 0. А в системе Damaging можно просто без всяких условий делать entity.health = entity.health - damage.health_damage
Но пока хз на счет гибкости и юзабилити такого подхода.
77 Кб, 1280x720>>305497 (OP)
Начал свою игру про вселенную где можно делать ВСЁ ещё во времена 8, в 9 аесь апи поменяли пришлось переделывать, подзаебало стал простаивать, потом к 10 опять всё переделывать уже забросил.
Вообще то что там нихуя нет хорошо - если где-то криво сам правишь не надо чужой сортир копать.
Начал свою игру про вселенную где можно делать ВСЁ ещё во времена 8, в 9 аесь апи поменяли пришлось переделывать, подзаебало стал простаивать, потом к 10 опять всё переделывать уже забросил.
Вообще то что там нихуя нет хорошо - если где-то криво сам правишь не надо чужой сортир копать.
>>311670
Можно было продолжать на 8 или 9 пилить если ты мог на них пилить, какая разница какая версия?
Можно было продолжать на 8 или 9 пилить если ты мог на них пилить, какая разница какая версия?
>>311671
Там толи какая-то хуйня с производительностью была от каких-то функций толи ещё что-то не работало, не помню уже.
Там толи какая-то хуйня с производительностью была от каких-то функций толи ещё что-то не работало, не помню уже.
>>311671
андроид порт только в 0.10 добавили, норм ретину только в 0.11 завезут. впрочем я хз что там надо было такого нахуевертить, чтобы переделывание под новую версию заняло больше 1 выходных.
андроид порт только в 0.10 добавили, норм ретину только в 0.11 завезут. впрочем я хз что там надо было такого нахуевертить, чтобы переделывание под новую версию заняло больше 1 выходных.
5,1 Мб, webm,718x404
>>311757
не бойся у твоего 3-в-ряд с донатом конкурентов нет
не бойся у твоего 3-в-ряд с донатом конкурентов нет
>>311667
Запилил свою физику в свой фреймворк.
Пришлось подумать как реорганизовать цельную обработку коллизий (нашли одно-разрешили одно) в поэтапную (нашли все - разрешили все). Решил, что пускай сначала в виде ивентов у энтити будут накапливаться коллизии, а потом в другой системе, если тела все еще пересекаются, то разрешать их. Т.е. у меня сейчас 2 системы на это: проверка коллизий, и разрешение коллизий, но сейчас понял, что это минимум, и систему разрешения надо заменить скорее на систему определения типа коллизий (или все-таки прикрутить это к самой проверке), а далее, само разрешение (расталкивание) будет одним из этих типов (и будет отдельная система под это).
Еще приходится в ивентах постоянно следить, чтобы они удалялись после обработки, мб оптимизировать это как-то.
В целом могу сказать, что фреймворк работает, надо только немного перестроить мышление под обработку компонентов системами (а не объектов апдейтами), и можно будет получать кайф от модульного кодинга всего функционала игры.
Запилил свою физику в свой фреймворк.
Пришлось подумать как реорганизовать цельную обработку коллизий (нашли одно-разрешили одно) в поэтапную (нашли все - разрешили все). Решил, что пускай сначала в виде ивентов у энтити будут накапливаться коллизии, а потом в другой системе, если тела все еще пересекаются, то разрешать их. Т.е. у меня сейчас 2 системы на это: проверка коллизий, и разрешение коллизий, но сейчас понял, что это минимум, и систему разрешения надо заменить скорее на систему определения типа коллизий (или все-таки прикрутить это к самой проверке), а далее, само разрешение (расталкивание) будет одним из этих типов (и будет отдельная система под это).
Еще приходится в ивентах постоянно следить, чтобы они удалялись после обработки, мб оптимизировать это как-то.
В целом могу сказать, что фреймворк работает, надо только немного перестроить мышление под обработку компонентов системами (а не объектов апдейтами), и можно будет получать кайф от модульного кодинга всего функционала игры.
43 Кб, 656x678Чувачок замутил воксельный рендерер для лова, можно теперь хуярить в 3д.
https://love2d.org/forums/viewtopic.php?f=5&t=83158
https://love2d.org/forums/viewtopic.php?f=5&t=83158
>>312285
Дирижабль из мацы.
Дирижабль из мацы.
57 Кб, 1257x689>>311757
пора на дифолд перекатываться уже. ничем не хуже хуюнити, базарю
http://www.defold.com/manuals/lua/
>андроид порт только в 0.10 добавили
пора на дифолд перекатываться уже. ничем не хуже хуюнити, базарю
http://www.defold.com/manuals/lua/
>>313383
Вроде туторы норм есть, какие-то игры сделаны, компил под разные платформы, но комьюнити че-то никакое, лов2д как-то поживее.
Вроде туторы норм есть, какие-то игры сделаны, компил под разные платформы, но комьюнити че-то никакое, лов2д как-то поживее.
Блять, луа - самый уебанский язык на планете земля. Какого хуя, блять? Половина копируется по ссылке, половина по значению, никаких стандартных функций нет, пишите все с нуля. Сука, ассемблер удобнее.
>>319904
Инты и булы по значению, таблицы и строки по ссылки, что непонятного?
Какие функции тебе нужны? Комьюнити луа хоть и относительно мертвое по сравнению с другими языками, но все-таки умельцы делают достаточно всяких либ, которые покрывают большинство возникающих потребностей, надо только поискать.
Так-то язык довольно прикольный и легкий, со своими фичами.
Инты и булы по значению, таблицы и строки по ссылки, что непонятного?
Какие функции тебе нужны? Комьюнити луа хоть и относительно мертвое по сравнению с другими языками, но все-таки умельцы делают достаточно всяких либ, которые покрывают большинство возникающих потребностей, надо только поискать.
Так-то язык довольно прикольный и легкий, со своими фичами.
>>319967
Да я просто охуел, что таблицы копируются по ссылке и нет стандартной функции клонирования, но уже загуглил. Просто не очень интуитивная шняга, переписать бы этот фреймворк под православный руби.
Да я просто охуел, что таблицы копируются по ссылке и нет стандартной функции клонирования, но уже загуглил. Просто не очень интуитивная шняга, переписать бы этот фреймворк под православный руби.
есть два знакомых, что дико котируют его, а мне чет не зашел.
это бамп в тематике
110 Кб, 1366x768>>320029
У нормальных людей уже давно свой пак либ-на-все-случаи-жизни, чтобы не пердолиться с мелкой фигнёй.
У нормальных людей уже давно свой пак либ-на-все-случаи-жизни, чтобы не пердолиться с мелкой фигнёй.
Бампусики. Всем любви в этом ITT треде.
Есть ли у отписавшихся тут какой-либо прогресс и успехи?
Или свалили в итоге на что-то еще?
Есть ли у отписавшихся тут какой-либо прогресс и успехи?
Или свалили в итоге на что-то еще?
>>409659
Ну так, более-менее.
Время от времени что-то пилится, например, сейчас таки замутил систему сущностей на HC с тегированием и блекджеком.
Там что-то такое.
Ну так, более-менее.
Время от времени что-то пилится, например, сейчас таки замутил систему сущностей на HC с тегированием и блекджеком.
Там что-то такое.
>>409741
прикольно, если бы они еще не трахали его и держали дистанцию и что-то делали по idle.
в этом плане было интересно изучать Don't starve. Там подобное относится к 'мозгам'. Советую глянуть как там реализовано.
прикольно, если бы они еще не трахали его и держали дистанцию и что-то делали по idle.
в этом плане было интересно изучать Don't starve. Там подобное относится к 'мозгам'. Советую глянуть как там реализовано.
>>409747
Ну, это простейший тестовый ИИ, который нужен только чтобы узнать, работает ли система ИИ, так что ничего страшного.
Мне другое интересно: как нормально впиливать поиск путей, который будет работать с комплектами полигонов, и не проще ли при создании карты заранее построить графы путей, по которым можно двигаться как по ключевым точкам. И да, игра должна проходить на замкнутом пространстве, с ключевыми точками вроде зон захвата (нет, это не wot2d), точками спавна бонусов и всего такого, и с временно недоступными зонами, вроде открывающихся/закрывающихся ворот.
Алгоритмы ИИ должны учитывать, что прежде чем проходить ворота, их нужно открыть.
Ну, это простейший тестовый ИИ, который нужен только чтобы узнать, работает ли система ИИ, так что ничего страшного.
Мне другое интересно: как нормально впиливать поиск путей, который будет работать с комплектами полигонов, и не проще ли при создании карты заранее построить графы путей, по которым можно двигаться как по ключевым точкам. И да, игра должна проходить на замкнутом пространстве, с ключевыми точками вроде зон захвата (нет, это не wot2d), точками спавна бонусов и всего такого, и с временно недоступными зонами, вроде открывающихся/закрывающихся ворот.
Алгоритмы ИИ должны учитывать, что прежде чем проходить ворота, их нужно открыть.
Ни у кого нет желания в команде на лов2д попилить изометрический шутан с элементами путешествования?
>>409854
Каркас двигла замутил?
Просто без этого, разработка затянется, ибо вместо наполнения контентом, будет разработка базовых инструментов. Хотя, конечно, можно взять GRID.
P.S. Сам не хочу слезать со своих проектов, надо закончить хоть что-то.
Каркас двигла замутил?
Просто без этого, разработка затянется, ибо вместо наполнения контентом, будет разработка базовых инструментов. Хотя, конечно, можно взять GRID.
P.S. Сам не хочу слезать со своих проектов, надо закончить хоть что-то.
>>409880
Свой убер-ECS фреймворк как раз писал для этого.
Не знаю, придется ли его еще допиливать, но простой прототип со своим физоном и простой ГУИ на кнопочках достаточно легко получилось сделать.
Свой убер-ECS фреймворк как раз писал для этого.
Не знаю, придется ли его еще допиливать, но простой прототип со своим физоном и простой ГУИ на кнопочках достаточно легко получилось сделать.
Попробовал леху в сравнении с годотом. Заебато то, что все очень просто, даже с физоном не трахался, в отличие от годота (хотя там тоже, в принципе, ничего сложного нет, но с редактором можно словить нехилых идиотизмов).
Единственное, что не нравится, нет менеджеров сцен и полноценного (или хотя бы минимального) гуя из коробки, поэтому придется либо сторонние модули подключать либо писать велосипед (но они меня сильно подзаебали, так что уже хочется чего-то готового).
Пробовал нарколыжить в HaxeFlixel еще, но что-то он меня пиздец вымораживает со своими обновлениями хитбоксов и прочего при изменении свойств объектов.
Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
Единственное, что не нравится, нет менеджеров сцен и полноценного (или хотя бы минимального) гуя из коробки, поэтому придется либо сторонние модули подключать либо писать велосипед (но они меня сильно подзаебали, так что уже хочется чего-то готового).
Пробовал нарколыжить в HaxeFlixel еще, но что-то он меня пиздец вымораживает со своими обновлениями хитбоксов и прочего при изменении свойств объектов.
Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
>>409996
Там по сути от ООП вообще ничего нет, кроме двоеточия для передачи "self" в качестве первого параметра метода.
Но если раскуришь суть таблиц, метатаблиц, замыканий в lua, то, как мне кажется, становится даже интересненько.
В общем в луа много чего занятного можно найти.
>Ну и с lua я, конечно, знатно поебался, потому что ООП реализован, по крайней мере, необычно для меня как в привычных С++, Java и других подобного семейства языковю
Там по сути от ООП вообще ничего нет, кроме двоеточия для передачи "self" в качестве первого параметра метода.
Но если раскуришь суть таблиц, метатаблиц, замыканий в lua, то, как мне кажется, становится даже интересненько.
В общем в луа много чего занятного можно найти.
>>409996
Короче, залез в колхоз еще глубже.
Есть у меня сцена, в общем, на ней тайловая карта, даже не важно откуда. Так вот в чем дело, отрисовать саму карту, в принципе, сложности не составляет, даже регион, элементарно. Только вот что делать с объектами. Допустим, у меня тысячи их, естественно, отрисовывать объекты, находящиеся вне области видимости смысла нет, поэтому нужно использовать либо сетку размещения (или как это дерьмо называется) или квадрантные деревья.
Или это леха сам делает?
Короче, залез в колхоз еще глубже.
Есть у меня сцена, в общем, на ней тайловая карта, даже не важно откуда. Так вот в чем дело, отрисовать саму карту, в принципе, сложности не составляет, даже регион, элементарно. Только вот что делать с объектами. Допустим, у меня тысячи их, естественно, отрисовывать объекты, находящиеся вне области видимости смысла нет, поэтому нужно использовать либо сетку размещения (или как это дерьмо называется) или квадрантные деревья.
Или это леха сам делает?
>>410176
По-моему для отрисовки ничего такого не применяют. В буфер отрисовки записывается только видимая часть, и занимается этим OpenGL/DirectX, которые используются в SDL (Love2D вроде на нем основан).
Разбиение пространства обычно для расчет физона используется, ибо считать столкновения для 1000 объектов действительно проблематично.
А для ускорения отрисовки, особенно тайловой карты, используют батчинг (sprite batch), т.е. по сути составление одной большой картинки из тайлов, которая за один вызов функции сразу вся отрисовывается.
По-моему для отрисовки ничего такого не применяют. В буфер отрисовки записывается только видимая часть, и занимается этим OpenGL/DirectX, которые используются в SDL (Love2D вроде на нем основан).
Разбиение пространства обычно для расчет физона используется, ибо считать столкновения для 1000 объектов действительно проблематично.
А для ускорения отрисовки, особенно тайловой карты, используют батчинг (sprite batch), т.е. по сути составление одной большой картинки из тайлов, которая за один вызов функции сразу вся отрисовывается.
>>410205
Про батчинг я знаю. Вот именно проблема в том, что именно отрисовывать, не буду же я перебирать 10000 объектов (в поисках тех, которые попадают в экран), скажем, если на экране в области видимости только 30 из них, например.
Или все же сделать простым перебором всех сущностей и отрисовывать только те, которые появляются на экране.
Про батчинг я знаю. Вот именно проблема в том, что именно отрисовывать, не буду же я перебирать 10000 объектов (в поисках тех, которые попадают в экран), скажем, если на экране в области видимости только 30 из них, например.
Или все же сделать простым перебором всех сущностей и отрисовывать только те, которые появляются на экране.
>>410207
Попробуй сначала отрисовать вообще все и посмотреть хватает ли фпс. Потом уже оптимизировать.
Попробуй сначала отрисовать вообще все и посмотреть хватает ли фпс. Потом уже оптимизировать.
>>410208
Думаю так и сделаю. Спасибо.
Думаю так и сделаю. Спасибо.
>>410207
Разбей карту на кусочки NxM тайлов, рисуй только те чанки, которые влезают в камеру. Один батч на один чанк. Идеально - прорисовка четырёх-девяти чанков квадратом. Подгони размеры чанков под камеру, или, если есть зум, вычисляй область видимости. Да и в памяти обычно не нужно держать всю карту, выгружай ненужные куски. Ясен хрен что ближайшую область надо держат
ь, чтобы не тормозило га чтении Так даже легко мутить бесконечные карты как в майнкрафтике. Ничего сложного, просто арифметика.
Разбей карту на кусочки NxM тайлов, рисуй только те чанки, которые влезают в камеру. Один батч на один чанк. Идеально - прорисовка четырёх-девяти чанков квадратом. Подгони размеры чанков под камеру, или, если есть зум, вычисляй область видимости. Да и в памяти обычно не нужно держать всю карту, выгружай ненужные куски. Ясен хрен что ближайшую область надо держат
ь, чтобы не тормозило га чтении Так даже легко мутить бесконечные карты как в майнкрафтике. Ничего сложного, просто арифметика.
>>410207
Дополнение:
Аналогично можно поступить с игровыми объектами, спавня их в нужном чанке. В чанк пихать список ссылок на нпс, а у нпс - хранить ссылку на чанк в котором он сидит. При перемещении, нпс самоудаляется из чанка в котором был, добавляется в чанк в котором оказался, и меняет свою ссылку на текущий чанк. И так - с любыми объектами.
Дополнение:
Аналогично можно поступить с игровыми объектами, спавня их в нужном чанке. В чанк пихать список ссылок на нпс, а у нпс - хранить ссылку на чанк в котором он сидит. При перемещении, нпс самоудаляется из чанка в котором был, добавляется в чанк в котором оказался, и меняет свою ссылку на текущий чанк. И так - с любыми объектами.
31 Кб, 376x96Почаны, а можно ли как-то сделать следующее:
- требуется обсчитать что-то ресурсоемкое, но его нужно обсчитать не ПРЯМО СИЙЧАС, а на низком приоритете и по готовности сгенерить евент. То есть не в текущем update, который должен длиться доли секунды, а вообще в принипе.
Можно ли добавить как-то фоновую задачу?
- предположим некропека не выдерживает эти ваши 60фпс или даже консольные смус 30фпс. Как мне дропать фреймы? Завести счетчик, который будет обновляться в update и в draw уже просчитывать когда скипнуть, а когда нет? нужно ли при этом делеить или задержка и так генериться между каждым update?
- требуется обсчитать что-то ресурсоемкое, но его нужно обсчитать не ПРЯМО СИЙЧАС, а на низком приоритете и по готовности сгенерить евент. То есть не в текущем update, который должен длиться доли секунды, а вообще в принипе.
Можно ли добавить как-то фоновую задачу?
- предположим некропека не выдерживает эти ваши 60фпс или даже консольные смус 30фпс. Как мне дропать фреймы? Завести счетчик, который будет обновляться в update и в draw уже просчитывать когда скипнуть, а когда нет? нужно ли при этом делеить или задержка и так генериться между каждым update?
>>425534
сам себе отвечу на второй вопрос - наверно проще как-то задать фпс, если он вообще задается?
зачем оно вообще нужно? ну например для пошаговой игрульки 60фпс НИНУЖНА, а скажем 5 хватит на анимацию.
сам себе отвечу на второй вопрос - наверно проще как-то задать фпс, если он вообще задается?
зачем оно вообще нужно? ну например для пошаговой игрульки 60фпс НИНУЖНА, а скажем 5 хватит на анимацию.
94 Кб, 604x392и еще вопрос. есть у меня ПОДОЗРЕНИЕ, что вывод было бы неплохо буферизировать вместу тупого вызова draw на каждый фрейм. Попробую пояснить.
предположим есть у нас буфер в котором отражен слой из тайлов - задников. Ну чтобы совсем проще выразиться. Предположим у нас клон террарии и есть несколько буферов-слоев. Задник, тайлы с водичкой, землей и прочим песком и тайл с монстрами поверх них (тот же червь-пидор что атакует под землей). Не суть. Если делать все по-еблански то на каждый чих надо будет все рисовать заново, что подозреваю, будет крайне медленно.
Вместо этого генерим в буфер на область в 2-3 экрана с каждой стороны один раз тайлы и потом лишь меняем (копнули землицу, убрали тайл, перерисовали лишь эту небольшую область (ну и слои за ней) вместо генерации всего экрана. Или это сложно реализуемо/нереализуемо вообще?
Я наверняка изобретаю велосипед, но ведь лубовь 2д и есть один большой велосипед, разве что можно где-то спиздить готовое решение.
Кстати по-поводу пиздинга - как потом можно сныкать свой ШЕДЕВР? на ум приходит лишь обсфускация наподобие минимизаторов для яваскриптов. Где все преобразуется в трудновоспринимаемую мешанину из односимвольных переменных и функций.
предположим есть у нас буфер в котором отражен слой из тайлов - задников. Ну чтобы совсем проще выразиться. Предположим у нас клон террарии и есть несколько буферов-слоев. Задник, тайлы с водичкой, землей и прочим песком и тайл с монстрами поверх них (тот же червь-пидор что атакует под землей). Не суть. Если делать все по-еблански то на каждый чих надо будет все рисовать заново, что подозреваю, будет крайне медленно.
Вместо этого генерим в буфер на область в 2-3 экрана с каждой стороны один раз тайлы и потом лишь меняем (копнули землицу, убрали тайл, перерисовали лишь эту небольшую область (ну и слои за ней) вместо генерации всего экрана. Или это сложно реализуемо/нереализуемо вообще?
Я наверняка изобретаю велосипед, но ведь лубовь 2д и есть один большой велосипед, разве что можно где-то спиздить готовое решение.
Кстати по-поводу пиздинга - как потом можно сныкать свой ШЕДЕВР? на ум приходит лишь обсфускация наподобие минимизаторов для яваскриптов. Где все преобразуется в трудновоспринимаемую мешанину из односимвольных переменных и функций.
>>425544
Проще перерисовать.
В мобилках попадалась луа у пары игор, зашифрованы хз чем, ключ скорее всего в бинарнике.
Premature optimization is the root of all evil.
Проще перерисовать.
В мобилках попадалась луа у пары игор, зашифрованы хз чем, ключ скорее всего в бинарнике.
Premature optimization is the root of all evil.
81 Кб, 594x525>>425542
у меня от этого PHPшный ИТЕРАТОР.
а что, если нельзя вот так вот разбить на части? может там будет вызов какой-то одной функции которая будет выполняться 5-10с? И не вижу установку приоритета, ведь будет одинаково тормозить и бороться за цпу наряду с главным циклом, что приведет к "лагам".
>coroutine.yield
у меня от этого PHPшный ИТЕРАТОР.
а что, если нельзя вот так вот разбить на части? может там будет вызов какой-то одной функции которая будет выполняться 5-10с? И не вижу установку приоритета, ведь будет одинаково тормозить и бороться за цпу наряду с главным циклом, что приведет к "лагам".
>>425549
Если у тебя основная задача будет полностью выжирать цпу, то может и будут проблемы. Но скорее всего всё будет ок.
Если у тебя основная задача будет полностью выжирать цпу, то может и будут проблемы. Но скорее всего всё будет ок.
64 Кб, 800x600о, кажется нашел что мне нужно:
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.
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.
Ну в общем остается вопрос как правильно делать КЛОН ТИРАРИИ. С трудом верю что тупо прорисовывать весь экран на каждый чих. Предположим для простоты это пошаговая игрулька, но с эфектами/анимацией. Зачем мне перерисовывать все, если достаточно перегенерить лишь слой с эффектами, который накладывается поверх всех? ну там искорки, огонек или еще какая пежня.
528 Кб, 800x445>>410205
ох лол, так вот же что я искал. осталось понять как этот самый батчинг делать.
а по-поводу всей карты, интересно в Rimworld она вся в памяти? Или тоже подгружается по необходимости.
ох лол, так вот же что я искал. осталось понять как этот самый батчинг делать.
а по-поводу всей карты, интересно в Rimworld она вся в памяти? Или тоже подгружается по необходимости.
274 Кб, 775x600>>410207
могу ошибаться, но в том же don't starve, там по-моему все реализованно именно тупым перебором сущностей с вычислением расстояния до игрока. Игрок всегда в центре, поэтому можно понять, попадает в кадр или нет.
могу ошибаться, но в том же don't starve, там по-моему все реализованно именно тупым перебором сущностей с вычислением расстояния до игрока. Игрок всегда в центре, поэтому можно понять, попадает в кадр или нет.
>>425556
Ну смари кароч. В тёрке вообще нужно только набор канвасов на каждый чанк. Один раз отрисовал канвас с тайлами, и дальше его дорисовываешь (заменил тайл с A на B, или удалил, это более чем реально). Ну и теням свой канвас. А эффекты партиклов и так работают. Мобам - да, берём батч и рисуем однотипных мобов в нём. Можно автоматизировать, мол, если данный моб заспавнен но для него нет спрайтбатча - создать для него батч. С love v0.11 будет проще, ибо там это будет полуавтоматизировано.
Ну смари кароч. В тёрке вообще нужно только набор канвасов на каждый чанк. Один раз отрисовал канвас с тайлами, и дальше его дорисовываешь (заменил тайл с A на B, или удалил, это более чем реально). Ну и теням свой канвас. А эффекты партиклов и так работают. Мобам - да, берём батч и рисуем однотипных мобов в нём. Можно автоматизировать, мол, если данный моб заспавнен но для него нет спрайтбатча - создать для него батч. С love v0.11 будет проще, ибо там это будет полуавтоматизировано.
>>425959
а загнать все в один батч, а потом копировать лишь то что видно низя? слишком большой расход памяти?
если чесна то нихуй не понил. чанк - группа тайлов из которой составляется текущий экран?
лучши ткни ссылкой где почитать терминологию с картинками если знаишь.
все же интересно как зделоли в римворлде, там размеры жестко ограничены и карта может выводиться полностью на экран. Неужели и там трахаются склеивая области вместо одной большой?
а загнать все в один батч, а потом копировать лишь то что видно низя? слишком большой расход памяти?
если чесна то нихуй не понил. чанк - группа тайлов из которой составляется текущий экран?
лучши ткни ссылкой где почитать терминологию с картинками если знаишь.
все же интересно как зделоли в римворлде, там размеры жестко ограничены и карта может выводиться полностью на экран. Неужели и там трахаются склеивая области вместо одной большой?
150 Кб, 1299x1007>>426124
У одного батча лимит на ~35к спрайтов (или вообще столько сколько влезают в память видяхи, не знаю точно). Маловато будет для тёрки.
Терминология - моя собственная и майнкрафто-тёрочная.
У одного батча лимит на ~35к спрайтов (или вообще столько сколько влезают в память видяхи, не знаю точно). Маловато будет для тёрки.
Терминология - моя собственная и майнкрафто-тёрочная.
>>426135
Тут есть пара опечаток и "неочевидностей", но как-нибудь разберёшься.
Тут есть пара опечаток и "неочевидностей", но как-нибудь разберёшься.
110 Кб, 600x800>>426135
спасибо, Аноний, реально помогло.
метатаблицы тут используешь для эмуляции наследования "классов"?
или оно же необходимо для определения методов тоже, иначе при создании нового объекта Chunk пришлось бы создавать все методы заново, я правильно понимаю?
асло не сейджи, бро, итс хартс май филлингз
спасибо, Аноний, реально помогло.
метатаблицы тут используешь для эмуляции наследования "классов"?
или оно же необходимо для определения методов тоже, иначе при создании нового объекта Chunk пришлось бы создавать все методы заново, я правильно понимаю?
асло не сейджи, бро, итс хартс май филлингз
алсо я правильно понял что у тебя чанк - это 4 тайла в одном, типа квад в терминологии любви2д? т.е. по-сути лишних тайлов за камерой тут может быть лишь по одному по горизонтали и/или вертикали.
ух ебать разумисты все это придумали.
ух ебать разумисты все это придумали.
Если это так, то тут интереснее как ты эти чанки хранишь и видимо уничтожаешь. Ведь если игрок, скажем, будет постоянно двигаться влево, то рано или поздно надо будет мочить самый правый чанк, иначе пожно так всю память засрать ими.
Или похуй и все эти квады-хуяды занимают копейки памяти?
Или похуй и все эти квады-хуяды занимают копейки памяти?
вообще я нихуя не понял зачем вообще эти квады нужны.
как я себе наивно представляю использование тайлов:
- грузим в память (видеопамять?) тайл, а то и атлас.
получаем некий дескриптор и потом используем его для вставки вместо загрузки каждый раз.
Все эти рогалики-хуялики используют не так много тайлов чтобы обосраться с памятью. Да бля, у меня в скуйриме наверно 4к труселя моей вагини с нормалью занимали больше чем все эти пиксельные обмылки.
Если еще юзать атласы и определять тайлы через них, так вообще должна быть дружбомагия с точки зрения перфоманса.
я просто не пойму это навязчивую идею везде юзать квады.
чем блять 2х2тайла так прям лучше чем один.
как я себе наивно представляю использование тайлов:
- грузим в память (видеопамять?) тайл, а то и атлас.
получаем некий дескриптор и потом используем его для вставки вместо загрузки каждый раз.
Все эти рогалики-хуялики используют не так много тайлов чтобы обосраться с памятью. Да бля, у меня в скуйриме наверно 4к труселя моей вагини с нормалью занимали больше чем все эти пиксельные обмылки.
Если еще юзать атласы и определять тайлы через них, так вообще должна быть дружбомагия с точки зрения перфоманса.
я просто не пойму это навязчивую идею везде юзать квады.
чем блять 2х2тайла так прям лучше чем один.
959 Кб, 3080x1842>>426155
Метатаблица - да, чтобы дёргать методы Chunk'а не пересоздавая каждый раз кучу методов, ибо куча времени тратится/куча пространства жрётся. А чанков может быть МНОГО.
>>426157
Ничего не понял. Чанк, в "коде" - 128х128 тайлов.
Тайл - элемент атласа спрайтов. Без какого либо физона, просто отображение.
На каждый чанк выдаётся по батчу. Батч содержит полный атлас тайлов и двухмерный массив тайлов данного чанка (кстати, лучше бы его линеаризовать, типа, переделать из двухмерного в одномерный. Тогда вычисление элемента по координатам будет примерно такое: pos = (y - 1) * chunksize + x; chunk[pos] = N, и с полной картой сделать то же самое).
>>426158
>>426163
Чанки хранятся и уничтожаются, допустим, проверкой при переходе игрока из одного чанка в другой - сохраняем на хард разницу между сгенерированным и измененниями от игрока в чанке на хард, и удаляем из памяти. С другой стороны соответственно загрузили/сгенерировали. Это же просто!
Квад - это "трафарет", по которому из картинки вырезается прямоугольник. Ну тип у тебя атлас спрайтов (как на пике), и ты нарезаешь его на кучу мелких картинок, точнее - запихиваешь в спрайтбатч весь атлас, и при добавлении нового спрайта в батч - указываешь, каким трафаретом эту картинку обрезать (допустим, x/y/w/h: 64х64-128х64, вторая картинка). Это - стандартная тактика opengl.
Чанк - это наша абстракция определения на карте некоторой тайловой области.
Карта - совокупность чанков. Что не так?
Метатаблица - да, чтобы дёргать методы Chunk'а не пересоздавая каждый раз кучу методов, ибо куча времени тратится/куча пространства жрётся. А чанков может быть МНОГО.
>>426157
Ничего не понял. Чанк, в "коде" - 128х128 тайлов.
Тайл - элемент атласа спрайтов. Без какого либо физона, просто отображение.
На каждый чанк выдаётся по батчу. Батч содержит полный атлас тайлов и двухмерный массив тайлов данного чанка (кстати, лучше бы его линеаризовать, типа, переделать из двухмерного в одномерный. Тогда вычисление элемента по координатам будет примерно такое: pos = (y - 1) * chunksize + x; chunk[pos] = N, и с полной картой сделать то же самое).
>>426158
>>426163
Чанки хранятся и уничтожаются, допустим, проверкой при переходе игрока из одного чанка в другой - сохраняем на хард разницу между сгенерированным и измененниями от игрока в чанке на хард, и удаляем из памяти. С другой стороны соответственно загрузили/сгенерировали. Это же просто!
Квад - это "трафарет", по которому из картинки вырезается прямоугольник. Ну тип у тебя атлас спрайтов (как на пике), и ты нарезаешь его на кучу мелких картинок, точнее - запихиваешь в спрайтбатч весь атлас, и при добавлении нового спрайта в батч - указываешь, каким трафаретом эту картинку обрезать (допустим, x/y/w/h: 64х64-128х64, вторая картинка). Это - стандартная тактика opengl.
Чанк - это наша абстракция определения на карте некоторой тайловой области.
Карта - совокупность чанков. Что не так?
30 Кб, 1485x657>>426158
Во, дополню
Во, дополню
>>426163
Ещё дополню цитатой себя любимого:
Суть: когда у тебя много-много одинаковых спрайтов (или спрайтов, помещённых на одну картинку) - бесполезно рисовать их циклом, типа такого:
for i = 0, map.width - 1 do
for j = 0, map.height - 1
love.graphics.draw(image, imap.tilesize, j map.tilesize)
end
end
Это реально полный трындец: каждый раз когда вызывается love.graphics.draw, новая копия картинки отправляется видеокарте, вместе с параметрами, где и как её рисовать.
spritebatch - это такая хитрая штука, которая выглядит как "одна картинка + много мест где её рисовать".
function love.load()
— Мутим спрайтбатч, с картинкой игровой карты
tilemap = love.graphics.newSpriteBath(img, map.width map.height, 'static')
for i = 0, map.width - 1 do
for j = 0, map.height - 1 do
— добавляем в неё позиции спрайта игровой карты
tilemap:add([quad,] imap.tilesize, j * map.tilesize)
end
end
end
function love.draw()
— Передаём видеокарте одну картинку в spritebatch,
— и кучу мест, где её надо нарисовать
love.graphics.draw(tilemap)
end
Таким образом получается в 100500 раз быстрее.
Квадами можно вырезать из картинки с тайлами, типа той что приведена внизу, отдельные квадратики, и тоже добавлять в spritebatch. Квад = трафарет, по которому мы вырезаем из картинки прямоугольный кусочек, и добавляем в список того, как рисовать весь атлас.
Ещё дополню цитатой себя любимого:
Суть: когда у тебя много-много одинаковых спрайтов (или спрайтов, помещённых на одну картинку) - бесполезно рисовать их циклом, типа такого:
for i = 0, map.width - 1 do
for j = 0, map.height - 1
love.graphics.draw(image, imap.tilesize, j map.tilesize)
end
end
Это реально полный трындец: каждый раз когда вызывается love.graphics.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. Квад = трафарет, по которому мы вырезаем из картинки прямоугольный кусочек, и добавляем в список того, как рисовать весь атлас.
>>426163
Ещё дополню цитатой себя любимого:
Суть: когда у тебя много-много одинаковых спрайтов (или спрайтов, помещённых на одну картинку) - бесполезно рисовать их циклом, типа такого:
for i = 0, map.width - 1 do
for j = 0, map.height - 1
love.graphics.draw(image, imap.tilesize, j map.tilesize)
end
end
Это реально полный трындец: каждый раз когда вызывается love.graphics.draw, новая копия картинки отправляется видеокарте, вместе с параметрами, где и как её рисовать.
spritebatch - это такая хитрая штука, которая выглядит как "одна картинка + много мест где её рисовать".
function love.load()
— Мутим спрайтбатч, с картинкой игровой карты
tilemap = love.graphics.newSpriteBath(img, map.width map.height, 'static')
for i = 0, map.width - 1 do
for j = 0, map.height - 1 do
— добавляем в неё позиции спрайта игровой карты
tilemap:add([quad,] imap.tilesize, j * map.tilesize)
end
end
end
function love.draw()
— Передаём видеокарте одну картинку в spritebatch,
— и кучу мест, где её надо нарисовать
love.graphics.draw(tilemap)
end
Таким образом получается в 100500 раз быстрее.
Квадами можно вырезать из картинки с тайлами, типа той что приведена внизу, отдельные квадратики, и тоже добавлять в spritebatch. Квад = трафарет, по которому мы вырезаем из картинки прямоугольный кусочек, и добавляем в список того, как рисовать весь атлас.
Ещё дополню цитатой себя любимого:
Суть: когда у тебя много-много одинаковых спрайтов (или спрайтов, помещённых на одну картинку) - бесполезно рисовать их циклом, типа такого:
for i = 0, map.width - 1 do
for j = 0, map.height - 1
love.graphics.draw(image, imap.tilesize, j map.tilesize)
end
end
Это реально полный трындец: каждый раз когда вызывается love.graphics.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
глупость сморожу, но что если в цикле их загонять в канвас, а уже потом один раз рисовать канвас.
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 вместо нормальных драйверов.
подумал попробовать откатиться на старые версии. Потому как примеры что я смотрел на фуреме любви практически все тормозили безбожно, впрочем там местные кириллы вообще не парились ни с фпс ни с какой-либо буферизаций, тупо драв и все.
>их циклом, типа такого:
>
>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 можно было дёргать методы.
Большое количество кириллов с форума - не умеют в спрайтбатчи, полностью прогружают гигантские вещи и просто не умеют в оптимизацию. Лове может быть быстрым, но нужно уметь, это не юнька где за тебя всё уже оптимизировали "для сферической задачи".
Да, вместо батча можно использовать канвас.
Типа при загрузке чанка, мы создаём этому чанку канвас (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
Кстати, не понимаю как это может упрощать текстурки, за исключением уровня мипмепа.
За качеством текстурок - смотри 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
Кстати, не понимаю как это может упрощать текстурки, за исключением уровня мипмепа.
>>426492
Хм, символы умножения просираются. Тут можно в code?
[code]
function getRelativeSizedQuad(img, x, y, w, h)
local px, py = img:getDimensions()
return love.graphics.newQuad(px ✶ x, py ✶ y, px ✶ w, py ✶ h, px, py)
end
q = getRelativeSizedQuad(image, 0, 0, 0.2, 0.3)
[/code]
Хм, символы умножения просираются. Тут можно в code?
[code]
function getRelativeSizedQuad(img, x, y, w, h)
local px, py = img:getDimensions()
return love.graphics.newQuad(px ✶ x, py ✶ y, px ✶ w, py ✶ h, px, py)
end
q = getRelativeSizedQuad(image, 0, 0, 0.2, 0.3)
[/code]
>>426481
это понятно, вот например что требует 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. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
>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. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
>>426481
это понятно, вот например что требует 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. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
>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. Ладно сегодня наконец попробую потестить скорость с тайлами. Да я помню какую-то любовь-демку с кучей анимированных объектов. У меня тогда челюсть отвисла, ведь даже некропк справлялся.
>>426492
эм в том-то и дело что не надо ничего писать и вычислять.
тым было на уровне
image = asset('atlas.tex',0.12323,0.1234,0.02323,0.022323)
А дальше саму текстуру можно было уменьшить или вообще один раз задать другой путь для всех ассетов, где валялись уменьшенные текстуры.
Оче удобно. Не нужны никакие магические константы с размерами тайлов. Вообще.
эм в том-то и дело что не надо ничего писать и вычислять.
тым было на уровне
image = asset('atlas.tex',0.12323,0.1234,0.02323,0.022323)
А дальше саму текстуру можно было уменьшить или вообще один раз задать другой путь для всех ассетов, где валялись уменьшенные текстуры.
Оче удобно. Не нужны никакие магические константы с размерами тайлов. Вообще.
>>426513
Если мир - тайловый, то нужны, потому что от этого идёт перенос координат с мировых в тайловые, например. Ну, или плодить каждый тайл отдельной сущностью, с параметрами x/y/w/h, что совсем не круто, ибо жрётся бешеное пространство. Зато в тайловом мире так можно спавнить сущности (кусты/игровые объекты/выброшенные предметы и т.п.) Но их в идеале должно быть сравнительно немного. Если ты заметил, даже в террарии однотипное говно объединяется в стаки при вываливании на землю, ибо жрёт немеряно места. Ну, выбросил ты 9000 кирпичиков земли. Их все надо бы физически обсчитать, или заморозить их физон, разморозить если что-то их касающееся изменилось, например кирпич под ними сломали (для этого нужна мелкая пространственная сетка и эвенты), но если выбросишь слишком много - привет, резкие просадки fps!
Но рисовать их всё равно надо всей кучей, и ту же коллизию калькулировать.
Если мир - тайловый, то нужны, потому что от этого идёт перенос координат с мировых в тайловые, например. Ну, или плодить каждый тайл отдельной сущностью, с параметрами x/y/w/h, что совсем не круто, ибо жрётся бешеное пространство. Зато в тайловом мире так можно спавнить сущности (кусты/игровые объекты/выброшенные предметы и т.п.) Но их в идеале должно быть сравнительно немного. Если ты заметил, даже в террарии однотипное говно объединяется в стаки при вываливании на землю, ибо жрёт немеряно места. Ну, выбросил ты 9000 кирпичиков земли. Их все надо бы физически обсчитать, или заморозить их физон, разморозить если что-то их касающееся изменилось, например кирпич под ними сломали (для этого нужна мелкая пространственная сетка и эвенты), но если выбросишь слишком много - привет, резкие просадки fps!
Но рисовать их всё равно надо всей кучей, и ту же коллизию калькулировать.
>>426513
Ты вообще заметил, что тайловые миры оказываются значительно быстрее/экономичнее по памяти миров, основанных на векторных объектах (особенно с физоном для каждого)?
Ты вообще заметил, что тайловые миры оказываются значительно быстрее/экономичнее по памяти миров, основанных на векторных объектах (особенно с физоном для каждого)?
>>426508
Демка - вот эта? https://love2d.org/forums/viewtopic.php?t=82562
Это потому что каждая зверюшка - элемент батча. Просто этот товарищ умеет в спрайтбатчи, и даже суть демки - показать автоматический батч.
Эту штуку впихнут в следующую версию love2d, тогда можно будет рисовать циклом кучу говна, и оно будет полуоптимально рендерится. Это относится к картинкам и векторным примитивам (не к тексту, увы).
Демка - вот эта? https://love2d.org/forums/viewtopic.php?t=82562
Это потому что каждая зверюшка - элемент батча. Просто этот товарищ умеет в спрайтбатчи, и даже суть демки - показать автоматический батч.
Эту штуку впихнут в следующую версию love2d, тогда можно будет рисовать циклом кучу говна, и оно будет полуоптимально рендерится. Это относится к картинкам и векторным примитивам (не к тексту, увы).
>>426525
в террарии, что-то просрали в последних версиях, там есть ощутимый лаг в одних и техже местах карты (видимо как раз граница загруженных чанков-панков и делая шаг в сторону все это начинает подгружаться) реньше такого не было.
А проблему 9000 кирпичей они вроде решили куда проще - там вроде как есть лимит на количество отображаемых объектов. После которого новые тупо не отобразятся пока не подберешь старое. Ну и плюс они там не валяются вечно а со временем исчезают.
По-поводу отдельных тредов/потоков я спрашивал тоже с огдядкой на террарию. Например, там corruption/hollow постепенно расрастался по всей карте, независимо от положения игрока. Добавь сюда расчет перелива жидкостей и рост травки - ну ни как такое не обработать за один цикл update. Уверен что там это как-то просчитывается параллельно.
в террарии, что-то просрали в последних версиях, там есть ощутимый лаг в одних и техже местах карты (видимо как раз граница загруженных чанков-панков и делая шаг в сторону все это начинает подгружаться) реньше такого не было.
А проблему 9000 кирпичей они вроде решили куда проще - там вроде как есть лимит на количество отображаемых объектов. После которого новые тупо не отобразятся пока не подберешь старое. Ну и плюс они там не валяются вечно а со временем исчезают.
По-поводу отдельных тредов/потоков я спрашивал тоже с огдядкой на террарию. Например, там corruption/hollow постепенно расрастался по всей карте, независимо от положения игрока. Добавь сюда расчет перелива жидкостей и рост травки - ну ни как такое не обработать за один цикл update. Уверен что там это как-то просчитывается параллельно.
>>426531
На тему corruption/hollow, смотри в чём прекол:
1. У нас есть некоторая функция, по которой генерируется/распространяется биом.
2. Каждый чанк имеет некоторое "время с начала мира".
3. Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти.
Это читерный способ. То же самое можно с растениями: запоминаем время посадки и выгружаем чанк. Когда чанк загружается снова - рассчитываем разницу во времени между предыдущим состоянием и текущим, добавляем рандома и вот, наше растение выросло пока нас не было. Аналогичным образом работают всякие куки-кликеры, в которых печеньки копятся даже при закрытом браузере (но в webstorage есть время выхода!)
На тему corruption/hollow, смотри в чём прекол:
1. У нас есть некоторая функция, по которой генерируется/распространяется биом.
2. Каждый чанк имеет некоторое "время с начала мира".
3. Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти.
Это читерный способ. То же самое можно с растениями: запоминаем время посадки и выгружаем чанк. Когда чанк загружается снова - рассчитываем разницу во времени между предыдущим состоянием и текущим, добавляем рандома и вот, наше растение выросло пока нас не было. Аналогичным образом работают всякие куки-кликеры, в которых печеньки копятся даже при закрытом браузере (но в webstorage есть время выхода!)
>>426531
Пардон, дополню ещё раз.
Перелив жидкостей - это вообще отдельная тема. Жидкости динамические по сути своей.
Считай что жидкость считает последний загруженный чанк твёрдой границей, и не льётся дальше. Сам проверь, попыткой слить океан в ад. Когда ты в аду, вода сверху перестаёт течь потому что чанк с бесконечной водой выгружен, а те которые активны в данный момент - уже слили воду.
И да, держать в памяти стоит чуть больше чанков: условно, если рендерим мы девять штук, то в памяти, чтобы не было лагов, держим штук двадцать-тридцать, на всяк случ. И можно предугадывать загрузку при движении: игрок падает вниз -> предполагаем что он будет падать ещё некоторое время -> загружаем сразу пачку чанков снизу, но рисовать продолжаем только те, которые влезают в камеру.
Кстати, для исследования террарии советую собрать нищеноутбук с очень медленным хардом. При падении с высоты, можно заметить насколько далеко прогружаются и рендерятся чанки: видно как из пустоты возникает почва, когда прогружается. С ранними билдами старбаунда - та же фигня.
Пардон, дополню ещё раз.
Перелив жидкостей - это вообще отдельная тема. Жидкости динамические по сути своей.
Считай что жидкость считает последний загруженный чанк твёрдой границей, и не льётся дальше. Сам проверь, попыткой слить океан в ад. Когда ты в аду, вода сверху перестаёт течь потому что чанк с бесконечной водой выгружен, а те которые активны в данный момент - уже слили воду.
И да, держать в памяти стоит чуть больше чанков: условно, если рендерим мы девять штук, то в памяти, чтобы не было лагов, держим штук двадцать-тридцать, на всяк случ. И можно предугадывать загрузку при движении: игрок падает вниз -> предполагаем что он будет падать ещё некоторое время -> загружаем сразу пачку чанков снизу, но рисовать продолжаем только те, которые влезают в камеру.
Кстати, для исследования террарии советую собрать нищеноутбук с очень медленным хардом. При падении с высоты, можно заметить насколько далеко прогружаются и рендерятся чанки: видно как из пустоты возникает почва, когда прогружается. С ранними билдами старбаунда - та же фигня.
>>426530
да она, правда с дефолтным количество котов в 4000 некропека выдает 6фпс, но с "всего лишь" 1000ю уже 24. Для меня такое количество в любом случае оверкил, поэтому и впечатлило.
да она, правда с дефолтным количество котов в 4000 некропека выдает 6фпс, но с "всего лишь" 1000ю уже 24. Для меня такое количество в любом случае оверкил, поэтому и впечатлило.
>>426562
И это ещё не самый оптимальный способ применения батчей. Можно быстрее, правда, вокруг этого придётся мутить весь рендер.
а) батч, при добавлении спрайта, возвращает его ID. Это позволяет модифицировать то что мы рендерили без перезагрузки всех данных в видеокарту. Ну там, кадры менять, или двигать или и то и то.
б) Батчи имеют несколько режимов оптимизаций (static/dynamic/stream). Угадай, какой самый эффективный для тайловой карты.
в) Товарищ в своей либе, после каждого draw выдаёт batch:flush. Это сжирает приличное время.
И это ещё не самый оптимальный способ применения батчей. Можно быстрее, правда, вокруг этого придётся мутить весь рендер.
а) батч, при добавлении спрайта, возвращает его ID. Это позволяет модифицировать то что мы рендерили без перезагрузки всех данных в видеокарту. Ну там, кадры менять, или двигать или и то и то.
б) Батчи имеют несколько режимов оптимизаций (static/dynamic/stream). Угадай, какой самый эффективный для тайловой карты.
в) Товарищ в своей либе, после каждого draw выдаёт batch:flush. Это сжирает приличное время.
>>426543
В донтстарве так и делают, все, что за пределами текущего экрана и по 2-3 экрана с каждой стороны - спит. Потом когда подходишь к усыпленной сущности, то вызывается longupdate.
>Когда мы появляемся в чанке, сравниваем время от начала мира с текущим, и обновляем его в соответствии с изменениями, которые должны были в нём произойти.
В донтстарве так и делают, все, что за пределами текущего экрана и по 2-3 экрана с каждой стороны - спит. Потом когда подходишь к усыпленной сущности, то вызывается longupdate.
кстати, а использование png как-то отражается на рендере?
или там при загрузке тайла все преобразуется в какой-то свой распакованный формат и не занимаются херней?
в том же DS позволенно лишь использовать текстуру в определенном формате. Все эти пнг идут лесом.
или там при загрузке тайла все преобразуется в какой-то свой распакованный формат и не занимаются херней?
в том же DS позволенно лишь использовать текстуру в определенном формате. Все эти пнг идут лесом.
331 Кб, 1601x1017>>426578
Свой формат, раньше можно было грузить джипеги, а сейчас нет (хз почему, мб лицензии).
Для канвасов - отдельный набор форматов:
https://love2d.org/wiki/CanvasFormat
Это сделано для оптимизаций размеров/занимаемой памяти.
Есть тип данных ImageData:
https://love2d.org/wiki/ImageData
Его суть в том, что из этой фигни можно генерить картинки, а ещё, писать свои упаковщики/распаковщики произвольного формата в данный:
функцией mapPixel можно грузить картинки, например, из rgba8. На пике пример.
Свой формат, раньше можно было грузить джипеги, а сейчас нет (хз почему, мб лицензии).
Для канвасов - отдельный набор форматов:
https://love2d.org/wiki/CanvasFormat
Это сделано для оптимизаций размеров/занимаемой памяти.
Есть тип данных ImageData:
https://love2d.org/wiki/ImageData
Его суть в том, что из этой фигни можно генерить картинки, а ещё, писать свои упаковщики/распаковщики произвольного формата в данный:
функцией 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
достаточно же лишь один раз определить и за пределами двух циклов.
но чувак реально рулит. Взял да и переопределил стандартный объект, а значит для кириллов достаточно лишь подключить файл.
Забавно, его почти никто не юзает....
еще странно что он размер картинки кота зачем-то вычисляет внутри цикла
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
достаточно же лишь один раз определить и за пределами двух циклов.
но чувак реально рулит. Взял да и переопределил стандартный объект, а значит для кириллов достаточно лишь подключить файл.
Забавно, его почти никто не юзает....
>>426696
Ну, это же вызывается один раз, а не каждый кадр, так что всё пучком.
Ну, это же вызывается один раз, а не каждый кадр, так что всё пучком.
98 Кб, 800x600у него там еще демка со звездами.
прикрутил туда ограничение на fps - просто песня. 1000 звезд вращается и перемещается, 15фпс (на удивление сносно выглядит без дерганий, 25-30 конечно лучше) , меньше 40% загрузки некропроца(900мгц) и он вырубает активное охлаждение. В результате тишина.
10/10
Осталось лишь запилить шедевр и грести зимбабвийские баксы лопатой.
Ну вообще-то любовь годна не только для игрушек. Оче просто сделать визуализацию чего-то полезного. Например наглядную историю изменений в git/svn и тп. Яваскрипт бы обосрался от 1000 звезд даже на i7.
И все кросплатформенно, бесплатно и шустро.
прикрутил туда ограничение на fps - просто песня. 1000 звезд вращается и перемещается, 15фпс (на удивление сносно выглядит без дерганий, 25-30 конечно лучше) , меньше 40% загрузки некропроца(900мгц) и он вырубает активное охлаждение. В результате тишина.
10/10
Осталось лишь запилить шедевр и грести зимбабвийские баксы лопатой.
Ну вообще-то любовь годна не только для игрушек. Оче просто сделать визуализацию чего-то полезного. Например наглядную историю изменений в git/svn и тп. Яваскрипт бы обосрался от 1000 звезд даже на i7.
И все кросплатформенно, бесплатно и шустро.
>>426709
На i5/печ760 выдаёт 96 fps на котиках. Мне норм.
На i5/печ760 выдаёт 96 fps на котиках. Мне норм.
>>426696
Это будет по дефолту в следующей ловке.
Это будет по дефолту в следующей ловке.
>>426709
v8 с webgl не обосрутся от тысячи звёзд на i7 если есть видеокарта :3
Но да, ловка примерно в пять-десять раз быстрее, хотя бы за счёт отсутствия бешеного количества прослоек жаваскрипт/браузер/opengl. С лове похожая ситуация (lua/c-core/opengl), но оптимизация на месте, плюс luajit откровенно не даёт оверхеда на переключение между контекстами, это охренительная прибавка.
v8 с webgl не обосрутся от тысячи звёзд на i7 если есть видеокарта :3
Но да, ловка примерно в пять-десять раз быстрее, хотя бы за счёт отсутствия бешеного количества прослоек жаваскрипт/браузер/opengl. С лове похожая ситуация (lua/c-core/opengl), но оптимизация на месте, плюс luajit откровенно не даёт оверхеда на переключение между контекстами, это охренительная прибавка.
153 Кб, 500x500>>426786
вангую, что там будет еще нехилое различие по потребляемой памяти.
если еще учесть, что луа запустится даже на кофемолке с мегабайтом памяти (на самом деле вроде даже килобайтах), то хипстерское js-поделие уже в аутсайдерах.
так что любовь победит и тут.
Особенно если учитывать как в js на каждый чих создается объект и отсутствие integer в принципе.
итого дикий оверхед для простого массива.
У луа жи есть это ваше FFI, которое мне надо будет вкурить, но подозреваю что это чит, реализующий строгую типизацию и убирающий тот самый оверхед из-за нестрогой.
вангую, что там будет еще нехилое различие по потребляемой памяти.
если еще учесть, что луа запустится даже на кофемолке с мегабайтом памяти (на самом деле вроде даже килобайтах), то хипстерское js-поделие уже в аутсайдерах.
так что любовь победит и тут.
Особенно если учитывать как в js на каждый чих создается объект и отсутствие integer в принципе.
итого дикий оверхед для простого массива.
У луа жи есть это ваше FFI, которое мне надо будет вкурить, но подозреваю что это чит, реализующий строгую типизацию и убирающий тот самый оверхед из-за нестрогой.
>>426790
ffi = "пишем на луа на сишке", со всеми профитами, плюс подрубание произвольных сишных библиотек, с прописыванием хедера в cdef, с отсутствием оверхеда и прочей милотой.
Рекомендую.
ffi = "пишем на луа на сишке", со всеми профитами, плюс подрубание произвольных сишных библиотек, с прописыванием хедера в cdef, с отсутствием оверхеда и прочей милотой.
Рекомендую.
>>426790
Оу, кстати, у меня где-то валялась ffi-векторная либка. https://pastebin.com/i7qC1aKn
В качестве вектора используется сишная структура (x, y), к которой прицеплена метатаблица для перегрузки арифметики/методов. Мгновенно создаются и обсчитываются сотни и тысячи векторов, плюс сахарок.
Оу, кстати, у меня где-то валялась ffi-векторная либка. https://pastebin.com/i7qC1aKn
В качестве вектора используется сишная структура (x, y), к которой прицеплена метатаблица для перегрузки арифметики/методов. Мгновенно создаются и обсчитываются сотни и тысячи векторов, плюс сахарок.
>>426796
Карочи, посоны, мне стало лень делать кучу всего, поэтому вот тут есть что-то похожее на движок. Как раз те самые танчики. Система сущностей, колбеки на столкновения и всё говно.
Заодно можно посмотреть как риальные поцоны делают проекты.
https://bitbucket.org/MainTomato/tank-o-box/src/67a4bc1def45708424f9facc09b8b04102c36433/?at=develop
Карочи, посоны, мне стало лень делать кучу всего, поэтому вот тут есть что-то похожее на движок. Как раз те самые танчики. Система сущностей, колбеки на столкновения и всё говно.
Заодно можно посмотреть как риальные поцоны делают проекты.
https://bitbucket.org/MainTomato/tank-o-box/src/67a4bc1def45708424f9facc09b8b04102c36433/?at=develop
111 Кб, 693x600Ох щит, так у луа тоже целых нету.
На массив типа намбер 1000х1000 тратится 8000К
то есть по 8 байт на ячейку, еба. Значит ебашут флоат.
ну ебана, хотеть однобайтовый массив.
асло если пыриться в collectgarbage('count'), то каждую секунду проебывается по килобайту. Одно радует 'collect' мгновенно.
А вообще чому течет? уничтожение локальных переменных/функций внутри других функций выполняется отложенно? Я прост не понимаю откуда вообще взяться 'утечкам'.
Пошел пыриться в FFI. Ебал я в рот столько тратить на массив 1-2битовых значений.
На массив типа намбер 1000х1000 тратится 8000К
то есть по 8 байт на ячейку, еба. Значит ебашут флоат.
ну ебана, хотеть однобайтовый массив.
асло если пыриться в collectgarbage('count'), то каждую секунду проебывается по килобайту. Одно радует 'collect' мгновенно.
А вообще чому течет? уничтожение локальных переменных/функций внутри других функций выполняется отложенно? Я прост не понимаю откуда вообще взяться 'утечкам'.
Пошел пыриться в FFI. Ебал я в рот столько тратить на массив 1-2битовых значений.
27 Кб, 464x387заменил двумерный луа 1000х1000 массив на чит:
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, который хуй пойми какого типа.
Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
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, который хуй пойми какого типа.
Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
27 Кб, 464x387заменил двумерный луа 1000х1000 массив на чит:
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, который хуй пойми какого типа.
Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
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, который хуй пойми какого типа.
Или надо использовать сишные функции для присваивания/чтения значения из подобных массивов?
Мгновенный репорт вниманиеблядка >>426985
>>426985
http://luajit.org/ext_ffi_semantics.html
Кстати да, я особо ничего не имею против сусеки, но давай аккуратнее.
>И вообще так можно пользовать? lua же будет пытаться впихнуть свой number, который хуй пойми какого типа.
http://luajit.org/ext_ffi_semantics.html
Кстати да, я особо ничего не имею против сусеки, но давай аккуратнее.
>>427127
все равно нихрена не понял
Conversions from Lua objects to C types
number→double
то есть при присвоении ffi-массиву оно будет использовать double значение, а С потом приведет к uint8?
что произойдет если lua-значение превысит допустимый диапозон, скажем будет 256?
еще как можно юзать битовые маски? ведь интежер не завезли.
если для тру интежер будет сгенерен кода наподобие
and EAX, 0xFF
то с вещественными хуй пойми как он там оперирует и насколько это будет тормозить для эмуляции целого.
или все битовые операции лучше проводить силами того же FFI используя сишные операторы?
как же бесит, ну вот кому пришла замечательная идея избавиться от integer.
тут пишут что в 5.3 добавили
https://stackoverflow.com/questions/4484437/lua-integer-type
Но love использует luajit, который в свою очередь - 5.1. SOOOOOQAAA
все равно нихрена не понял
Conversions from Lua objects to C types
number→double
то есть при присвоении ffi-массиву оно будет использовать double значение, а С потом приведет к uint8?
что произойдет если lua-значение превысит допустимый диапозон, скажем будет 256?
еще как можно юзать битовые маски? ведь интежер не завезли.
если для тру интежер будет сгенерен кода наподобие
and EAX, 0xFF
то с вещественными хуй пойми как он там оперирует и насколько это будет тормозить для эмуляции целого.
или все битовые операции лучше проводить силами того же FFI используя сишные операторы?
как же бесит, ну вот кому пришла замечательная идея избавиться от integer.
тут пишут что в 5.3 добавили
https://stackoverflow.com/questions/4484437/lua-integer-type
Но love использует luajit, который в свою очередь - 5.1. SOOOOOQAAA
>>427189
Ну тип ты можешь сделать так:
buf = ffi.new('unsigned char[?]', 4)
for i = 0, 3 do buf = math.random(255) end
И это будет Тру char'ы.
Что сложного?
Ну тип ты можешь сделать так:
buf = ffi.new('unsigned char[?]', 4)
for i = 0, 3 do buf = math.random(255) end
И это будет Тру char'ы.
Что сложного?
>>427189
Да, конечно, числа будут приведены к соответствующему сишному типу. Тогда если ты прибавишь единичку к 255 char'а, оно примет значение 1.
Ты давай не выёбывайся и не бомби, а изучай и ебош.
Да, конечно, числа будут приведены к соответствующему сишному типу. Тогда если ты прибавишь единичку к 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 и поиметь ВЫИГРЫШ в производительности, т.к. ничего не требуется преобразовывать?
я в си совершенно не бум бум, но равзе 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 и поиметь ВЫИГРЫШ в производительности, т.к. ничего не требуется преобразовывать?
>>427221
ващет должно обнулиться, но продолжу ебошить.
а если бы понадобилось однобайтовое со знаком, то що? char уже не катит.
> ты прибавишь единичку к 255 char'а, оно примет значение 1.
ващет должно обнулиться, но продолжу ебошить.
а если бы понадобилось однобайтовое со знаком, то що? char уже не катит.
>>427257
Да, в нуль скатится, меня подглюкивает.
Луашные float'ы нормально преобразуются в сишные типы при загонянии соответствующего значения.
А если тебе нужен со знаком - тогда просто char же.
Ну ёпт.
В char можно запихивать луашные флоаты -128-127,
в unsigned можно пихать те же флоаты в диапазоне 0-255, и т.п.
Тот факт что в луа все числа флоатами - напротив довольно неплохо: вычисления стоит проводить с максимальной точностью, когда хранить - с пониженной. Знаешь что такое накапливающиеся ошибки?
P.S. В сях - все значения это числа. Просто char часто используют в качестве строк, но это всё равно числа 0-255. И с ними можно производить арифметику. Там нет строк в классическом смысле, но при строковой интерпретации, массив байтов НЕОЖИДАННО оказывается строчкой. Главное - не забывать про терминатор.
Да, в нуль скатится, меня подглюкивает.
Луашные 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 осилили.
97 Кб, 870x838>>427312
Integer в lua 5.3 - 64-битные, занимает те же восемь байт. Так что можешь упороться.
boolean в луа - отдельный тип, он как раз (как ни странно) однобайтный, по моему, не знаю точно.
Ну а ты чо? Дали тебе ffi, рассказали что можно сделать нормальную оболочку над сишкой и дёргать её из луа.
Радовался бы, так нет, надо флудить и бомбить, как будто тебе десять лет.
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) {}
все, еба. И память не расходуется и битики можно гонять и все довольны.
вместо деления/умножения на степерь двойки - битовый сдвиг и тп.
сравни большие числа, там где мантисса присутсвует.
не сможешь, ты сможешь лишь проверить, что их разница меньше некоторой заданной константы (точность) аля 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
даже если так - похуй. можно легко вытащить требуемый байт двумя арифметическими сдвигами, которые потребляют 1 или пару тактов проца.
хуй там плавал. Создаешь табличку и загоняешь туда одни лишь true. Результат - те же 8 байт на ячейку. Спецом замерял этим вашим гарбадж коллектором.
>Integer в lua 5.3 - 64-битные, занимает те же восемь байт. Так что можешь упороться.
даже если так - похуй. можно легко вытащить требуемый байт двумя арифметическими сдвигами, которые потребляют 1 или пару тактов проца.
>boolean в луа - отдельный тип, он как раз (как ни странно) однобайтный, по моему, не знаю точно.
хуй там плавал. Создаешь табличку и загоняешь туда одни лишь true. Результат - те же 8 байт на ячейку. Спецом замерял этим вашим гарбадж коллектором.
>>427329
когда массив занимает в 8 раз больше чем требуется, то это не бесполезный дроч, особенно когда предполагается большая размерность и массив далеко не один.
когда массив занимает в 8 раз больше чем требуется, то это не бесполезный дроч, особенно когда предполагается большая размерность и массив далеко не один.
>>427329
15000х5000 тайлов в ванильной луа - генерится пять минут и занимает 9гб, когда как ffi - мгновенен и жрёт 150мб памяти.
15000х5000 тайлов в ванильной луа - генерится пять минут и занимает 9гб, когда как ffi - мгновенен и жрёт 150мб памяти.
>>427337
Ну и катись отсюда, для тебя придумали сишку, асм и машинные коды.
Обмазывайся там своими байтоёбствами.
Ну и катись отсюда, для тебя придумали сишку, асм и машинные коды.
Обмазывайся там своими байтоёбствами.
>>427337
Тот факт что скриптовая луа имеет такие фичи - уже повод молиться на майка пола.
А ты иди нах )))
Тот факт что скриптовая луа имеет такие фичи - уже повод молиться на майка пола.
А ты иди нах )))
>>427342
Тебе три, блять, раза рассказали и даже показали как писать на сишке на луа, со всеми профитами сишных структур, переносимостью и скоростью исполнения. FFI ещё и включает в себя либу битовых операций, обмазывайся сколько влезет.
А в js/php инты - занимают столько же места сколько флоаты (64 бита), там аналогичная хуйня.
Так что или учись или съеби, мудила.
Тебе три, блять, раза рассказали и даже показали как писать на сишке на луа, со всеми профитами сишных структур, переносимостью и скоростью исполнения. FFI ещё и включает в себя либу битовых операций, обмазывайся сколько влезет.
А в js/php инты - занимают столько же места сколько флоаты (64 бита), там аналогичная хуйня.
Так что или учись или съеби, мудила.
>>427361
дык я и пытаюсь, знал бы ебучий С, не выябывавлся бы :)
js/php совершенно другая песня. первый вообще не создан был для больших объемов, второй живет доли секунды и итераторов/мемкешей/субд хватает.
дык я и пытаюсь, знал бы ебучий С, не выябывавлся бы :)
js/php совершенно другая песня. первый вообще не создан был для больших объемов, второй живет доли секунды и итераторов/мемкешей/субд хватает.
>>427369
Это то, что не надо "пытаться" сделать. Попытка подразумевает шанс провала.
Это нужно просто взять и сделать.
Взять книжку K&C, почитать, сделать мелкую хуёвину (типа крестиков-ноликов в консоли), понять как работают разные типы данных и всё тут, дальше можно продолжать.
И да, что непонятного в использовании ffi? Ты объявляешь переменную/массив так же как это было бы в луа или в сишке, и точно так же с ним работаешь.
Это не рокет-саенс, тут всё очень тупо даже для пхпшника который почитал про типы данных.
Чего расселся? Иди баловаться, бля.
Это то, что не надо "пытаться" сделать. Попытка подразумевает шанс провала.
Это нужно просто взять и сделать.
Взять книжку K&C, почитать, сделать мелкую хуёвину (типа крестиков-ноликов в консоли), понять как работают разные типы данных и всё тут, дальше можно продолжать.
И да, что непонятного в использовании ffi? Ты объявляешь переменную/массив так же как это было бы в луа или в сишке, и точно так же с ним работаешь.
Это не рокет-саенс, тут всё очень тупо даже для пхпшника который почитал про типы данных.
Чего расселся? Иди баловаться, бля.
>>427369
Из данной фразы следует вывод, что незнание плодит выебоны.
> дык я и пытаюсь, знал бы ебучий С, не выябывавлся бы
Из данной фразы следует вывод, что незнание плодит выебоны.
>>427418
А чего так упорото? Я тоже успел написать gol, но там были классические правила.
А чего так упорото? Я тоже успел написать gol, но там были классические правила.
>>427444
батчи-квады
если еще ту библиотечку подрубить, то пара фпс проебется somehow
теперь мой внутренний Кирилл говорит мне, что надо замутить очередь задач.
Тип есть несколько параметров, влияющих на производительность:
- собственно fps, тут все понятно. Лимитуем, появляется больше ресурсов для расчетиков в update()
- допустимое количество итераций update(), для генерации следующего состояния игры. Ну там мобье аналайзит свое окружение, агрится на вражин, расчет пасфиндинга и прочая пежня. На примере игры в жизть экспериментально получил от 5 до 15 тактов. Дальше уже как-то грустна.
- размер карты (массива), где это все обсчитывается. С игрой в жизть тут не читернешь с длинными апдейтами чанков за пределами камеры, нужно все обсчитывать.
Зойчем вообще это все нужна. Мой внутренний Кирилл глаголит - предположим что необходимо сгенерить новый эвент НОЧЬ ДЛИННЫХ НОЖЕЙ. А это значит надо подгрузить тайлы, музяку и еще какую пежню, которая может быть далеко не копеешной. Вместо того, чтобы загрузить все разом и пролагаться - предполагается все загрузить за X итераций, расчитать что необходимо и по готовности начать эвент.
Мой внутренний Кирилл - уебан?
батчи-квады
если еще ту библиотечку подрубить, то пара фпс проебется somehow
теперь мой внутренний Кирилл говорит мне, что надо замутить очередь задач.
Тип есть несколько параметров, влияющих на производительность:
- собственно fps, тут все понятно. Лимитуем, появляется больше ресурсов для расчетиков в update()
- допустимое количество итераций update(), для генерации следующего состояния игры. Ну там мобье аналайзит свое окружение, агрится на вражин, расчет пасфиндинга и прочая пежня. На примере игры в жизть экспериментально получил от 5 до 15 тактов. Дальше уже как-то грустна.
- размер карты (массива), где это все обсчитывается. С игрой в жизть тут не читернешь с длинными апдейтами чанков за пределами камеры, нужно все обсчитывать.
Зойчем вообще это все нужна. Мой внутренний Кирилл глаголит - предположим что необходимо сгенерить новый эвент НОЧЬ ДЛИННЫХ НОЖЕЙ. А это значит надо подгрузить тайлы, музяку и еще какую пежню, которая может быть далеко не копеешной. Вместо того, чтобы загрузить все разом и пролагаться - предполагается все загрузить за X итераций, расчитать что необходимо и по готовности начать эвент.
Мой внутренний Кирилл - уебан?
>>428228
Меньше швабодки но есть встроенный admob, не надо пересобирать двигло с прописыванием бриджа от lua до java.
И многое упрощено. Если в лове - ничего нет, то в короне есть куча всякой лабуды. Мне предлагали работу в короне: там есть проект портирования её на luajit.
Меньше швабодки но есть встроенный admob, не надо пересобирать двигло с прописыванием бриджа от lua до java.
И многое упрощено. Если в лове - ничего нет, то в короне есть куча всякой лабуды. Мне предлагали работу в короне: там есть проект портирования её на luajit.
Есть к этому чуду хоть минимально нерукожопая GUI библиотечка? Только не на уровне рисования квадратных чёрных кнопок, а что-нибудь посерьёзнее. Я заебался велосипеды педалить
>>425534
В отдельном треде. Очевидно же.
В отдельном треде. Очевидно же.
>>434104
Хоть одну сам использовал? Большинство по виду какие то васяноподелия, да ещё и попахивающие
Хоть одну сам использовал? Большинство по виду какие то васяноподелия, да ещё и попахивающие
>>426924
ffi.new("char[100500]")
ffi.new("char[100500]")
>>434106
Бери имгуй и не выебывайся. На оффициальном форуме целый трендж есть.
Бери имгуй и не выебывайся. На оффициальном форуме целый трендж есть.
>>434106
Хочешь оФФициальную? Пиши сам, продвигай чтобы использовали, собирай инфу на тему "что подправить чтобы было зашибись", поддерживай, обновляй до новых версий love2d и т.д.
Хочешь оФФициальную? Пиши сам, продвигай чтобы использовали, собирай инфу на тему "что подправить чтобы было зашибись", поддерживай, обновляй до новых версий love2d и т.д.
>>436224
Вот в этом и проблема LOVE как движка. Нихуя нет, кроме самой базы, всё работает на языке, в котором тоже нихуя нет кроме самой базы. Всё как в JS, только коммьюнити на порядки меньше, поэтому и либы все -
древнее говно.
Короче, не ебитесь с этим лавом, переезжайте на Godot, там грядёт эпик вин в виде 3.0 версии.
Я кончил.
Год ебался с LOVE-кун
Вот в этом и проблема LOVE как движка. Нихуя нет, кроме самой базы, всё работает на языке, в котором тоже нихуя нет кроме самой базы. Всё как в JS, только коммьюнити на порядки меньше, поэтому и либы все -
древнее говно.
Короче, не ебитесь с этим лавом, переезжайте на Godot, там грядёт эпик вин в виде 3.0 версии.
Я кончил.
Год ебался с LOVE-кун
126 Кб, 1686x552>>436267
Движок?
Опачки, а где тут хоть одно слово "engine"? Ни одного не видно. Ой, а что это за незнакомое слово "framework"? Опачки, а это и не движок!
В этом и прелесть LOVE как фреймворка: ничего нет, ничто не привязывает тебя к конкретной структуре/архитектуре, хуярь как хочешь, ошибайся, делай новое только лучше, потом становишься мастером дзен и уходишь в программисты с зп >100к. Так и сделал.
Движок?
Опачки, а где тут хоть одно слово "engine"? Ни одного не видно. Ой, а что это за незнакомое слово "framework"? Опачки, а это и не движок!
В этом и прелесть LOVE как фреймворка: ничего нет, ничто не привязывает тебя к конкретной структуре/архитектуре, хуярь как хочешь, ошибайся, делай новое только лучше, потом становишься мастером дзен и уходишь в программисты с зп >100к. Так и сделал.
>>436273
Ну дык это и не движок, что ты хочешь
Ну дык это и не движок, что ты хочешь
>>436267
Ты просто мамкин неосилятор, который не умеет в архитектуру приложений сложнее чем helloworld. Простые вещи тут делать в три раза быстрее чем на годоте, а для чуть более сложных - нужно мутить движок. Движок - это как раз система связей между объектами, рендером, звучками и всем прочим.
Ты просто мамкин неосилятор, который не умеет в архитектуру приложений сложнее чем helloworld. Простые вещи тут делать в три раза быстрее чем на годоте, а для чуть более сложных - нужно мутить движок. Движок - это как раз система связей между объектами, рендером, звучками и всем прочим.
> Ждва года ебался, понял что к чему, начал охуенно ебошить.
>>436303
ты сам понимаешь, что ты несешь?
>вот картинку нарисовать на экране проще, чем в годоте!
>а вот для более сложных вещей нужно запилить свою плохую версию годота!
>ты просто не понимаешь всех преимуществ этого чудесного не движка
ты сам понимаешь, что ты несешь?
>>436385
Тебя просто опустили а ты кукарекаешь.
Вот, старого педика почитай, что ли на досуге, дельные вещи графоманит:
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
Тебя просто опустили а ты кукарекаешь.
Вот, старого педика почитай, что ли на досуге, дельные вещи графоманит:
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
>>436389
я не годотфанатик, но после этого высера
читать не стал. Единсвенная причина так делать - бесдисковая станция, да и то там проще будет по rdp-like протоколу работать.
NFS жи - локалочка, DMZ между серверами, порою с резервированием каналов (X сетевушечек как одна для предотвращения проблем с илнками/портами/и тп)
Только полный даун будет использовать NFS прост для домашн директории ))). Так как работа с мелкими файлами там будет существенно медленней чем с неторопливым 5000rpm IDE
я не годотфанатик, но после этого высера
>Если домашние директории лежат на дисках, подмонтированных по NFS (одна абстракция)
читать не стал. Единсвенная причина так делать - бесдисковая станция, да и то там проще будет по rdp-like протоколу работать.
NFS жи - локалочка, DMZ между серверами, порою с резервированием каналов (X сетевушечек как одна для предотвращения проблем с илнками/портами/и тп)
Только полный даун будет использовать NFS прост для домашн директории ))). Так как работа с мелкими файлами там будет существенно медленней чем с неторопливым 5000rpm IDE
Бля эти годот пидоры еще изобрели свой велосипедоскрипт, который еще согасно докам умудряется работать медленее с массивами одного типа аля ByteArray.
Уж лучше с FFI поебстись.
Уж лучше с FFI поебстись.
60 Кб, 540x960Лучше по топику задам вопросец:
как местные гуру генерят карты с тайлами? Хранят в массивах (json/xml)? В картинках, где цвет пикселя определяет тайл. Или еще как?
как местные гуру генерят карты с тайлами? Хранят в массивах (json/xml)? В картинках, где цвет пикселя определяет тайл. Или еще как?
https://www.youtube.com/watch?v=S6jqR7wmnw4
асло пример как человек ебется с тайлами в годоте.
а шо, если я захочу бесконечную карту с генерящимеся/подгружающимеся на ходу тайлами? в луа тебя ограничивает лишь твоя фантазия и лень.
В годоте - похоже невозможно в принципе.
асло пример как человек ебется с тайлами в годоте.
а шо, если я захочу бесконечную карту с генерящимеся/подгружающимеся на ходу тайлами? в луа тебя ограничивает лишь твоя фантазия и лень.
В годоте - похоже невозможно в принципе.
>>436403
Алё, дядь, ноды в годоте можно и из кода инстансить. Вешаешь на карту какой-нибудь MapGenerator, которому прописываешь инстансить новые локации в зависимости от положения игрока. Старые не забываешь удалять, если не 100 гигов оперативы.
>>436402
https://love2d.org/wiki/Tiled
Алё, дядь, ноды в годоте можно и из кода инстансить. Вешаешь на карту какой-нибудь MapGenerator, которому прописываешь инстансить новые локации в зависимости от положения игрока. Старые не забываешь удалять, если не 100 гигов оперативы.
>>436402
https://love2d.org/wiki/Tiled
>>436398
В 3.0 можешь ебаться в уютненьком Godot'е с любым ЯП. Гугли GDNative.
И поясни, где ты нашел такую хуйню
Искренне твой, годот пидор
В 3.0 можешь ебаться в уютненьком Godot'е с любым ЯП. Гугли GDNative.
И поясни, где ты нашел такую хуйню
>который еще согасно докам умудряется работать >медленее с массивами одного типа
Искренне твой, годот пидор
>>436417
http://docs.godotengine.org/en/stable/learning/scripting/gdscript/gdscript_basics.html
GDScript arrays are allocated linearly in memory for speed. Very large arrays (more than tens of thousands of elements) may however cause memory fragmentation. If this is a concern special types of arrays are available. These only accept a single data type. They avoid memory fragmentation and also use less memory but are atomic and tend to run slower than generic arrays. They are therefore only recommended to use for very large data sets:
ByteArray: An array of bytes (integers from 0 to 255).
IntArray: An array of integers.
FloatArray: An array of floats.
StringArray: An array of strings.
Vector2Array: An array of Vector2 objects.
Vector3Array: An array of Vector3 objects.
ColorArray: An array of Color objects.
тутачки. я даж не знаю как можно было умудриться сделать slower.
http://docs.godotengine.org/en/stable/learning/scripting/gdscript/gdscript_basics.html
GDScript arrays are allocated linearly in memory for speed. Very large arrays (more than tens of thousands of elements) may however cause memory fragmentation. If this is a concern special types of arrays are available. These only accept a single data type. They avoid memory fragmentation and also use less memory but are atomic and tend to run slower than generic arrays. They are therefore only recommended to use for very large data sets:
ByteArray: An array of bytes (integers from 0 to 255).
IntArray: An array of integers.
FloatArray: An array of floats.
StringArray: An array of strings.
Vector2Array: An array of Vector2 objects.
Vector3Array: An array of Vector3 objects.
ColorArray: An array of Color objects.
тутачки. я даж не знаю как можно было умудриться сделать slower.
>>436396
Есть. Например, при разработке короны, или оборонки РФ.
Есть. Например, при разработке короны, или оборонки РФ.
>>436397
Да ты, я смотрю, дебилушка, и не воспринимаешь аналогии.
Да ты, я смотрю, дебилушка, и не воспринимаешь аналогии.
>>436428
>Написано же - пользуй только для больших массивов, чтобы избежать фрагментации. Медленнее они из-за оверхеда на проверку типа и избежания этой самой фрагментации.
>>436535
ох лол, там написанно про падение производительности для массивом со статической типизацией. Какую ты проверку типов должен делать для них? они ебанутые?
Далее там в примере сказанно про десятки-сотни тысяч элементов.
На секундочку это в пределах одного-двух сегментов 64к для однобайтового-двубайтового массива. С такими даже DOS справлялся.
На секунодочку, для копирования, заполнения подобных массивов данными есть даже специальные команды аля movsb или stosw, которые работают на порядки быстрее простого перебора и заполнения по одному элементу как было бы в случае обычных ассоциативных с динамической типизацией.
ох лол, там написанно про падение производительности для массивом со статической типизацией. Какую ты проверку типов должен делать для них? они ебанутые?
Далее там в примере сказанно про десятки-сотни тысяч элементов.
На секундочку это в пределах одного-двух сегментов 64к для однобайтового-двубайтового массива. С такими даже DOS справлялся.
На секунодочку, для копирования, заполнения подобных массивов данными есть даже специальные команды аля movsb или stosw, которые работают на порядки быстрее простого перебора и заполнения по одному элементу как было бы в случае обычных ассоциативных с динамической типизацией.
>>436538
Бля, ну ты тупой. Если ты из динамического ГДСкрипта напихиваешь в статически типизированный массив, кто должен проверять, че ты туда напихиваешь?
Бля, ну ты тупой. Если ты из динамического ГДСкрипта напихиваешь в статически типизированный массив, кто должен проверять, че ты туда напихиваешь?
>>436541
и что значит динамический гдскрипт? это какой-то новый уровень фантазий? скрипт сам себя пишет или что?
там где-то говориться о твоих фантазиях по перемещению данных из динамически типизированного массива в статически типизированный?
там просто говориться о медленной работе, там где она наоборот должна быть быстрой.
и что значит динамический гдскрипт? это какой-то новый уровень фантазий? скрипт сам себя пишет или что?
там где-то говориться о твоих фантазиях по перемещению данных из динамически типизированного массива в статически типизированный?
там просто говориться о медленной работе, там где она наоборот должна быть быстрой.
>>436567
Схуяль типизированный массив должен быть быстрее, если он решает задачу фрагментации памяти?
Схуяль типизированный массив должен быть быстрее, если он решает задачу фрагментации памяти?
>>437936
забавно, не знал что такие задачи существуют, но ладно
еще раз. там в примере сказанно от тысячах элементов. А это копейки. У тебя обоссаная текстура/меш займет как 5-10 таких массивов и никто не умрет.
> задачу фрагментации памяти
забавно, не знал что такие задачи существуют, но ладно
еще раз. там в примере сказанно от тысячах элементов. А это копейки. У тебя обоссаная текстура/меш займет как 5-10 таких массивов и никто не умрет.
Заебошил систему состояний со стаком.
Табличка override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака".
Табличка override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака".
>>411408 (OP)
>>438065
а нахуя это надо?
>>438065
>override, в состоянии, указывает, что "это состояние не даёт использовать функции update/draw указанные в override, у предыдущих элементов стака"
а нахуя это надо?
>>438066
Ну ты смотри. Игровая пауза продолжает рендерить игровое состояние, но запрещает ему получать нажатия на кнопки/обновляться.
Ну ты смотри. Игровая пауза продолжает рендерить игровое состояние, но запрещает ему получать нажатия на кнопки/обновляться.
В том году для девджема делал на Love2D простенькую игрушку с бесконечной на ходу генерируемой тайловой картой - очень даже интересный процесс.
Упёрся в скорость отрисовки, и только тут в треде вычитал какие там ещё возможности есть с хранением текстурок newSpriteBath в видеопамяти и быстрой отрисовкой, надо будет добраться и переделать, да и FFI тоже может пригодиться.
Упёрся в скорость отрисовки, и только тут в треде вычитал какие там ещё возможности есть с хранением текстурок newSpriteBath в видеопамяти и быстрой отрисовкой, надо будет добраться и переделать, да и FFI тоже может пригодиться.
>>442738
хуясе, а что с ней случилось? рисует же SDL2, если не ошибаюсь
обычо такая хуита начинается, когда в отрисовку логику пихают, или наоборот, лал
>Упёрся в скорость отрисовки
хуясе, а что с ней случилось? рисует же SDL2, если не ошибаюсь
обычо такая хуита начинается, когда в отрисовку логику пихают, или наоборот, лал
да я тупо 100500 маленьких картинок выводил, потом сделал чтобы не всегда всё перерисовывать, а только изменения, но сделал криво - через сохранение текущей картинки в текстурку в каждом кадре (что не хило так кушало память, если её не чистить принудительно в каждом кадре, что как-то не очень хорошо).
Переделаю как руки дойдут на SpriteBatch ну и там в принципе можно убрать принудительное стирание старой картинки каждый кадр на уровне фреймворка, тогда даже мой исходный вариант будет шустрее, не говоря уже про раздельную прорисовку кусков карты.
но для прототипов love очень даже хорош, как для чего-то более законченного - пока не знаю :)
Переделаю как руки дойдут на SpriteBatch ну и там в принципе можно убрать принудительное стирание старой картинки каждый кадр на уровне фреймворка, тогда даже мой исходный вариант будет шустрее, не говоря уже про раздельную прорисовку кусков карты.
но для прототипов love очень даже хорош, как для чего-то более законченного - пока не знаю :)
>>443106
Рисует - opengl, конечно.
Скорость отрисовки в данном плане - скорость заливки данных в видеокарту, ибо куча говна дублируется.
Рисует - opengl, конечно.
Скорость отрисовки в данном плане - скорость заливки данных в видеокарту, ибо куча говна дублируется.
Хочу вкатится в http://ggez.rs/
Какие подводные?
Какие подводные?
>>446358
Ну issue если что создать всегда можно. Не велика проблема. Меня больше инетересует что анон думает за сам love2d
Ну issue если что создать всегда можно. Не велика проблема. Меня больше инетересует что анон думает за сам love2d
>>446359
Сам по себе Love2D пиздат, но специфичен в целом.
Алсо, если это адаптация лова для раста, то возможно еще не все фичи реализованы, и выход новой версии будет задерживаться, хотя это менее критично.
Ну если чувствуешь в себе силы, то можешь какие-нибудь простые демки запиливать.
Сам по себе Love2D пиздат, но специфичен в целом.
Алсо, если это адаптация лова для раста, то возможно еще не все фичи реализованы, и выход новой версии будет задерживаться, хотя это менее критично.
Ну если чувствуешь в себе силы, то можешь какие-нибудь простые демки запиливать.
>>446360
Че бы такого запилить ради теста.
Че бы такого запилить ради теста.
62 Кб, 873x507Бля за що
Сделал Hello_button и задумался.
https://anotepad.com/notes/ti57jh
А если у меня будет несколько кнопок\объектов на экране, мне что каждый проверять на границы по очереди? Или есть какой-то неизъебский способ?
https://anotepad.com/notes/ti57jh
А если у меня будет несколько кнопок\объектов на экране, мне что каждый проверять на границы по очереди? Или есть какой-то неизъебский способ?
>>454136
А не удобнее будет заставить объекты следить за мышью, и реагировать, если она рядом?
А не удобнее будет заставить объекты следить за мышью, и реагировать, если она рядом?
>>454140
По сути тож самое же, только в другом месте проверки.
По сути тож самое же, только в другом месте проверки.
>>454140
Можешь натянуть на экран сетку пространственной индексации, заполнять её кнопками которые попадают в ячейки сетки, делить координаты мыши на шаг сетки в пикселях и пробегать только по кнопкам, которые касаются ячейки в которой есть мышь.
Это - быстрее всего для обработки, но чуть медленнее в загрузке.
Можешь натянуть на экран сетку пространственной индексации, заполнять её кнопками которые попадают в ячейки сетки, делить координаты мыши на шаг сетки в пикселях и пробегать только по кнопкам, которые касаются ячейки в которой есть мышь.
Это - быстрее всего для обработки, но чуть медленнее в загрузке.
Посоны, немного тупой вопрос.
Я копаюсь под капотом у love2djam2018 и скачал например gift. Разархивировал love файл, а там main.lua, который моим сублимом открывается чисто как hex.
Но екзешником love2d съедается как миленький.
Может кто-нибудь предположить что это за метод сокрытия информации?
Decode в другую кодировку не помог.
File signature 1b4c 4a01 02 нигде не нахожу.
Я копаюсь под капотом у love2djam2018 и скачал например gift. Разархивировал love файл, а там main.lua, который моим сублимом открывается чисто как hex.
Но екзешником love2d съедается как миленький.
Может кто-нибудь предположить что это за метод сокрытия информации?
Decode в другую кодировку не помог.
File signature 1b4c 4a01 02 нигде не нахожу.
>>487573
Луа-код можно компилить в байткод, это нормально.
И любая луа-машина (в т.ч. love2d) будет с ней работать.
Правда, у разных версий lua разный байткод, поэтому версии 5.1 и 5.3, например, несовместимы.
В love2d используется luajit, и байткод соответствующий.
Луа-код можно компилить в байткод, это нормально.
И любая луа-машина (в т.ч. love2d) будет с ней работать.
Правда, у разных версий lua разный байткод, поэтому версии 5.1 и 5.3, например, несовместимы.
В love2d используется luajit, и байткод соответствующий.
>>490081
Спасибо большое за разъяснение.
Спасибо большое за разъяснение.
>>305497 (OP)
Народ вкатился в LOVE2D.
Посмотрел небольшую кучу примеров и игр, добрался до
Zerobrain Studio.
Что еще нужно для комфортного гейм дева и есть ли хорошие книги по LUA ? love2D ?
Народ вкатился в LOVE2D.
Посмотрел небольшую кучу примеров и игр, добрался до
Zerobrain Studio.
Что еще нужно для комфортного гейм дева и есть ли хорошие книги по LUA ? love2D ?
>>536774
https://www.lua.org/pil/contents.html
https://love2d.org/wiki/Main_Page
Документашки просто топ, закачаешься.
Также чекай всякие либы для лов2д на той же вики или на форумах/гитхабах, много чего полезного можно найти.
https://www.lua.org/pil/contents.html
https://love2d.org/wiki/Main_Page
Документашки просто топ, закачаешься.
Также чекай всякие либы для лов2д на той же вики или на форумах/гитхабах, много чего полезного можно найти.
>>536774
Зачем тебе книги по Луа? Там язык в полчаса изучения, достаточно одной табл урока на утубе, если не трогать метатаблицы и все с ними.
Зачем тебе книги по Луа? Там язык в полчаса изучения, достаточно одной табл урока на утубе, если не трогать метатаблицы и все с ними.
>>305497 (OP)
Почему создатели Love2d переписывали функции каждую подверсию???
зачем drawq превращатьв draw
screen в window
love.mousepressed( x, y, button ) в
где button ='l' или 'r'
а в 0.10.2
уже
love.mousepressed( x, y, button, istouch )
button = 1 или 2
!!!!
Почему создатели Love2d переписывали функции каждую подверсию???
зачем drawq превращатьв draw
screen в window
love.mousepressed( x, y, button ) в
где button ='l' или 'r'
а в 0.10.2
уже
love.mousepressed( x, y, button, istouch )
button = 1 или 2
!!!!
>>537039
чтобы запутать
чтобы запутать
bump
>>537039
Еще раз, я же.
Я новичок в Love2d.
То что игру реально написать это круто! Скачал кучу примеров, исходников.
Но вот то что автор программы наплодил версии не сильно совместимые между собой это МИНУС!
пусть сделает love 12 запускающий любой код от love 0.1.1 до love 11.2 .
И кстати никто не знает почему он в 11 версии ушел в установке цвета от 255, 255,255 к 1,1,1 (0.444, 0.111, 0,888)? В чем смысл?
Еще раз, я же.
Я новичок в Love2d.
То что игру реально написать это круто! Скачал кучу примеров, исходников.
Но вот то что автор программы наплодил версии не сильно совместимые между собой это МИНУС!
пусть сделает love 12 запускающий любой код от love 0.1.1 до love 11.2 .
И кстати никто не знает почему он в 11 версии ушел в установке цвета от 255, 255,255 к 1,1,1 (0.444, 0.111, 0,888)? В чем смысл?
412 Кб, 640x480>>540776
Ты, похоже, новичок во всем? Ты еще Торвальдсу скажи сделой мне МакВиндовс, штобы все летало. Просто это нагло. Разработчики (если не ошибаюсь, л2д разрабатывает тоже не один человек) сознательно избавляются от глючно работающего кода, кода, вызывающего конфликты и прочее. Делать универсалку для развивающегося любительского движка, это значит нагружать исполняющий файл. Если какой-нибудь Автодеск может себе позволить (да и им это в кассу, ибо этим они отличаются от всяких конкурентов) и поддерживать одновременно дохуялиард версий.
Еще раз, почитай про обозначения версий. В большинстве систем версификации софта считается, что 11.1.2 и 11.1.1 имеют между собой общего 99 процентов кода и естественно они будут почти соместимы, а версия лоадера скажем 12.1 и программы 9.1.2 могут иметь (и имеют право иметь) кардинальные различия, вплоть до полностью переписанного с нуля кода. Совместимость двух дохуялиарда версий стоит дохуялиард денег, времени и кода. Ты готов оплатить их труд? Нет?
Подозреваю, решил упростить математическое преобразование в гамме для платформы в целом. Чтобы работа пользовательских шейдеров была быстрее.
>пусть сделает 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, раз ввели в предыдущих версиях.
>сознательно избавляются от глючно работающего кода
Глючно работающий код?
Да ты теоретик!
Там просто функция window внезапно меняется на screen
drawq - сделали в следующей версии ее уже нет, но вы можете просто убрать букву q и все заработает!
Нахрена???
Сокращение кода, оптимизация бла бла бла.
Сделайте так что внутри черной коробки drawq была равна draw, раз ввели в предыдущих версиях.
>>540822
еще раз ты теоретик!
Почему тогда он с 0.10.2 версии скакнул до 11.0 ?
Это вообще охуенные изменения?
> что 11.1.2 и 11.1.1 имеют между собой общего 99 процентов кода и естественно они будут почти соместимы, а версия лоадера скажем 12.1 и программы 9.1.2 могут иметь
еще раз ты теоретик!
Почему тогда он с 0.10.2 версии скакнул до 11.0 ?
Это вообще охуенные изменения?
>>540919
вот тут хуй знает, я за л2д не слежу, если честно. Просто луашник и мимокрокодил.
>Почему тогда он с 0.10.2 версии скакнул до 11.0 ?
вот тут хуй знает, я за л2д не слежу, если честно. Просто луашник и мимокрокодил.
>>540918
Между draw и drawq чуть больше изменений, чем просто буква.
Нахера тащить легаси код, если так захотел какой-то васян? Проект можно допилить и на старой версии, если сильно надо, просто через какие-то костыли будет.
Синтаксис уточняется, унифицируется, становится более красивым, а старое и некрасивое нет смысла тащить.
Если сильно приспичит, можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
Между draw и drawq чуть больше изменений, чем просто буква.
Нахера тащить легаси код, если так захотел какой-то васян? Проект можно допилить и на старой версии, если сильно надо, просто через какие-то костыли будет.
Синтаксис уточняется, унифицируется, становится более красивым, а старое и некрасивое нет смысла тащить.
Если сильно приспичит, можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
>>540933
Да именно это я и сделал, а тысячи новичков забили на это и пошли пилить свои игры в другие платформы.
Почему рубится сук на котором сидят?
Из за изменения с цветом не совместимы игры написанные <0.10 и >11.0
Этож сплошное отпугивание новичков, я взял прример и у меня ничего не работает.
>можешь в мейн.луа написать function love.graphics.drawq(...) love.graphics.draw(...) end и все будет работать как прежде.
Да именно это я и сделал, а тысячи новичков забили на это и пошли пилить свои игры в другие платформы.
Почему рубится сук на котором сидят?
Из за изменения с цветом не совместимы игры написанные <0.10 и >11.0
Этож сплошное отпугивание новичков, я взял прример и у меня ничего не работает.
>>540943
Когда-то все равно придется исправлять ошибки прошлого. Сначала посчитали, что удобно будет 0..255 использовать, и это в принципе привычно. Но потом, видимо, стали чаще использовать фичи опенгла и шейдеров, а там удобнее 0,0..1,0. Относительно недавно еще какие-то фичи для более легкого 3д подвезли.
То что туторы на официальном сайте не апдейтят, это плохо, хотя документация там топовая. Да и уроки посвежее и более полные есть от юзеров, на хабре или еще где-то можно найти.
Когда-то все равно придется исправлять ошибки прошлого. Сначала посчитали, что удобно будет 0..255 использовать, и это в принципе привычно. Но потом, видимо, стали чаще использовать фичи опенгла и шейдеров, а там удобнее 0,0..1,0. Относительно недавно еще какие-то фичи для более легкого 3д подвезли.
То что туторы на официальном сайте не апдейтят, это плохо, хотя документация там топовая. Да и уроки посвежее и более полные есть от юзеров, на хабре или еще где-то можно найти.
266 Кб, 838x470Кто нашел source примеров от oysi или oysi93?
Речь про 3D в love2d
https://www.youtube.com/watch?v=x8k3vaPRXd4
Речь про 3D в love2d
https://www.youtube.com/watch?v=x8k3vaPRXd4
Отдельного треда по box2d я как-то не нашел. Поэтому спрошу прямо здесь: Я с физикой как-то никогда не работал, поэтому на box2d смотрю как на черта в табакерке.
Сейчас появилось желание сделать вернее идиотская привычка проводить новогодние вечера делая никому ненужную херню для себя небольшую игру, с физикой: А именно лабиринт по которому нужно будет катать шарик. То есть шарик должен отскакивать от стенок, катиться по инерции, расталкивать препятствия и прочие Но ещё на стадии прикидки в голове и чтения мануалов я понял одну вещь: У меня будет довольно большой и сложный лабиринт, и все его части должны быть физическими препятствиями. Логично сделать каждый "тайл" отдельным прямоугольным физическим объектом - но очевидно что их будет дохуя. И собственно вопрос - как можно сделать в box2d объект сложным по структуре но при этом считающим одним объектом при расчётах?
Сейчас появилось желание сделать вернее идиотская привычка проводить новогодние вечера делая никому ненужную херню для себя небольшую игру, с физикой: А именно лабиринт по которому нужно будет катать шарик. То есть шарик должен отскакивать от стенок, катиться по инерции, расталкивать препятствия и прочие Но ещё на стадии прикидки в голове и чтения мануалов я понял одну вещь: У меня будет довольно большой и сложный лабиринт, и все его части должны быть физическими препятствиями. Логично сделать каждый "тайл" отдельным прямоугольным физическим объектом - но очевидно что их будет дохуя. И собственно вопрос - как можно сделать в box2d объект сложным по структуре но при этом считающим одним объектом при расчётах?
>>542187
Сотню статических боксов он должен легко сожрать, тем более что динамический будет только один объект.
То что ты объединишь множество боксов в один полигон выигрыша не даст. Сложный объект сложнее проверять на столкновение.
Сотню статических боксов он должен легко сожрать, тем более что динамический будет только один объект.
То что ты объединишь множество боксов в один полигон выигрыша не даст. Сложный объект сложнее проверять на столкновение.
>>542190
Будут еще динамические препядствия но не много. Даже если сотню сожрёт без проблем, я сам перфекционист и не люблю пустой траты ресурсов. Пока придумал что на этапе генерации лабиринта собирать соседние "клетки" в более большие прямоугольники и создавать физические обьекты только для них уже. Но сделать алгоритм нормальным не получаеться.
Будут еще динамические препядствия но не много. Даже если сотню сожрёт без проблем, я сам перфекционист и не люблю пустой траты ресурсов. Пока придумал что на этапе генерации лабиринта собирать соседние "клетки" в более большие прямоугольники и создавать физические обьекты только для них уже. Но сделать алгоритм нормальным не получаеться.
Вопрос уроня - идиот:
Сам фресворк поддерживает оптимизацию отрисовки того что не попадает в текущий кадр. Или при прорисовки объекта нужно сначала самому проверять его фактическую видимость?
Сам фресворк поддерживает оптимизацию отрисовки того что не попадает в текущий кадр. Или при прорисовки объекта нужно сначала самому проверять его фактическую видимость?
>>542305
Самому нужно пилить, насколько я знаю.
Самому нужно пилить, насколько я знаю.
>>540930
Потому что в обновке много изменений и сильная несовместимость с предыдущей версией. Первая цифра означает мажорный релиз, вторая - багфиксы.
10.0 => 11.0 => 11.1 => 11.2.
Оно не сразу скакало, очевидно были промежуточные.
Потому что в обновке много изменений и сильная несовместимость с предыдущей версией. Первая цифра означает мажорный релиз, вторая - багфиксы.
10.0 => 11.0 => 11.1 => 11.2.
Оно не сразу скакало, очевидно были промежуточные.
>>540943
Есть polyamory (https://github.com/megagrump/polyamory)
Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
Есть polyamory (https://github.com/megagrump/polyamory)
Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
9,5 Мб, 598x424>>542305
Сам запилишь.
По мне, эффективной методикой является использование чего-то вроде регулярной сетки, в которой располагаются объектики.
На гифке, например, я использовал библиотеку hardon collider для коллизии, и оттуда же - регулярную сетку. Из неё вырезается некоторая область (список объектов по AABB), и рендерится. Соответственно, объектов может быть сколько угодно, не попавшие в экран мы даже не проверяем.
Если у тебя ну прям до жопы одинаковых объектов, то уже эффективнее пихать в батчи и рисовать сразу всё через батч (например, вытаскивать объекты из большой области и пихать в батч). Развлекалова много, в общем.
Сам запилишь.
По мне, эффективной методикой является использование чего-то вроде регулярной сетки, в которой располагаются объектики.
На гифке, например, я использовал библиотеку hardon collider для коллизии, и оттуда же - регулярную сетку. Из неё вырезается некоторая область (список объектов по AABB), и рендерится. Соответственно, объектов может быть сколько угодно, не попавшие в экран мы даже не проверяем.
Если у тебя ну прям до жопы одинаковых объектов, то уже эффективнее пихать в батчи и рисовать сразу всё через батч (например, вытаскивать объекты из большой области и пихать в батч). Развлекалова много, в общем.
>>542513
Есть, не боюсь.
Но вот вопрос, если сторонние умельцы делают ланчер для запуска всего множества версий, то это востребовано?
Так почему бы создателям, не сделать единый экзешник для всего подмножества версий 0.0.1 - 0.10.2 и так уж и быть если прям нереально еще один 11.0-15.0. (а лучше love2d.exe вообще для всех)? Версию сами просили в conf.lua записывать, какие команды на что меняли тоже знают.
>Есть polyamory (https://github.com/megagrump/polyamory)
>Типа лончер для запуска приложений в произвольной версии love2d (соответственно, у тебя должны быть поставлены все необходимые версии). Не бойся, 10гб места они не сожрут.
Есть, не боюсь.
Но вот вопрос, если сторонние умельцы делают ланчер для запуска всего множества версий, то это востребовано?
Так почему бы создателям, не сделать единый экзешник для всего подмножества версий 0.0.1 - 0.10.2 и так уж и быть если прям нереально еще один 11.0-15.0. (а лучше love2d.exe вообще для всех)? Версию сами просили в conf.lua записывать, какие команды на что меняли тоже знают.
>>542706
Ты предлагаешь им запаковать все версии love в одну? Ты бы ещё предложил запихнуть все версии какого-нибудь дистра линукса в один дистр, или все-все версии питона в один питон.
Ты предлагаешь им запаковать все версии love в одну? Ты бы ещё предложил запихнуть все версии какого-нибудь дистра линукса в один дистр, или все-все версии питона в один питон.
>>542706
За время развития love2d, менялись версии динамических библиотек (хотя бы версии SDL), ты плохо понимаешь цену того что хочешь.
За время развития love2d, менялись версии динамических библиотек (хотя бы версии SDL), ты плохо понимаешь цену того что хочешь.
>>544376
Гы?
Че там запоковывать то?
Там всего то надо принимать команды в двух - трех форматах, запоковать внутренние приравнивания что screen = windows если что, drawq = draw и так далее. +1000-30000 байт смотря сколько раз они команды меняли безосновательно.
Гы?
Че там запоковывать то?
Там всего то надо принимать команды в двух - трех форматах, запоковать внутренние приравнивания что screen = windows если что, drawq = draw и так далее. +1000-30000 байт смотря сколько раз они команды меняли безосновательно.
>>544377
Игнорируйте его, такие люди должны стучаться в службу поддержки Микрософт с просьбой портировать легаси-код из win 3.1.
Игнорируйте его, такие люди должны стучаться в службу поддержки Микрософт с просьбой портировать легаси-код из win 3.1.
>>544704
Сколько ты готов заплатить разработчикам за такой мердж?
Сколько ты готов заплатить разработчикам за такой мердж?
>>537039
было хуево, стало пиздато. С интежерами поди по-проще будет, чем бесполезные где button ='l' или 'r'
кстати а mousewheel нажатие там обрабатывается?
и вообще чего доебался. Найди хоть один более-менее популярный продукт, где бы не менялся API.
>>490081
этот самый байт код можно "дизассемблировать" до удобочитаемого и понятного lua, т.е. реально использовать для соркытия СУПИРСИКРЕТНАГО кода игры?
Вообще что юзают перед тем как выкладывать в тот же стим, какие-нибудь обфускация кода с добавлением кучи воды и бесполезных функция с переменными, чтобы запутать? Или всем просто похуй?
>button = 1 или 2
было хуево, стало пиздато. С интежерами поди по-проще будет, чем бесполезные где button ='l' или 'r'
кстати а mousewheel нажатие там обрабатывается?
и вообще чего доебался. Найди хоть один более-менее популярный продукт, где бы не менялся API.
>>490081
этот самый байт код можно "дизассемблировать" до удобочитаемого и понятного lua, т.е. реально использовать для соркытия СУПИРСИКРЕТНАГО кода игры?
Вообще что юзают перед тем как выкладывать в тот же стим, какие-нибудь обфускация кода с добавлением кучи воды и бесполезных функция с переменными, чтобы запутать? Или всем просто похуй?
>>545615
я смотрел, популярные офусцируют.
А вот на ресурсе где дайте 2$ или просто скачайте, и где переодическит и с кодом выкладывают, не обфусцируют.
я смотрел, популярные офусцируют.
А вот на ресурсе где дайте 2$ или просто скачайте, и где переодическит и с кодом выкладывают, не обфусцируют.
Лованы, а под ондроед кто-то что-то мастерил?
я попробовал свой тестовый гейм оф лайф запустить на мобилочке, результат как бы немного разочировал, все эти банчи-хуянчи оно обрабатывало медленее чем на древнем сабноуте.
Но, если все в пределах экрана, то 60 фпс на изичах.
Правда чому-то офицальной любви 11.2 даже нет в планах, 11.1 приходится ставить руками без маркета. Чувстую придется свою собирать и ебаться с манифестами и плейсторе.
Может кто уже пытался?
я попробовал свой тестовый гейм оф лайф запустить на мобилочке, результат как бы немного разочировал, все эти банчи-хуянчи оно обрабатывало медленее чем на древнем сабноуте.
Но, если все в пределах экрана, то 60 фпс на изичах.
Правда чому-то офицальной любви 11.2 даже нет в планах, 11.1 приходится ставить руками без маркета. Чувстую придется свою собирать и ебаться с манифестами и плейсторе.
Может кто уже пытался?
373 Кб, 1280x1024>>551430
так это не только в ондроеде
сейм шит, бро
>приходится ставить руками без маркета
так это не только в ондроеде
>60 фпс на изичах
сейм шит, бро
>>305497 (OP)
Где список успешных игр на love2d?
Где список успешных игр на love2d?
>>551452
зойчем ты мне показал скрин с кудахтера, писечка именно в сборке под ондроед. А make install я и на фришечке осилил.
>>551469
в стиме как минимум пара релизнутых, но там все совсем простые.
я же хотеть делать рпгешечки/хиросы под ондроед без донатов и банеов. Бесплатная демка и платная фулл за бакс.
Алсо обратил внимание как в плейсторе донатопораша пытается пролезть в топ. Делают донатопорашу и ставят ей минимальную цену, потом делают скидку в 100% и вуаля - ты в топах премиум игр по скидке.
зойчем ты мне показал скрин с кудахтера, писечка именно в сборке под ондроед. А make install я и на фришечке осилил.
>>551469
в стиме как минимум пара релизнутых, но там все совсем простые.
я же хотеть делать рпгешечки/хиросы под ондроед без донатов и банеов. Бесплатная демка и платная фулл за бакс.
Алсо обратил внимание как в плейсторе донатопораша пытается пролезть в топ. Делают донатопорашу и ставят ей минимальную цену, потом делают скидку в 100% и вуаля - ты в топах премиум игр по скидке.
>>551501
ну вот тоже руками ПОД СЕБЯ, а не из бинарного пакета, это же лёвы тред. а под ондроед .apk небось проще сбилдить даже из линупса и фришки, тока сдк/ндк доставить
>зойчем
ну вот тоже руками ПОД СЕБЯ, а не из бинарного пакета, это же лёвы тред. а под ондроед .apk небось проще сбилдить даже из линупса и фришки, тока сдк/ндк доставить
>>551549
ну опять же имеет смысл только при распространении линупс/макос версии. Для шинды достаточно прикрепить лов файл в конец стандартного екзешника.
А вот с дроедом чувствую та еще ебля.
ну опять же имеет смысл только при распространении линупс/макос версии. Для шинды достаточно прикрепить лов файл в конец стандартного екзешника.
А вот с дроедом чувствую та еще ебля.
>>551557
https://love2d.org/wiki/Game_Distribution#Android
вот с нуля арк из под макоси и линупса билдят же вроде
а через АРК тулс как раз и есть ебля с манифестами
https://love2d.org/wiki/Game_Distribution/APKTool
к этому можно еще запилить мультик на вебсокетах вебморду логин/пасс + база юзеров, их ачивок, статистика онлаен и т.п. типа свой стим, лал
ну и дев с битбакета вещает про легаси сборку, пакадж и деплой с адмобом, версия 0.10.x
https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/Home
https://love2d.org/wiki/Game_Distribution#Android
вот с нуля арк из под макоси и линупса билдят же вроде
а через АРК тулс как раз и есть ебля с манифестами
https://love2d.org/wiki/Game_Distribution/APKTool
к этому можно еще запилить мультик на вебсокетах вебморду логин/пасс + база юзеров, их ачивок, статистика онлаен и т.п. типа свой стим, лал
>Publishing as a HTML5 or JavaScript game is possible
ну и дев с битбакета вещает про легаси сборку, пакадж и деплой с адмобом, версия 0.10.x
https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/Home
>>551574
читай внимательно
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.
не хотеть
ну кириллу будет мягко говоря трудно конкурировать с остальными донато и баннеропарашами. Наоборот, поделок без баннеров и доната можно по пальцам пересчитать, этим и надо брать, имхо. Например, ровно ОДНУ вменяемую рпгешечку - Exiled kingdoms. А ведь если ПОДУМОТЬ, то там нет ничего особенного. Прередеренный псевдо 3д, довольно простые квесты и локации. ЛЕВИЛДИЗИГН уровня кирилла. Разве что стори неплохая и текст самих квестов.
читай внимательно
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, но тоже поверхностно и тема была не раскрыта и вообще не рпг, а тайкун кокойто
>читай
я не читал пока, увидел легаси и решил посмотреть позже, все равно при ~200kbps эти сдк/ндк тянуть неохота
и свежих доков нет вроде, внизу там висит линк на типа апдейт, но я и его не читал
а вот рпгешки помню прикольные на j2me под нокию были, причем брендовые, мож даже от близзардов. там нужно было в локациях выполнять квесты, гулять по глобалу и пиздить нпц. экономику вот только вроде не завозили туда. а жаль. единственно именно экономическим был клон серии Anno или Port Royale, но тоже поверхностно и тема была не раскрыта и вообще не рпг, а тайкун кокойто
13 Кб, 400x131>>551596
из тайги капчую. ну почти: паблик вайфай хотспот с плавающим сигналом, который иногда вообще теряется.
игрухи то да, код смотреть не запрещают же, ну или не все, но вот захочется например шейдоры задрочить, а в новой версии двигла у них например синтаксис сломан. я штото переписывал шейдорное с 8 на 9ку вроде, так после этого ни с кем неделю не разговаривал. причем и в документации никуя об этом не было
из тайги капчую. ну почти: паблик вайфай хотспот с плавающим сигналом, который иногда вообще теряется.
игрухи то да, код смотреть не запрещают же, ну или не все, но вот захочется например шейдоры задрочить, а в новой версии двигла у них например синтаксис сломан. я штото переписывал шейдорное с 8 на 9ку вроде, так после этого ни с кем неделю не разговаривал. причем и в документации никуя об этом не было
988 Кб, 442x347Тестю bump. Очень крутая штука, если хорошо организовать проект.
Никаких лишних коллизий, объекты ровно без реакции пролезают в дырки, размером ровно с эти объекты, очень круто. Ну, и все объекты являются "пулями", при попытке перемещения, быстродвижущиеся снаряды не пролетают.
Никаких лишних коллизий, объекты ровно без реакции пролезают в дырки, размером ровно с эти объекты, очень круто. Ну, и все объекты являются "пулями", при попытке перемещения, быстродвижущиеся снаряды не пролетают.
>>305497 (OP)
Думаю, куда бы перекатиться с геймейкера. Устал в первую очередь от его ебучего языка gml, в котором нельзя даже создать свою структуру данных. Ну и в целом хочется выйти на более ненубский уровень, чтобы движок не определял за меня архитектуру игры. Так вот, как говорят в годот треде, почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец?
Думаю, куда бы перекатиться с геймейкера. Устал в первую очередь от его ебучего языка gml, в котором нельзя даже создать свою структуру данных. Ну и в целом хочется выйти на более ненубский уровень, чтобы движок не определял за меня архитектуру игры. Так вот, как говорят в годот треде, почему я должен выбрать love2d? Если love2d обертка над sdl, то может сразу выбирать sdl, ну или аналогичные sfml, allegro или libgdx на худой конец?
>>554572
love2d - это, если быть точным, обертка над sdl+opengl.
sdl и прочие - это низкоуровневые графические библиотеки, единственной высокоуровневой фичей которых является абстракция платформо-OS-зависимых API.
инструменты и сущности высокого порядка тебе придется велосипедить самому.
Если ты не демосценер/любитель подрочить байты ради собственного удовлетворения или просто хочешь научится в низкоуровневое дрочерство/не программист крупной игровой студии, а хочешь просто делать игори - то выбираемое тобой направление сомнительно - ты 90% всего времени потратишь на велосипединг кривых велосипедов и их отладку. Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун. И только после этого ты сможешь заниматься непосредственно игрой, в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи и ты раз за разом будешь срываться с написания геймплейной логики в написание фич двигуна, а твоему мозгу будет все сложнее и сложнее держать всё это в голове одновременно и работать в таком ритме.
В крупных студиях такой проблемы нет - у них есть четкое понимание зачем им велосипеды, какой профит (более лучший графоний c инновационными техниками и номинации за графон на ежегодной VGA, инструменты для разработчиков в рамках заданной концепции игры, успешная борбьба с собственной соснульной платформой) они с них получат, четкий план как и чего они пилят, большая команда разработчиков, разделение разработки по командам, допилка фич в соответствии с планом и.т.д.
Тебе же придется всё это делать в жало.
love2d - это, если быть точным, обертка над sdl+opengl.
sdl и прочие - это низкоуровневые графические библиотеки, единственной высокоуровневой фичей которых является абстракция платформо-OS-зависимых API.
инструменты и сущности высокого порядка тебе придется велосипедить самому.
Если ты не демосценер/любитель подрочить байты ради собственного удовлетворения или просто хочешь научится в низкоуровневое дрочерство/не программист крупной игровой студии, а хочешь просто делать игори - то выбираемое тобой направление сомнительно - ты 90% всего времени потратишь на велосипединг кривых велосипедов и их отладку. Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей, мапить их на уровень GAPI, колхозить/прикручивать собственный скриптовый двигун. И только после этого ты сможешь заниматься непосредственно игрой, в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи и ты раз за разом будешь срываться с написания геймплейной логики в написание фич двигуна, а твоему мозгу будет все сложнее и сложнее держать всё это в голове одновременно и работать в таком ритме.
В крупных студиях такой проблемы нет - у них есть четкое понимание зачем им велосипеды, какой профит (более лучший графоний c инновационными техниками и номинации за графон на ежегодной VGA, инструменты для разработчиков в рамках заданной концепции игры, успешная борбьба с собственной соснульной платформой) они с них получат, четкий план как и чего они пилят, большая команда разработчиков, разделение разработки по командам, допилка фич в соответствии с планом и.т.д.
Тебе же придется всё это делать в жало.
>>554572
У всех свои особенности. love2d - он на lua, и в этом его прикол. sdl - на чистом си, а sfml - на c++, и он объекто-ориентирован. Allegro, ClanLib, HGE и подобные - на с++, и как я понимаю, и них более богатый функционал, т.е. больше полезных фич для геймдева из коробки можно найти.
Какой язык ближе - такой и выбирай. Дополнительный функционал, на самом деле, не обязательно самому писать, можно найти другие сторонние библиотеки, их куча в опенсорсе.
>>554621
По моему скромному опыту могу несколько вещей добавить.
Во-первых, какие-то сложные вещи можно найти в инете. Если тайловая игра, можно присобачить Tiled. Хотя для не-тайловых хз, есть ли подобное.
Во-вторых, не обязательно вообще сложно писать. Можно максимально упрощать, делать только необходимое - это ключ к успеху. Только при надобности - делать более абстрактно, расширяя функционал и рефакторя код.
В-третьих, первый проект да, можно дохуя всего с нуля написать. Но если будешь более-менее аккуратно писать, то наберется парочка полезных собственных либ, которые можно потом переиспользовать.
Это все очень интересно и дает много опыта. Но с практической точки зрения - я хз как на это будут смотреть потенциальные работодатели, которые 90% используют юнити под мобилки. Адекватные наверное оценят опыт, но хорошее знание нужного им инструмента это не заменит полностью.
> почему я должен выбрать 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, как вообще все правильно ЗДЕЛОТЬ. С префабами и поэтэссами.
>инструменты и сущности высокого порядка тебе придется велосипедить самому.
Ты так говоришь как что-то плохое.
В любом случае придется тратить время либо на велосипеды, либо на изучение юнити-хуюнити. Но вот с последним ты можешь упереться в непреодолимую стену ограничений. А так тебе полная свобода сделать свое говно. Я так это вижу.
Ну и упоминание крупных студий тут совсем не к месту. Любовь как бы занимает совершенно другую нишу. Это для одиночек или пары человек, которые могут в кодинг, но не хотят мышевозить в юнитях и гейммейкерах.
>в ходе чего тебе будет постоянно пригорать пердак от внезапного отсутствия той или иной фичи
В моем случае пердак уже давно подготовлен, я не питаю иллюзий и просто сделаю максимально просто.
Тут есть другой момент, в отличие от юнитей, мне не надо изучать инструмент, тот же реадктор что ты упомянул, по-сути можно сразу ваять свой ААА ШИДЕВР. А самое главное есть отличные примеры на чем можно поучиться, а то и откровенно спиздить - Don't starve, ToME4 и тп.
Кстати, читая исходнки DS я ПОНИЛ как именно там реализуется анимация, со всеми этими стейтграфами, как реализован AI, как вообще все правильно ЗДЕЛОТЬ. С префабами и поэтэссами.
>>554636
Вот это манямир.
Юнити больше 10 лет в разработке.
Конечно же, это только плюс, что нужно все самому делать, ведь у тебя есть 10+ лет чтобы сделать движок
Вот это манямир.
Юнити больше 10 лет в разработке.
Конечно же, это только плюс, что нужно все самому делать, ведь у тебя есть 10+ лет чтобы сделать движок
>>554621
Проблема то в том, что со временем понимаешь, что стандартные фичи гамака не очень нужны (а их кстати не так уж и много). Физику сам рассчитываю, столкновения сам считаю, поиск пути свой писать приходится, даже спрайты для некоторых нужд приходится в ручном режиме анимировать, а не в стандартном автоматическом, редактор уровней неудобный. В итоге от гамака нужна только возможность рисовать спрайты на экране. А вот при попытке что-то навелосипедить натыкаешься на внутренние ограничения движка.
>Тебе придется придумывать и реализовывать самому редактор уровней, иерархию игровые сущностей
Проблема то в том, что со временем понимаешь, что стандартные фичи гамака не очень нужны (а их кстати не так уж и много). Физику сам рассчитываю, столкновения сам считаю, поиск пути свой писать приходится, даже спрайты для некоторых нужд приходится в ручном режиме анимировать, а не в стандартном автоматическом, редактор уровней неудобный. В итоге от гамака нужна только возможность рисовать спрайты на экране. А вот при попытке что-то навелосипедить натыкаешься на внутренние ограничения движка.
>>554648
Чтобы сделать игру, не нужно 10 лет тратить на движок.
За пол года, если без сильных выебонов, можно сделать норм игрушку практически с нуля.
Люди за сутки или за неделю без юнитей пилят годные прототипы игр на джемах. Остальное время уходит на допиливание, контент и прочее.
Чтобы сделать игру, не нужно 10 лет тратить на движок.
За пол года, если без сильных выебонов, можно сделать норм игрушку практически с нуля.
Люди за сутки или за неделю без юнитей пилят годные прототипы игр на джемах. Остальное время уходит на допиливание, контент и прочее.
>>554635
Мне никакой из этих языков не ближе. Важнее, чтобы движок не был заброшен и стабильно работал. Я так понимаю sdl тут лидирует.
>Какой язык ближе - такой и выбирай.
Мне никакой из этих языков не ближе. Важнее, чтобы движок не был заброшен и стабильно работал. Я так понимаю sdl тут лидирует.
>>554648
Простой вопрос - чому Klei такие идиоты и не зделоли все на юнити?
Асло, юнити для меня - синоним тормозов, быстрой растраты батарейки на мобиле. А вот внезапно нечто на самописном движке работает бодрячком (рпгшечка).
Простой вопрос - чому Klei такие идиоты и не зделоли все на юнити?
Асло, юнити для меня - синоним тормозов, быстрой растраты батарейки на мобиле. А вот внезапно нечто на самописном движке работает бодрячком (рпгшечка).
>>554658
Все, которые на слуху, так или иначе разрабатываются и достаточно стабильно работают. Попробуй посмотреть туториалы по каждому, как запиливается какая-нибудь простая игра, глянь код, выбери более приемлемый для тебя вариант по синтаксису/апи.
Все, которые на слуху, так или иначе разрабатываются и достаточно стабильно работают. Попробуй посмотреть туториалы по каждому, как запиливается какая-нибудь простая игра, глянь код, выбери более приемлемый для тебя вариант по синтаксису/апи.
>>554663
А ты что, klei?
Время разработки складывается из времени написания движка, времени создания редакторов и время создания контента.
Ты можешь, например, взять кривой tiled, и времени на создание в нем контента ты убьешь в разы больше, чем если ты будешь делать тайловые карты в юнити.
Тебе будет нехватать возможностей tiled, и ты будешь писать костыли, и еще больше затягивать разработку.
А ты что, klei?
Время разработки складывается из времени написания движка, времени создания редакторов и время создания контента.
Ты можешь, например, взять кривой tiled, и времени на создание в нем контента ты убьешь в разы больше, чем если ты будешь делать тайловые карты в юнити.
Тебе будет нехватать возможностей tiled, и ты будешь писать костыли, и еще больше затягивать разработку.
>>554663
Пргресс, ёптаблядь.
>Klei
>2013 неголодайка на крестах и луа
>2014 Invisible на чужом фреймворке с крестами и луа
>2018 HOT Lava на UE4 с крестами. В процессе движок апгрейдится до Юнити
>2017 Oxygen Not Included на юнити. Без крестов и луа.
Пргресс, ёптаблядь.
>>554679
Учатся на своих ошибках парни
Учатся на своих ошибках парни
>>554679
Заметь, что кроме DS - все шлак и вроде как без модов.
А именно на них держится его популярность.
Как там с модами под юнити, бтв?
Алсо DS и DST - это своего рода TES у беседки или ФИФА у ЕА, которую доить можно еще долго. DLC выпускают каждые два года и их всегда раскупают. У меня большие сомнения, что юнити поделия обладают такой же кустомабельностью. Под DS вон даже DnD запилили. Там вообще по-сути конструктор, ваяй что хочешь.
Заметь, что кроме DS - все шлак и вроде как без модов.
А именно на них держится его популярность.
Как там с модами под юнити, бтв?
Алсо DS и DST - это своего рода TES у беседки или ФИФА у ЕА, которую доить можно еще долго. DLC выпускают каждые два года и их всегда раскупают. У меня большие сомнения, что юнити поделия обладают такой же кустомабельностью. Под DS вон даже DnD запилили. Там вообще по-сути конструктор, ваяй что хочешь.
>>554737
Хуй знает, объективно оксиген лучшее, что было у клей.
https://forums.kleientertainment.com/forums/topic/88186-mods05-oni-modloader/
Кек. У оксигена модкит есть и глобальные моды.
На оксиген раз в месяц выходит обнова, которая расширяет геймплей, добавляет новые фичи и ресурсы.
Хуй знает, объективно оксиген лучшее, что было у клей.
>НЕДАВНИЕ ОБЗОРЫ: Очень положительные (359)
>ВСЕ ОБЗОРЫ: Очень положительные (15,946)
>Там вообще по-сути конструктор, ваяй что хочешь.
https://forums.kleientertainment.com/forums/topic/88186-mods05-oni-modloader/
Кек. У оксигена модкит есть и глобальные моды.
>DLC выпускают каждые два года
На оксиген раз в месяц выходит обнова, которая расширяет геймплей, добавляет новые фичи и ресурсы.
>>554761
ну ок, сравнимо
хотя еще далеко
лол
превед конпеляция и лишь под венду
спасибо,я этого овна уже под римворлд поел
ну ок, сравнимо
хотя еще далеко
> It allows to load mods contained in independent dll files
лол
превед конпеляция и лишь под венду
спасибо,я этого овна уже под римворлд поел
>>554771
Так неголодайка и вышла пораньше. Ну и покупается лучше, всё-таки 40 рублей это не 250.
Ну во-первых, платформа-то одна. На линупсах в эти ваши игры не играют. А во-вторых, игровой код в открытом виде, ilSpy в руки и погнал пилить под себя. Да и нахуя Клей давать тебе модкит уровня беседковского такой же глючный, но дающий дофига контроля если они сами по себе пилят "моды" ради подъёма продаж. Но мы уже уходим в строну, что хотел я уже сказал.
>хотя еще далеко
Так неголодайка и вышла пораньше. Ну и покупается лучше, всё-таки 40 рублей это не 250.
>превед конпеляция и лишь под венду
Ну во-первых, платформа-то одна. На линупсах в эти ваши игры не играют. А во-вторых, игровой код в открытом виде, ilSpy в руки и погнал пилить под себя. Да и нахуя Клей давать тебе модкит уровня беседковского такой же глючный, но дающий дофига контроля если они сами по себе пилят "моды" ради подъёма продаж. Но мы уже уходим в строну, что хотел я уже сказал.
>>554621
Объясни подробнее, разве sdl в свою очередь не обертка над opengl и directx, чтобы самому в эти апи не лезть? Зачем love2d в opengl лезет?
>love2d - это, если быть точным, обертка над sdl+opengl.
Объясни подробнее, разве sdl в свою очередь не обертка над opengl и directx, чтобы самому в эти апи не лезть? Зачем love2d в opengl лезет?
>>554838
Шейдеры, например, в любом случае пишутся на glsl. Плюс кусочек оптимизаций вывода графена. SDL - не всеобъемлющая обёртка над графикой, хотя там и много всего полустандартного.
Шейдеры, например, в любом случае пишутся на glsl. Плюс кусочек оптимизаций вывода графена. SDL - не всеобъемлющая обёртка над графикой, хотя там и много всего полустандартного.
>>551452
Ты зачем из-под рута сидишь, дурик?
Ты зачем из-под рута сидишь, дурик?
25,9 Мб, 768x483бампуски
>>571468
а насколько там важные отличия?
порта на ведроид скорее всего не будет в ближайшем будущем вот и думал чтоб все на одной 11.1 базе делать свои ААА прожекты.
а насколько там важные отличия?
порта на ведроид скорее всего не будет в ближайшем будущем вот и думал чтоб все на одной 11.1 базе делать свои ААА прожекты.
>>573721
Юнити потребует бабло за комерч. исп. На юнити особо не повелосипедишь, юзай что дают и не выебывайся. А на луа я могу хоть по сети передать все - от текстурки до полного префаба очередного монстрика со своими стайтграфами, мозгами и прочим.
В общем не мешай тут кирилить, пили очередной раннер, платформир и прочее тормозное говно для мобил.
Юнити потребует бабло за комерч. исп. На юнити особо не повелосипедишь, юзай что дают и не выебывайся. А на луа я могу хоть по сети передать все - от текстурки до полного префаба очередного монстрика со своими стайтграфами, мозгами и прочим.
В общем не мешай тут кирилить, пили очередной раннер, платформир и прочее тормозное говно для мобил.
>>573722
Ну удачи тебе
>ыыы юнитя для шкальникав, ыыыы, пили платформиры, пока я тут гташку заебашу на говне, ыыы
Ну удачи тебе
>>573723
Тредик не про говноюнити. Иди метйся говном с уе4 и годотами. Там тебе рады.
А тут суровые дивилопиры. Это все равно как сидиезник сунулся бы к ассемблеровщикам.
Тредик не про говноюнити. Иди метйся говном с уе4 и годотами. Там тебе рады.
А тут суровые дивилопиры. Это все равно как сидиезник сунулся бы к ассемблеровщикам.
>>573724
Да вы только на словах львы толстые, а на деле хуи велосипедные. Пока очередной костыль пилите весь ваш настрой улетучивается. На ваших говнодвижках вообще игр нету, балаболки пиздливые.
Да вы только на словах львы толстые, а на деле хуи велосипедные. Пока очередной костыль пилите весь ваш настрой улетучивается. На ваших говнодвижках вообще игр нету, балаболки пиздливые.
>>573725
как минимум две в стиме, с положительным рейнтингом.
так что ИЗВИНИСЬ.
ДА и вообще можно подумОть тут хоть один успешный дивилопир на этом твоем лагунити.
>вообще игр нету
как минимум две в стиме, с положительным рейнтингом.
так что ИЗВИНИСЬ.
ДА и вообще можно подумОть тут хоть один успешный дивилопир на этом твоем лагунити.
>>573762
Билд для тестов (льём сурц игры в ~/sdcard/lovegame)
https://bitbucket.org/rude/love/downloads/love-11.1-android.apk
Как билдить полноценные приложения - есть инструкции же, и там есть 11.1 и по моему даже 11.2.
Билд для тестов (льём сурц игры в ~/sdcard/lovegame)
https://bitbucket.org/rude/love/downloads/love-11.1-android.apk
Как билдить полноценные приложения - есть инструкции же, и там есть 11.1 и по моему даже 11.2.
>>576154
Более чем
Более чем
>>581847
Диплом пишу, пока прогресса нет.
Диплом пишу, пока прогресса нет.
>>305497 (OP)
Имеет ли смысл писать все велосипеды и прочее на C/SDL или сразу переходить на LOVE? Сильно ли последний сжирает лишних ресурсов? Единственная ссылка по теме ведёт на давно закрытый форум
Имеет ли смысл писать все велосипеды и прочее на C/SDL или сразу переходить на LOVE? Сильно ли последний сжирает лишних ресурсов? Единственная ссылка по теме ведёт на давно закрытый форум
>>599824
сильно. на love2d сейчас смысла писать нет. нет поддержки платформ
>Сильно ли последний сжирает лишних ресурсов?
сильно. на love2d сейчас смысла писать нет. нет поддержки платформ
>>599824
Если собираешься пилить 2д, то хватит за глаза. Да и 3д есть возможность сделать, и скорее всего успешно, если пилить по уму.
Луа на самом деле не такой уж жирный (не зря ж его во встраиваемых системаю юзают и как скриптовый язык часто). А какие-то критичные части можно перевести на плюсы (FFI).
С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними.
Короче лёв скорее для энтузиастов. Если нравится луа+лёв и есть желание повозиться, то не вижу проблем.
Пара списков игр на лёве:
https://store.steampowered.com/curator/32659238-LÖVE-Games/
https://itch.io/games/platform-android/tag-love2d
Если собираешься пилить 2д, то хватит за глаза. Да и 3д есть возможность сделать, и скорее всего успешно, если пилить по уму.
Луа на самом деле не такой уж жирный (не зря ж его во встраиваемых системаю юзают и как скриптовый язык часто). А какие-то критичные части можно перевести на плюсы (FFI).
С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними.
Короче лёв скорее для энтузиастов. Если нравится луа+лёв и есть желание повозиться, то не вижу проблем.
Пара списков игр на лёве:
https://store.steampowered.com/curator/32659238-LÖVE-Games/
https://itch.io/games/platform-android/tag-love2d
>>599828
проблема луа в отсутствии низкоуровневых типов данных.
любой мало-мальски сложный алгоритм будет нещадно тормозить из-за таблиц.
>Луа на самом деле не такой уж жирный
проблема луа в отсутствии низкоуровневых типов данных.
любой мало-мальски сложный алгоритм будет нещадно тормозить из-за таблиц.
>>599828
Любительские поделки, которые не обновлялись годами. Я бы на это серьезно не рассчитывал при создании игры, так как будет не очень приятно в конце разработки обнаружить какую-нибудь ошибку при использовании порта
>С кроссплатформенностью да, не все так гладко, но вообще люди и под линуксом, и на андроид пилят, и на мак/иос. Были порты и для веба, сейчас хз как с ними.
Любительские поделки, которые не обновлялись годами. Я бы на это серьезно не рассчитывал при создании игры, так как будет не очень приятно в конце разработки обнаружить какую-нибудь ошибку при использовании порта
>>599831
Таблицы в целом довольно оптимизированы, даже если будут дырки в массиве. Для числовой индексации там обычный массив используется, для доступа по ключу - хэш-таблица, там особо нечему тормозить если совсем жирно не растрачиваться на использование памяти. Есть некоторые фишки, которые стоит учитывать для оптимального кода
https://www.lua.org/gems/sample.pdf
http://lua-users.org/wiki/OptimisationCodingTips
Можно подрубить FFI и на Сях запилить какую тебе угодно plain old data структуру.
>>599832
Тут да, гарантий никаких. Если хочешь беззаботно покорять мир своей поделкой на всех возможных устройствах, то скорее надо смотреть в сторону чего-то более весомого.
Таблицы в целом довольно оптимизированы, даже если будут дырки в массиве. Для числовой индексации там обычный массив используется, для доступа по ключу - хэш-таблица, там особо нечему тормозить если совсем жирно не растрачиваться на использование памяти. Есть некоторые фишки, которые стоит учитывать для оптимального кода
https://www.lua.org/gems/sample.pdf
http://lua-users.org/wiki/OptimisationCodingTips
Можно подрубить FFI и на Сях запилить какую тебе угодно plain old data структуру.
>>599832
Тут да, гарантий никаких. Если хочешь беззаботно покорять мир своей поделкой на всех возможных устройствах, то скорее надо смотреть в сторону чего-то более весомого.
>>599824
С/С++ и SDL2 - это уже почти стандарт в гейдеве, та что все равно пригодиться
использовать ли Love - это уже зависит от проекта: 2d игры на компы и андроиды, несложные графические навороты.. если похоже на требуемое, то можно брать
сам lua мало тормозить работоспособность проекта, все же самый быстрый скриптовый язык, поэтому его и используют в большинстве игр в том или ином виде
С/С++ и SDL2 - это уже почти стандарт в гейдеве, та что все равно пригодиться
использовать ли Love - это уже зависит от проекта: 2d игры на компы и андроиды, несложные графические навороты.. если похоже на требуемое, то можно брать
сам lua мало тормозить работоспособность проекта, все же самый быстрый скриптовый язык, поэтому его и используют в большинстве игр в том или ином виде
>>601407
Вот только используют его для простого скриптинга поведения объектов, а не для программирования геймплея.
Вот только используют его для простого скриптинга поведения объектов, а не для программирования геймплея.
>>601415
Не совсем. К геймплею относятся общие компоненты и алгоритмы. Контроллер персонажа, инвентарь, логика скиллов, заклинаний, поиск пути и т.д.
А скрипты это скорее конкретные сценарии поведения для разных объектов. Активировать дверь при нажатии кнопнки с определенным ID, показать диалог с конкретными NPC. Задать NPC какое-то поведения для определенного квеста. Такие мелкие поведения очень удобно писать в скриптах, и очень неудобно писать в нормально геймплейном C++ коде.
Не совсем. К геймплею относятся общие компоненты и алгоритмы. Контроллер персонажа, инвентарь, логика скиллов, заклинаний, поиск пути и т.д.
А скрипты это скорее конкретные сценарии поведения для разных объектов. Активировать дверь при нажатии кнопнки с определенным ID, показать диалог с конкретными NPC. Задать NPC какое-то поведения для определенного квеста. Такие мелкие поведения очень удобно писать в скриптах, и очень неудобно писать в нормально геймплейном C++ коде.
>>601430
То есть скрипт это как правило небольшой, одноразовый кусок кода, который используется только в одном месте игры и больше не используется нигде.
Поэтому так легко писать такой код на высокоуровневых скриптах: просто когда тебе нужно новое поведение, то создаешь новый скрипт и все.
В С++ либо хардкодить это все нужно, либо пытаться параметризировать все в какой-то общий для всех объектов компонент.
То есть скрипт это как правило небольшой, одноразовый кусок кода, который используется только в одном месте игры и больше не используется нигде.
Поэтому так легко писать такой код на высокоуровневых скриптах: просто когда тебе нужно новое поведение, то создаешь новый скрипт и все.
В С++ либо хардкодить это все нужно, либо пытаться параметризировать все в какой-то общий для всех объектов компонент.
>>601430
Инвентарь, поиск пути и прочее - это не геймплей, а скорее движковые фичи. Их да, имеет смысл на языке самого движка делать. Все остальное - нормально реализуется в скриптах.
Проблема скриптов на с++ не в том, что неудобно писать, а в том, что надо перекомпилировать код при любых изменениях, и это довольно затяжное дело в больших проектах.
Инвентарь, поиск пути и прочее - это не геймплей, а скорее движковые фичи. Их да, имеет смысл на языке самого движка делать. Все остальное - нормально реализуется в скриптах.
Проблема скриптов на с++ не в том, что неудобно писать, а в том, что надо перекомпилировать код при любых изменениях, и это довольно затяжное дело в больших проектах.
>>601590
Сразу видно человека, никогда не писавшего на плюсах. Перекомпилируется только отдельный измененный объектный файл, т.е. если у тебя 100 cpp файлов и ты меняешь один, компилируется только один измененный, и это проходит быстро.
Вот если ты меняешь заголовок, который подключен в 100 файлах, тогда будет печаль, но на практике такое редко бывает, т.к. один заголовочник в 100 файлах это признак говнокода.
>что надо перекомпилировать код при любых изменениях
Сразу видно человека, никогда не писавшего на плюсах. Перекомпилируется только отдельный измененный объектный файл, т.е. если у тебя 100 cpp файлов и ты меняешь один, компилируется только один измененный, и это проходит быстро.
Вот если ты меняешь заголовок, который подключен в 100 файлах, тогда будет печаль, но на практике такое редко бывает, т.к. один заголовочник в 100 файлах это признак говнокода.
>>601595
Это очевидно. Но плюсы все равно не так быстро компилятся, зависит же еще от самого кода в файле.
Я к тому, что подхватить на лету скриптовый файлик проще, особенно если это нужно делать не программеру.
Это очевидно. Но плюсы все равно не так быстро компилятся, зависит же еще от самого кода в файле.
Я к тому, что подхватить на лету скриптовый файлик проще, особенно если это нужно делать не программеру.
>>601411
И для того и для того, не только как конфигурационные файлы, но и более крупные куски геймплея: minetest, dst.. тысячи их.
>>601430
Ну приблизительно так, только игра не всегда проектируется как монолитный проект, поэтому в скрипты еще уходит та логика, которая может быть модифицирована игроками и мододелами.
>>601590
Нет, так поступают по другим причинам. Данные выкидывают в скрипты в проектам, потому что часто ядром геймплейной логики, которая пишется на плюсах, занимается одни кодеры, а сам контент с его тонким поведением описывают другие кодеры или вообще те, кто далековат от программирования.
И для того и для того, не только как конфигурационные файлы, но и более крупные куски геймплея: minetest, dst.. тысячи их.
>>601430
Ну приблизительно так, только игра не всегда проектируется как монолитный проект, поэтому в скрипты еще уходит та логика, которая может быть модифицирована игроками и мододелами.
>>601590
Нет, так поступают по другим причинам. Данные выкидывают в скрипты в проектам, потому что часто ядром геймплейной логики, которая пишется на плюсах, занимается одни кодеры, а сам контент с его тонким поведением описывают другие кодеры или вообще те, кто далековат от программирования.
>>599826
ондроед есть (нестандартная репа)
шинда есть
линупс с фрибсд есть
про гейос только неуверен, да и хуй с ней. С ней даже стим не особо заморачивается.
шо еще надо?
ондроед есть (нестандартная репа)
шинда есть
линупс с фрибсд есть
про гейос только неуверен, да и хуй с ней. С ней даже стим не особо заморачивается.
шо еще надо?
>>599831
есть FFI
есть FFI
Ананасы, раньше кодил немного на луа (делал аддоны и всякие скрипты для варкрафта).
Потом как-то забросил это дело, а некоторое время назад занялся играми и написал несколько на с++ и sfml.
Здорово, конечно, но всё это делалось довольно не быстро.
Недавно попробовал луа снова (не для игр), оказалось очень здорово и быстро.
Так вот, с чего начать разбираться в love2d?
Потом как-то забросил это дело, а некоторое время назад занялся играми и написал несколько на с++ и sfml.
Здорово, конечно, но всё это делалось довольно не быстро.
Недавно попробовал луа снова (не для игр), оказалось очень здорово и быстро.
Так вот, с чего начать разбираться в love2d?
>>615734
Скорость разработки с лёвом - неоднозначный вопрос. Хотя сейчас все больше библиотек появляется, в чем-то становится попроще.
Начинай с вики, она очень годная. Там же и список известных либ можно найти. Какие-то вещи можно на форуме найти.
Если сам кумекаешь нормально, то этого хватит. А так, на хабре и на ютубчике еще можно найти серию уроков на русском
Скорость разработки с лёвом - неоднозначный вопрос. Хотя сейчас все больше библиотек появляется, в чем-то становится попроще.
Начинай с вики, она очень годная. Там же и список известных либ можно найти. Какие-то вещи можно на форуме найти.
Если сам кумекаешь нормально, то этого хватит. А так, на хабре и на ютубчике еще можно найти серию уроков на русском
>>615734
С вики, плюс на ютубе можешь найти приличное количество туториалов. Не советую замахиваться на что-то сложное, начни с крестиков-ноликов, змеек и понгов.
С вики, плюс на ютубе можешь найти приличное количество туториалов. Не советую замахиваться на что-то сложное, начни с крестиков-ноликов, змеек и понгов.
>>615734
и вечно
В каком смысле быстро? В плане чего? Скорости работы, скорости написания программ?
> оказалось очень здорово и быстро.
и вечно
В каком смысле быстро? В плане чего? Скорости работы, скорости написания программ?
>>627468
Скорости написания конечно же
Скорости написания конечно же
>>627468
К концу декабря запилю свой ШИДЕВР. Всем пиздеЦ!
Ну а если серьезно, то очевидно жи что можно кодить прямо в активном игоре, правя и дописывая на лету. Без конпеляций и смс.
К концу декабря запилю свой ШИДЕВР. Всем пиздеЦ!
Ну а если серьезно, то очевидно жи что можно кодить прямо в активном игоре, правя и дописывая на лету. Без конпеляций и смс.
>>633260
год не указан, так что жди
год не указан, так что жди
>>645656
Потихонечку, помаленечку.
Потихонечку, помаленечку.
Нужно хоть расшевелить и поднять наш тред, а то что мы.
Кто какие библиотеки использует в проектах и почему? Или может чем-то не зашли и писали свое намного лучше?
Animation: anim8, Walt ...
Localization: utf8, i18n ...
ECS: concord, knife, nata, tiny-ecs ...
Кто какие библиотеки использует в проектах и почему? Или может чем-то не зашли и писали свое намного лучше?
Animation: anim8, Walt ...
Localization: utf8, i18n ...
ECS: concord, knife, nata, tiny-ecs ...
>>645730
Один проект полностью на своем, в т.ч. ECS , физон и небольшая GUI либа, потому что ебанутый. На самом деле очень тяжело каждую систему самостоятельно пилить.
Другой проект решил заюзать готовые решения, для GUI - SUIT, ибо заебался. От того же автора собираюсь для твининга hump.timer использовать.
SUIT своеобразный довольно, и достаточно лоу-левельный, приходится все равно свои надстройки придумывать. Но среди всего это, наверное, самый простой варик, чтобы сел и поехал. Есть imgui и nuklear, но их еще компилить надо.
Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д.
https://github.com/love2d-community/awesome-love2d
Один проект полностью на своем, в т.ч. ECS , физон и небольшая GUI либа, потому что ебанутый. На самом деле очень тяжело каждую систему самостоятельно пилить.
Другой проект решил заюзать готовые решения, для GUI - SUIT, ибо заебался. От того же автора собираюсь для твининга hump.timer использовать.
SUIT своеобразный довольно, и достаточно лоу-левельный, приходится все равно свои надстройки придумывать. Но среди всего это, наверное, самый простой варик, чтобы сел и поехал. Есть imgui и nuklear, но их еще компилить надо.
Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д.
https://github.com/love2d-community/awesome-love2d
>>645743
По поводу ECS есть такой бенчмарк от создателя одного из них (Concord):
https://github.com/Tjakka5/love-ecs-benchmarks
только в нем наиболее используемого tiny-ecs нет, думаю запилить, как время будет
Да, с gui сложно определяться. Особенно когда мультиплатформу надо и пытаешься сдружить какой-нибудь imgui под андроид.
Эту подборку как раз недавно потыкал почти всю. И оказалось, что ей новичков только пугать. Там почти все либо устаревшее либо гораздо хуже альтернатив, которые там даже не представлены. Надо тоже какую-то такую подборку сделать, только в каждом пункте по несколько вариантов с пояснениями для этих самых новичков, что вот берите это если надо это или берите то - если то.
По поводу ECS есть такой бенчмарк от создателя одного из них (Concord):
https://github.com/Tjakka5/love-ecs-benchmarks
только в нем наиболее используемого tiny-ecs нет, думаю запилить, как время будет
Да, с gui сложно определяться. Особенно когда мультиплатформу надо и пытаешься сдружить какой-нибудь imgui под андроид.
>Алсо, чтобы не забывали, подборка наиболее известных либ для лов2д.
Эту подборку как раз недавно потыкал почти всю. И оказалось, что ей новичков только пугать. Там почти все либо устаревшее либо гораздо хуже альтернатив, которые там даже не представлены. Надо тоже какую-то такую подборку сделать, только в каждом пункте по несколько вариантов с пояснениями для этих самых новичков, что вот берите это если надо это или берите то - если то.
>>645752
Тот списочек вроде как даже обновляется. Только видимо устаревшие линки никто не хочет убирать.
Что сам юзаешь? Что пилишь?
Как сейчас с компиляцией под андроид? Сильно надо надрываться, чтобы адекватно работало?
Тот списочек вроде как даже обновляется. Только видимо устаревшие линки никто не хочет убирать.
Что сам юзаешь? Что пилишь?
Как сейчас с компиляцией под андроид? Сильно надо надрываться, чтобы адекватно работало?
>>645759
Нет, под андроид сейчас довольно удобно, все есть даже для последней актуальной версии ловки.
Юзаю обычно из несамописного только i18n и imgui. Но тоже хочется каких-то уже готовых стандартных библиотек, принятых и поддержиаемых сообществом. Для игр так вообще вроде есть ряд основных задач, которые хорошо было бы прямо в сам движок уже изначально встроить, те же состояния. А то пишут все зоопарк кода, потом выкладывают просто так, потом новички лезут и путаются.
Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
Нет, под андроид сейчас довольно удобно, все есть даже для последней актуальной версии ловки.
Юзаю обычно из несамописного только i18n и imgui. Но тоже хочется каких-то уже готовых стандартных библиотек, принятых и поддержиаемых сообществом. Для игр так вообще вроде есть ряд основных задач, которые хорошо было бы прямо в сам движок уже изначально встроить, те же состояния. А то пишут все зоопарк кода, потом выкладывают просто так, потом новички лезут и путаются.
Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
>>645762
Лёв изначально как биндинг над SDL задумывался, так что вряд ли в него будут игроспецифичные вещи добавлять.
Так-то вообще можно конструктор на ловке запилить. И уже были какие-то попытки, например Grid https://love2d.org/forums/viewtopic.php?f=5&t=80115
Вообще есть мысли под ECS намутить какой-то просмотрщик-редактор, чтобы можно было сущности проектировать, смотреть какие компоненты с данными есть, автоматически генерить системы с нужной оболочкой и просто писать в них поведение.
Круто.
Я свои поделки все никак не доведу до нормального состояния. Хотелось бы в стим как-нибудь релизнуться. Но на горизонте событий этого пока не предвидится.
Лёв изначально как биндинг над SDL задумывался, так что вряд ли в него будут игроспецифичные вещи добавлять.
Так-то вообще можно конструктор на ловке запилить. И уже были какие-то попытки, например Grid https://love2d.org/forums/viewtopic.php?f=5&t=80115
Вообще есть мысли под ECS намутить какой-то просмотрщик-редактор, чтобы можно было сущности проектировать, смотреть какие компоненты с данными есть, автоматически генерить системы с нужной оболочкой и просто писать в них поведение.
>Я пилю всякие мелкие игры на студию одну: чаще банальные телефонные тыкалки и тому подобное.
Круто.
Я свои поделки все никак не доведу до нормального состояния. Хотелось бы в стим как-нибудь релизнуться. Но на горизонте событий этого пока не предвидится.
Поясните про терминологию ECS:
вот есть компонент, например, позиция в пространстве (условно мечника)
сущность - это уже созданный экземпляр (один из 10 мечников в игре) или это как некий класс этот мечник, а экземпляры называются другим словом?
Вроде везде создают что-то типа World, куда пихают сущности уже как экземпляры.
вот есть компонент, например, позиция в пространстве (условно мечника)
сущность - это уже созданный экземпляр (один из 10 мечников в игре) или это как некий класс этот мечник, а экземпляры называются другим словом?
Вроде везде создают что-то типа World, куда пихают сущности уже как экземпляры.
>>645793
В ЕЦС сущность - это то, под чем объединяется набор компонентов. Набор компонентов не фиксированный, поэтому условный мечник может стать условным лучником, если удалить/добавить какие-то компоненты.
С одной стороны сущность - это абстракция в ЕЦС подходе, типа в игре есть игровые сущности, они все разные, но механизм один и тот же (т.е. что-то типа класса, но на самом деле его нет явно).
С другой стороны сущность - это уже айдишник в каком-то конкретном менеджере ЕЦС, к которому как раз привязываются компоненты, и тут оно ближе к экземпляру.
В ЕЦС сущность - это то, под чем объединяется набор компонентов. Набор компонентов не фиксированный, поэтому условный мечник может стать условным лучником, если удалить/добавить какие-то компоненты.
С одной стороны сущность - это абстракция в ЕЦС подходе, типа в игре есть игровые сущности, они все разные, но механизм один и тот же (т.е. что-то типа класса, но на самом деле его нет явно).
С другой стороны сущность - это уже айдишник в каком-то конкретном менеджере ЕЦС, к которому как раз привязываются компоненты, и тут оно ближе к экземпляру.
>>645795
Ну т.е. сущность - это все же уже созданный экземпляр некого "объекта"?
Ну вот в игре допустим в каком-то файлике хранится "name = волк, hp = 100", а в другом "name = злой волк, hp = 150"
Под это дело есть компоненты.
Конкретный экземпляр волка из первого файлика - это и будет Сущность по ECS? Т.е. уже конкретный волк где-то в мире с конкретными жизнями, который был заспавнен со 100 hp.
Ну т.е. сущность - это все же уже созданный экземпляр некого "объекта"?
Ну вот в игре допустим в каком-то файлике хранится "name = волк, hp = 100", а в другом "name = злой волк, hp = 150"
Под это дело есть компоненты.
Конкретный экземпляр волка из первого файлика - это и будет Сущность по ECS? Т.е. уже конкретный волк где-то в мире с конкретными жизнями, который был заспавнен со 100 hp.
>>645801
Не встречал где-либо разделение на общий класс сущности и ее экзепляр в игре, поэтому скорее всего тоже сущностью можно называть.
Не встречал где-либо разделение на общий класс сущности и ее экзепляр в игре, поэтому скорее всего тоже сущностью можно называть.
М>>645796
Нет, в ECS "сущность" это просто айдишник, обычно integer.
Нет, в ECS "сущность" это просто айдишник, обычно integer.
>>645921
там тоже нет термина, про который спрашивал
там тоже нет термина, про который спрашивал
397 Кб, 800x800Знаю что спрашиваю не там, но кто нибудь знает какой программой можно рисовать полигонами (желательно что бы можно было их потом разукрасить) Векторные редакторы так могут?
Вот картинка по типу этого
Хотелось бы сделать такую графику в своём love2d проекте, и желательно так что бы при зуме не пропадало качество.
Было бы ещё лучше если бы картинка такого формата была бы просто набором координат как obj форматы, но забейте про это, я потом может что то своё такое напишу. Сейчас просто прошу помочь найти программу которая может подобное
Вот картинка по типу этого
Хотелось бы сделать такую графику в своём love2d проекте, и желательно так что бы при зуме не пропадало качество.
Было бы ещё лучше если бы картинка такого формата была бы просто набором координат как obj форматы, но забейте про это, я потом может что то своё такое напишу. Сейчас просто прошу помочь найти программу которая может подобное
>>647222
Тебе нужен векторный редактор. Вообще вроде от адоби лучший, но я очень люблю аниме студию, она проще и быстрее гораздо делать, но функций меньше, что-то суперсложное не сделаешь. Но такую бошку запросто.
Тебе нужен векторный редактор. Вообще вроде от адоби лучший, но я очень люблю аниме студию, она проще и быстрее гораздо делать, но функций меньше, что-то суперсложное не сделаешь. Но такую бошку запросто.
>>647226
Оке, фенькю, позже гляну
Оке, фенькю, позже гляну
Вечер добрый. Можно ли на лёве реализовать простенький мультиплеер, шобработало? Или это херня идея?
Уровень функционала, который я хочу от этого: не более шести игроков, пошаг, геймплей неторопливый, но динамичный, на уровне карточных игор.
Просто люблю Луа, посему выбор у меня невелик - лёва, всякие короны там и крафтстудио.
Уровень функционала, который я хочу от этого: не более шести игроков, пошаг, геймплей неторопливый, но динамичный, на уровне карточных игор.
Просто люблю Луа, посему выбор у меня невелик - лёва, всякие короны там и крафтстудио.
>>648201
Люди делают, значит можна
Люди делают, значит можна
>>648201
получилось?
получилось?
Сделал почти 3д проекцию в love2d но есть проблема с полигонами, некоторые полигоны отрисовываются на других из-за чего происходит странная непонятная хрень, есть ли способ сортировать по переменной в таблице?
table.sort сортирует только если значение число а не таблица, по сути это bubble sort
Мне подойдёт даже пример с сортировкой 2д спрайтов по координатам (есть ведь алгоритмы где рисуют слева направо сверху вниз)
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))
Или вообще свою сортировку какую хочешь, хотя в луа квиксорт используется.
Погуглил за тебя
Можно кастомный компаратор написать
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))
Или вообще свою сортировку какую хочешь, хотя в луа квиксорт используется.
>>653046
С ним
С ним
>>305852
Мас. Рэндом, лол
А що будет если звезды сойдутся и будет два одинаковых номера?
Асло библиотеку классов давным-давно навасянили и без этого велосипеда.
Мас. Рэндом, лол
А що будет если звезды сойдутся и будет два одинаковых номера?
Асло библиотеку классов давным-давно навасянили и без этого велосипеда.
>>653047
В общем спасибо тебе что погуглил, всё равно полезная хрень, но я нашёл объяснение создание функции для table.sort
Век живи век учись, блять
В общем я попробую отсортировать грани по тому что я нашёл, для этого я скорее всего опять буду 3 дня дрочить код
В общем спасибо тебе что погуглил, всё равно полезная хрень, но я нашёл объяснение создание функции для table.sort
Век живи век учись, блять
В общем я попробую отсортировать грани по тому что я нашёл, для этого я скорее всего опять буду 3 дня дрочить код
>>653046
Чё за торида?
Чё за торида?
куда надо пихать игру, когда собираешь по андроид?
вроде указано, что в app/src/assets, создал, кидаю туда и все равно запускает дефолтное окошечко с шариком
вроде указано, что в app/src/assets, создал, кидаю туда и все равно запускает дефолтное окошечко с шариком
>>655133
upd: app\src\main\assets\
upd: app\src\main\assets\
Пробовал уже варианты и архивом love и просто main.lua положить, но все равно не видит, внутри apk все есть в этом же assets каталоге
74 Кб, 256x256>>653010
Тут проблема для z-буфера, причём она глубже чем кажется: для такого программного рендеринга, нужно из треугольника выпиливать видимую часть (многоугольник, не пересекающийся с другими полигонами более переднего плана), и рендерить уже его.
Прикреплённая картинка - это rarjpeg с Настоящим Хардварным 3d на ловке, переименуй в .love и чекни.
Тут проблема для z-буфера, причём она глубже чем кажется: для такого программного рендеринга, нужно из треугольника выпиливать видимую часть (многоугольник, не пересекающийся с другими полигонами более переднего плана), и рендерить уже его.
Прикреплённая картинка - это rarjpeg с Настоящим Хардварным 3d на ловке, переименуй в .love и чекни.
>>659174
Уточнение: тут же простейший пример хардварной трёхмерной графики через шейдер:
1. Два канваса: рендертаржет + Z-буфер
2. Слегка модифицированные меши, с координатами точек по Z-оси,
3. Кастомный шейдер, который принимает матрицы view (камера) и model (матрица модельки)
Уточнение: тут же простейший пример хардварной трёхмерной графики через шейдер:
1. Два канваса: рендертаржет + Z-буфер
2. Слегка модифицированные меши, с координатами точек по Z-оси,
3. Кастомный шейдер, который принимает матрицы view (камера) и model (матрица модельки)
30 Кб, 1441x257>>659174
Если будут вопросы по распаковке - из rarjpeg'а достаточно отпилить часть с картинкой (см пик), и можно открывать как zip-архив с исходным кодом.
Если будут вопросы по распаковке - из rarjpeg'а достаточно отпилить часть с картинкой (см пик), и можно открывать как zip-архив с исходным кодом.
>>659174
Ого, спасибо за развёрнутый ответ, я попытаюсь что то из этого понять
Ого, спасибо за развёрнутый ответ, я попытаюсь что то из этого понять
>>659848
Мне по фану, да и мне это действительно помогает, чем глубже копаю тем больше понимаю
Мне по фану, да и мне это действительно помогает, чем глубже копаю тем больше понимаю
>>659848
А в чем там проблема-то, немного переписать рендер под 3D. А так ловка это же тонкая прослойка над SDL2, так что вообще ограничений особо никаких.
А в чем там проблема-то, немного переписать рендер под 3D. А так ловка это же тонкая прослойка над SDL2, так что вообще ограничений особо никаких.
>>661962
Дополню: плюс в 11 версии добавили кучу трёхмерных фишек опенгла, вроде того же z-буфера нормального, и возможности нормально кастомить меши в произвольные массивы данных на видеокарте: запилить модель + цвета вершин + кости + шейдеры по отношению к конкретным костям - как нехуй делать.
Дополню: плюс в 11 версии добавили кучу трёхмерных фишек опенгла, вроде того же z-буфера нормального, и возможности нормально кастомить меши в произвольные массивы данных на видеокарте: запилить модель + цвета вершин + кости + шейдеры по отношению к конкретным костям - как нехуй делать.
Что интересного в 12 ловке добавят?
Тут сверху есть пару слов об этом, но я тупой и нихера не понял.
Мой 3д проект который я хочу сделать тупо стоит на месте как раз из-за того что я не умею в глубину, сортирую полигоны по расстоянию, но это затратно.
Вроде как уже и больше понимать стал, пытаюсь просто нарисовать 2 меша треугольника так что бы было видно что буфер глубины работает, но сколько я видосов не смотрел я всё равно нихуя не понимаю + тут як понял именно на шейдере всё можно сделать, как в OpenGL ( смотрел в видосах ), но повторюсь что я нихуя не пойму.
Может я и сам когда нибудь всё выясню но хотелось бы ускорить этот прогресс, т.к. сейчас зависаю в месте без интернета и от скуки делаю всякую парашу в ловке (на андроиде, гыг)
СПАСИТЕ МЕНЯ и простите за всю хуйню которую я ща написал, два дня не спал мозг не работает
Мой 3д проект который я хочу сделать тупо стоит на месте как раз из-за того что я не умею в глубину, сортирую полигоны по расстоянию, но это затратно.
Вроде как уже и больше понимать стал, пытаюсь просто нарисовать 2 меша треугольника так что бы было видно что буфер глубины работает, но сколько я видосов не смотрел я всё равно нихуя не понимаю + тут як понял именно на шейдере всё можно сделать, как в OpenGL ( смотрел в видосах ), но повторюсь что я нихуя не пойму.
Может я и сам когда нибудь всё выясню но хотелось бы ускорить этот прогресс, т.к. сейчас зависаю в месте без интернета и от скуки делаю всякую парашу в ловке (на андроиде, гыг)
СПАСИТЕ МЕНЯ и простите за всю хуйню которую я ща написал, два дня не спал мозг не работает
>>697969
Самое главное забыл - хотелось бы избежать использование сторонних/чужих библиотек, ибо хочу именно всё сам делать научится, так сказать склад велосипедов пополнить
Самое главное забыл - хотелось бы избежать использование сторонних/чужих библиотек, ибо хочу именно всё сам делать научится, так сказать склад велосипедов пополнить
89 Кб, 264x191Луа-куны, нытик-кун вернулся.
Глядите, чо нашел. Это ведь почти лёв2д, но с функционалом среды разработки и всяких плюшек! Плюс обещают много чего искаропки.
https://store.steampowered.com/app/1386180/Bitty_Engine/
Меня смущает цена. Позволить-то себе могу, хуле. Сэкономлю на завтраках бензине разобью свинью-копилку. Вопрос 1) взлетить ли и не забьет ли разраб 2) буду ли пилить игоры, а то ляжет ненужным грузом, как RPGmaker на аккаунте. Но это скорее вопросы для самокопания. Я сюда не спрашивать пришел, а поныть сообщить, что в кои-то веки кто-то делает ДВИЖОК с луашечкой.
Глядите, чо нашел. Это ведь почти лёв2д, но с функционалом среды разработки и всяких плюшек! Плюс обещают много чего искаропки.
https://store.steampowered.com/app/1386180/Bitty_Engine/
Меня смущает цена. Позволить-то себе могу, хуле. Сэкономлю на завтраках бензине разобью свинью-копилку. Вопрос 1) взлетить ли и не забьет ли разраб 2) буду ли пилить игоры, а то ляжет ненужным грузом, как RPGmaker на аккаунте. Но это скорее вопросы для самокопания. Я сюда не спрашивать пришел, а поныть сообщить, что в кои-то веки кто-то делает ДВИЖОК с луашечкой.
>>716726
Купил это чудо. Пока мне действительно нравится. Нечто среднее между love2d и юнети.
Триде вроде не завезли, но мне оно особо не надо пока.
В отличие от юнети ничего лишнего и lua искаропки.
Купил это чудо. Пока мне действительно нравится. Нечто среднее между love2d и юнети.
Триде вроде не завезли, но мне оно особо не надо пока.
В отличие от юнети ничего лишнего и lua искаропки.
>>716726
Оставил тебе (и всем луа-кунам) пост в срачетреде: >>717286 →
> Луа-куны, нытик-кун вернулся.
Оставил тебе (и всем луа-кунам) пост в срачетреде: >>717286 →
>>717287
юнетикам пора уяснить, что луа-куны принципиально в писькомерстве не участвуют, ибо взрослые и обеспеченные люди, не нуждающиеся в самоутверждении
>Оставил тебе (и всем луа-кунам) пост в срачетреде
юнетикам пора уяснить, что луа-куны принципиально в писькомерстве не участвуют, ибо взрослые и обеспеченные люди, не нуждающиеся в самоутверждении
88 Кб, 480x480>>717363
Ибо кому кроме нас еще в голову придет постоянно колесо изобретать
Ибо кому кроме нас еще в голову придет постоянно колесо изобретать
Сижу в данный момент на некро нетбуке win7-32
При запуске даже просто love.exe (да, качаю 32-битную) получаю ошибку пикрил. Аналогично на 10 версии. 9 работает, т.к. она еще была без ентих ваших джиэлей.
В системных требованиях ловки gl 2.1+, на этом ноуте gl 3.0
Куда еще потыкаться?
При запуске даже просто 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
#ifdef PIXEL
vec4 effect( vec4 color, Image tex, vec2 texture_coords, vec2 screen_coords )
{
vec4 texcolor = Texel(tex, texture_coords);
return texcolor color;
}
]]
love.graphics.setShader(shader)
И типа всё, дальше этим шейдером всё рисовать.
Ну в целом как бы драйверы, но возможно, придётся накатать какой-нибудь шейдер а ля
local shader = love.graphics.newShader[[
#pragma language glsl1
#ifdef VERTEX
vec4 position( mat4 transform_projection, vec4 vertex_position )
{
return transform_projection vertex_position;
}
#endif
#ifdef PIXEL
vec4 effect( vec4 color, Image tex, vec2 texture_coords, vec2 screen_coords )
{
vec4 texcolor = Texel(tex, texture_coords);
return texcolor color;
}
]]
love.graphics.setShader(shader)
И типа всё, дальше этим шейдером всё рисовать.
12 Кб, 623x387>>718310
шейдер не помог, собственно он валится уже на этапе, даже если просто движок запустить без проекта. Драйверы максимально возможные тут уже стоят. Ну видимо старше 9 ловки на этом некроноуте не побалуешься.
шейдер не помог, собственно он валится уже на этапе, даже если просто движок запустить без проекта. Драйверы максимально возможные тут уже стоят. Ну видимо старше 9 ловки на этом некроноуте не побалуешься.
>>718330
Сидел за любовь?
Сидел за любовь?
>>718315
Да при запуске без проекта, оно такое запускает проект "по умолчанию" с настройками по умолчанию же, который как раз рисует тебе экран no-game.
Но опять таки похоже на дрова.
Да при запуске без проекта, оно такое запускает проект "по умолчанию" с настройками по умолчанию же, который как раз рисует тебе экран no-game.
Но опять таки похоже на дрова.
>>718374
МИНИМАЛЬНЫЕ:
ОС: Windows 7/8/10 (32/64bit) (плюс есть под мак и лин)
Процессор: 1.5GHz
Оперативная память: 512 MB ОЗУ
Видеокарта: Intel HD
Место на диске: 150 MB
Только не говори, что у тебя на нетбуке не взлетит
МИНИМАЛЬНЫЕ:
ОС: Windows 7/8/10 (32/64bit) (плюс есть под мак и лин)
Процессор: 1.5GHz
Оперативная память: 512 MB ОЗУ
Видеокарта: Intel HD
Место на диске: 150 MB
Только не говори, что у тебя на нетбуке не взлетит
>>716890
Уже сделал, но у меня всё сводится к тому что я хреначу код до тех пор пока у меня не выйдет что то похожее на то что я хочу, а мне ещё парсер obj файлов писать, и много другого. Я бы хотел просто именно понять как это работает, что бы мне было с первого взгляда ясно что и куда пихать, а не что бы потом вспоминать что я сделал в прошлый раз что бы повторить, вместо того что мне нужно сделать в этот раз. Никаких чужих библиотек и строк кода я в своём коде не использую, разве что смотрю на них что бы понять как они работают, а всё своё пишу сам, ибо лучшее понимание приходит когда ты не только знаешь как это сделать, но и знаешь как это работает.
БТВ рад что тред ожил
Уже сделал, но у меня всё сводится к тому что я хреначу код до тех пор пока у меня не выйдет что то похожее на то что я хочу, а мне ещё парсер obj файлов писать, и много другого. Я бы хотел просто именно понять как это работает, что бы мне было с первого взгляда ясно что и куда пихать, а не что бы потом вспоминать что я сделал в прошлый раз что бы повторить, вместо того что мне нужно сделать в этот раз. Никаких чужих библиотек и строк кода я в своём коде не использую, разве что смотрю на них что бы понять как они работают, а всё своё пишу сам, ибо лучшее понимание приходит когда ты не только знаешь как это сделать, но и знаешь как это работает.
БТВ рад что тред ожил
>>718375
Есть старый асус еее 900 с встроенной интел, под 32бит freebsd, love2d работает, но нужно указать
LOVE_GRAPHICS_USE_GL2 = 1
в переменных окружения и все работает.
Для 64бит hd4800 под ту же фрюшечку все работает и без переменных.
Есть старый асус еее 900 с встроенной интел, под 32бит freebsd, love2d работает, но нужно указать
LOVE_GRAPHICS_USE_GL2 = 1
в переменных окружения и все работает.
Для 64бит hd4800 под ту же фрюшечку все работает и без переменных.
Что за хуйня у меня происходит при использовании шейдера с кастомной матрицей? Наверное я просто тупой.
Разве матрица допустим
Представим у меня есть вектор 1 1 1 (1)
ну или посложнее, полигон
0 0 0
1 0 0
0 1 0
Треугольник получается
И матрица
X = 1
Y = 1
Z = 1
1 0 0 1 = (X1)+(Y0)(Z0)+(W1) = 2
0 1 0 0 = (X0)+(Y1)(Z0)+(W0) = 1
0 0 1 0 = (X0)+(Y0)(Z1)+(W0) = 1
0 0 0 1 = (X0)+(Y0)(Z0)+(W1) = 1
(получается из точки 1 1 1 мы получили 2 1 1) (смещение по иксу)
но при использовании mat4 vec4 у меня выходит какая то ересь, все точки по оси X будто бы смещаются ближе к центру
Вообще я в шейдерах не сильно шарю, но мне сейчас хотя бы матрицы нужно научится применять
Вот допустим для разрешения 1920 1080 что бы левый верхний угол был началом координат для XY я должен использовать матрицу
1/1920 0 0 -1
0 1/1080 0 -1
0 0 1 0 (можно и 0 0 0 0, наверное)
0 0 0 1
Если я хочу нарисовать кубик от левого угла экрана то с матрицей
1 0 0 1
0 1 0 1
0 0 1 0
0 0 0 1
то у меня просто пустой экран, все вершины непонятно куда пропали
Я ничего не понимаю, может ли мне это кто обьяснить?
Я просто хочу сделать 3д графику, потихоньку узнаю что-то новое, но в чём проблема этой матрицы?
Для начала я хочу попробовать
Model to World
World to View
View to Projection
И вот ещё несколько вопросов. Меш хранит в себе координаты вершин, а крутит и перемещает эти вершины уже шейдер. Но что если я захочу рисовать один и тот же меш в разных вариантах? Что мне нужно будет сделать? (естественнно я говорю о love2d)
у меня допустим есть меш кролика, и я хочу нарисовать три кролика в разных координатах, мне придётся создавать таблицу с координатами, и делать три разных меш-объекта? Или я могу перед отрисовкой меша передавать шейдеру матрицу перемещения?
Допустим
krolik = newMesh(bla bla)
setshader(3d)
for k, v in pairs(таблица с крооликами) do
3d:send("modetoworld", v["МАТРИЦА ОБЪЕКТА С ИНФОРМАЦИЕЙ О ЕГО КООРДИНАТАХ, РАЗМЕРЕ, ВРАЩЕНИЯХ'])
draw(krolik)
end
естественно с буфером глубины (его я не так давно научился делать) и прочей хуетой
Ну я слишком туп. Но всё же очень сильно хочу научится делать 3д собственноручно. Пока что на Lua, OpenGL для меня сложноват
Итоговые вопросы:
1. Как мне рисовать несколько объектов из одной модельки (меша) но с разными координатами, вращением и размером (все это же матрица, не?)
2. Что не так у меня с матрицей?
Вопросы просто по фану
1. Могу ли я сделать тасселяцию?
2. Могу ли я для каждой вершины делать какое нибудь смещение? (представь куб только что каждая его вершина смещена на рандомное значение от -1 о 1 * (1/20))
3. Могу ли я изменять координаты uv развёртки во время отрисовки меша? Допустим что бы сделать кадровую анимацию текстуры. Представь что uv.x у каждой вершины меняется на +1 каждую секунду. хз. говорю же не шарю
Teach me sensei
Пожалуйста если используете трудные слова, или хорошо шарите в шейдерах, то распишите это всё так будто бы для ребёнка, а то у меня iq как у хлебушка
Разве матрица допустим
Представим у меня есть вектор 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 как у хлебушка
Что за хуйня у меня происходит при использовании шейдера с кастомной матрицей? Наверное я просто тупой.
Разве матрица допустим
Представим у меня есть вектор 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 как у хлебушка
Разве матрица допустим
Представим у меня есть вектор 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 как у хлебушка
>>735394
Я даун как шизоид всё расписал, извините. Спешил и мысли путаются
Я даун как шизоид всё расписал, извините. Спешил и мысли путаются
>>735394
Прочитай хотя бы теоретически https://learnopengl.com/
Или найди на хабре перевод
В голове хоть структура какая-то появится
Прочитай хотя бы теоретически https://learnopengl.com/
Или найди на хабре перевод
В голове хоть структура какая-то появится
>>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
Прочитал. Но именно о том о чём я написал там ни слова.
Скачал библиотеку 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
>>737932
чем то мне полюбился Lua, но мысль попробовать godot была, вот только боюсь к языку опять привыкать да синтаксис учить
чем то мне полюбился Lua, но мысль попробовать godot была, вот только боюсь к языку опять привыкать да синтаксис учить
Тред еще жив?
да
>>737827
В целом, для полноценного 3d неплохо заходит Defold.
Но и ловка неплохо заходит. А зачем делать translate через умножения вершин? Есть же вершинный шейдер.
Если анимировать - да, оно понадобится. За примерами анимаций советую посмотреть демку love3d и IQM-формат, можно передрать оттуда.
В целом, для полноценного 3d неплохо заходит Defold.
Но и ловка неплохо заходит. А зачем делать translate через умножения вершин? Есть же вершинный шейдер.
Если анимировать - да, оно понадобится. За примерами анимаций советую посмотреть демку love3d и IQM-формат, можно передрать оттуда.
44 Кб, 749x382Аноны, есть ли смысл вот так извращаться, чтобы запилить вменяемое ООП на луа?
__index не предлагать.
__index не предлагать.
>>744673
Да, норм тема. Есть свои плюсы и минусы
http://lua-users.org/wiki/ObjectOrientationTutorial
Есть варианты запила ООП через специальные промежуточные классы, в чем-то мб удобнее
http://lua-users.org/wiki/SimpleLuaClasses
https://github.com/kikito/middleclass
Да, норм тема. Есть свои плюсы и минусы
http://lua-users.org/wiki/ObjectOrientationTutorial
Есть варианты запила ООП через специальные промежуточные классы, в чем-то мб удобнее
http://lua-users.org/wiki/SimpleLuaClasses
https://github.com/kikito/middleclass
Здраст. сорян что оффтоп, но вот я видел парочку симуляторов логики (логические вентили)
И вот как бы такой вот вопрос, если я хочу сделать себе такой же симулятор, но у меня получается так что обновление схемы происходит каждый игровой тик, как мне сделать так что бы схема полностью обновлялась за один игровой тик?
Просто если я сделаю цепь из 5 ворот то активировав первое она полностью активируется через 4 тика. Есть пара примеров. Garrys Mod с модом Wiremod (там есть logic gates)
Scrap mechanic
Digital Logic Sim от какого то ютубера
NandGame
В последних двух задержки либо нет либо она очень низкая, хотя вот в NandGame игра тебе говорит если ты замкнул схему, так что мне кажется что в DigitalLogicSim задержка есть но очень маленькая. Так же, если вдруг делать такую же симуляцию как в NandGame то как мне сделать проверку замыкания? Что бы не было бесконечного цикла
И вот как бы такой вот вопрос, если я хочу сделать себе такой же симулятор, но у меня получается так что обновление схемы происходит каждый игровой тик, как мне сделать так что бы схема полностью обновлялась за один игровой тик?
Просто если я сделаю цепь из 5 ворот то активировав первое она полностью активируется через 4 тика. Есть пара примеров. Garrys Mod с модом Wiremod (там есть logic gates)
Scrap mechanic
Digital Logic Sim от какого то ютубера
NandGame
В последних двух задержки либо нет либо она очень низкая, хотя вот в NandGame игра тебе говорит если ты замкнул схему, так что мне кажется что в DigitalLogicSim задержка есть но очень маленькая. Так же, если вдруг делать такую же симуляцию как в NandGame то как мне сделать проверку замыкания? Что бы не было бесконечного цикла
>>745385
Быстро фикс
Сорян, в Garrys Mod с Wiremod на логических вентилях я тоже не заметил задержки, а она на Lua, вот и хочу узнать как я могу сделать свой симулятор без задержки
Быстро фикс
Сорян, в Garrys Mod с Wiremod на логических вентилях я тоже не заметил задержки, а она на Lua, вот и хочу узнать как я могу сделать свой симулятор без задержки
>>745385
Юзай алгоритмы на графах.
Просто берешь и обходишь граф сети, включаешь то, что должно быть включено. Остальное отключено.
При обходе помечаешь пройденные вершины, если наткнулся на уже пройденную - значит у тебя цикл.
Обойти граф из пары десятков элементов ничего не стоит практически.
Юзай алгоритмы на графах.
Просто берешь и обходишь граф сети, включаешь то, что должно быть включено. Остальное отключено.
При обходе помечаешь пройденные вершины, если наткнулся на уже пройденную - значит у тебя цикл.
Обойти граф из пары десятков элементов ничего не стоит практически.
>>744673
Плюсы:
- При изменении класса, все "объекты" под ним не меняются;
- Чуть-чуть быстрее доступ (при редком дёргании методов);
- Как бы можно делать "приватные поля".
Минусы:
- На каждый объект оверхед не только в виде таблички с данными, но и функциями, которые надо сгенерировать, поддерживать а потом выкинуть со смертью объекта;
- При пакетной обработке кучи идентичных объектов не включается JIT, скорость исполнения падает в тысячи раз (касается только PC и android);
- Невозможность организовать нормальных изменяемых общих полей всех объектов;
- Лишняя визуальная вложенность кода.
Чем плох __index? Ты его не понимаешь? Чем плохи либы-генераторы классов?
Плюсы:
- При изменении класса, все "объекты" под ним не меняются;
- Чуть-чуть быстрее доступ (при редком дёргании методов);
- Как бы можно делать "приватные поля".
Минусы:
- На каждый объект оверхед не только в виде таблички с данными, но и функциями, которые надо сгенерировать, поддерживать а потом выкинуть со смертью объекта;
- При пакетной обработке кучи идентичных объектов не включается JIT, скорость исполнения падает в тысячи раз (касается только PC и android);
- Невозможность организовать нормальных изменяемых общих полей всех объектов;
- Лишняя визуальная вложенность кода.
Чем плох __index? Ты его не понимаешь? Чем плохи либы-генераторы классов?
13 Кб, 658x414>>745385
Удваиваю этого >>745392.
Запоминаешь положение генераторов сигнала (какие-нибудь условные кнопки-рычаги), это твои начальные точки графов. Поиском в ширину проходишь по всем затронутым элементам, переключая их состояние в зависимости от сигналов, запоминая уже пройденные вершины как защита от циклов.
У элементов с несколькими входами, желательно обновлять их состояние за тик в зависимости от количества входов, максимум столько раз, сколько у них входов.
Да, в том же миникруфте не просто так сделана система перегорания элементов при слишком активном переключении.
Удваиваю этого >>745392.
Запоминаешь положение генераторов сигнала (какие-нибудь условные кнопки-рычаги), это твои начальные точки графов. Поиском в ширину проходишь по всем затронутым элементам, переключая их состояние в зависимости от сигналов, запоминая уже пройденные вершины как защита от циклов.
У элементов с несколькими входами, желательно обновлять их состояние за тик в зависимости от количества входов, максимум столько раз, сколько у них входов.
Да, в том же миникруфте не просто так сделана система перегорания элементов при слишком активном переключении.
Объясните, что за хуйня. В какой-то момент генерировал мир, процесс потреблял 400MB памяти, после этого все данные были записаны на диск из процесса все переменные были выкинуты, ради эксперимента запущен сборщик мусора в принудительном порядке. Итог сборщик мусора lua говорит, что потребляется около десяти мегабайт памяти (вообще там пустое окно, в которое выводиться статистика о памяти), а вот ОС говорит, что процесс LOVE всё ещё использует ~400MB памяти.
Кто из них пиздит? Или lua не освобождает фактически, освобождённую память?
Кто из них пиздит? Или lua не освобождает фактически, освобождённую память?
>>747946
Хуй знает, может у тебя какие-то еще текстурки куда-то были загружены, может файл какой-то был открыт, может ты си код вызывал и там что-нибудь не очистил. Луа наверное только свое считает, переменные, таблицы, функции и все такое.
Хуй знает, может у тебя какие-то еще текстурки куда-то были загружены, может файл какой-то был открыт, может ты си код вызывал и там что-нибудь не очистил. Луа наверное только свое считает, переменные, таблицы, функции и все такое.
>>747946
Как именно она тебе это говорит? Может, это не реально используемая память, а просто зарезервированная под процесс? Я тоже со своими программами (на паскале) подобное наблюдаю: сначала раздуваются, а потом плюс-минус сохраняют состояние, лишь со временем медленно теряя объём (но сборщик мусора в паскале срабатывает мгновенно, дело не в нём, а в ОС).
Если любишь экспериментировать, попробуй создать и запустить отдельную программу, которая займёт собой максимум оперативной памяти. Только файл подкачки отключи. В какой-то момент винда начнёт сжимать в памяти всё что только можно сжать, и закрывать все лишние процессы, включая даже explorer.exe (рабочий стол может исчезнуть, просто открой explorer из командной строки). Вот в такой ситуации, по идее, у твоей игры должны отобрать все резервные ресурсы. Если игра "сжалась" в памяти - то всё в порядке. Если так и осталось висеть 400 МБ ни за что - то у тебя явно какая-то утечка.
Также попробуй повторно создать всё то, что у тебя заняло 400 МБ. Если утечки нет, то будет плюс-минус столько же, если утечка - будет около 800 МБ.
Если всё-таки утечка, нужно смотреть где выделяется память в куче (любые динамические структуры данных) и каждый раз принудительно её освобождать. Нельзя просто "выкинуть переменные", нужно сказать ОС, что тебе эта область памяти больше не нужна. Сборщик мусора должен делать это сам, но кто его знает как он устроен.
>ОС говорит, что процесс 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 вообще пустая.
Я даже уже не знаю куда смотреть теперь.
После долгого разбора выяснилось, что память выделяется (вот эти 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
ОС может выделять память в зависимости от скорости её потребления. Например, ты разом запросил пол гига - и она выделяет лишний гиг, потому что ты сразу схомячил здоровый кусок. Или ты запрашиваешь те же пол гига маленькими кусочками растянуто, тогда лишний гиг не будет выделяться, или выделится но сильно меньше.
Мой персональный совет: не еби себе мозги всей этой чушью. Пока память не начала бесконтрольно расти не высвобождаясь - тебе похер на всё что там происходит. ОС тебя переиграет и уничтожит все попытки заткнуть фонтан выделяемой памяти, пока она есть, и это нормально и даже хорошо: память должна использоваться. Освобождать незанятое начнёт только когда памяти начнёт не хватать.
ОС может выделять память в зависимости от скорости её потребления. Например, ты разом запросил пол гига - и она выделяет лишний гиг, потому что ты сразу схомячил здоровый кусок. Или ты запрашиваешь те же пол гига маленькими кусочками растянуто, тогда лишний гиг не будет выделяться, или выделится но сильно меньше.
Мой персональный совет: не еби себе мозги всей этой чушью. Пока память не начала бесконтрольно расти не высвобождаясь - тебе похер на всё что там происходит. ОС тебя переиграет и уничтожит все попытки заткнуть фонтан выделяемой памяти, пока она есть, и это нормально и даже хорошо: память должна использоваться. Освобождать незанятое начнёт только когда памяти начнёт не хватать.
с трудом нашел тред, добрый день анон, кто-то ещё использует его или я один такой? был бы рад с кем-нибудь скооперироваться, для взаимопомощи.
>>794884
Использует, лавка норм. Взаимопомощь проще получить в соцсетях/телеге.
Использует, лавка норм. Взаимопомощь проще получить в соцсетях/телеге.
Бумп.
Лованы, как успехи?
Скоро уже скоро запилю свой ААА прожект на базе этого.
Основная цель - ондроед, там где луаджит нормально не пашет в лове.
Я буду успешен!
Лованы, как успехи?
Скоро уже скоро запилю свой ААА прожект на базе этого.
Основная цель - ондроед, там где луаджит нормально не пашет в лове.
Я буду успешен!
Ну охуеть, вчера только нашел сайт по love2d с последней активностью в 2016 году, теперь еще и это. Такими темпами может и могилу разраба вчерашней давности откопаю где-нибудь.
>>884896
А в чем сейчас профит использовать движки на скритпоязыках типа love2d или pygame, когда есть javascript? Работает в вебе, везде поддерживается, быстрый (среди скриптовых), оптимизированный.
А в чем сейчас профит использовать движки на скритпоязыках типа love2d или pygame, когда есть javascript? Работает в вебе, везде поддерживается, быстрый (среди скриптовых), оптимизированный.
>>884890
у тебя видимо айсикью однозначное и ты не смог найти разницу в закрепленных темах и новых?
у тебя видимо айсикью однозначное и ты не смог найти разницу в закрепленных темах и новых?
>>884919
а шо, хтмл5 ужо смогло не тормозить и не грузить гпу на 100% на сценках уровня первой кваки?
а шо, хтмл5 ужо смогло не тормозить и не грузить гпу на 100% на сценках уровня первой кваки?
>>885675
А че с того что он не новый? Я лишь отметил что в последнее время часто встречаю источники по этой теме с угасшей активностью. Иди умойся, "айсикью"шный.
А че с того что он не новый? Я лишь отметил что в последнее время часто встречаю источники по этой теме с угасшей активностью. Иди умойся, "айсикью"шный.
слушайте подскажите есть какая-то разница? между:
local M = {}
function M:foo(bar)
self.bar = bar
end
и
function M.foo(bar)
M.bar = bar
end
И насколько вообще второй вариант корректен? Просто разницы в рабоет не обнаружил, но для чего тогда городят эти ":" или передачу self первым аргументом?
local M = {}
function M:foo(bar)
self.bar = bar
end
и
function M.foo(bar)
M.bar = bar
end
И насколько вообще второй вариант корректен? Просто разницы в рабоет не обнаружил, но для чего тогда городят эти ":" или передачу self первым аргументом?
>>917747
Как написано выше, чтобы эмулировать методы. Отличия методов от просто функций в том, что они зачастую работают с объектом, которому принадлежат.
Пример из 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
> 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
>>917765
Ты мне ответил про разницу M.foo(self) и M:foo().
А я спрашивал про использование M вместо self. Тоесть обращение к самой переменной внутри ее "метода"
Ты мне ответил про разницу M.foo(self) и M:foo().
А я спрашивал про использование M вместо self. Тоесть обращение к самой переменной внутри ее "метода"
>>917769
Через точку получается статик метод, обращение к M - обращение к классу, обращение к self - обращение к экземпляру класса, всё как в обычных языках.
Через точку получается статик метод, обращение к M - обращение к классу, обращение к self - обращение к экземпляру класса, всё как в обычных языках.
>>917769
```
local M = {}
function M:good_foo(value) self.good_inner = value end
function M.bad_foo(value) M.bad_inner = value end
local N ={}
N.good_foo = M.good_foo
N.bad_foo = M.bad_foo
N:good_foo(10)
N.bad_foo(10)
print(N.good_inner, N.bad_inner)
```
```
local M = {}
function M:good_foo(value) self.good_inner = value end
function M.bad_foo(value) M.bad_inner = value end
local N ={}
N.good_foo = M.good_foo
N.bad_foo = M.bad_foo
N:good_foo(10)
N.bad_foo(10)
print(N.good_inner, N.bad_inner)
```
>>917777
Спасибо, теперь понятно.
Спасибо, теперь понятно.
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 11 сентября в 14:25.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 11 сентября в 14:25.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.