Добавлен , опубликован
Небольшая наработка, реализующая достаточно высокоэффективную одновременную обработку множества снарядов, движущихся с соблюдением основных законов кинематики. В карте присутствует сама система и техдемо к ней, а также краткое описание. Для работы требуются установленные парсеры vJass и cJass.
Особенности:
  • Одновременная обработка до 400 активных снарядов без падения производительности
  • Возможность "на ходу" изменять частоту обработки снарядов и основные константы
  • Максимальная отвязанность системы от внутриигровых контроллеров движения
  • Хорошо написанный самодокументирующийся код с прозрачной архитектурой
Кроме того, в карте можно найти полную эмулированую библиотеку "math.h" из набора стандартных библиотек Си (в системе практически не используется, делал когда-то ради собственного удовольствия), полновесный набор функций для работы с векторами и классную модельку дамми-юнита со множеством анимаций разных углов наклона (к сожалению, автор модели мне неизвестен).
С радостью приму любой фидбек относительно системы, а также предложения по улучшению реализованного в ней функционала.
P.S.: версия системы указана как "0.9", однако при отсутствии каких-либо существенных замечаний по поводу её реализации она же будет являться финальной ("1.0").
P.P.S.: возможно, на днях запилю пару небольших статеек с более-менее подробным разбором системы и/или векторного подхода к движению (старая, кмк, не слишком информативна), о потребности пишите в комменты.
P.P.P.S.: если что, я не программист и никогда себя им не считал / не называл, так что в случае нахождения каких-нибудь заметных косяков прошу не пылать экспрессией на весь сайт. // Toadcop, привет маме! Мне понятны твои мотивы, но фильтры на базарах таки иногда надо включать.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
30
7 лет назад
Отредактирован Clamp
0
Да, и еще: 9,8 - это для метров. В варике 1 единица расстояния это вовсе не метр, а гораздо меньшая величина.
Это вполне очевидно. Выставил 9.8, визуально результат меня устроил, с чего бы менять?

В бонусе - тебе не придется перерасчитывать величину gravity каждый раз, когда ты меняешь tickrate.
Такой себе по ценности, одно дополнительное деление и одно дополнительное умножение раз в практически никогда процессор сможет выдержать.
обязательно должен везде делится на tickrate
Точно! Каждое деление вектора на число - это три операции деления, каждый объект описывается двумя векторами, то есть всего шесть операций деления. Достаточно согласиться с твоим предложением, и их количество вырастает до девяти, что не то, чтобы критично, но в 1.5 раза тяжелее без каких-либо профитов вообще.
Кроме того, в самом коде физического компонента объекта логика описывается пусть с уже обмусоленной ошибкой, но всё-таки универсально: при обновлении объекта он смещается в направлении суммирующей на её величину, а скейлинг этой величины под тикрейт - работа контроллера, который обрабатывает этот объект и устанавливает сам тикрейт.
0
12
7 лет назад
0
Clamp:
без каких-либо профитов вообще.
Смысловое понимание кода увеличивается в разы. Что напрямую сказывается на времени его написания и отладки, из-за отсутствия/наличия дурацких ошибок, как с этим impulse и умножением на массу. Оптимизация это вообще дело последнее, которое выполняется уже после реализации всего, что хотели реализовать, поскольку добавлять что-нибудь еще к оптимизированному коду - это чистое мучение.
Clamp:
Кроме того, в самом коде физического компонента объекта логика описывается пусть с уже обмусоленной ошибкой, но всё-таки универсально: при обновлении объекта он смещается в направлении суммирующей на её величину, а скейлинг этой величины под тикрейт - работа контроллера, который обрабатывает этот объект и устанавливает сам тикрейт.
Вот эту часть текста я не очень понял. Tickrate устанавливается в GameField, а обработка объектов идет в PhysObj. Чья же тогда это работа?
0
30
7 лет назад
Отредактирован Clamp
0
обработка объектов идет в PhysObj
В нём писывается логика движения, однако свой .update() он самостоятельно никаким образом не вызывает.

Кстати, технически вектор "impulse" выражает m*v, поскольку в карте-примере из поста масса фактически не имеет значения (видимо, просто забыл удалить её из кода) и её хранение отдельным используемым скаляром приведёт только к увеличению числа рассчётов; при увеличении функционала, например, при добавлении взаимных столкновений, массу нужно будет вынести из вектора в отдельный скаляр, а вектор назвать "velocity". Показанная карта-пример, конечно, не лучшая из возможных, но, на мой взгляд, вполне адекватна (если оставить за скобками утверждение о полноценности модели в ней).

Попробую популярно пояснить лежащий в основе архитектуры подход.
Физический объект является описанием поведения игрового объекта (behavior; VisObj и DmgObj - тоже behavior по сути), он содержит в себе только те данные, которые касаются непосредственно связанного с физикой поведения игрового объекта (определение и движение объекта в пространстве), и никаких более. Этими данными являются: радиус-вектор, вектор импульса, радиус столкновений и логика движения. Последнюю в теории можно вынести из объекта, но тогда система несколько потеряет в модульности. Кроме того, хранить логику движения внутри метода полезно тем, что в случае её отсутствия/отключения у какого-либо объекта код движения даже читаться не будет.
Как абсолютно верно заметил Doc, результаты движения должны обрабатываться не в движимом теле или его компоненте, а в движущей системе, так как в результате перемещения игрового объекта он может вступить в те или иные взаимодействия с другими сущностями, обладающими физическим компонентом. Их сам по себе объект обработать не способен и не должен быть способен, он не "божественный".
Сам игровой объект - оболочка, через которую связаны все его компоненты. Система обработки ("стак" в GameField) обращается к нему с командой на апдейт, все взаимодействия между компонентами производятся в нём и нигде более.

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

Оптимизация это вообще дело последнее, которое выполняется уже после реализации всего, что хотели реализовать, поскольку добавлять что-нибудь еще к оптимизированному коду - это чистое мучение.
В карте-примере отсутствует преждевременная оптимизация. Ощущение её наличия могло возникнуть из-за того, что данные, которые никак не задействованы в логике примера, были удалены из неё целиком. Массу вот только пропустил.
Этот комментарий удален
0
30
4 года назад
Отредактирован Clamp
0
Если кому не влом, может проверить, запустится карта в рефордже или нет? Из меню, не из редактора (так как иначе оно попробует собрать cjass)

А то есть мнение, что все системы движения поломались в последних версиях
1
27
4 года назад
1
Clamp, Все работает

При чем напрямую из редактора
0
30
4 года назад
0
Феникс, спасибо
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.