Concept

" Вы вообще очень странные существа, наконец сказал визирь. Вы даже устроены удивительно у вас мягкие ткани тела торчат наружу, а кость находится глубоко внутри.
А что тут такого? опешил я.
Нет логики, сказал кубарь. Логично, когда организм защищает панцирем свои мягкие ткани от внешней среды. Но какой смысл держать кости внутри организма, окружив их мягкой ранимой тканью? Словно вас раздирает что-то изнутри, словно вы опасаетесь агрессии изнутри больше, чем от окружающей среды." _{-- Леонид Каганов (рассказ 'Там где нет ветра')}

Примерка для инкапсуляции. Слева направо - двойной RaspberryPi 4B, nVidia Jetson Nano B01, Intel NUC gen11.

История tru3bicon

В ходе работы над полухоббийным проектом киберпространственной антиконсоли сложилась нетривиальная ситуация - плата прототипирования с допмодулями и портами физически не уместилась в отведенное под нее проработанное корпусное пространство. Таким образом, мне потребовалось существенно перепилить форму корпуса под менее феншуйные габариты/формы/пропорции, после чего выяснилось, что во временную костыльную версию теперь можно утрамбовать множество вариантов начинки, а это существенно расширяет границы применимости такой итерации корпуса - неплохой сценарий для перевоплощения сего корпуса под универсальное позиционирование и отдельный брендинг. По ходу переосмысления пришел к тому, что существует ненулевой смысл зарелизить корпус под GPLv3 и поделиться сим концептом с хабрасообществом.

Суть tru3bic0n

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

Описание tru3bic0n

Итак, рассматриваемый корпус представляет собой объект класса Евклид своеобразный "кубик в кубе" - внутренний куб имеет сэндвичную структуру, будучи разделен на 2 подошвы теплообмена и картридж с инкапсулированной электроникой и вмонтирован диагональными ребрами во внешнюю орбитальную кубическую раму. Форма куба концептуально являет собой базовый не бионический элемент, который многим близок с детства - от наборов разноцветных кубиков, через кубические игральные кости, до культового кубика Рубика. Наиболее рациональными материалами для формирования данного корпуса сейчас видятся сплавы алюминия, магния, меди.

Применение tru3bic0n

Наболее целесообразными кейсами наполнения нового корпуса представляются одноплатники - туда с легкостью размещаются всевозможные Pi-образные платы с обилием обвязки и коннекторов. Также корпус представляется интересным для инкапсуляции системных плат микроПК, микроворкстейшнов, микросерверов. Не исключены и кейсы удобной инкапсуляции высокопроизводительной периферии - внешних видеокарт, сопроцессоров нейрокомпьютинга, asic-майнеров.

Контекст tru3bic0n

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

Технологии tru3bic0n

На ранних итерациях для небольших партий - наиболее продуктивным способом изготовления представляется вытачивание рамы из монолитных заготовок посредством ЧПУ-фрезерования. В мелкосерийном производстве для оптимизации потерь времени/материала/оснастки целесообразными выглядят технологии литья в заполняемую форму по SLA 3D-печатным испаряемым моделям и металлическая 3D-печать по SLM-процессу. Относительно картриджей для электроники - пока вполне здравим смотрится планомерный путь от полимерной SLA/DLP/LCD 3D-печати, через двухкомпонентное литье в силиконовые формы, к штамповке пластиком в пресс-формах под давлением.

Ценность tru3bic0n

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

Планы tru3bic0n

