Хочу купить робота-пылесоса
С док станцией и автоочисткой. Цена значения не имеет. Типа такого, как на картинке. Есть у вас опыт использования? Поделитесь! Обзоры в интернетах часто заказные. Нужен реальный опыт использования. Спасибо.
С док станцией и автоочисткой. Цена значения не имеет. Типа такого, как на картинке. Есть у вас опыт использования? Поделитесь! Обзоры в интернетах часто заказные. Нужен реальный опыт использования. Спасибо.
Думаю, большинство моих читателей успела застать эру кнопочных телефонов с поддержкой Java-приложений. Помните ли вы, как мониторили разделы с загрузками на WAP-сайтах и ждали выхода новых игр, которые подойдут под ваш телефон и разрешение экрана? А какой восторг вызывали свежие 3D-игры, где графика с каждым релизом становилась всё лучше и была вполне на уровне PlayStation 1? V-Rally, Galaxy On Fire, Asphalt Urban GT, Deep3D, Sony Ericsson Tennis, Left 2 Die, Counter Terrorism 3D — думаю, хотя бы один из этих тайтлов вам знаком. Но задумывались ли вы, как работали эти игры «под капотом»? Каким образом разработчикам удавалось адаптировать полноценные 3D-шутеры и гонки под железо, где не было 3D-ускорителей (видеокарт), сопроцессора для чисел с плавающей точкой (FPU), а одноядерный процессор, работающий на частоте 100-200МГц, помимо игры обрабатывал ещё и звук, ввод, а также радиомодуль? Сегодня мы узнаем: как разрабатывали игры под J2ME, какие графические API существовали и на каких телефонах поддерживались, почему игры на Sony Ericsson шли лучше, чем на Nokia, а на «закуску» сами с нуля напишем 3D-бродилку в практической части! Интересно? Тогда добро пожаловать под кат!
Обычно принято считать, что полноценные 3D-игры на кнопочных телефонах начали выходить примерно в 2004-2005 году, как раз с выходом графического API M3G. Однако, история мобильного трёхмерного гейминга тянется несколько дальше и уходит корнями в самое начало двухтысячных годов — как раз, когда телефоны только-только начинали обрастать мультимедийным функционалом.
Мы с вами привыкли, что существовали Java-игры для простых кнопочных телефонов и BREW-игры для телефонов Qualcomm. Но на рубеже нулевых сразу несколько перспективных компаний боролось за право стать разработчиком основной мобильной платформы и вытеснить J2ME. Одной из самых известных была Mophun, которая представляла из себя кроссплатформенную виртуальную машину, исполняющую байткод в собственном формате. И уже в ~2002-2003 году, Mophun представили 3D API для разработки очень симпатичных мобильных игр, которые и работали шустро.
Кстати, опробовать Mophun-библиотеку вы можете и сами: в РФ из Mophun-девайсов был как минимум Sony Ericsson T610, которые сейчас можно купить чуть ли не по «сотке» на вторичке.
Помимо Mophun, на французских телефонах производства Alcatel и Sagem была установлена платформа In-Fusio, тоже основанная на J2ME (а может и какой-то собственный сабсет API), однако со своим специфическим набором API, ориентированном на разработку игр. Мы с EXL даже в прошивке OT535 копались, прямо в HEX-редакторе, чтобы найти информацию о встроенной 2.5D-игре-бродилке:
Как можно заметить, спрос на 3D-игры появился практически в тот момент, когда в мобильные девайсы начали ставить достаточно мощные по тем годам процессоры: ~60-100МГц. Разработчики реально верили, что телефоны можно превратить не только в мультимедийное устройство, но и портативную хэндхэлд-консоль с графикой уровня не хуже GBA!
В сегодняшнем материале я хотел бы сосредоточиться именно на трехмерных Java-играх. Очевидно, что вручную рисовать 3D-графику без использования внешнего нативного API, написанного, например, на C, было бы проблематичным — девайс просто не вывез бы оверхеда Java-машины (хотя есть и исключение — некоторые 2.5D игры используют собственный портальный рендерер по типу того, что был в Duke Nukem 3D).
В процессе существования J2ME любая компания могла внести предложение по необязательному расширению мобильной платформы: это называется JCP (Java Community Process), а спецификации в ней — JSR. Таким образом, появилось множество разных расширений: AWT, GLES, M3G, PIM, Bluetooth API и примерно к 2005 году, M3G появился на большинстве кнопочных телефонов. Но мы ведь не одним M3G ограничены! Давайте глянем, какие ещё GAPI существовали на мобилках.
Под J2ME телефоны существовало сразу три стандартизированных графических API для отрисовки трёхмерной графики, которые были описаны в виде JSR. Вероятно, были ещё какие-то особенные API для телефонов из Азии (где традиционно телефоны акцентировались на играх с крутой 3D-графикой), однако они не поддерживались на обычных устройствах и информации о них очень мало.
Рассмотрим основные GAPI, которые использовались на большинстве телефонов:
M3G JSR184: Mobile 3D Graphics — самый популярный графический API, который поддерживался на большинстве Java-телефонов. Известен своей открытостью, функционалом и довольно неплохой производительностью. Строго говоря, M3G — это не только Immediate API для отрисовки треугольников в духе OpenGL или D3D как мы привыкли, но и уже готовый граф сцены (а-ля Unity), формат моделей, система материалов, обработки столкновений, освещения и т. д. Был достаточно хорошо оптимизирован и имел низкий порог вхождения, благодаря чему стал стандартом на мобилках.
Mascot Capsule: графический движок, разработанный японской компанией Hi Corp. Использовался в основном на телефонах для азиатского рынка и выдавал очень хороший на момент выхода уровень графики. Во многих аспектах лучше, чем M3G, однако порог вхождения в него несколько выше. Несколько напоминает D3D/OpenGL. Поддерживался на Sony Ericsson и на Motorola.
OpenGL ES JSR239: поддерживался только на некоторых моделях и вышел достаточно поздно (в контексте Java-телефонов), из-за чего популярности на простых телефонах не получил, зато активно использовался в смартфонах (стоит взглянуть на игры для iPhone 2G для сравнения). Является самым «тяжелым» и функциональным графическим API из перечисленных. Что интересно: изначально Google полностью перенесли JSR239 на Android, дабы поспособствовать портированию игр с Java-телефонов на смартфоны с зеленым роботом. По первой это, скорее всего, даже помогало.
Большинство читателей застали игры, использующие именно платформу M3G, которая, помимо отрисовки 3D-графики, предоставляла ещё много самых разных фишек: например, уже упомянутый граф сцены с собственным форматом файлов. Поскольку плагины для импорта и экспорта в 3d max были доступны каждому, а сам M3G плохо располагает к тому, чтобы использовать собственные форматы файлов, вскоре на некоторые игры начали повально появляться моды. Пожалуй, одним из рекордсменов по числу модов является игра Left 2 Die, которую как только не переделывали: и под Half-Life, и под Quake, и под обычную Left 4 Dead закос делали… чего только не было
Другой игрой, на которую часто делали моды — это Comcraft, написанная студентом в начале 2010-х годов. Там, в основном, моды имели чисто характер ретекстура а-ля «новые типы блоков». Всё это было возможно благодаря наличию на Java-телефонах различных Zip-архиваторов, благодаря чему молодые моддеры могли перепаковывать ресурсы игр как им угодно.
Ну и третья легендарная игра, которую расковыряли через пару лет после выхода — это, конечно-же, Galaxy on Fire 2. Изначально, она была рассчитана для запуска на мощных устройствах уровня Symbian-смартфонов и телефонов Sony Ericsson. Однако умельцы урезали звуки, музыку и игра запускалась даже на s40!
А вот с глобальными модами, меняющими геймплей игры, не задалось. Несмотря на то, что программы на Java легко декомпилируются, большинство разработчиков обфусцировали код при публикации игры. По каким-то причинам никто не хотел копаться и деобфусцировать чужой код (хотя это явно гораздо проще, чем копаться в нативном коде в IDA Pro) и хотя бы попытаться сделать некоторое подобие «SDK для модов». Увы :(
Характеристики типичного кнопочного телефона тех лет были не особо впечатляющими:
Процессор: 104-200МГц, ARM926EJ-S ядро, иногда с поддержкой нативного выполнения Java-байткода. Без сопроцессора для чисел с плавающей точкой (FPU), без какого-либо видеоускорителя (за некоторыми исключениями) — вся нагрузка ложилась на процессор и иногда вспомогательный DSP.
ОЗУ: 8-16Мб SDRAM-памяти. Java-приложениям не доставалась вся память, а лишь её небольшой кусок, называемый кучей (Heap). Обычно размер Heap был от 800Кб до 2Мб. Умельцы даже патчили Java-машины некоторых телефонах, дабы выделить программам больше памяти. От размера кучи зависела работа тяжелый игр и программ: когда heap заканчивался, приложение падало в OutOfMemoryException.
Память: 10Мб-8Гб Flash-памяти.
Дисплей: CSTN, TN или AMOLED (редко) матрица с разрешением от 128x128, до 480x320 (возможно бывало и выше).
Очевидно, что на устройстве с такими характеристиками классические техники отрисовки 3D-графики не будут работать из-за малого количества памяти. Поэтому в ход шли некоторые интересные хаки, знакомые нам со времен PlayStation 1 и даже более старых консолей!
Начнём с сортировки примитивов. Представим, что у нас есть машинка и домик позади неё. Если мы отрисуем сначала машинку, а затем домик — то домик окажется перед машинкой, что полностью сломает эффект погружения и какую либо проекцию:
Пример такого эффекта можно найти в большинстве игр для PlayStation 1 — вот тут, например, лапки обезьяны видны поверх камня, чего быть не должно.
В современных приложениях, для сортировки геометрии по удаленности от наблюдателя используется screen-space техника Z-buffering, которая позволяет «дешево» отсекать невидимую глазу часть геометрии. Принцип её прост: по размерам окна приложения создаётся буфер, где каждый пиксель содержит информацию не о цветности, а о дальности фрагмента в этой конкретной точке. По итогу, во время отрисовки машинки, в Z-буфер будет записана глубина (дальность) конкретного фрагмента (участка геометрии), а когда будет нарисована домик, то видеочип сравнит значение глубины фрагмента машинки с машинкой и если значение глубины, хранящееся в буфере окажется меньше (или больше — зависит от реализации) прошлого значения — тогда часть машинки будет нарисована там, где нужно. Думаю, такое объяснение более чем понятное :)
Однако, Z-буфер требует драгоценную память (минимум ширина экрана * высота экрана * 2 — число байт в half float — т. е. 153 килобайта для экрана 240х320 как минимум) и наличие FPU для достаточной точности буфера глубины. Если же попробовать использовать обычные числа для этого, то вскоре мы столкнемся с проблемами точности, из-за чего будем видеть depth-fighting и от техники будет больше проблем, чем пользы.
В телефонах используется точно такая же техника, как и в PS1: сортировка отдельных полигонов. На PS1 с этим помогал отдельный векторный сопроцессор, который управлял трансформацией геометрии, освещением и мог эффективно сортировать треугольники, не нагружая основной процессор. А вот на телефонах этим занят основной процессор, вместе с растеризацией, обработкой игровой логики, звука и радиомодуля. Поэтому для корректной сортировки, вся отрисовка в GAPI на телефонах делится на «батчи», где программист отсылает набор нужных ему команд (отрисовать такую-то модельку с такой-то текстурой и такой-то трансформацией), а API затем уже трансформирует и сортирует вершины наиболее эффективным способом.
Второй интересный момент — это система координат. Как я уже говорил ранее, аппаратной поддержки float-чисел в телефонах зачастую не было. Однако j2me-машина и компилятор C (в те годы для прошивок чаще использовали ADS, чем GCC) предоставляли программную реализацию float-чисел, которая была ощутимо медленнее аппаратного FPU. Поэтому даже такие операции, как вычисление синуса и косинуса могли стать относительно тяжелыми для телефона, чего уж говорить о перемножении матриц.
Для обхода этого ограничения использовалось две техники: fixed-point числа, где число с дробной частью представлено в виде обычного целого чисел, с которым умеет работать процессор (M3G) и обычные целые числа, которые представляют нормализованные числа 0.0… 1.0 (Mascot Capsule). Оба способа имеют ограниченную точность и в некоторых моментах могут давать артефакты, но здесь всё сильно зависит от самой игры. Например, из-за низкой точности при движении персонажа мир может «трясти».
И третий момент — это текстурирование и освещение. Сама концепция идентична той, которая используется в большинстве современных игр, однако из неё исключается важный этап: перспективно-корректное наложение текстур. Если говорить простыми словами, то при линейном наложении текстуры на геометрию «как есть», если подойти к модельке домика слишком близко — мы увидим искажения текстуры на его поверхности. Другой пример — шахматная доска, которая при приближении будет не идеально ровной, а если подойти совсем близко — то мы получим серьезные артефакты, которые полностью исказят визуальное представление. Для перспективной коррекции нужен тоже нужен FPU: это не бесплатная операция, поэтому от неё обычно отказываются (исключение — M3G), потому игры под J2ME иногда выглядят весьма странно:
Один из «универсальных» советов: желательно на этапе проектирования уровня и геймплея не ставить слишком близко друг к другу разные объекты и не давать камере игрока «смотреть» слишком близко на большие объекты.
В процессе подготовки статьи, я декомпилировал и изучил несколько 2.5D-игр из нулевых а-ля Wolfenstein 3D. Многие из них для лучшей производительности использовали пакет Nokia UI с DirectGraphics, который предоставлял некоторые плюшки для 2D-игр и возможность блиттинга произвольных изображений напрямую в экранный буфер. Там разработчики на что только не шли: и классический рейкастинг, и портальный рендерер — и всё это работало довольно шустро :)
Но вы ведь сюда не учебник по «матану» и не OpenGL Red Book пришли читать, верно? Поэтому давайте напишем свою 3D-бродилку под Java-телефоны с нуля! Да, это не совсем игра, но даст явное представление о том, как писали игры в те годы.
А напишем мы не просто что-то совсем примитивное, а основу для 3D-шутера от первого лица! Да, вот так сразу :) Конечно, не уровень Crysis, графика из 90-х, но для кнопочных девайсов вполне неплохо. Более того, эту игрушку я написал за полтора дня: основной рендерер за полдня и ещё какую-то базовую часть геймплея за день.
В качестве графического API я решил использовать Mascot Capsule. Материала о нём в сети относительно мало и для многих вообще остается загадкой, как он работает «под капотом». Про M3G писал немного aNNiMON, да и некоторая информация в сети есть, а про JSR239 особо из-за плохой поддержки на реальных девайсах. Тут важно понимать, что M3G и Mascot Capsule — это не DX11 и не Vulkan, порог вхождения у них достаточно низкий и понять их довольно легко, если иметь базовые представления о том, как работает 3D-графика. Поэтому создаём проект, мидлет (приложение в терминологии J2ME) и погнали!
Начинаем, конечно же, с инициализации контекста.
В J2ME принято наследоваться от GameCanvas и реализовывать игровой цикл именно в нём. Для начала работы с MascotCapsule и M3G достаточно лишь создать объект Graphics3D (в случае M3G — получить ссылку на синглтон), а также выделить необходимые ресурсы — в нашем случае, это матрицы, которые здесь называются AffineTrans.
Самый примитивный игровой цикл будет выглядеть так. Сначала мы заливаем экран цветом для предотвращения эффекта Hall of mirrors и биндим объект Graphics к Mascot Capsule, затем рисуем сцену и освобождаем контекст, а потом вызываем flushGraphics для вывода изображения на экран:
Результат: синий экран.
Давайте что-нибудь нарисуем. Mascot Capsule может использовать как собственный формат моделей mbac и формат анимаций с ActionTable, так и произвольную геометрию. Юзать готовые форматы слишком просто, да и накатывать 3ds Max с плагинами не очень хочется, поэтому мы будем генерировать геометрию сами. Начнем с отрисовки треугольника и трансформации геометрии.
Effect3D — это материал в терминологии Mascot Capsule. Данный объект позволяет задавать визуальные параметры для геометрии: освещение и источник света, Toon-shading для придания эффекта мультяшности, настройки альфа-блендинга и некоторых других эффектов.
Далее идёт трансформация геометрии: процесс преобразования треугольников из локальной системы координат в мировую, экранную и затем уже Clip-space.
Где affineMatrix — основная матрица, хранящая в себе результат перемножения viewProj матриц, а affineRotationY и affineTranslate — матрицы трансформации сначала для камеры, а затем уже для преобразования модели в мировые координаты. При этом проекция — тоже часть AffineTrans. Вот такая вот путаница.
В FOV (512) задается значение в радианах, где 0 — это 0, 4096 — это 3.14 * 2 (360 градусов). Это же касается и углов в поворотах.
Обратите внимание — матрицы имеют размерность 3x3, а не 4x4, как это принято в «больших» системах. translate здесь нет — только lookAt.
Идём дальше — к фактической отрисовке треугольников. Геометрия может иметь текстурные координаты, цвета и нормали. Формат вершины можно задавать динамически — необязательно передавать сразу все аттрибуты вершин. Из-за особенностей Mascot Capsule, геометрия не будет отрисована, если не переданы текстурные координаты или цвет.
UV-координаты указываются в абсолютных координатах текстуры. т. е. не 0..255, как на 3dfx Voodoo, например, а 0… ширина текстуры и 0… высота текстуры. Учитывая, что класс текстуры не позволяет даже её размер узнать… решение так себе.
Результат:
Добавляем второй треугольник, дабы нарисовать квад:
На этом, половина рендерера написана. Я не шучу :)
Теперь генерируем геометрию для кубика. Для наглядности я написал простенький класс для генерации геометрии на лету. Отдельный формат для моделей нам пока не нужен, поэтому я «запеку» геометрию в отдельный массив вершин.
Результат:
Текстурированные кубики рисовать умеем, камера у нас тоже есть: уже можно реализовать бродилку :)
Уровни делать мы будем… прямо в IDE. Каким образом? Уровень будет храниться классическим для подобных игр способом: сетка x на x, где каждое число указывает ID-текстуры (и в оставшихся битах можно разместить какие-нибудь атрибуты), где 0 — блок отсутствует. Все блоки предполагаются твердыми.
З.Ы На Пикабу нет тега с кодом, поэтому пришлось вставлять код в виде скринов. А поскольку на кол-во медиа-элементов в посте есть ограничение в 25 блоков, пришлось остальной код кастрировать :(
Отрисовка подобного уровня в самом простом случае очень простая: мы просто проходимся по всей сетке и рисуем каждый куб, если ему назначена текстура. Однако, это не очень эффективный метод: в случае больших уровней с множеством перекрытых комнат, на GAPI ложится лишняя работа по сортировке геометрии, а также страдает филлрейт. Лучше всего разделить такие уровни на комнаты и рисовать только видимые участки уровня.
Результат:
Теперь нам необходимо реализовать возможность ходьбы по уровню. Для этого мы будем поворачивать камеру по координате Y при нажатии кнопок вправо и влево, а для движения вперед и назад вычислять forward-вектор, указывающий на направление персонажа относительно угла поворота, который представляет из себя синус и косинус угла поворота персонажа в радианах.
Напомню, что углы хранятся в виде 4096 = 360гр. = 3.14 * 2.
Теперь наш персонаж умеет ходить!
Однако без пола и потолка игра выглядит не особо привлекательно. Самое время их добавить! Настоящий вертикальный потолок реализовать будет затруднительно из-за отсутствия коррекции текстур — пол будет постоянно «плыть», что не очень красиво. Поэтому мы воспользуется дедовскими методами и закрасим нижнюю часть экрана серым, а потолок сделаем фоновой картинкой! Таким образом, каким бы большим не был уровень, в центре экрана всегда будет какая-то стенка, из-за чего мы не сломаем нашу перспективную проекцию!
Смешивать Graphics и Graphics3D одновременно нельзя — сильно падает производительность. А вот использовать Graphics для отрисовки интерфейса поверх Graphics3D после отрисовки кадра — можно! Суть хака простая: рисуем с ортографической (параллельной) матрицей половинку экрана с текстурой неба, а вторую половинку — просто серый квад. Всё очень легко и просто!
Рисуем оружие поверх экрана и получаем некое подобие 3D-шутера.
Game.current.renderer.getGraphics().drawImage(weapon, Game.current.renderer.getWidth() - weapon.getWidth() + (int)viewBobFactor, Game.current.renderer.getHeight() - weapon.getHeight(), Graphics.LEFT | Graphics.TOP);
Результат:
Обратите внимание на все артефакты, о которых я рассказывал в разделе оптимизации игр. И текстуры плывут, и мир дребезжит — всё это результаты оптимизаций со стороны разработчиков GAPI. Зато работает шустро!
В любом шутере нужна обработка столкновений. Даже в космическом скроллшутере :)
Тут я чуток наговнокодил, поскольку нет необходимости проверять столкновение игрока с вообще всеми кубами на сцене: достаточно сделать выборку из ближайших восьми блоков, но для наглядности оставил так.
Принцип прост: обычная проверка AABB, весь резолвинг — это откидывание игрока обратно, если после последнего движения он «врезался в стену».
Можно считать, что основа игры уже готова.
Давайте посмотрим. Запускаем бродилку в эмуляторе:
Но как насчет реального девайса? Для тестов у меня есть SE W200i, W610i и J10i2!
Все поддерживают Mascot Capsule, так что с тестами проблем не будет. Ниже тест на W200i, на остальных девайсах в моем первом комменте - Пикабу не даёт загрузить слишком много картинок/видео в один пост :(
Вот как-то так в нулевых и писали 3D-игры для кнопочных телефонов. Да, мы практически не затронули тему 3D-игр на Symbian-смартфонах (ранее я писал статью о разработке игры под WinMobile), но обсудили множество тонкостей и написали собственный Proof of Concept бродилки для подобных Java-мобилок. Исходным кодом бродилки я делюсь, кто угодно может использовать его как основу для своей игры или что-то типа такого. По крайней мере, видел пару лет назад несколько Java-игр, которые кто-то всё ещё делает.
Пишите свой опыт с Java-играми в комментариях :)
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады!
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Друзья! Многие ли из вас помнят такой телефон, как Nokia N-Gage? В начале нулевых финская компания сделала смелую попытку ворваться на рынок игровых консолей, создав устройство, которое сочетало в себе сразу две функции: полноценный смартфон на базе аппаратной платформы WD2 с Symbian на борту и игровая консоль с собственными картриджами! Год назад читатель подарил мне N-Gage QD с некоторыми аппаратными проблемами, которую я успешно оживил и подготовил подробную статью, в которой мы: узнаем историю появления N-Gage на свет и на чём он работал «под капотом», отремонтируем устройство и узнаем о самых частых аппаратных «болячках» смартфонов Nokia на платформе WD2, а также посмотрим на местную игровую библиотеку подробнее и выясним особенности разработки игр под Symbian! Интересно? Тогда добро пожаловать под кат!
Пожалуй, в истории мобильного подразделения Nokia, N-Gage один из самых желанных и неоднозначных устройств, когда либо разработанных компанией. Девайс прошёл долгий путь от смартфона, который ругали чуть ли не все, до легендарного устройства, которое ценится некоторыми людьми и сейчас.
По сути, N-Gage является уникальным смартфоном. За всё время существования мобильного рынка, по настоящему игровых телефонов почти и не выходило: можно вспомнить телефоны Sony Ericsson с геймпадом EGB-30,Xperia Play, японские и корейские телефоны, о которых мало кто слышал, да и китайские реплики Nokia с эмулятором NES на борту.
Я писал материал о Xperia Play год назад
В начале нулевых, рынок мобильных игр начинал активно развиваться. С ростом мощностей мобильных девайсов и появлением цветных дисплеев, стали появляться самые разные платформы для запуска мобильных приложений и продажи игр через операторские сети. Например, довольно большим успехом пользовалась перспективная платформа Mophun (Sony Ericsson T310, T610), которая использовала собственный платформо-независимый байткод. Помимо этого, в платформе были уже готовые библиотеки для упрощения разработки игр: вывод 2D спрайтов, 3D графики (программный рендеринг), звука и обработка ввода. Нельзя также не вспомнить о Qualcomm BREW — который использовался во многих CDMA-телефонах в США и была по настоящему нативной, позволяя использовать все ресурсы телефона. Но самой популярной стала, конечно же, J2ME, которая предустанавливалась на большинство телефонов до ~2014 года.
Sony Ericsson T610 - один из девайсов, поддерживающих Mophun
Само собой Nokia не могли упустить момент и не попытаться занять нишу на мобильном рынке игр. У Nokia было две основные платформы: S40, используемая в кнопочных телефонах и S60, платформа основанная на Symbian, которая использовалась в смартфонах компании. Уже в 2003 году, в платформах S40 и S60 была полноценная поддержка J2ME игр и Java показывала себя как достаточно перспективная платформа. Nokia даже реализовали свои собственные расширения для J2ME, дабы игры могли использовать больше возможностей устройства, чем предоставляет MIDP. В целом, телефоны Nokia были очень популярными, благодаря чему почти все J2ME игры имели собственную версию под S40 (а иногда и более навороченные под S60).
N-Gage, который должен был объединить телефон и игровую консоль, был анонсирован ещё в ноябре 2002 года, однако вышел в свет 7 октября 2003 года.
Первая версия N-Gage
Однако N-Gage был отнюдь не первым устройством в подобном дизайне. Его предком принято считать Nokia 3300 — смартфон, который в первую очередь был ориентирован для использования в качестве мультимедийного устройства и прослушивания музыки. Тем не менее, устройство тоже поддерживало J2ME и на нём вполне можно было проходить Symbian-годноту из нулевых.
N-Gage был встречен весьма неоднозначно. В устройстве было достаточно много как аппаратных, так и программных недоработок, которые вызывали недовольство среди пользователей. Первая и пожалуй самая главная для игровой консоли — отсутствие возможности горячей смены картриджей с играми. Сами игровые картриджи были реализованы в виде обычных MMC-карт памяти, однако, судя по всему в S60 не было поддержки «горячей» замены карт памяти как таковой, из-за чего для смены игры необходимо было сначала достать аккумулятор, заменить флэшку с игрой, установить аккумулятор, включить устройство и дождаться его загрузки (секунд 15) и только потом уже начинать играть. А учитывая, что это был телефон, то довольно длительное пребывание вне сети устраивало далеко не всех пользователей.
Картриджи были проблемой и для жителей отдаленных регионов. В России, насколько мне известно, картриджи можно было купить только в Москве и СПБ, хотя возможно и ещё в каких-то больших городах. Но вот, например, у меня, жителя Ейска, едва ли была возможность купить картридж «физически» — разве что только под заказ. Другое дело Java игры, которые весили по 50-100 килобайт в те годы и без проблем скачивались даже через мобильный интернет. Впрочем, судя по всему, никакого особого DRM в N-Gage играх не было и после того, как энтузиасты научились сливать игры с MMC-карточек — на N-Gage начало процветать пиратство.
Даже с точки зрения звонков у девайса были свои нарекания. Конструктивно инженеры Nokia решили расположить слуховой динамик не с лицевой части, а с боковой. Из-за этого для разговоров приходилось переворачивать телефон боком. Выглядело это весьма необычно для прохожих, незнакомых с N-Gage. :)
Тем не менее, в устройстве были и революционные решения: вспомнить хотя-бы N-Gage Arena, который объединял мобильных игроков в одну сеть с друзьями, таблицами рекордов и т. д.
Чуть меньше чем через год, в мае 2004 года вышла N-Gage QD: исправленная и доработанная версия N-Gage, в которой заметно изменили дизайн, добавили поддержку замены картриджей без выключения девайса и добавили слуховой динамик на переднюю часть корпуса. Именно эта версия N-Gage стала популярной и её чаще всего можно найти на онлайн-барахолках.
И хотя N-Gage ругали за недоработки, мобильным игрокам она полюбилась за высокий уровень игр для телефонов тех лет: графика была гораздо лучше чем на GBA и была близка по уровню к PS1, геймплей разнообразнее, чем в Java-версиях, да и сами игры имели довольно большой полноценный сюжет. Это был действительно замах на уровень таких мастодонтов, как Nintendo! Приятным бонусом была полноценная поддержка Java-игр, благодаря чему на телефоне можно было гораздо удобнее проходить уже вышедшие игры для MIDP 1.0, даже если вся библиотека игр N-Gage уже была пройдена!
Не менее интересно девайс устроен и «под капотом». Как я уже говорил выше, N-Gage был построен на базе зарекомендовавшей себя платформы Nokia WD2, которая использовалась в смартфонах 3650, 3300, 3230, 6600 и.т.д. Многие годы смартфоны Nokia работали на базе чипсетов OMAP, в случае WD2 это скорее всего (не точно, есть вероятность что UPP собственной разработки — как и в случае с S40) были специализированные версии OMAP с «перевернутыми» регистрами для предотвращения портирования Linux на устройства Nokia, поскольку OMAP были доступны рядовым энтузиастам.
Характеристики N-Gage были следующими:
Процессор: ARMv4 ядро на частоте 104МГц, что было стандартом для многих телефонов в те годы (например Siemens на платформе S-Gold работали на той же частоте, а E-Gold — вдвое меньшей). Скорее всего, процессор собственной разработки Nokia.
Память: 16Мб SDRAM ОЗУ и 16Мб ПЗУ, раздельно. Иногда флэш-память изнашивалась и в СЦ её нередко меняли. Мои читатели, которые в нулевых работали в СЦ наверняка вспомнят о "бутербродах" на некоторых телефонах :)
Дисплей: 2.1" матрица с разрешением 176x208 и глубиной цвета 12-бит (4096 цветов), выполненная по технологии CSTN (хотя возможно и TN). Для тех лет, диагональ дисплея и его разрешение были оптимальными, круче были только коммуникаторы с 2.4" дисплеями 240x320. Фактически все (или почти все) смартфоны Nokia на Symbian тех лет использовали одну и ту же матрицу, с чуть разной длинной шлейфа (просто где-то её переворачивали вверх-тормашками, как на N70).
ОС: Symbian 6.1
Аудиовыход: 2.5мм джек (моно)
Как видите, ни о каком GPU и речи не шло. Вся отрисовка полагалась исключительно на процессор и результат того, что даже такие крутые 3D-игры как Tony Hawks и Tomb Raider идут на N-Gage — заслуга программистов, которые оптимизировали свои рендереры для работы на 104МГц ядре! А ведь некоторые телефоны тех лет (например, Motorola) использовали отдельные 2D GPU для ускорения отрисовки интерфейса и работы с камерой — ATI Imageon!
Благодаря тому, что девайс строился на смартфонной платформе, на нем можно было не только играть, но и слушать музыку, а также смотреть видео и серфить интернет. Весьма и весьма для тех лет!
Даже спустя несколько лет после выхода телефон N-Gage, сам бренд и платформа N-Gage Arena продолжила существование на флагманских смартфонах Symbian, которые уже не имели такой игровой дизайн. Одним из N-Gage 2.0 девайсов была легендарная Nokia N95, которая в плане игровой направленности была гораздо круче, поскольку в устройстве использовался GPU PowerVR MBX Lite. Да, точно такой же, как и в iPhone 2G!
Конечно же, рано или поздно я и сам хотел обзавестись собственной N-Gage, с чем мне помог мой читатель, причём всё как я люблю: девайс был полурабочим и требовал некоторого ремонта. Более года назад мне написал подписчик на DTF с никнеймом «Improved white bonkle» и предложил заслать N-Gage QD и ещё одну плату под ремонт с некоторыми аппаратными проблемами: первая плата висела на белом экране, а вторая просто висела на логотипе Nokia без подсветки экрана. Помимо N-Gage, читатель положил «толстую» зарядку и флэшку на 1Гб, за что ему огромное спасибо.
Читатель рассказывал, что девайс он покупал у некого коллекционера «гаг» в России и довольно много играл на ней в эксклюзивные игры для данной платформы. После поломки устройства, девайс лежал у него какое-то время, пока он не заметил мои статьи и не решил заслать устройство под ремонт в хорошие руки. :)
Ну что-ж, давайте оживим девайс!
Я не зря отметил то, что девайс подарили мне более года назад. Мне удалось сразу продиагностировать N-Gage и обнаружить неисправности, однако фактически отремонтировать устройство у меня не вышло: в то время я откровенно «бомжевал» и у меня даже более-менее адекватной паяльной станции не было. Дабы было понятно: тогда я перепаял коннектор АКБ, сейчас я восстановил BTEMP. На данный момент мне материально активно помогаете вы, мои читатели, поэтому за год я смог обустроить небольшое рабочее место, пригодное для проведения большинства ремонтных работ.
Разбирается девайс очень просто, как и большинство телефонов Nokia тех лет: снимается передняя часть корпуса (панелька), откручиваются винты, снимается пластиковая часть с клавиатурой, дисплей и затем плата из задней части корпуса. Кстати, панельки очень часто любили менять для придания свежего вида устройству: эдакие скины тех лет. :)
Обратите внимание на то, что некоторые детские болячки пользователь и сам мог отремонтировать. Не работает разъём ЗУ, наушники, вибромотор или динамик? Пошёл, купил за 10 рублей на ближайшем радиорынке и сам поменял! Вот уж настоящий right to repair. :)
Визуально осмотрев плату, я пришёл к выводу, что плата скорее всего не копанная китайцами: компаунд UPP'а (процессор) и Mjoelner (радиотракт) был не тронут, флэша с виду тоже в норме, все элементы стояли ровно. Однако около коннектора аккумулятора, я обнаружил следы канифоли: кто-то явно вручную перепаивал коннектор АКБ. Спросив у читателя, я получил утвердительный ответ: он действительно пытался перепаять коннектор аккумулятора с помощью советского паяльника.
Но почему же тогда устройство виснет на заставке Nokia без подсветки? Давайте взглянем на схему:
У коннектора АКБ три контакта: плюс питания, масса и BSI, который уходит напрямую в UEM (контроллер питания). Смартфоны Nokia на платформе WD2 были очень капризны к сопротивлению на BSI и UEM отказывался давать разрешение на старт при установке несовместимого аккумулятора. Казалось бы, BL-4C, BL-5C и BL-5CB по размерам почти одинаковые, но имеют разное сопротивление на BSI.
Однако даже при установке совместимого АКБ, устройство отказывалось включаться. Вывод простой: линия BSI находится в обрыве. Первым делом я сдул коннектор АКБ, перепаял его и девайс наконец-то нормально включился… ненадолго.
Произошло падение в «белый экран», как и вторая плата. Причиной этому стала «стекляшка» рядом — токовый датчик LM3820: вероятно, в ходе ремонта коннектора, читатель умудрился неравномерно поплавить шары под стекляхой, из-за чего контакт нарушился. Стекляха среагировала на прогрев с флюсом и девайс снова включился…
Коннектор АКБ уже был, в скажем так, не идеальном состоянии, поэтому для точного исключения влияния коннектора я залудил контакты. Я люблю, когда платы не уколхожены, а весь ремонт близок к заводскому - поэтому коннектор "за кадром" будет заменен на норм.
Но не заряжался. :( При попытке зарядить девайс, система показывала сообщение «не заряжается» и потребление падало в ноль. Ремонт я проводил ещё тогда, когда у меня и станции нормальной не было, из-за чего я умудрился сколоть NTC-термистор прямо под коннектором аккумулятора (обычно он расположен либо с обратной стороны коннектора АКБ, либо с обратной стороны платы), прямо с пятачками.
Я знаю, что иногда меня читают опытные мастера с многолетним опытом, которые уже тянутся написать «Рукожоп! Мы в нулевых в ещё более тяжелых условиях умудрялись мобилки ремонтировать, а ты вон люкей себе не смог купить!». Но я лично считаю, что если косяк нормально исправлен, даже через год — то это не косяк. :) Поэтому лезем в схему и смотрим, куда у нас уходит BTEMP:
BTEMP идёт в UEM через обвязку в виде конденсатора C230, который расположен с обратной стороны платы, около КП. Найти его можно в Component finder'e, который можно найти в самом конце почти любой схемы на телефоны Nokia:
Подпаиваемся, включаем и девайс и… всё снова работает, в том числе и зарядка. :)
На этом ремонт устройства закончен.
Отдельное слово хотелось бы сказать о дисплеях: для N-Gage обычно их принято считать достаточно редкими. Однако есть нюанс: практически все смартфоны Nokia на платформе WD2 (и пару на BB5 — например, N70) использовали одну и ту же матрицу с параллельным интерфейсом. Различия были лишь в форме шлейфа. В N70, например, этот дисплей ставился «перевернутым», однако длины шлейфа не хватало для того, чтобы поставить дисплей в N-Gage. Тем не менее, теоретически можно попробовать поставить куда менее редкий дисплей от 6630.
В процессе подготовки материала и изучения схемы, я вывел небольшой мануал по базовой диагностике N-Gage и любого телефона Nokia на платформе WD2:
Белый экран, есть звук включения и реакция кнопок. Чаще всего виноват EMIF-фильтр COM01F2: хрупкая «стекляха», которая повреждается при попадании влаги или падении устройства. Реже — обрыв сигнальных линий дисплея до коннектора дисплея, а то и отвал омапа.
Белый экран, ноль реакции: из-за бага в первых версиях прошивки, при полном заполнении внутренней памяти девайс виснул на белом экране. Реже — проблемы с питанием на OMAP, отвал процессора. Из-за попадания воды может пострадать токовый датчик.
Нет подсветки, лого Nokia: обрыв BSI или неподходящий аккумулятор.
Нет реакции на кнопку включения: замерить напряжение на входе кнопки включения (должно быть близко к VBAT), дальше смотреть в сторону UEM и его обвязки. На некоторых смартфонах Nokia (уже чуть более поздней платформы — например N70) кнопка включения идёт через EMIF-фильтр вместе с клавиатурой, из-за чего убитая стекляха может стать причиной отсутствия напряжения на PWRON.
Нет подсветки, есть изображение: проверить напряжение на C130 — если там есть 13.3В, значит бустер работает нормально. Если напряжение более 13В, то нет фидбека (т. е. катода с подсветки на самом дисплее), необходимо проверить обрыв на коннекторе дисплея. Проверить драйвер подсветки D130, при необходимости заменить (подходит с многих Nokia тех лет, иногда кустарно заменяют на драйверы подсветки с других телефонов).
Как я уже говорил выше, читатель задарил мне ещё и флэшку, на которой было установлено куча игр: как портов игр с других платформ, так и нативных «дампов» с картриджей, а также эмуляторов. Было ли во что поиграть на N-Gage? Давайте узнаем:
Именно на платформу N-Gage вышло не так уж и много игр: всего около 50. Однако среди них всё равно найдется во что поиграть: многие известные издатели решили рискнуть и разработать игры по собственным вселенным для N-Gage. В каких-то случаях это были порты с других платформ (например, Asphalt 2 с PSP, хотя это не совсем верно, поскольку Asphalt изначально мобильная игра), в каких-то уникальные игры, дополняющие ЛОР той или иной вселенной (например, TES Travellers). Не забываем про игры для обычных Symbian-смартфонов, порты и J2ME игры: таким образом, библиотека получается весьма и весьма обширной!
Ну и не стоит забывать и о эмуляторах! С играми для NES и SMD, игровой потенциал N-Gage увеличивается в разы. Ещё бы дисплей был чуть-чуть побольше и хотя-бы классический TN, а не немного блеклый CSTN и было бы вообще идеально.
Помимо игр, на многих Symbian-смартфонах стояли некоторые приложения, которые были must-have для тех лет: например, файловый менеджер X-Plore с диспетчером задач, а также сторонний плеер LCG JukeBox (нормальный плеер с плейлистами появился только в Symbian 8). Иногда диспетчер задач не спасал и девайс приходилось перезагружать.
Давайте же глянем на игры подробнее. Как я уже говорил ранее, все 3D-игры были софтварными: т. е. вся трансформация, обработка освещения и растеризация треугольников с текстурированием и перспективной коррекцией (если была) происходила исключительно на ЦПУ. Поскольку FPU в процессоре не было, использовались fixed-point числа.
Переходим к гоночкам. Тут у нас аж две части Asphalt, ещё тогда, когда серия не стала донатным «фритуплеем». Asphalt 2 весьма занимательная игра с оптимальной производительностью, кое-где конечно бывают просадки, но в целом более чем играбельно. Как это игралось в нулевых? Сравните скриншоты с j2me-версией, которая напоминает гоночные 2.5D игры с SMD и NES (при этом, в ней есть 3D-элементы и игра использует M3G) и версию для Symbian/PSP/NDS, думаю тут всё итак будет понятно:
Однако большинство читателей наверняка интересуют игры в известных вселенных. Взять, например, полноценный порт первой Tomb Raider. Насколько я понимаю, оригинальная TR славилась тем, что изначально разрабатывалась с расчетом на легкое портирование между разными платформами (да чего уж там говорить, игру отреверсили и переписали с нуля как минимум два раза!). Первый Pentium неплохо тянул TR в софтваре, а N-Gage справляется явно не хуже:
Не забываем и про 2D! В некоторых телефонах Motorola, Siemens и Samsung использовались внешние 2D видеоускорители ATI Imageon. В их задачи входила обработка изображения с камеры, функции контроллера дисплея, а также аппаратное ускорение некоторых 2D-операцией: блиттинг, отрисовка линий, прямоугольников и возможно ещё каких-то примитивов. Однако N-Gage, даже без помощи аппаратного блиттинга был способен выдавать приемлемый FPS и уровень графики в 2D играх. Например, в Sonic, где у нас есть параллаксовые фоны с покадровой анимацией:
Ну и нельзя не вспомнить про уникальную игру на N-Gage: TES Travels Shadowkey, которая была разработана специально для N-Gage и поиграть в неё можно только на оригинальном N-Gage, пропатченном Symbian-девайсе или EKA2L1. Вообще, это полноценная RPG от первого лица, расширяющая лор игры в Хаммерфелле и как минимум из-за этого она достойна к ознакомлению. Игра стилистически заметно напоминает Morrowind, графика близка по уровню к PS2. FPS, конечно, колеблется в районе 10, из-за чего игру можно считать пошаговой… но тем не менее, полноценная FPS RPG на мобилках — это многого стоит!
Есть также примеры отличной графики и… очень низкой производительности. Если в TES ещё можно попробовать поиграть в пошаговой манере, то как насчет шутера от первого лица в 5-6 кадров? Речь, конечно же, о Call of Duty. Игра получилась очень красочной (с трушными полигональными ландшафтами и кучей пропов), но крайне медленно работало на желез N-Gage.
С разработкой своих приложений под N-Gage дела обстоят сложно. С одной стороны, в Symbian 6.1 ещё не было сертификатов, необходимости делать джейлбрейк и менять дату в устройстве. С другой стороны, для разработки под N-Gage требуется установка оригинального SDK для S60: приложения скомпилированные с помощью более свежих версий SDK работать не будут! Ни о каком Qt и речи не идёт и даже Carbide окажется слишком свежим для нашего устройства.
Оригинальный SDK можно скачать здесь.
Кроме того, SDK использует весьма своеобразную систему сборки, написанную на Perl, которая поддерживает только древнюю версию ActiveState Perl 5.6.1 аж от 2001 года и не работает на Windows 7/8/10! С отладкой на реальном устройстве тоже возникнут проблемы: для этого необходим относительно редкий FBus-кабель (который устанавливается вместо аккумулятора и подключается к ПК через RS232-преобразователь), либо использование программатора а-ля UFS HWK. Хотите отлаживать игру на ПК? Тут есть симулятор, прямо как при разработке под iOS: однако этих симуляторов целых два (для Visual C++ 98 и CodeWarrior) и с каждым возникают проблемы при сборке (то линкер крашнется, то разработчики забудут положить часть реализации системных либ для разных симуляторов в разные версии SDK). Хотите разрабатывать игры? С симулятором об этом можно забыть — отрисовка слишком медленная. Готовьтесь писать кроссплатформенный рантайм, который под Windows будет использовать GDI, а под Symbian нативное API для графики! Программа крашнулась на реальном устройстве и инструментов для отладки у вас нет? Ничего подробнее «приложение остановлено» вы не получите!
Ну а вишенкой на торте станет весьма своеобразный сабсет C++, который используется для написания приложений. Сама система полностью построена по принципам ООП, однако ради уменьшения размера выходного кода была полностью убрана поддержка исключений: предполагается, что программист будет вручную помещать объекты на стек (для Stack unwinding'а), полностью убран RAII как концепция с введением NewL и ConstructL, где L — означает Leave (т.е исключение может выбросить только функция-фабрика, а не фактический конструктор) и кодов ошибок, а также полное отсутствие поддержки глобальных переменных (но есть частичная поддержка констант — из преинициализированных данных, судя по всему, поддерживаются только строковые литералы). Да, никакого .data и .bss, что серьёзно усложняет портирование существующих приложений под Symbian. Спасибо что есть пакет для совместимости с POSIX и реализовали часть stdlib.
Почему нет глобальных переменных?
Приложения в Symbian — это, по сути, dll-библиотеки, с которыми общается UI-фреймворк. Ради сохранения памяти, в Symbian решили сделать все загружаемые библиотеки доступными для любых процессов в системе. Поэтому Symbian и не позволяет библиотекам иметь собственную статическую память, зато можно свободно использовать динамический аллокатор. У exe таких ограничений нет, однако там свои сложности при взаимодействии с системным API. Тем не менее, с Quake поступили своеобразным грязным хаком: Приложение в меню лишь «значок», который фактически запускает соответствующий exe-файл на флэшке!
Дело улучшает кастомный SDK для хоумбрю от энтузиаста из Германии. Он портировал SDL2, Lua и адаптировал тулчейн для работы в современных системах. Но лично для меня это не трушно — нужно использовать оригинальный SDK. :)
В целом — это одно из объяснений того, почему N-Gage стала относительно провальной как платформа для игр. Конечно в своё время был жив форум разработчиков Nokia, где были как официальные сэмплы от Nokia, так и мануалы от других разработчиков, однако базовые косяки при проектировании архитектуры платформы портили всю малину. Чего уж стоит обратная совместимость: для быстрой отрисовки графики предполагалось рисовать картинку в обход графического сервера, напрямую получая указатель на фреймбуфер. В начале фреймбуфера лежала структура с описанием разных пиксельформатов, которые были отнюдь нестандартными: 12-битный, 16-битный, 18-битный. Из-за этого, игры для старых версий Symbian могли давать артефакты на 9.x, например.
Написание полноценной, пусть и небольшой игры — материал для отдельной статьи. Есть идея написать кроссплатформенную игрушку, которая работала под разными платформами кнопочных девайсов: от Motorola ROKR на Linux и китайских клонах Nokia (E71 все помнят?), до эльфов на Siemens'ах и Motorola E398. Таким образом, мы рассмотрим особенности разработки под каждую платформу (например, на моторах был 2D-ускоритель ATI Imageon).
Вот таким был легендарный N-Gage. Девайс, конечно, действительно весьма своеобразный. С одной стороны это гениальное решение: взять смартфонную платформу и сделать на её базе игровую консоль. С другой стороны, с разработкой игр под N-Gage, или, например, прямыми функциями телефона были свои проблемы. Девайс получился немного сыроватым, но лично я считаю, что концепция имеет право на жизнь, но пока ни у кого не получилось сделать действительно массовый девайс. По моему мнению, нужно сохранить как можно больше N-Gage живыми. Сложно даже представить сколько потенциально оживляемых плат уехало в чермет…
А вам понравился N-Gage?
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады!
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!
Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.
Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:
1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.
2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти.
Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).
3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:
Где по итогу:
.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.
И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.
А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:
Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.
Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.
Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.
Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.
В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!
Однако в таком подходе есть несколько серьезных ограничений:
Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).
Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).
Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!
Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!
Заголовок нашего бинарника будет выглядеть вот так:
Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.
Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.
Собираем нашу программу:
xtensa-esp32-elf-cc.exe test.c -fno-pic -nostdlib -nostartfiles -Wl,--section-start=.text=0x0
xtensa-esp32-elf-objcopy.exe --only-section=.text --output-target binary a.out run.bin
-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld).
objcopy скопирует из полученного ELF только необходимую нам секцию .text.
Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:
Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.
По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё!
Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:
Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.
Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.
Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x6000,
phy_init, data, phy, 0xf000, 0x1000,
factory, app, factory, 0x10000, 1M,
executable, data, undefined, 0x110000, 0x10000
Для заливки программы можно использовать соответствующее Partition API, либо parttool.py:
parttool.py --port "COM41" write_partition --partition-name=executable --input "run.bin"
Переходим к загрузчику программы:
Прошиваем ESP32:
И смотрим результат:
SysCall 25
SysCall 35
SysCall 15
Всё работает!
Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.
Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :)
И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Да-да, у меня самой первой, была та самая знаменитая Nokia 8110!
Чем она знаменита?
Об этом ниже.
Nokia 8110
А вот чем:
Узнаете кадры?
Это классический продакт-плейсмент.
Продакт-плейсмент – это контент, созданный по заказу рекламодателя в обмен на вознаграждение. В таких материалах могут напрямую использоваться товары третьего лица, его рекламное сообщение или бренд.
Так вот Nokia решила запиарить свой новый телефон, вставив его в кучу кадров в ставший культовым фильм "Матрица" 1999 года, братьев, позже сестёр Вачовски.
У меня телефон появился в 2001 году. Выдали на работе.
И телефон над сказать так себе. У меня к нему был почему то усиленный аккумулятор, который торчал огромным горбом и не лез ни в один карман. Ещё из минусов: Малюсенький монохномный экран, отсутствие виброзвонка, необходимость выдвигать антенну при каждом звонке, неудобный кнопки, пара мелодий на звонок вшитых, ну ис выдвинутой крышкой и антенной это была натурально "лыжа" сантиметров в 30 в длину. В фильме кстати герои не разу у телефона антенну не выдвигают, связь у них видать везде хорошая была. Игр кстати в нем тоже не было.
А так в целом, просто мобила на халяву и я с ней ходил примерно год. Потом поменял. На что не помню. Но первый телефон, он как первая любовь запомнится на всегда! :)
А братья\сестры Вачовски в следующей серии Матрицы - "Матрица. Перезагрузка" 2003 года поменяли телефон для Нео, Тринити и Мёрфиуса вот на такую бандуру от Самсунг:
Какой у вас первый мобильник или смартфон были?
Я с детства не любил чистить зубы, но любил гаджеты. Поэтому, наивно надеялся, что если купить прикольные гаджеты для нелюбимого процесса, то и зубы чистить будет весело.
Уточка отвернулась, чтобы не видеть тот стыд, что я пишу
Конечно же, недолго думая, я выбрал Xiaomi. Для "ванной комнаты" они выпускают товары под суббрендом с благозвучным для русского уха названием Soocas.
Зубная щётка
Кто знает, как включить на ней поворотники?
Выбрал модель X5. Это звуковая щётка чистит зубы выметающими движениями, а не возвратно-вращательными, как щётки с круглой головкой, но при этом в теории, в отличии от убер мощных ультразвуковых не вредит пломбам и коронкам.
Так, как такие щётки воздействую на зубы сильнее, чем ручные, паста для них нужна особенная, с минимальным абразивным эффектом. Я остановился на President Sensitive - у каждой пасты есть показатель абразивности (RDA) и у PS он показался для мне оптимальным.
(Если что, я не стоматолог, а простой обыватель, который перечитал кучу статей ещё до заполнения интернета нейросетевой водой.)
Поставлялась щётка с бохатым комплектом: 3 насадки разной жёсткости, кружка, чехол, беспроводная док-станция (зарядка от USB).
Минусом для меня стало то, что щётка подключается не к MiHome / MiFit / Zepp, а требует своё отдельное приложение Soocas. Первые дни я с ещё ним поигрался, радуясь своей прогрессии, а потом благополучно забил.
В повседневной жизни щётка меня тоже круто подставила... Хотя в комплекте и есть стакан для щётки, но разве вам не хочется просто стильно поставить её на плоское дно?
Я не самый осторожный человек и часто могу махать руками, а любой толчок стильно роняет зубную щётку на условно грязный пол или в условно грязную раковину... Конечно, можно снимать наконечник с щетиной, но тогда пропадает стиль. Да и вы сами то не офигеете его туда-сюда дёргать?
Хотя сменные головы для щётки штука дешёвая. С этими постоянными падениями есть нюанс: с щёткой идут три щетины: мягкая (для привыкания), средняя и жёсткая. И если средние/жёсткие свободно продаются на али, то вот мягкую там найти не очень легко... По какой-то причине не чистили долго зубки и они отвыкли от щётки? Придётся начать сразу с хардкора или кипятить старую.
Но конечно, главную свою функцию щётка выполняет отлично: хорошо чистит зубы. В ней есть встроенный таймер, который сигнализирует, что пора переключаться на другую четверть челюсти. (~30 секунд на четверть, 2 минуты на полную чистку)
Через приложение можно активировать опцию защиты от разбрызгивания пасты, чтобы щётка плавно набирала обороты, а не сразу врубалась на максимум.
Разве, что я чуть больше ожидал от режима "массажа языка / дёсен" - думал, что этой какой-то особенный кайф, который будет вознаграждением после чистки зубов, но так и не понял как оно должно работать.
Что и привело меня к печальному итогу: как бы ни крута была машина щётка проблема остаётся в прокладке между сиденьем и рулём раковиной и зеркалом. Даже геймификация процесса не смогла меня приучить регулярно чистить зубы.
Сейчас Х5 уже не найти в продаже (единственный лот продаётся за безумные 8700р) - ей на замену пришли другие, более новые модели:
Soocas X3Pro с технологией одновременной вибрации и пульсации, а так-же УФ боксом. (~6300р)
(У этой щётки, как и у X5 указаны 12 режимов работы, но по сути это 4 режима работы * 3 степени интенсивности.)
Soocas X3U Обычная / Вангоговская, а некоторые ещё и со здоровой щёткой для ЛИЦА. (~3680р без доп головок.)
Soocas X3S, который видимо отличается от X3U только расцветкой и отсутствием массажирования лица. (~4900р)
(У этих щёток указаны просто 4 режима работы без выбора интенсивности.)
(Хотя сам по себе X5 был улучшенной версией X3.)
Ещё есть другие буквы и линейки! Sonic, V1, D2... В этой азиатской логике нейминга без стопки ополаскивателя рта не разобраться. Я бы выбирая себе щётку сейчас со своей дотошностью к деталям, поехал бы крышей. (У меня был выбор между тремя вариантами.)
Если рискнёте в это погрузиться, то на мой взгляд, выбирать надо по этим признакам:
- Звуковая
- Частота пульсации (Думаю, что после какого-то предела уже нет разницы)
- Способ зарядки (Беспроводная станция уменьшает шанс на залитие)
- Наличие в продаже запасных головок (У X5 - X3 полная совместимость)
- Интенсивность режимов (Если у вас чувствительные зубы)
Из VIP опций это:
- Подключение к приложению (Если думаете, что более подвержены игрофикации чем я)
- Включение во рту
Но помните, что любая обычная щётка во рту, уделает самую крутую на раковине.
Недавно ещё вышел Soocas Neos - щётка со встроенным ирригатором. Кстати, об этом...
Ирригатор
Меня с детства пугало, как родственники орудовали во рту зубочистками. А постфактум, когда немного подтянул зубную теорию благодаря лучшему автомобильно-стоматологическому видеоблогеру, ужаснулся ещё сильнее...
Впрочем, зубная нить меня больше не прельщала - повезло и межзубные промежутки у меня были минимальными и еда там не застревала. (Даром, что сами зубы кривые...) Что-то туда с усилием протискивать... Нить напрягалась так сильно, что я боялся порезать ею нёбо. Бр...
И так бы я и жил, пока однажды из-за некорректной формы пломбы, у меня не оказалась крупная щель, куда начали забивать волокна еды, травмируя десну. С щелью я конечно разобрался, но воспоминания остались. Потом я увидел ирригатор в гостях у друзей... Потом мне его посоветовали на чистке зубов... Так у меня и появился Soocas W3 Pro (~3570р).
На самом деле, не знаю что можно о нём рассказать. Работает штука очень прикольно: стреляет водой под высоким давлением, чтобы максимально безболезненно выталкивать грязь из щелей между зубов.
Ирригатор максимально "тупой" и "простой" - никаких приложений. Зарядка через Type-C (Скрыт заглушкой.) Управление - через две кнопки: питание и выбор режима огня (воды?) в выключенном состоянии / скорость работы во включённом.
В комплекте есть несколько насадок для разных целей, но я пользуюсь только узкой. Всё моё взаимодействие с остальными ограничивается тем, что я роняю, фирменную подставку, она раскрывается и я иду обеззараживать выпавшие насадки кипятком.
Я не могу сказать, что приобретя эти гаджеты стал чаще чистить зубы, но однозначно процесс стал веселее, а качество на затрачиваемые усилия выросло.
По данным опроса, проведённого Всероссийским центром изучения общественного мнения (ВЦИОМ), большая часть россиян поддерживает инициативу запрета использования смартфонов и иных гаджетов детьми во время учебных занятий.
«Большинство россиян (83%) считают, что личные телефоны и смартфоны мешают школьникам учиться. Три четверти опрошенных (73%) поддерживают идею о запрете использования смартфонов и других гаджетов во время занятий», — цитирует ТАСС материалы исследования.
Также 69% респондентов полагают, что школьники станут лучше учиться, если подобные ограничения будут введены.