Собственно, чем я уже с 2019 года и пользуюсь. А уж стекла от подглядывания на смартфоны видел еще ой с каких бородатых времен... В общем, новизна идеи вызывает сомнения)).
Тут понимаете, какое дело, если бы выкинуть из всей этой схемы Битрикс - тогда тонкие оптимизации имели бы смысл. Но даже если просто подключить самые минимальные битриксовые "заголовки" к простейшему php-скрипту, то потребление памяти подскакивало с нескольких мегабайт сразу на тридцатку, а если уж начать использовать эти битриксовые API, то вообще пиши-пропало. Уверен, с 2013 года, когда я последний раз с этим возился, Битрикс в этом вопросе продвинулся вперед и теперь потребляет памяти ещё больше, чем ранее ? Так что если уж вы правда озабочены вопросом памяти, и ваш сервер правда может упасть от растраты пары сотен лишних мегабайт - ну тогда ваши скрипты должны писаться на базе фреймворка, который об этом будет заботиться.
Хммм, ну я вот толком пользуюсь, у меня с 2012 года и по сей день там куча всего. Сравнение с блокнотом совсем не понял, чувство блокнота у меня, скорее, вызывают современные модные «заметкашные» программы...
Да постоянно надо следить, что используешь по делу, а что нет... Я как-то видел код, где разработчик вдохновился и напихал везде генераторов типа экономить память, а мог бы не экономить, собрать данные в один запрос, распихать индексы в бд и, в общем, быстрее производить вычисления))) Не модно, не молодёжно, без всяких новых фич языка, зато быстрее...Но мы зачем-то экономим память, которой у сервера и так дохрена.
В мире битрикса типичная ситуация - набить большой и жирный массив, а потом пустить его гулять по компоненту до самого шаблона, пока он не набъёт его нужными данными. Итого, если говорить о памяти, то у нас она занята дважды: данными, занесенными в шаблон, и теми же данными в мега-массиве.
В этом плане инкрементарное внесение данных "в шаблон" решит проблему забития памяти в том плане, что она не будет израсходована дважды на одни и те же данные. Думаю, автору показывать это в рамках данного бенчмарка было бы уже бессмысленно.
Вот другой вопрос, как этот подход натягивать на реалии фреймворка, который многими своими частями до сих пор работает по такой логике, будто у нас на дворе php 5.3, если даже не старше....
В коде нету преобразования байтов обратно в модели, а используются геттеры - это добавляет некоторый оверхед на постоянную десериализацию + компилятор не может знать, что геттеры всегда возвращают одни и те же значения
Спасибо, ценное замечание, вернусь к этому, как устраню более серьёзные и насущные проблемы.
Ну это всё истории о том, как поработать с байтами, да ещё и только в read-only режиме. Нам привязывают руки к ногам и заявляют, что тем самым обезопасили от возможных негативных последствий, если бы мы могли двигать руками свободно =) Конечно, можно и так что-то придумать, но простого масштабирования тут не сделать, если заранее архитектуру не продумал со знанием всех возможных проблем.
Хотя в SharedArrayBuffer уже можно писать, да. Ещё бы это не только лишь в веб принесли...
но случайное заполнение тестовых данных не делает тест объективным
Ну тут уже у кого какая степень желания заморочиться. Я тест-то прогнал всего на одной машине, всего 15 раз, а в фоне ещё и работать могло что-то... в общем, никогда его нельзя будет считать объективным.
Когда HR укусил копирайтера, родилась эта статья)))
Я что-то совсем не верю в эти корпоративные танцы. Каждый ойчар, который ко мне в компанию приходил, начинал с этой своей любимой игрушки, видимо где-то в ойчарской методичке это прописано, вот их и несёт по скрипту...
Мы занимаемся аутсорс-разработкой. На текущий момент все эти потуги про миссии и цели редуцированы до простой и близкой каждому вменяемому профессионалу формулировки: мы команда профессионалов, мы все хотим нормально заработать и сделать это приятным для себя и достойным способом.
Всё. Никаких завываний о высоком и непонятном, без претензий на мировое господство и т.п.
Ну тут автор явно работает на генерацию статей для продвижения, а не для шэринга полезного опыта ;-) впереди ещё целая серия, не реже одной штуки в месяц, уверен в этом.
фильтр ответил "нет", но на самом деле элемент добавлялся. И такого быть не может, так как BloomFilter никогда не сбрасывает битики, а только выставляет.
Супер, мне этого достаточно)
На этапе "прогрева" я пробегаюсь по всем игровым типам объектов и вычисляю, может ли комбинация объектов типа А и Б вызвать коллизию. Если да, то добавляю хэш этой комбинации в фильтр.
Потом, уже во время игры, я только выполняю проверку, если хэша от пары типов в фильтре нет - значит и на столкновения проверять дальше не стоит.
Вроде бы всё вписывается в логику, да и в демке работает ??♂️
Я, простите, запутался: как подружить утверждение, что фильтр гарантирует отсутствие ложноотрицательных срабатываний и то, что он гарантирует точность только для добавленных в него элементов?..
Ну да, взять подходящий инструмент для решения задачи - это не наш метод, возьмём неподходящий и будем превозмогать)
В реальной жизни превозмогать приходится довольно часто, поэтому чем знать 30 разных языков под каждую узкую задачу, которую он идеально решает - лучше всё же хорошо знать свой основной, чтобы относительно быстро справиться с какими-то редкими особыми случаями.
Ну а если глобально, что у меня тут игровой движок на хрен пойми чём - ну таки да, я и не скрывал в прошлых своих статьях, что т.к. это хобби, где я и хотел заморочиться с чем-то странным чисто во имя искусства ?
В моём случае он вроде бы подходит. Задача - закешировать результат вычисления на наличие возможности коллизии между двумя типами объектов. В принципе мне даже гарантия того, что отрицательный ответ дадут безошибочно - подходит, т.к. если объекта гарантированно нет в списке доступных к столкновению пар - всё, прерываем вычисления, едем дальше. А в этом, собственно, и состоит цель "широкой фазы" определения столкновений.
Угу, вот это то, с чего меня больше всего бомбит, когда начинаешь проект на стеке, который тебе разрекламировали как "может всё", а потом узнаешь правду и у тебя все планы и дедлайны слетели, перед заказчиком хз как оправдываться и т.п....
Добавлю про Flame свои три копейки, т.к. в эту тему уже года полтора погружен.
Там сейчас всё нормально запускается, в плане примеров, и все они работают в браузере, там же можно потыкать, ничего не скачивая.
Сам движок довольно ограниченный, во-первых тем, что под копотом skia, которая особо не даёт как-то "на микроуровне" рулить GPU, во-вторых намерениями разработчиков, которые в целом не принимают во внимание случаи, когда в игре будет больше пару сотен компонентов, ну а в третьих самим контингентом пользователей. Не все, конечно, дубы, но от некоторых такое чувство, что вчера они собирали игру в Game Maker а сегодня написали свой Hello World на дарте и теперь преисполнились...
Для иллюстрации: вот сделали для Flame движок для быстрого делания RPG игр, и вроде на нем легко собрать то, что нужно, но даже просто карту он будет рендерить на 15-30 FPS на средненьком телефоне, потому что автор просто даже близко не думал о том, скольок ресурсов жрут его архитектурные решения.
Или вот совсем недавно в самомом Flame даже сейчас можно посадить FPS, просто добавим несколько тысяч пустых компонентов. которые даже рендериться не будут. А до недавнего времени простое касание экрана приводило к перебору всего дерева компонентов, что, конечно, подвешивало игру.
Узкое место архитектуры движка - это дерево компонентов, модификация которого выходит довольно дорого, а масла в огонь подливает "архитектурная политика" разработчиков, которые считают, что любые объекты нужно запихивать в это дерево. Что плохо сказывается на производительности, но об этом они будут думать только когда начнут разрабатывать версию движка 2.0, то есть где-то в необозримом будущем.
Если резюмировать, то движок без допилов можно использовать только для игр, которые более-менее помещаются в ваш один экран. Все вот эти идлеры, инфинити раннеры, вот это вот всё... Остальное он при текущей архитектуре просто не потянет.
А ещё есть проблемы со звуком (задержки воспроизведения в зависимости от платформы, крэши, влияние на производительность всей остальной игры) , с методами ввода (для мыши не распознаётся кнопка, которой был произведён клик, для геймпадов библиотека заброшена и вообще несовместима ни с современным Dart ни с Flame)....
В общем, к этому движку надо подходить крайне осторожно, особенно когда из каждого утюга тебе кричат, что Flutter крутой и сейчас захватит мир, вот мы вам сюда пиксельные шейдеры даже завезли, вот вам новый графический движок Impeller, который магически будет рендерить лучше (фигня, типичная рекомендация для Flame - выключите его, и все баги пройдут).... а то часто у людей любовь к конкретному инструменту перевешивает здравый смысл и критическое мышление, увы.
Я такой злой, не потому что у меня с Flame ничего не получилось, наоборот - запилил на нем прототип игры, преодолел бОльшую часть проблем, которые шли вместо с Flame в коробке, пилю свою либу для более сложных и масштабных игр... вот весь этот долгий пройденный путь и позволяет мне ругаться на движок не просто со злости. а со знанием дела xD
Что за жесть, господи, кирпич весом почти в 2 кило попадает в категорию "самых лёгких"... По мне так вообще всё, что по весу >= 1.2 кило, не заслуживает упоминания в подобных номинациях. Ну и "тонким лёгким ультрабуком" тоже называться не имеет права. Но нам все-таки пытаются продать под этим видом полуторакилограммовые железки....
Это звучит настолько искусственно, сухо и казённо, такое чувство, что новость про какой-то полузакрытый проект от Минобороны, а не об игровом движке, ещё и с открытым кодом... который нам не покажут или покажут после отправки письменного заявления, победы в тендере и т.п......
...я один бегло прочитал "в виде робокишок"?...
Собственно, чем я уже с 2019 года и пользуюсь. А уж стекла от подглядывания на смартфоны видел еще ой с каких бородатых времен... В общем, новизна идеи вызывает сомнения)).
Тут понимаете, какое дело, если бы выкинуть из всей этой схемы Битрикс - тогда тонкие оптимизации имели бы смысл. Но даже если просто подключить самые минимальные битриксовые "заголовки" к простейшему php-скрипту, то потребление памяти подскакивало с нескольких мегабайт сразу на тридцатку, а если уж начать использовать эти битриксовые API, то вообще пиши-пропало. Уверен, с 2013 года, когда я последний раз с этим возился, Битрикс в этом вопросе продвинулся вперед и теперь потребляет памяти ещё больше, чем ранее ? Так что если уж вы правда озабочены вопросом памяти, и ваш сервер правда может упасть от растраты пары сотен лишних мегабайт - ну тогда ваши скрипты должны писаться на базе фреймворка, который об этом будет заботиться.
А, ну да. Согласен ?
Хммм, ну я вот толком пользуюсь, у меня с 2012 года и по сей день там куча всего. Сравнение с блокнотом совсем не понял, чувство блокнота у меня, скорее, вызывают современные модные «заметкашные» программы...
Да постоянно надо следить, что используешь по делу, а что нет... Я как-то видел код, где разработчик вдохновился и напихал везде генераторов типа экономить память, а мог бы не экономить, собрать данные в один запрос, распихать индексы в бд и, в общем, быстрее производить вычисления))) Не модно, не молодёжно, без всяких новых фич языка, зато быстрее...Но мы зачем-то экономим память, которой у сервера и так дохрена.
В мире битрикса типичная ситуация - набить большой и жирный массив, а потом пустить его гулять по компоненту до самого шаблона, пока он не набъёт его нужными данными. Итого, если говорить о памяти, то у нас она занята дважды: данными, занесенными в шаблон, и теми же данными в мега-массиве.
В этом плане инкрементарное внесение данных "в шаблон" решит проблему забития памяти в том плане, что она не будет израсходована дважды на одни и те же данные. Думаю, автору показывать это в рамках данного бенчмарка было бы уже бессмысленно.
Вот другой вопрос, как этот подход натягивать на реалии фреймворка, который многими своими частями до сих пор работает по такой логике, будто у нас на дворе php 5.3, если даже не старше....
Спасибо, ценное замечание, вернусь к этому, как устраню более серьёзные и насущные проблемы.
Ну это всё истории о том, как поработать с байтами, да ещё и только в read-only режиме. Нам привязывают руки к ногам и заявляют, что тем самым обезопасили от возможных негативных последствий, если бы мы могли двигать руками свободно =) Конечно, можно и так что-то придумать, но простого масштабирования тут не сделать, если заранее архитектуру не продумал со знанием всех возможных проблем.
Хотя в SharedArrayBuffer уже можно писать, да. Ещё бы это не только лишь в веб принесли...
Ну тут уже у кого какая степень желания заморочиться. Я тест-то прогнал всего на одной машине, всего 15 раз, а в фоне ещё и работать могло что-то... в общем, никогда его нельзя будет считать объективным.
Когда HR укусил копирайтера, родилась эта статья)))
Я что-то совсем не верю в эти корпоративные танцы. Каждый ойчар, который ко мне в компанию приходил, начинал с этой своей любимой игрушки, видимо где-то в ойчарской методичке это прописано, вот их и несёт по скрипту...
Мы занимаемся аутсорс-разработкой. На текущий момент все эти потуги про миссии и цели редуцированы до простой и близкой каждому вменяемому профессионалу формулировки: мы команда профессионалов, мы все хотим нормально заработать и сделать это приятным для себя и достойным способом.
Всё. Никаких завываний о высоком и непонятном, без претензий на мировое господство и т.п.
А ведь когда-то эти 60к были неплохой такой ЗП для и мидла :-/
Ну тут автор явно работает на генерацию статей для продвижения, а не для шэринга полезного опыта ;-) впереди ещё целая серия, не реже одной штуки в месяц, уверен в этом.
Супер, мне этого достаточно)
На этапе "прогрева" я пробегаюсь по всем игровым типам объектов и вычисляю, может ли комбинация объектов типа А и Б вызвать коллизию. Если да, то добавляю хэш этой комбинации в фильтр.
Потом, уже во время игры, я только выполняю проверку, если хэша от пары типов в фильтре нет - значит и на столкновения проверять дальше не стоит.
Вроде бы всё вписывается в логику, да и в демке работает ??♂️
Я, простите, запутался: как подружить утверждение, что фильтр гарантирует отсутствие ложноотрицательных срабатываний и то, что он гарантирует точность только для добавленных в него элементов?..
В реальной жизни превозмогать приходится довольно часто, поэтому чем знать 30 разных языков под каждую узкую задачу, которую он идеально решает - лучше всё же хорошо знать свой основной, чтобы относительно быстро справиться с какими-то редкими особыми случаями.
Ну а если глобально, что у меня тут игровой движок на хрен пойми чём - ну таки да, я и не скрывал в прошлых своих статьях, что т.к. это хобби, где я и хотел заморочиться с чем-то странным чисто во имя искусства ?
А за +1 структуру данных - спасибище! ?
В моём случае он вроде бы подходит. Задача - закешировать результат вычисления на наличие возможности коллизии между двумя типами объектов. В принципе мне даже гарантия того, что отрицательный ответ дадут безошибочно - подходит, т.к. если объекта гарантированно нет в списке доступных к столкновению пар - всё, прерываем вычисления, едем дальше. А в этом, собственно, и состоит цель "широкой фазы" определения столкновений.
Да, конечно, буду только рад ?
Угу, вот это то, с чего меня больше всего бомбит, когда начинаешь проект на стеке, который тебе разрекламировали как "может всё", а потом узнаешь правду и у тебя все планы и дедлайны слетели, перед заказчиком хз как оправдываться и т.п....
Добавлю про Flame свои три копейки, т.к. в эту тему уже года полтора погружен.
Там сейчас всё нормально запускается, в плане примеров, и все они работают в браузере, там же можно потыкать, ничего не скачивая.
Сам движок довольно ограниченный, во-первых тем, что под копотом skia, которая особо не даёт как-то "на микроуровне" рулить GPU, во-вторых намерениями разработчиков, которые в целом не принимают во внимание случаи, когда в игре будет больше пару сотен компонентов, ну а в третьих самим контингентом пользователей. Не все, конечно, дубы, но от некоторых такое чувство, что вчера они собирали игру в Game Maker а сегодня написали свой Hello World на дарте и теперь преисполнились...
Для иллюстрации: вот сделали для Flame движок для быстрого делания RPG игр, и вроде на нем легко собрать то, что нужно, но даже просто карту он будет рендерить на 15-30 FPS на средненьком телефоне, потому что автор просто даже близко не думал о том, скольок ресурсов жрут его архитектурные решения.
Или вот совсем недавно в самомом Flame даже сейчас можно посадить FPS, просто добавим несколько тысяч пустых компонентов. которые даже рендериться не будут. А до недавнего времени простое касание экрана приводило к перебору всего дерева компонентов, что, конечно, подвешивало игру.
Узкое место архитектуры движка - это дерево компонентов, модификация которого выходит довольно дорого, а масла в огонь подливает "архитектурная политика" разработчиков, которые считают, что любые объекты нужно запихивать в это дерево. Что плохо сказывается на производительности, но об этом они будут думать только когда начнут разрабатывать версию движка 2.0, то есть где-то в необозримом будущем.
Если резюмировать, то движок без допилов можно использовать только для игр, которые более-менее помещаются в ваш один экран. Все вот эти идлеры, инфинити раннеры, вот это вот всё... Остальное он при текущей архитектуре просто не потянет.
А ещё есть проблемы со звуком (задержки воспроизведения в зависимости от платформы, крэши, влияние на производительность всей остальной игры) , с методами ввода (для мыши не распознаётся кнопка, которой был произведён клик, для геймпадов библиотека заброшена и вообще несовместима ни с современным Dart ни с Flame)....
В общем, к этому движку надо подходить крайне осторожно, особенно когда из каждого утюга тебе кричат, что Flutter крутой и сейчас захватит мир, вот мы вам сюда пиксельные шейдеры даже завезли, вот вам новый графический движок Impeller, который магически будет рендерить лучше (фигня, типичная рекомендация для Flame - выключите его, и все баги пройдут).... а то часто у людей любовь к конкретному инструменту перевешивает здравый смысл и критическое мышление, увы.
Я такой злой, не потому что у меня с Flame ничего не получилось, наоборот - запилил на нем прототип игры, преодолел бОльшую часть проблем, которые шли вместо с Flame в коробке, пилю свою либу для более сложных и масштабных игр... вот весь этот долгий пройденный путь и позволяет мне ругаться на движок не просто со злости. а со знанием дела xD
Что за жесть, господи, кирпич весом почти в 2 кило попадает в категорию "самых лёгких"... По мне так вообще всё, что по весу >= 1.2 кило, не заслуживает упоминания в подобных номинациях. Ну и "тонким лёгким ультрабуком" тоже называться не имеет права. Но нам все-таки пытаются продать под этим видом полуторакилограммовые железки....
Это звучит настолько искусственно, сухо и казённо, такое чувство, что новость про какой-то полузакрытый проект от Минобороны, а не об игровом движке, ещё и с открытым кодом... который нам не покажут или покажут после отправки письменного заявления, победы в тендере и т.п......
А, блин, маленькая ссылка на Fdroid, спасибо ?
Читал наискосок, ибо зачем мне детальный разбор приложения, с которым много лет как знаком. Наискосок этой ремарки не видно.