Но если у тебя известная структура данных, то напиши функцию

Там просто будет

Ладно

Я просто думал есть похожая шняга типо #массив

Напишешь и хоба нашел

#map*(#(map.submap))

👌спасибо

Если у тебя, конечно, карта прямоугольная

Манулы это хорошо

Жаль что приучить нельзя

Один манул

*агрессивно потряхивает зонтиком*

Лентач Во время "Марша пенсионеров" в Минске менты использовали против протестующих слезоточивый газ и светошумовые гранаты. В МВД это официально подтвердили, пишет "Интерфакс". Силовики утверждают, что участники "Марша" якобы сами виноваты — проявили агрессию. Ганс, мы что, злодеи?

Беларусь я бы для себя определенно рассматривал как один из вариантов релокации. Раньше как-то не думал на эту тему.

Такой вопрос. Сижу, ковыряю ассеты от Kenney. Папка под названием ParticlePack. Каждая картинка весом в несколько десятков килобайт и размером 512*512. Я может как-то не так себе это представляю, но не дохера ли для частиц? Что за частички такие бегемотские? Попробовал в animation set запихнуть, анимация не впечатлила. Что с этим делать? У автора информации по нолям. Это что-то самоочевидное и только самые пустые чайники не в курсе?

Партиклы бывают разными. Для своих условий ты типа пожмёшь.

Мол, лучше оно будет в более высоком разрешении чем в более низком, сжать объёмное возможно, а разжать пожатое — нет, фарш невозможно провернуть назад и так далее.

Хм... Ну, так-то да. И степень двойки опять же, кромсай на здоровье.

А во-вторых, вот это — тоже партиклы: https://www.artstation.com/artwork/GXKZN3 И тут крайне желательно их высокое разрешение, а то будет, блин, взрыв с торчащими пикселями ))

Мелочь частичную вижу, а основной взрыв вроде набор спрайтов, не?

Партиклы, партиклы

Причём взрыв полностью плоский, но повёрнут к камере.

Ткни пальцем, где почитать можно. Если есть источники...

Вернулся к 2д изометрии, прикрутил простенькое освещение.

Огонь факела спрайтовый + частицы?

угу

Да, тут тож

Вот этот огонёчек — чисто на партиклах с постобработкой: https://youtu.be/qWjlPVDxwPo

Этот на основе меша, но тоже с партиклами сверху https://youtu.be/I7TdqrB6N7w

Хм-2... А ведь в дефолде есть эффекты для партиклов, точно. Надо ковырять, короче, пробовать.

Хм-2... А ведь в дефолде есть эффекты для партиклов, точно. Надо ковырять, короче, пробовать.

Модификаторы, если точнее.

Сижу я на олимпиаде, пишу код на сишке, запускаю - провалы в памяти. Пытаюсь найти эту дыру, но дебагера на компе нет. Пишу код на петоне - все зашибись. Отправляю на проверку - все тесты пройдены. Вывод: я не умею работать с памятью (

Нормально ))

Думал на сишке будет быстрее, поэтому изначально его выбирал, а в итоге питон ни чуть не медленнее. Только памяти много жрёт

1. Смотря какая задача 2. Смотря какой интерпретатор питона 3. Смотря насколько активно используются сишные либы

Ееееее, появилось немного лишнего времени, покопался в сишном коде и написал интерфейс для взаимодействия между lua и java, теперь на андроиде все пути открыты, в общем то

Кек, ну как все, синхронные

А я запилил чисто-ffi-либу с векторами-матрицами-кватернионами, и щас буду дополнять функционалом для определённых штук.

так юнити победим!1

А ещё недоразобрался с чтением материалов, поэтому всё выглядит пластмассовым из-за shininess.

Кстати, всегда удивляло, что у love так слабо форсится это направление, есть один репозиторий, который на самом деле не то чтобы хорошо задокументирован, и то, что есть, позволяет просто работать самой love внутри контейнера, так скозатб

А я запилил чисто-ffi-либу с векторами-матрицами-кватернионами, и щас буду дополнять функционалом для определённых штук.

За счёт ffi.copy(dst, src, ffi.sizeof(src)), тут даже дофига быстрые операции с матрицами.