Сейчас концепция корпуса еще довольна сыра и поверхностна, но если вектор фидбека окажется в позитивном ключе - планирую интенсивную проработку/дополнение/исправление. Относительно реализации, на данный момент есть только FDM-напечатанные габаритные модели - запланированные посредством ЧПУ-фрезерования прототипы из Д16Т отложены на март/апрель/май по причине тотального отстуствия в ДефолтСити вменяемых розничных поставщиков крупных алюминиевых заготовок, прототипы посредством литья через выгораемые модели пока малореальны по факту отсутствия у потенциальных изготовителей SLA-3D-принтеров с достаточно крупной рабочей камерой, прототипы посредством SLM-3D-печати теплопроводящими сплавами еще нецелесообразны по факторам чрезмерных затрат времени и ресурсов, которые требуются для этой сыроватой технологии. Буду рад любой конструктивной критике концепта, любым рацпредложениям по конструктиву, любой полезной информации для совершенствования корпусировки.

Сопоставление габаритов Raspberry PiСопоставление габаритов Jetson NanoСопоставление габаритов Intel Nuc

"- Куб значит частица куб значит воксель куб значит пиксель куб значит цель куб значит выбор куб значит свобода куб значит жизнь куб значит всё...
- Куб начинается и куб заканчивается я живу ради куба - у жизни нет другого смысла и у жизни есть смысл - смысл значит куб.
- Жизнь бессмысленна без цели, а у меня есть цель - у меня есть куб!" _{-- я (небольшая графоманская импровизация на тему философии кубарей в scp-стиле)}

Представьте себе, что вы студент, изучающий современные фичи C++. И вам дали задачу по теме concepts/constraints. У преподавателя, конечно, есть референсное решение "как правильно", но для вас оно неочевидно, и вы навертели гору довольно запутанного кода, который всё равно не работает. (И вы дописываете и дописываете всё новые перегрузки и специализации шаблонов, покрывая всё новые и новые претензии компилятора).

А теперь представьте себе, что вы преподаватель, который увидел эту гору, и захотел помочь студенту. Вы стали упрощать и упрощать его код, и даже тупо комментировать куски юнит-тестов, чтобы оно хоть как-то заработало... А оно всё равно не работает. Причём, в зависимости от порядка юнит-тестов, выдаёт разные результаты или вообще не собирается. Где-то спряталось неопределённое поведение. Но какое?

Сперва преподаватель (то есть, я) минимизировал код вот до такого: https://gcc.godbolt.org/z/TaMTWqc1T

// пусть у нас есть концепты указателя и вектораtemplate<class T> concept Ptr = requires(T t) { *t; };template<class T> concept Vec = requires(T t) { t.begin(); t[0]; };// и три перегрузки функций, рекурсивно определённые друг через другаtemplate<class T> void f(T t) {  // (1)  std::cout << "general case " << __PRETTY_FUNCTION__ << std::endl;}template<Ptr T> void f(T t) {  // (2)  std::cout << "pointer to ";  f(*t);  // допустим, указатель не нулевой}template<Vec T> void f(T t) {  // (3)  std::cout << "vector of ";  f(t[0]);  // допустим, вектор не пустой}// и набор тестов (в разных файлах)int main() {  std::vector<int> v = {1};    // тест А  f(v);  // или тест Б  f(&v);  // или тест В  f(&v);  f(v);  // или тест Г  f(v);  f(&v);}

Мы ожидаем, что

• f(v) выведет "vector of general case void f(T) [T=int]"

• f(&v) выведет "pointer to vector of general case void f(T) [T=int]"

А вместо это получаем

• А: "vector of general case void f(T) [T=int]"

• Б: "pointer of general case void f(T) [T=std::vector<int>]" ?

• В: clang выводит Б и А ?!, gcc ошибку линкера

• Г: clang и gcc выводят ошибку линкера

Что здесь не так?!

А не так здесь две вещи. Первая это то, что из функции (2) видны объявления только (1) и (2), поэтому результат разыменования указателя вызывается как (1).

Без концептов и шаблонов это тоже прекрасно воспроизводится: https://gcc.godbolt.org/z/47qhYv6q4

void f(int x)    { std::cout << "int" << std::endl; }void g(char* p)  { std::cout << "char* -> "; f(*p); }  // f(int)void f(char x)   { std::cout << "char" << std::endl; }void g(char** p) { std::cout << "char** -> "; f(**p); }  // f(char)int main() {  char x;  char* p = &x;  f(x);  // char  g(p);  // char* -> int  g(&p); // char** -> char}

