Мне тоже приходилось делать БПФ (на миллионе значений), и тоже играл в оптимизации, правда на x86. Что-то работало хорошо, что-то нет. Например, я пробовал вычисление синуса заменить на таблицу, причём максимально в лоб и пусть даже с погрешностями: массив из 91 значения, от нуля до 90 градусов, аргумент просто приводится к int отбасыванием дробной части. Так вот sin(float x) работал на 2-3% быстрее, чем arr[(int) float x]. У меня возникло подозрение, что вычисление синуса как-то хитро оптимизировано (набором инструкций SSE, например), что даже прямое обращение в массив не смогло выиграть. Эту тему я дальше копать не стал, она так и осталась для меня тайной. Может, какой-то флаг при компиляции был отключен (target был Release в Borland Developer Studio C++). Это было в 2010-м году на Intel Core 2 Duo. Если кто знает, в чём секрет, поделитесь =)
Я прошу вас, авторы. Всем уже и так ясно, что нужно соблюдать меры предосторожности. Не нужны больше устрашения. Хотите помочь — придумайте, как снизить психическое напряжение и пишите об этом.
Мне кажется, вы как-то поперёк прочитали статью. Она как раз не усташающая, а развенчивающая «страшилки», то есть обнадёживающая и успокаивающая.
Как минимум не элементарно.
На часах 0:30, мы говорим «половина первого (часа)». С начала суток прошло ноль часов и ещё половина часа. Чувствуете, в чём подвох? Прошло ноль часов, но говорим «половина первого часа».
Далее мы говорим, что живём в 2019-м году. В две тысячи девятнадцатом году. Сколько лет прошло с начала эры? По аналогии с часами нужно сказать, что две тысячи восемнадцать полных лет, и записывать их как 24.12.2018.
Сутки с нуля, исчисление лет с нуля…
Cогласно григорианскому календарю, нулевого года не существует [2 до н.э., 1 до н.э., 1 н.э.]. То есть ребёнку может быть ноль лет, а нашей эре сразу стал один год. ru.wikipedia.org/wiki/0_год
И товарища ikle сверху слили ни за что. Первое десятилетие — это годы 1,2...10. Начало второго десятилетия — это 11-й год. Также и 2021-й год будет началом нового десятилетия.
Финальным толчком для создания этого манифеста послужил недавный всплеск активности борцов (борчих?) за социальную справедливость, рассматриваемый в статье по первой ссылке (та, что с названием SJWJS).
Last night I posted about the term “domain driven design,” frequently abbreviated “DDD” - which is a common large bra measurement in the US, & often part of dirty movie titles.
I’ve deleted the thread. And replaced it with this one!
На случай, если твит будет выпилен, тут лежит скриншот
Краткая суть простыни: методология (и соотв. книга) Domain Driven Design сокращается как DDD. А если вы вдруг не знали, DDD — это особо крупный размер чашки бюстгалтера и популярный запрос на сайтах с видео определённой тематики. И автора задевает «исключающая» натура этого сокращения (в том смысле, что исключает дам с меньшим размером), а также намёк на грязные видео. И дама говорит, что не важно ваше намерение, а действие, которое производит само слово. Даже если вы не знали этого сокращения, кто-то может оскорбиться, и уже потому вы виноваты.
Дама занимает серьёзный пост в сообществе Ruby (могу ошибаться), судя по внешним признакам: «Software engineer, founder of @railsbridge, Director of Ruby Central, Architect at @salesforceux».
Современные небольшие движки хороши для прототипирования. Как было с Dustforce, к примеру. На GameMaker за пару месяцев набросали концепт, а потом пару лет сидели и кодили на C++, потому что игра по сути frame-perfect и не имеет права даже на микрофризы. Эти движки также хорошо могут справиться с простыми и нетребовательными играми (логические, квесты, метроидвании, простые платформеры).
В целом же современные движки — палка о двух концах.
С одной стороны это благо, потому что уменьшают порог вхождения в индустрию. С другой стороны, это бич, потому что меньшают порог вхождения в индустрию, снижают уровень компетентности и требований (засилие инди-хлама на Steam), используют неоптимальные языки и инструменты (фризы из-за GC, или например любая игра, даже пустой экран, на Godot содержит в себе 30Мб движок, который интерпретирует код, то есть виртуальная машина типа Java), либо вовсе являются монструозными комбайнами (типа Unity, Unreal Engine и CryEngine в гигабайты величиной).
Ну и да, приведите примеры AAA-проектов на этих движках? Кроме приснопамятного Star Citizen, разумеется, который никогда не выйдет. В том-то и дело, что такой движок используется либо небольшой студией, либо самой студией-автором движка. Большинство крупных и высокобюджетных тайтлов (Quake/Rage/DOOM 2016/Wolfenstein, Battlefield, Anthem, Dragon Age, GTA, Red Dead Redemption, Call of Duty, Witcher, Uncharted, новые Tomb Raider, Assassin's Creed, Horizon Zero Dawn, Diablo III, Starcraft 2, Overwatch и т.д.) работают на собственных разработках студий. Да, этим движкам дают названия, типа RedEngine, idTech, RAGE, Decima, Frostbite — но они не становятся достоянием общественности, а либо оседают в студии, либо лицензируются за большие деньги. Почему? Наверное, потому что отполированы и заточены под свой внутренний пайплайн. В отличие от конструкторов, которые должны угодить всем, но средненько.
Возвращаясь к Handmade Hero. Цель — не просто сделать игру. Цель — научиться делать качественную игру и понимать механизмы, которые лежат у движков под капотом (в определённых пределах).
Мне непонятен ваш мотив. Почему вы защищаете людей, которые плодят низкокачественные решения? Соседний пост Моё разочарование в софте за два дня собрал 340 плюсов и 900 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
Смысл каждого эпизода в том, что любое действие разжёвывается. Есть десятки эпизодов, где целый час идёт чисто рисование на доске (вот произведение матриц, например guide.handmadehero.org/code/day362/#354) Потому это и продолжается так долго. Если убрать объяснения (-50% времени), Q&A (-20% времени), на чистый кодинг останется 140 эпизодов средней длиной 1,5 часа (до 350-го эпизоды были короче), то есть 210 часов чистой работы, грубо говоря. Округлим до 240 часов. 240 часов это 3 месяца интенсивной работы. Это крайне мало для того результата, который есть на экране (с учётом разработки с нуля, 100% понимания и полной ответственности за каждую строчку кода, и соответствующей производительности). И не стоит забывать, что значительная часть кода будет использоваться повторно в последующих проектах (аппаратный уровень, алогритмы работы с векторами/матрицами/массивами, камера, управление, инструменты отладки, движок анимации и тд).
Видимо, Кейси на старости лет стал забываться. В подтверждение, кому интересно, есть наглядная иллюстрация компиляции карты из набора объёмных «кистей»-примитивов в первом Quake.
Причём в статье не говорится о Constructive Solid Geometry. В квейке реализация пространства идёт через алгоритм BSP-деревьев. Насколько я понимаю, в скомпилированном виде карта квейка выглядит именно как полость, вырезанная внутри бесконечного сплошного материала, и поэтому нельзя провалиться за пределы карты. Отсюда наверное и возникло заблуждение. А вот в Unreal реализована полноценная CSG, позволявшая редактировать геометрию уровня в редакторе на лету. wikivividly.com/wiki/Unreal_Engine#Unreal_Engine_1 Ну и ссылка на статью по конструктивной сплошной геометрии до кучи wikivividly.com/wiki/Constructive_solid_geometry
Замечу, мы говорим про первые игры Quake и Unreal из девяностых годов. С тех пор многое изменилось.
Ловко вы переобулись. Насмешливый тон про хардкор, компилятор и собственноручный компьютер звучал отнюдь не двусмысленно =) Наверное, вы просто шутили, а я воспринял всерьёз. Но раз уж начался диалог, отвечу по существу.
Никто и не говорит, что Handmade Hero нужен всем. Этот проект как раз для тех 10%, которые хотят знать все тонкости и разрабатывать максимально эффективные и оптимизированные игры, а в будущем, возможно, разрабатывать новые технологии, фреймворки и языки. Он возник как реакция компетентного инженера на повальную безграмотность, оказуаливание и конвеерность индустрии разработки игр. Такие дела.
А по теме: фреймворки написаны людьми. Фреймворк не даёт вам полного понимания, как игра работает под капотом. Когда вы учитесь создавать игры с помощью Unity, вы учитесь создавать игры на Unity. Если завтра Unity сгорит, включит анальный DRM, запросит с вас 90% прибыли или не сможет портироваться на нужную вам платформу из-за религиозных соображений, вы окажетесь в луже. Потому что вы не владеете своей игрой. Вы владеете набором инструкций для Unity. А если вам нужно будет портировать игру на Windows 11 через десять лет, Unity может вовсе не существовать к тому моменту: в таком случае удачи. Когда вы работаете с библиотеками, вы не можете обойти их ограничения. Если библиотека не умеет что-то делать, вам придётся либо лезть в её исходники, изучать, править и пересобирать самому, либо дышать в лапу, если она закрытая, и менять свой стэк.
Во-вторых, вы будете смеяться, но есть такой парень Jonathan Blow, создатель Braid и The Witness. Он не доволен текущими средствами разработки, и пишет свой язык программирования с компилятором (если не ошибаюсь, с помощью LLVM), заточенный под геймдев. Называется Jai. Посмотрите стрим, например www.youtube.com/watch?v=K2rvoCQksG8 Достаточно хардкорно? Ну или можете ему написать, что он лопух и заблуждается =)
Если кому интересно, то Кейси уже два года ведёт онлайн-трансляции разработки зельда-подобной игры без фреймворков и библиотек на голом C/C++. То есть абсолютно с нуля, ни единой библиотеки, прямая работа с буферами (даже вывод аудио guide.handmadehero.org/code/day140). Целью этого проекта является обучение грамотных программистов в эпоху хипстеров тормозных текстовых редакторов на платформе Electron и игровых фреймворков, которые слишком тяжеловесны, неоптимизарованы и не позволяют узнать, как вещи работают на самом деле.
Уже вышло примерно 500 эпизодов (полтора-два часа в среднем), где код пишется, параллельно объясняется диаграммами guide.handmadehero.org/code/day079/#385 (в данном примере подход к генерации уровней из девяностых в играх Quake и Unreal, спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно), обсуждаются подходы ООП vs структуры и функции (спойлер: ООП для игр — неэффективно по многим причинам). Спектр тем огромен: эффективное программирование как таковое, компиляция, живая перезагрузка кода программы, отладка, игровая геометрия, камера, fps-независимость, коллизии, текстуры, аудио, анимация и так далее: словом, всё, что нужно для полноценной игры.
Следует оговориться, что на данный момент проект всё ещё далёк от завершения, наполнение как таковой игры отсутствует, и потребуется ещё не один год, чтобы довести это проект до состояния игры. Однако такое количество информации, представленное настолько наглядно, не найти ни в одной книге или обучающем курсе.
Хм, интересный вопрос. Тут нужен договор с Бегетом о предоставлении услуг, и кто там кому является клиентом. Предполагаю парочку крепких сюжетных твистов в этой драме.
По сути произошло следующее: REG.RU и Beget давно дружили, хостер не обладал статусом регистратора, поэтому все домены регистрировались через REG.RU и все были счастливы.
Очевидно, раньше Бегет продавал только хостинг и предлагал по партнёрке домен в РЕГ.РУ. Пользователь становился одновременно клиентом обеих компаний, отсюда и почта.
Позиция REG.RU понятна: они побежали жаловаться маме на то, что вы якобы использовали нечестную практику: перенос доменов к Бегет под видом продления на REG.RU. Лично мне письмо с таким предложением не приходило, потому я не могу подтвердить соответствие этого заявления реальности.
А вы делали подобные рассылки клиентам? Только честно =)
Может быть, этого и незаметно, но Super Time Force едва умещалась в пределы памяти Xbox 360. Из-за функции перемотки времени нам нужно было хранить всю информацию каждого активного объекта уровня в течение всей длительности перематываемой шкалы времени.
Не знаю деталей технической реализации, но возможно, что их механизм хранения перемотки не самый оптимальный. В любом случае, если кому захочется реализовать нечто подобное, рекомендую на эту тему доклад Jonathan Blow о его реализации перемотки времени в Braid (вышла на XBox360 в том числе): GDC Vault — The Implementation of Rewind in Braid
Вкратце: необходимо хранить изначальное положение всех объектов, хранить события создания и уничтожения объектов, хранить дельты только для объектов, изменивших своё положение. Это сразу отсекает необходимость сохранять статичные объекты мира, а также те, которые прекратили своё движение (например, разлетевшиеся осколки, которые упали и лежат неподвижно).
Ваш вариант головоломки содержит только одну «загогулину». Интернет показывает наличие других вариантов, если я правильно понял, этой же задачи: https://i.ytimg.com/vi/QP4sMtPQj_Y/maxresdefault.jpg — здесь видно две загогулины. Даже если это не так, на мгновение представим, что у нас есть две или более загогулины.
Так вот. Эти загогулины не являются выпуклыми, так что хоть под неё и есть место, она может не вставиться из-за блокирующих элементов вокруг. Иначе говоря, важен порядок вставки элементов. Очевидно, что модель, реализующая сборку в таких условиях не должна ограничиваться перестановкой элементов, но и реализуемостью их вставки (то есть учитывать порядок вставки).
И теперь, собственно, главный вопрос к людям опытным в этой области: может ли оказаться решение допустимое теоретически, но неосуществимое физически из-за невыпуклости элементов?
Спасибо вам за плагин. Постепенно осваиваем как прозрачную замену чёрному ящику из костылей select2.
Пока возник вопрос с динамическими интерполяциями.
В нашем случае на форме при смене типа автомобиля меняется источник данных для списка трансмиссий, и одновременно обязательность этого поля. Если поле становится необязательным, пользователь должен уметь его очистить. В директиве есть опция
cleanModel, но она проверяется один раз при компиляции, так что oi-select-options="{cleanModel:isRequired(vehicleType)}" выполнится только для исходного состояния формы. Смена vehicleType не приведёт к вычислению нового значения cleanModel и не разрешит очищать поле.
Есть ли возможность реализовать разбор elementOptions динамически и навесить этот разбор на нужные $watch (в нашем случае, смена источника данных)? Перекомпилировать всю директиву ради этого выглядит большим оверхедом.
sin(float x)работал на 2-3% быстрее, чемarr[(int) float x]. У меня возникло подозрение, что вычисление синуса как-то хитро оптимизировано (набором инструкций SSE, например), что даже прямое обращение в массив не смогло выиграть. Эту тему я дальше копать не стал, она так и осталась для меня тайной. Может, какой-то флаг при компиляции был отключен (target был Release в Borland Developer Studio C++). Это было в 2010-м году на Intel Core 2 Duo. Если кто знает, в чём секрет, поделитесь =)На часах 0:30, мы говорим «половина первого (часа)». С начала суток прошло ноль часов и ещё половина часа. Чувствуете, в чём подвох? Прошло ноль часов, но говорим «половина первого часа».
Далее мы говорим, что живём в 2019-м году. В две тысячи девятнадцатом году. Сколько лет прошло с начала эры? По аналогии с часами нужно сказать, что две тысячи восемнадцать полных лет, и записывать их как 24.12.2018.
Cогласно григорианскому календарю, нулевого года не существует [2 до н.э., 1 до н.э., 1 н.э.]. То есть ребёнку может быть ноль лет, а нашей эре сразу стал один год.
ru.wikipedia.org/wiki/0_год
И товарища ikle сверху слили ни за что. Первое десятилетие — это годы 1,2...10. Начало второго десятилетия — это 11-й год. Также и 2021-й год будет началом нового десятилетия.
Краткая суть простыни: методология (и соотв. книга) Domain Driven Design сокращается как DDD. А если вы вдруг не знали, DDD — это особо крупный размер чашки бюстгалтера и популярный запрос на сайтах с видео определённой тематики. И автора задевает «исключающая» натура этого сокращения (в том смысле, что исключает дам с меньшим размером), а также намёк на грязные видео. И дама говорит, что не важно ваше намерение, а действие, которое производит само слово. Даже если вы не знали этого сокращения, кто-то может оскорбиться, и уже потому вы виноваты.
Дама занимает серьёзный пост в сообществе Ruby (могу ошибаться), судя по внешним признакам: «Software engineer, founder of @railsbridge, Director of Ruby Central, Architect at @salesforceux».
В целом же современные движки — палка о двух концах.
С одной стороны это благо, потому что уменьшают порог вхождения в индустрию. С другой стороны, это бич, потому что меньшают порог вхождения в индустрию, снижают уровень компетентности и требований (засилие инди-хлама на Steam), используют неоптимальные языки и инструменты (фризы из-за GC, или например любая игра, даже пустой экран, на Godot содержит в себе 30Мб движок, который интерпретирует код, то есть виртуальная машина типа Java), либо вовсе являются монструозными комбайнами (типа Unity, Unreal Engine и CryEngine в гигабайты величиной).
Ну и да, приведите примеры AAA-проектов на этих движках? Кроме приснопамятного Star Citizen, разумеется, который никогда не выйдет. В том-то и дело, что такой движок используется либо небольшой студией, либо самой студией-автором движка. Большинство крупных и высокобюджетных тайтлов (Quake/Rage/DOOM 2016/Wolfenstein, Battlefield, Anthem, Dragon Age, GTA, Red Dead Redemption, Call of Duty, Witcher, Uncharted, новые Tomb Raider, Assassin's Creed, Horizon Zero Dawn, Diablo III, Starcraft 2, Overwatch и т.д.) работают на собственных разработках студий. Да, этим движкам дают названия, типа RedEngine, idTech, RAGE, Decima, Frostbite — но они не становятся достоянием общественности, а либо оседают в студии, либо лицензируются за большие деньги. Почему? Наверное, потому что отполированы и заточены под свой внутренний пайплайн. В отличие от конструкторов, которые должны угодить всем, но средненько.
Возвращаясь к Handmade Hero. Цель — не просто сделать игру. Цель — научиться делать качественную игру и понимать механизмы, которые лежат у движков под капотом (в определённых пределах).
Мне непонятен ваш мотив. Почему вы защищаете людей, которые плодят низкокачественные решения? Соседний пост Моё разочарование в софте за два дня собрал 340 плюсов и 900 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
Смысл каждого эпизода в том, что любое действие разжёвывается. Есть десятки эпизодов, где целый час идёт чисто рисование на доске (вот произведение матриц, например guide.handmadehero.org/code/day362/#354) Потому это и продолжается так долго. Если убрать объяснения (-50% времени), Q&A (-20% времени), на чистый кодинг останется 140 эпизодов средней длиной 1,5 часа (до 350-го эпизоды были короче), то есть 210 часов чистой работы, грубо говоря. Округлим до 240 часов. 240 часов это 3 месяца интенсивной работы. Это крайне мало для того результата, который есть на экране (с учётом разработки с нуля, 100% понимания и полной ответственности за каждую строчку кода, и соответствующей производительности). И не стоит забывать, что значительная часть кода будет использоваться повторно в последующих проектах (аппаратный уровень, алогритмы работы с векторами/матрицами/массивами, камера, управление, инструменты отладки, движок анимации и тд).
Видимо, Кейси на старости лет стал забываться. В подтверждение, кому интересно, есть наглядная иллюстрация компиляции карты из набора объёмных «кистей»-примитивов в первом Quake.
Полная статья здесь wikivividly.com/wiki/Quake_engine#Reducing_3D_complexity_to_increase_speed
Причём в статье не говорится о Constructive Solid Geometry. В квейке реализация пространства идёт через алгоритм BSP-деревьев. Насколько я понимаю, в скомпилированном виде карта квейка выглядит именно как полость, вырезанная внутри бесконечного сплошного материала, и поэтому нельзя провалиться за пределы карты. Отсюда наверное и возникло заблуждение. А вот в Unreal реализована полноценная CSG, позволявшая редактировать геометрию уровня в редакторе на лету. wikivividly.com/wiki/Unreal_Engine#Unreal_Engine_1 Ну и ссылка на статью по конструктивной сплошной геометрии до кучи wikivividly.com/wiki/Constructive_solid_geometry
Замечу, мы говорим про первые игры Quake и Unreal из девяностых годов. С тех пор многое изменилось.
Никто и не говорит, что Handmade Hero нужен всем. Этот проект как раз для тех 10%, которые хотят знать все тонкости и разрабатывать максимально эффективные и оптимизированные игры, а в будущем, возможно, разрабатывать новые технологии, фреймворки и языки. Он возник как реакция компетентного инженера на повальную безграмотность, оказуаливание и конвеерность индустрии разработки игр. Такие дела.
А по теме: фреймворки написаны людьми. Фреймворк не даёт вам полного понимания, как игра работает под капотом. Когда вы учитесь создавать игры с помощью Unity, вы учитесь создавать игры на Unity. Если завтра Unity сгорит, включит анальный DRM, запросит с вас 90% прибыли или не сможет портироваться на нужную вам платформу из-за религиозных соображений, вы окажетесь в луже. Потому что вы не владеете своей игрой. Вы владеете набором инструкций для Unity. А если вам нужно будет портировать игру на Windows 11 через десять лет, Unity может вовсе не существовать к тому моменту: в таком случае удачи. Когда вы работаете с библиотеками, вы не можете обойти их ограничения. Если библиотека не умеет что-то делать, вам придётся либо лезть в её исходники, изучать, править и пересобирать самому, либо дышать в лапу, если она закрытая, и менять свой стэк.
Во-вторых, вы будете смеяться, но есть такой парень Jonathan Blow, создатель Braid и The Witness. Он не доволен текущими средствами разработки, и пишет свой язык программирования с компилятором (если не ошибаюсь, с помощью LLVM), заточенный под геймдев. Называется Jai. Посмотрите стрим, например www.youtube.com/watch?v=K2rvoCQksG8 Достаточно хардкорно? Ну или можете ему написать, что он лопух и заблуждается =)
хипстеровтормозных текстовых редакторов на платформе Electron и игровых фреймворков, которые слишком тяжеловесны, неоптимизарованы и не позволяют узнать, как вещи работают на самом деле.Уже вышло примерно 500 эпизодов (полтора-два часа в среднем), где код пишется, параллельно объясняется диаграммами guide.handmadehero.org/code/day079/#385 (в данном примере подход к генерации уровней из девяностых в играх Quake и Unreal, спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно), обсуждаются подходы ООП vs структуры и функции (спойлер: ООП для игр — неэффективно по многим причинам). Спектр тем огромен: эффективное программирование как таковое, компиляция, живая перезагрузка кода программы, отладка, игровая геометрия, камера, fps-независимость, коллизии, текстуры, аудио, анимация и так далее: словом, всё, что нужно для полноценной игры.
Следует оговориться, что на данный момент проект всё ещё далёк от завершения, наполнение как таковой игры отсутствует, и потребуется ещё не один год, чтобы довести это проект до состояния игры. Однако такое количество информации, представленное настолько наглядно, не найти ни в одной книге или обучающем курсе.
Архив ютуба (нагляднее): www.youtube.com/user/handmadeheroarchive/videos
Архив с темами и метками (структурированнее) handmadehero.org/watch — пролистать ниже до списка эпизодов
А вы делали подобные рассылки клиентам? Только честно =)
Вкратце: необходимо хранить изначальное положение всех объектов, хранить события создания и уничтожения объектов, хранить дельты только для объектов, изменивших своё положение. Это сразу отсекает необходимость сохранять статичные объекты мира, а также те, которые прекратили своё движение (например, разлетевшиеся осколки, которые упали и лежат неподвижно).
Ваш вариант головоломки содержит только одну «загогулину». Интернет показывает наличие других вариантов, если я правильно понял, этой же задачи: https://i.ytimg.com/vi/QP4sMtPQj_Y/maxresdefault.jpg — здесь видно две загогулины. Даже если это не так, на мгновение представим, что у нас есть две или более загогулины.
Так вот. Эти загогулины не являются выпуклыми, так что хоть под неё и есть место, она может не вставиться из-за блокирующих элементов вокруг. Иначе говоря, важен порядок вставки элементов. Очевидно, что модель, реализующая сборку в таких условиях не должна ограничиваться перестановкой элементов, но и реализуемостью их вставки (то есть учитывать порядок вставки).
И теперь, собственно, главный вопрос к людям опытным в этой области: может ли оказаться решение допустимое теоретически, но неосуществимое физически из-за невыпуклости элементов?
Пока возник вопрос с динамическими интерполяциями.
В нашем случае на форме при смене типа автомобиля меняется источник данных для списка трансмиссий, и одновременно обязательность этого поля. Если поле становится необязательным, пользователь должен уметь его очистить. В директиве есть опция
cleanModel, но она проверяется один раз при компиляции, так чтоoi-select-options="{cleanModel:isRequired(vehicleType)}"выполнится только для исходного состояния формы. СменаvehicleTypeне приведёт к вычислению нового значенияcleanModelи не разрешит очищать поле.Есть ли возможность реализовать разбор
elementOptionsдинамически и навесить этот разбор на нужные$watch(в нашем случае, смена источника данных)? Перекомпилировать всю директиву ради этого выглядит большим оверхедом.Спасибо!