Блен, я вот только боюсь, что полноценный выход в тридэ неизбежно требует всякого обвеса, который в ту же юнити проект и превратит(

Вот ffi-шная ecs бы не помешала, а то обход иерархии приличного дерева объектов стоит дороже, чем их отрисовка в отдельных случаях

Мм? Зачем в ECS деревья?

Там же подсистемы — это прост списки объектов.

Ну, типа, персонаж состоит из их тушки, щита, меча, полоски HP и еще какой херни. Мы имеем объект персонажа, который на себе держит трансформ, скрипт для управления всем этим добром, и несколько трансформов-потомков, которые держат на себе компоненты-рендереры, и фиг знает что еще

Аа

Понятно, что деревом в любом случае лучше не злоупотреблять, но иерархическая сцена наиболее удобна

На самом деле я пока хз как такое организовать, но при реализации через ecs напрашивается саморендеринг: персонаж самостоятельно своим рендер-компонентом рисует на себе весь собственный обвес. Сама компонентная система работает как обработка списка, а конкретно у игрока ещё маленькое дерево со всякой фигнёй.

Ну, просто есть же еще понятие масштабируемости, такой подход позволяет с удобством и легкостью реализовать любые структуры: как персонажей, так и окошки, панельки, объекты окружения или еще какую хрень

Я прост не очень понимаю при чём тут именно ECS, я такое пилю на обычном ООП с объектами и списками их дочерних элементов.

Вроде, это и есть обычный ООП с объектами и списками их дочерних элементов, если я ничего не путаю

Вроде, это и есть обычный ООП с объектами и списками их дочерних элементов, если я ничего не путаю

Не, ECS это ты объявляешь кучу систем-синглтонов, типа "система рендеринга", "система обновления", "система повреждений" и так далее, а когда создаёшь объект — он цепляется ко всем этим системам и получает от них соответствующий компонент и методы.

https://habr.com/ru/post/343778/

И с одной стороны, ECS даёт некоторую гибкость и плоскость (как отсутствие вложенности), мы работаем с объектами чисто как с набором данных. А с другой — требует бешеного количества внешних обвязок в виде синглтонов, диспетчеризации событий, неизвестно как устроенных систем сообщений и так далее.

Как правило, в ECS уходят те, кто "разочаровался в ООП", т.е. не научился его готовить не доводя до патологий )))

Как правило, в ECS уходят те, кто "разочаровался в ООП", т.е. не научился его готовить не доводя до патологий )))

ecs не об этом

ecs это про перфоменс

паттерн был придуман, чтобы большой объём данных можно было крутить в кэше проца не тратя такты на чтение из памяти

причём тут ООП вообще?

Но используют его так как используют.

причём тут ООП вообще?

При том, что есть несколько групп людей, ярых фанатов DOD и ECS, которые поливают ООП какашками потому что "вот шо ты будешь делать, если у тебя дерево наследований разрослось до двадцати слоёв абстракций? А? ЧТО БУДЕШЬ ДЕЛАТЬ???7"

При том, что есть несколько групп людей, ярых фанатов DOD и ECS, которые поливают ООП какашками потому что "вот шо ты будешь делать, если у тебя дерево наследований разрослось до двадцати слоёв абстракций? А? ЧТО БУДЕШЬ ДЕЛАТЬ???7"

в c# такого нет

Есть.

такое есть в плюсах

в луа такого тоже нет

такое есть в плюсах

Это есть везде где есть ООП.

я не могу тебе ничего об этом сказать, это проблема проектирования, а не паттернов

Разумеется.

Но сваливается на ООП потому что "оно это позволяет" ))

Это есть везде где есть ООП.

это java

это java

С шарпом, плюсами и луями — та же история.

в c#, нет массового наследования, ты не путай классы и пакеты

А мы не про множественное наследование.

мы про безграмотность нынешних программистов, да.

Вообще, мы тут типа про слои абстракций: фреймворк на основе фреймворка на основе фреймворка.

И ООП это типа провоцирует, а ECS уничтожает серебряной пулей ))

ну на разных уровнях абстракции, разные решения, например движок-фреймворк, на плюсах, бизнес ты пишешь на # или луа и юзаешь разные приёмы, паттерны и всё это только о перфомансе, удобство только снится.