В отличие от инлайн-определений функций-членов в классе, где все объявления видны всем, определение свободной функции видит только то, что находится выше по файлу.

Из-за этого, кстати, для взаимно-рекурсивных функций приходится отдельно писать объявления, отдельно (ниже) определения.

Ладно, с этим разобрались. Вернёмся к шаблонам. Почему в тестах В и Г мы получили нечто, похожее на нарушение ODR?

Если мы перепишем код вот так:

template<class T> void f(T t) {.....}template<class T> void f(T t) requires Ptr<T> {.....}template<class T> void f(T t) requires Vec<T> {.....}

то ничего не изменится. Это просто другая форма записи. Требование соответствия концепту можно записать и так, и этак.

Но вот если прибегнем к старому доброму трюку SFINAE, https://gcc.godbolt.org/z/4sar6W6Kq

// добавим второй аргумент char или int - для разрешения неоднозначностиtemplate<class T, class = void> void f(T t, char) {.....}template<class T> auto f(T t, int) -> std::enable_if_t<Ptr<T>, void> {.....}template<class T> auto f(T t, int) -> std::enable_if_t<Vec<T>, void> {.....}..... f(v, 0) .......... f(&v, 0) .....

или ещё более старому доброму сопоставлению типов аргументов, https://gcc.godbolt.org/z/PsdhsG6Wr

template<class T> void f(T t) {.....}template<class T> void f(T* t) {.....}template<class T> void f(std::vector<T> t) {.....}

то всё станет работать. Не так, как нам хотелось бы (рекурсия по-прежнему сломана из-за правил видимости), но ожидаемо (вектор из f(T*) видится как "general case", из main - как "vector").

Что же ещё с концептами/ограничениями?

Коллективный разум, спасибо RSDN, подсказал ещё более минималистичный код!

Всего 4 строки: https://gcc.godbolt.org/z/qM8xYKfqe

template<class T> void f() {}void g() { f<int>(); }template<class T> void f() requires true {}void h() { f<int>(); }

Функция с ограничениями считается более предпочтительной, чем функция без них. Поэтому g() по правилам видимости выбирает из единственного варианта, а h() - из двух выбирает второй.

И вот этот код порождает некорректный объектный файл! В нём две функции с одинаковыми декорированными именами.

Оказывается, современные компиляторы (clang 12.0, gcc 12.0) не умеют учитывать requires в декорировании имён. Как когда-то старый глупый MSVC6 не учитывал параметры шаблона, если те не влияли на тип функции...

И, судя по ответам разработчиков, не только не умеют, но и не хотят. Отмазка: "если в разных точках программы одинаковые обращения к шаблону резолвятся по-разному, такая программа ill-formed, никакой диагностики при этом не нужно" (однако, ill-formed означает "не скомпилируется", а не "скомпилируется как попало"...)

Проблема известна с 2017 года, но прогресса пока нет.

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

Привет всем! Пока мы, на самом деле, безымянная студия и проект, который делаем имеет техническое название "CGDrone". Сегодня мне захотелось написать эту короткую статью. Понимаете, замучался от всей этой работы со скетчами, цветами, алгоритмами и исправлением багов во вращениях, которые реализованы с помощью кватернионов. Последние, к слову, меня порядочно побили.

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

Начало

Дело было в институте, конец магистратуры. Мы с моим товарищем из параллельной группы решаем создать свою супер-пупер 3D-головоломку от первого лица. Такую что просто ну просто бомба и огонь. Надеюсь вы поняли меня. Почему решили делать игру? У меня есть опыт в рисовании, закончил школу с ИЗО уклоном, у напарника есть опыт в создании 3D-моделей. Ну и оба мы программисты как-никак, поработали в фирмах в т.ч. игры делали. Почему головоломку? Потому, что нам нравятся головоломки.

