Доведя до ума SCARA 3D принтер и добившись достаточного качества печати я начал думать над следующей поделкой. Это само собой должен быть 3д принтер.
Для себя я решил, что новый принтер должен соответствовать таким критериям:
Маленький (область печати 10х10 см) — большой принтер у меня уже есть и теперь хочется второй на котором можно будет печатать тонким соплом и тонкими слоями небольшие детали (шестеренки и т д)
Быстрый
На какой-то не стандартной кинематике
Кинематика
Долго думал и перебирал кинематики которые позволяли печатать с высокой скоростью, простыми и компактными.
Размеры — 40x30x80 на стол не поставить (не влез даже на балкон, точнее влез но катушка с пластиком уже не влазила)
Вес — 8кг (частично из за Nema23 и тяжелых мебельных щитов)
Что мне хотелось
Шум — убрать шум на минимум (в идеале только звук шаговиков в 32 микрошаговом режиме). Один из самых громких источников шума в дельта механике это линейные направляющих и линейные подшипники, в природе лечится рельсовыми направляющими или нехитрой конструкцией с алюминиевым профилем и подшипников скольжения одетыми в оболочку (Kossel). Как по мне, в вертикальном состоянии линейные подшипники и линейные направляющие работают не в правильном режиме.
Размеры — хочется принтер который легко умещается на стол с творческим беспорядком. Далее — размер печатной области должен быть не меньше чем 10x10x10+.
Почему я решил пожертвовать размерами печатной области — а потому что за полгода почти каждодневной печати мне не разу не понадобилось напечатать что то больше, чем 10x10. Я принял решение что мне этой области хватит с головой и даже останется.
Также, на прогрев области 10x10 надо в 4 раза меньше мощности блока питания, а это позволяет использовать обычные внешние блоки питания — я влез всего в 60ватт (с подогреваемой платформой), у меня 8.5A 12v. Большим плюсом является внешний блок питания, который лежит под столом и не занимает место.
Вес — предыдущий параметр уже позволяет серьезно уменьшить вес, плюс укороченные Nema17 (меньший момент, но это не проблема). Cтруктурная сложность для небольших конструкций достигается легче и легкими материалами.
Причина побудившая меня собрать свой принтер из всего что есть под руками очень банальна — В мае на кикстартере был заказан M3D (я был в январском бакете). Пришел январь и судя по апдейтам с кикстартера задержка обещала быть довольно большой (на данный момент уже 7 месяцев), а в наличии был самодельный ЧПУ которым я уже не пользовался около года. Пользоваться ЧПУ перестал сразу как только понял что для моих нужд (сборка робота) плоские детали, которые я выпиливал из текстолита, не решали мои потребности а фрезеровать объемные детали было не из чего и технически сложным (некоторые модели выпилить на 3ех осевом ЧПУ физически невозможно ели не разбивать из на составные части) да и мусорность данного процесса явно не для домашнего использования.
Что такое ARM NEON? – ARM® NEON™ это SIMD движок … – другими словами это расширенный набор инструкций наподобие x86 CPU SSE/SSE2 но для процессоров с ARM архитектурой.
Зачем?
Всё и так было хорошо пока я не добавил поддержку FSAA. После этого фпс просел ниже чем 15.
После оптимизации у меня опять было около 25 FPS. Но в памяти засела одна функция которая потребляла 10% времени на кадр в которой я уже не знал что можно оптимизировать.
Благодаря одному моему другу, который время от времени задавал вопрос типа «А не хочешь ли ты задействовать NEON в своем движке» я таки решился (с его поддержкой) переписать эту функцию на NEON.
В конце данной статьи мною был озвучен план сделать порт под Android. Тут я попытаюсь описать проблемы, с которыми я столкнулся и методы их решения. Сразу хочу оговорится, что опыта работы с Android на данный момент ровно 2 месяца и возможно некоторые решения опасны или даже не приемлемы на данной платформе.
Движок
Движок (хобби) находится в разработке уже 10 лет.
Движок полностью написан на C/C++, до начала портации на Android поддерживал iOS и Windows.
Логика, рендеринг, звук — все на C/C++.
Каждый разработчик игр в сталкивается с проблемой переноса/натягивания пользовательского интерфейса.
Большинство моих знакомых просят художников делать текстурные атласы, и потом в ручную или при помощи встроенных в игру тулзов располагают это на экране.
Самая острая проблема заключается именно в расстановке данных объектов на экране. Я встречал варианты ручного позиционирования через .ini файлы с указанием положения на экране и описание прямоугольника с текстурными координатами. Это вполне приемлемо если у вас немного элементов и есть свободное время.
Записать живое видео игрового процесса iOS игры.
Как я не пытался сделать это раньше ничего хорошего из этого не получалось.
Самое сложное в этом процессе сделать так чтобы камера и снимаемое устройство было фиксировано.
В результате нескольких экспериментов я так и не смог сделать что то более менее удобоваримое поэтому видео снимал из Windows версии моего приложения.
Но на днях очень резко встал вопрос о наличие живого видео и была придумана убер система для записи живого видео с айпада.
Елементы системы
Табуретка
2 листа a4
iPad
Записывающее устройство (я использовал iPod Touch 4)
Время разработки — 6+ месяцев двух человек в свободное от работы время.
Состав команды — 1 художник 1 программист.
Время от идеи до прототипа — 1 неделя
Арт данные — 288 мегабайт, 1400 файлов
Код Движка и Игры (без сторонних библиотек) ~ 50024 строк кода, 485 файлов
Код Игры — 4338 строк — 12 файлов
Финальный размер дистрибутива для аплоада в AppStore 22мб
Финальный размер в AppStore 25мб
Доработка приложения для iPad заняло всего неделю. Основное время было затрачено на переработку пользовательского интерфейса. Аспект разрешения экрана iPad и iPhone разный, следовательно если вы не учли это при проектировании интерфейса — у вас проблема (особенно если количество экранов у вас велико).
Если 1024, не меняя аспект, привести к 480, то результирующая картинка будет 480x360 — получаем 40 лишних пикселей по вертикали. Одно из простых решение, это оставить пустое место снизу и сверху. Мне этот подход не нравится. Так как у меня всего три экрана (и почти все в векторе) я переделал исходные материалы под расширение 1024x768 и написал утилиту перегоняющую в 480x320, урезая(сдвигая) конкретные не нужные мне части сверху, снизу или с обоих сторон.
В октябре 2008 года на очередной встрече с двумя друзьями, я узнал, что оба они занимаются разработками игр под iPhone. В то время я уже имел почти законченный shareware проект под Windows.
Загоревшись желанием портировать его под iPhone, я начал работать в данном направлении.
Цели
Cоздать и настроить средства разработки под Windows платформу без покупки самого девайса, Mac и сопутствующих средств разработки. Покупку Mac была отложена до момента полного понимания что и как работает.
Почти готовый проект и тулзы для него были под Windows поэтому было принято решение всё делать под Windows.
Несколько дней на поиск в интернете и я приступил к осуществлению данной идеи.
Шаг Первый — Настройка окружения и компилятора под Windows, а точнее под Cygwin
Было потрачено где-то около месяца на сборку toolchain под Cygwin. Результатом этого был огромный makefile для сборки toolchain и скомпилированное приложение HelloWorld, которое негде было запустить, так как девайса у меня не было. Когда я говорю что это заняло месяц, это не означает что я месяц по 8 часов в день работал над этим, в основном работа велась по выходным и после работы. Много времени уходило на перекомпиляцию, фикс проблем с путями, фикс проблем компиляции и настройки среды CygWin (только Cygwin я переставлял раза три).
