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

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
30
7 лет назад
0
Если кому-нибудь зачем-нибудь понадобится, то по отдельной просьбе закину код системы в сам ресурс.
0
33
7 лет назад
0
«0x41726176» — чо это за абила?
0
30
7 лет назад
0
Кет, превращение друида-ворона
5
29
7 лет назад
Отредактирован Doc
5
Сори, но это пиздец говно. Я заревьювил все твои 500-600 строк кода и единственное, что в нем хорошего это стиль, код реально чистый.
Начнем по порядку.
    private void StackPop(int id) {
        stackCounter--;
        stack[id] = stack[stackCounter];
    }
Здесь у меня просто случилась аневризма. Стэк так не работает. При чем тут стек и зачем эта переменная названа стек - непонятно. Это random access list. В стеке нет доступа ни к чему, кроме хвоста.
        private PhysObj physic;
        private VisObj visual;
        private DmgObj damage;
Честно просто смешная попытка замутить нечто похожее на entity-component-system, ни о какой модульности речи тут не идет, с тем же успехом можно было слить все эти чайлд структуры в основную и ничего бы не изменилось. Оверинжиниринг без цели и бенефитсов.
Снаряды тупо всегда уничтожают себя при колижне с юнитами. Это та самая хваленая "матмодель"? Я не знаю смеяться или плакать. Это преимущество над движком тсх? Ты понимаешь вообще что там было основано на входе в ректангл только чтобы максимально перенести отсеивание колижнов в нативный код? Что наверняка в движке реализовано какое-нибудь quadtree которое нормально работает с большим количеством юнитов? Что есть у тебя? GroupEnumUnits? Я уже не говорю о том что поделие совершенно нерасширяемое, ты просто сам попробуй не трогая основной код реализовать пару спеллов. Тут даже такие банальности как то, что гравитация это скаляр, а не вектор. Зато зачем-то есть настраиваемый тикрейт и сила трения. Сила трения правда одна на всю карту, удобно.
Мега физика в "движке" это семплинг нормали граунда через GetTerrainZ? А, нет, вот, нашел:
this.impulse.z -= this.mass*gravity;
вот с этого просто в АХАХАХА, т.е. объект который весит меньше будет медленнее падать?
Какбы в итоге зашибись, учиться - учись. Но понты и умничанье в оффтопке лучше попридержать до момента пока не научишься. Тонна таких и намного лучше систем валяется на барахолке уже с десяток лет, без шуток. Код с семплингом нормали я видел в каждой из них, да и сам писал такой. Подобная система есть, например, у ханабиши.
0
21
7 лет назад
0
Doc, справедливости ради, объект, который весит больше, действительно в реальности быстрее падает из-за сопротивления воздуха. Да, переменную лучше назвать не mass, а как-нибудь наподобие resistance_factor, но фича с практической точки зрения полезная.
3
29
7 лет назад
Отредактирован Doc
3
То есть в этом случае чем больше сопротивление тем быстрее падает объект?)
Я бы ничего это не писал если бы не заявления в духе
[20:06:50] Clamp * Потому что всё от и до построено на матмодели, а не через костыли типа "юнит вошёл в область"
[20:06:16] Clamp * Доделал по инерции, смею утверждать, что у меня физика производительнее, чем в TcX
И прочий ненужный пафос.
0
30
7 лет назад
Отредактирован Clamp
0
ты просто сам попробуй не трогая основной код реализовать пару спеллов
Реализовал, потом мб залью мапу (если допилю).
Тут даже такие банальности как то, что гравитация это скаляр, а не вектор.
Исходно делал как раз через вектор, но не смог найти векторному выражению никаких применений, и перевёл в скаляр, хз.
Ты понимаешь вообще что там было основано на входе в ректангл только чтобы максимально перенести отсеивание колижнов в нативный код?
Тащемта, да, и это вроде где-то обсуждалось даже активно
зачем-то есть настраиваемый тикрейт
Глубоко в концепции это задумывалось как метод снизить нагрузку через снижение тикрейта при повышении количества объектов, но позже эмперически выяснил, что сам факт наличия такого числа юнитов оказывает на нагрузку несравнимо большее влияние, за сим оставил.

На самом деле, если бы не "ненужный пафос", то хрена-с-два я бы дождался здесь хоть какого-нибудь code review от практикующего специалиста, так что хз даже про его "нужность" или "ненужность". Хотя метод, конечно, не самый красивый, тут каюсь и приношу извинения.

При чем тут стек
Копипаста со статьи Скорпа, я знаю, что такое стак, но не увидел никакой проблемы в именовании, простите, если задел в нежных чувствах =)
с тем же успехом можно было слить все эти чайлд структуры в основную и ничего бы не изменилось.
стало бы нечитаемо, лол
На деле, это использую примерно так: есть набор пресозданых "визобжей" и дамагов, сам "физобж" варится по требованиям и на него вешаются копии нужных мне кусков конфигурации. Не помню, как это "правильно" называется, допустим, "factory" (надеюсь, не задел в нежных чувствах, если ошибся ;D)
Doc:
вот с этого просто в АХАХАХА
Ничего не могу сказать, действительно обосрался в полный рост \о/
Как-то получилось, что в игре выглядит нормально, "да и хер с ним, не буду трогать"
объект который весит меньше будет медленнее падать?
Там же проекция на ось z, то есть технически это ускорение падения, а не наоборот.
Снаряды тупо всегда уничтожают себя при колижне с юнитами.
А что им ещё делать, лол?

Если в сухом остатке, то действительно спасибо за то, что понатыкал в несколько куч, учту. Хотел бы попросить менее эмоционально и более предметно потыкать, по возможности, но само собой настаивать не могу.
0
29
7 лет назад
0
Фактически проблемы нет в наименовании никакой, работает - ок, но по факту если претендуешь на понятный код то естественно называть нужно своими именами.
Уничтожаться ниче офк не должно, какого фига физический объект должен за это отвечать? Но мое изначальное замечание было в сторону настраиваемости "движка".
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.