Работу мы разделили примерно пополам ну или делали кто что может. С одной стороны, если в команде 2 человека, то делить работу можно пополам! Удобно же :) И на контроль за результатами работы всех разработчиков не так много времени уходит как, скажем, ушло бы если бы в нашей команде было 30 человек.

В итоге все встало на свои места: я стал отвечать за весь код и графон (шейдеры, освещение, пост-эффекты), а напарник за уровни и юридические вопросы. Вначале, кстати, он моделил лучше меня. Но со временем стало понятно, что просить его перемоделивать что-то каждый раз - это дергать человека и отрывать от основной работы. К тому же требования к моделям могут меняться и человек сойдет с ума от 1000 правок в день. Так что позже модели перешли под мою ответственность.

В самом начале мы придумали идею, игровые законы, механики, протестировали все в голове, на бумаге, и в Unity, запланировали сетевой режим.

Не поверите, но у меня набралось 2 папки со скетчами по проекту и иногда мне все еще приходится набрасывать картинки/перебирать идеи/сопоставлять обьекты. Скетчи, которые я набрасывал выглядят примерно так:

На данный момент мы опубликовали большую часть скетчей в твиттере / инстаграме.

Были еще знакомые, мы попытались подключить их к проекту. Кроме нас в команде было две девушки (дизайнеры-художники), гейм-дизайнер и программист. Через 2-3 недели программист пошел работать в крупную фирму, после попыток прописать структуру проекта и сборки одного игрового обьекта - условный обьект с "глазом" (который следит за игроком). Потом нас покинули дизайнеры. Гейм-дизайнер оказался крепким. Он был с нами до последнего, а вот результатов его работы у нас не было :)

Кстати, игра на тот момент выглядела так:

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

Еще несколько скетчей:

Коротко о некоротком, о сети

Изначально мы планировали сетевой режим. Вот что-что не стоило делать, так это сеть. Я пытался вытягиват сеть до последнего. Просто как кот вцепляется в рыбу, так и я вцепился намертво в сеть В итоге мы реализовали комнаты, уровни, сетевое взаимодействие основных обьектов. Но все это двигалось очень долго, тесты и отладка занимали тьму времени. Интерфейс игры тогда выглядел так:

Мы много чего сделали по сетевой части, в том числе и организовали сетевой чат (иконка конверта) и систему общения голосом (иконка микрофона).

Позже я смекнул и понял одну важную вещь: сеть это круто, но если у вас в команде 2 человека и нет опыта в сетевой части(хотя лабы по сетям в институте мы сдавали только так), то лучше повременить с сетью, сделать основное:

Лучше синица в руках, чем журавль в небе

Попытки расширить команду

Позже мною предпиримались попытки привлечь в проект крутых художников. Но не пошло. Очевидные вещи, которые я выяснил:

• профессиональные художники хотят получать денюжки, а у нас есть только энтузиазм

• по большей части непрофессилнальные художники (из моего личного опыта) любят покреативить и вместо того чтобы сделать все максимально по ТЗ, их заносит и они по-полной берут на себя роль главного ГД и начинают работать уже в этом направлении

• мотивировать команду - это работа на которую затрачивается много времени

Для себя мы поняли еще одну вещь: у нас нет времени на выдачу ТЗ ребятам, которые работают на энтузиазме потому, что высока вероятность их ухода. Так что мы решили делать все сами и никого не искать, не расширять команду. У этого решения есть плюс, который я описал бы так:

Надеемся только на крепость рук, На руки друга и вбитый крюк - И молимся, чтобы страховка не подвела.

На данный момент мы все так же усердно работаем над проектом. Сделали кучу основной работы, работаем над оптимизацией, полировкой графона, анимациями и историей.

Так же в последнее время к нам присоединился переводчик, который взялся прорабатывать сценарий :) Уже вот год работает с нами как и мы на энтузиазме.

А вот и ссылки на нас:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey

https://vk.com/treload