Раньше образование было совершенно на другом уровне. Нас думать учили! Со мной и друзьями произошла вот какая история. Вот в таком же наборе, который хранился в кабинете географии, были представлены образцы металлов: сталь, медь, алюминий и пр. Видимо для изучения экономической географии. Классный такой набор, на каждом образце нанесена цифра. По цифре можно в перечне найти наименование. И был среди металлов образец магния! Ну кого научили думать, тот поймёт! Это же классная бомбочка. Полного рецепта приводить не буды, дабы кого-нибудь тоже думать не научить. Спёрли этот образец, вооружились напильником и аккуратно превратили его в магниевую стружку. Ну дальше по технологии, перемешали с остальными ингредиентами, завернули в пакет, заделали чиркаш. Отошли подальше от людей, подожгли, бросили..... И ничего! Ещё подожгли, опять бросили.... И снова - ничего! Короче, советские бракоделы вместо магния, комплектовали наборы образцами алюминия. Возможно, что их просто лучше чем нас думать научили.
Начинаем трудовую неделю с нового экспоната в виртуальном музее советской бытовой техники. Сегодня это учебно-наглядные пособия.
Я негативно отношусь к попыткам экономии на обучении. И замена реальных объектов на "картинки в интернете" сказывается на качестве негативно. Кому-то уровня абстрагирования достаточно и по картинке он все поймет. А кому-то для запоминания нужно пощупать, понюхать, в руках подержать. Советская промышленность располагала специализированными предприятиями, что производили различные учебные пособия. От кусочков древесины до биологических препаратов и залитых формалином органов животных.
1/2
Многие опыты по физике можно показать в записи. Но для некоторых школьников впечатления от просмотра реально демонстрируемых опытов - важный эмоциональный опыт.
1/3
Товарищ Gall как то высказал хорошую мысль - демонстрировать физические опыты лучше на оборудовании, на котором они были открыты.
1/5
Да, на последней фото - сменная шкала со шрифтом Брайля.
1/4
Демонстрационный манометр.
1/4
Демонстрационный электроскоп.
1/12
А вот эти спектральные трубки я помню еще со школы, потому что ремонтировал этот самый спектр-1, точнее пачку спектров. У них были проблемы с контактами, был сломан пластик, и один был с пробитым транзистором. А в кабинете физики (как и потом в универе на кафедре физики) были горы оборудования, которые можно было отремонтировать тюбиком клея и отверткой, просто никто не хотел/умел.
Рассматривая разряд в спектральной трубке через призму, можно было видеть четкие пики разных длинн волн.
1/7
Образцы дерева. Фото не передает ни плотность, ни твердость образцов.
1/2
Наглядные пособия по теме шерсти.
1/2
Пособия по волокнам
Основное химическое сырье - разные гранулы полимеров.
Телеграм канал для тех кому удобнее за мной следить там - в профиле.
И имя ему - eMCP Samsung серии KM. Дело в том, что в 2012-2014 году, Samsung выпускала откровенно дефектные микросхемы флэш-памяти. Проблема касалась всех устройств с eMMC (не NAND) флэхами Samsung: они работали-работали и в один момент просто сами по себе отказывали, переводясь в режим только для чтения. Для пользователя это ощущалось так: смартфон резко зависал, после передергивания АКБ включался и просто висел на заставке или падал в рекавери с надписями в духе "Failed to mount partition"...
Самые печально-известные затронутые устройства: Galaxy S3 (в меньшей степени), Galaxy S4 (им повезло чуточку больше), Galaxy S4 Mini (сильно пострадали), Galaxy S4 Zoom (подохли практически все, на авито почти нет живых, зато куча с дохлой памятью), а также вторые и третьи табы. Как уже выяснилось потом, благодаря ребятам из команды Z3x, проблема была в косячной прошивке контроллера на стороне самого чипа памяти. Дело в том, что eMMC и UFS - это внутри привычная нам NAND. В старых микросхемах NAND (возможно некоторые читатели вспомнят нанды в корпусе TSOP48) организацией Spare-страниц и коррекцией ошибок занимался контроллер в процессоре устройства и его "настороженность" зависела исключительно от драйвера mtd в системе. В eMMC же этим занимается тот самый контроллер внутри самого чипа памяти и из-за косяков в его прошивке он слишком быстро помечал страницы как поврежденные и в конце-концов уводил чип в режим read-only для того, чтобы хоть как-то спасти данные от потери.
BGA162, 1/8 - классика 2014 года
Но если вы присмотритесь к флэхе, то можете заметить дополнительные пины сверху и снизу относительно основных контактных площадок - это тест-поинты для внутреннего тестирования флэшек на заводе. Однако ребятам из Z3x откуда-то удалось достать информацию о том, как работать с этими флэшками через тест-поинты и прошивать их контроллеры, благодаря чему часть флэшек всё таки оживало после отдельной прошивки именно самого контроллера. Кроме того, ребята научились переписывать CID флэшек (для маскировки под другие чипы памяти при жесткой привязке - как в случае с Preloader'ами на MTK) и очищать RPMB-область, дабы продлить жизнь и без того косячным микросхемам памяти.
Доходило до абсурда: Samsung всегда были большими любителями налить компаунда и поставить флэшку вплотную к процессору. Пока счистишь компот - есть неиллюзорный шанс угреть рам или отвалить бутерброд, поэтому многие просто спиливали их дремелем.
На фото выше - смартфон-консоль JXD S5800, который как раз и пал жертвой этих чипов памяти. Иронично, но даже после установки другого чипа из моих запасов той же серии, но меньшего объёма - он также оказался сдохшим :) Что-ж, пойду заказывать и готовить для вас контент о реставрации диковинного смартфона родом из 2013 года, а заодно плеваться на Samsung.
Для ЛЛ: в двух словах не описать, длиннопост уж очень большой :)
Сегодня всё чаще можно услышать мысль о том, что раньше мобильные игры были лучше. В какой-то степени это правда: ранние Java-игры отличались отсутствием доната и сервисной модели монетизации, логической завершенностью большинства тайтлов, а также экспериментами с новыми жанрами. И всё это в рамках крайне ограниченных возможностей Java-телефонов. В этой статье я хотел бы рассказать о трудностях мобильной разработки образца 2005 года с конкретными примерами тех или иных решений, так что если вам интересно — добро пожаловать под кат!
Содержание:
Предисловие
Реалии разработки
Как игры работали «изнутри»?
Что стало с J2ME
Заключение
❯ Предисловие
Пожалуй, мобильный гейминг как класс зародился в самом начале двухтысячных годов. В какой-то момент, производители телефонов смекнули, что помимо задач обработки GSM-стека, у чипсета остаётся достаточно процессорного времени для обработки второстепенных задач, благодаря чему в телефонах начал появляться дополнительный функционал: к примеру — игры. И хотя первой мобильной игрой был клон Тетриса в Hagenuk MT-2000 1994 года выпуска, на практике игровые перспективы в телефонах увидели только в 2000 году, когда компания Sun выпустила спецификации стандартов CLDC 1.0 и MIDP 1.0.
Siemens SL45i — один из первых телефонов с поддержкой Java-приложений.
Дело в том, что в те годы телефоны работали на целом зоопарке самого разного железа и операционных систем. За год-два в телефонах одного производителя могло измениться всё: та же Motorola внезапно перешла с кастомной GSM-платформы на базе m68k в StarTAC'ах на стандартный TI HERCROM с ядром ARM7TDMI в телефонах линейки Talkabout, параллельно развивая свою собственную архитектуру M-Core в устройствах для CDMA-сетей. А Siemens, к примеру, использовали процессоры разработки Infineon под названием E-Gold, построенные на собственной архитектуре C166s, которые уже через несколько лет заменили на S-Gold'ы, построенные на ядре ARM926EJ-S. Для решения этой проблемы, компания Sun предложила миниатюрную Java-машину с набором стандартизированных API и свободным SDK, которые в теории позволяли легко разрабатывать программы, не зависящие от конкретного телефона. И имя этой машине — KVM (Key Virtual Machine), а мобильный профиль назвали J2ME (Java 2 MicroEdition).
Сердце Siemens M55 — тот самый процессор Infineon E-Gold
Набор API в первых телефонах с поддержкой Java был небогатым и состоял из CLDC — базовой инфраструктуры языка, и MIDP — набора классов для работы с «железом» устройства. Присутствовали пакеты для работы с дисплеем и создания простенького интерфейса (lcdui), примитивной работы с сетью (microedition.io), а также хранения данных (rms). При этом основная инфраструктура языка во многом была совместима с обычной Java версии 1.3 — то есть были классические потоки, коллекции (Vector, Stack, Hashtable — и это ещё не дженерики), генератор псевдослучайных чисел, исключения и даже минимальная рефлексия (Class.forName и Class.newInstance). Однако у CLDC 1.0 был один неприятный нюанс — он не поддерживал Float вообще ни в каком виде, из-за чего классы при компиляции проходили верификацию и дополнительную оптимизацию специальной утилитой — preverify.
Это весь java.util в CLDC 1.0. Сравните с современной реализацией этого пакета :)
И по правде сказать, этого набора API было слишком мало для разработки хоть сколь либо серьезных приложений и игр. Объём RMS был жёстко ограничен несколькими килобайтами, графическое API не умело рисовать кусочки изображения из атласов и использовать полупрозрачность, а о воспроизведении звука вообще можно было не мечтать. И это было справедливо для моделей 2001 года выпуска, но уже в 2002 начали появляться куда более продвинутые устройства с цветными дисплеями, полифонией и большим объёмом памяти. Каждый производитель начал реализовывать своё собственное API, из-за чего стали плодится отдельные версии приложений адаптированные для разных телефонов — Opera Mini S40 128x128, Gangstar SE 176x220, Prince Of Persia Mot 128x160...
Nokia 3300 2003 года выпуска. Один из первых телефонов с поддержкой Nokia API.
Но MIDP 1.0 был отнюдь не бесполезен как может показаться на первый взгляд. Именно под него разрабатывались первые версии Opera MIni, Jimm и самые первые Java-игры. Клон Pac-Man на SGH C100 как раз один из таких.
Однако уже в 2002 году появилась спецификация MIDP 2.0, которая привносила возможность воспроизведения звуков и музыки, проверки подписи приложений, а также продвинутое API для отрисовки графики и работы с расширениями. Несмотря на готовность спецификации, первые телефоны с поддержкой MIDP 2.0 появились только в 2003 году — это была Nokia 6600, а также Siemens S55/M55. И вот с Siemens'ами была небольшая загвоздка — их реализация MIDP 2.0 была обернута в отдельное Siemens API и не была на 100% совместима с Sun'овской, настоящая поддержка появилась лишь через год — в 2004 году. Остальные же производители продолжали использовать MIDP 1.0, включая Sony Ericsson (T610), Samsung (C100) и модели Nokia на платформе S40.
А уже в 2004 году, J2ME стала по настоящему популярной платформой. Появились сторонние лицензируемые реализации Java-машин и MIDP — Esmertec JBed и Aplix JBlend, на телефонах стала возможной отрисовка 3D-графики в реальном времени благодаря M3G и Mascot Capsule, а также начали появляться первые AA-игры от Gameloft — как, например, тот же самый Asphalt. Sun пошли ещё дальше и умудрились уговорить ARM на реализацию отдельного набора инструкций для ускорения JVM — Jazelle. Это, вероятно, первый и последний пример, когда JIT реализовывается не на уровне VM, а на уровне ISA процессора...
И на первый взгляд может показаться, что у Java банально не было конкурентов, однако это не так. Как раз таки конкурентов у J2ME было сразу три. Первый — это платформа Mophun, которая представляла из себя игровой движок с очень быстрым программным растеризатором 3D-графики и собственным C-подобным скриптовым языком. Заточен он был исключительно под игры и на нём вышло несколько очень крутых, на момент выхода, игр. Например, Lock'n'Load:
Mophun провалился как раз из-за ориентира только на игры. Насколько мне известно, API для других целей там просто не было. Второй платформой была ExEn от французской компании In-Fusio, которая также позволяла писать приложения на Java, но имела больший ориентир на игры. Однако её можно было найти только в французских (Alcatel One Touch, Sagem) и нескольких японских телефонах, а также у неё было жёсткое DRM, что помешало ей стать «народной». Чуть позже, In-Fusio начала предлагать ExEn как один из пакетов для «обычных» JVM, но платформа прекратила существование уже в середине 2000-х...
Alcatel One Touch 535 — один из немногих телефонов с поддержкой ExEn. Давно хочу себе подобный Alcatel поковырять, но почему-то не попадались ни разу.
А третьей платформой был BREW от компании Qualcomm. И по правде сказать, он был куда круче любой JVM — ведь предлагал писать полностью нативные программы на C, используя всю потенциальную мощность устройства. Но Qualcomm не был бы Qualcomm'ом, если бы не ограничил использование BREW только на телефонах с собственными чипсетами и RexOS, а также не отгородил всё отвратительным DRM. Впрочем, это тоже можно простить, ведь Qualcomm уже тогда был доминантном и двигателем прогресса телефонов, поскольку уже в 2004 году разработал и интегрировал собственный 3D-ускоритель. Но это уже совсем другая история...
Сейчас такая графика может показаться смешной, но в те годы видеоускоритель Defender3D творил чудеса. Игра с очень неплохой графикой и в 25-30 FPS на обычном кнопочном телефоне?! Невиданно!
Так что J2ME благодаря усилиям производителей телефонов и самой Sun стала по настоящему народной платформой. SDK был доступен абсолютно бесплатно и для всех, предлагалась отличная документация с множеством примеров программ, а приложения можно было ставить и отлаживать откуда угодно и как угодно, прямо как на Android. И это стало одной из проблем...
❯ Реалии разработки
Как и сейчас, в те годы мобильными играми в основном занимались небольшие команды. Условно был программист, который недавно постиг Java, перейдя на него с Delphi или C++, пару художников, которые рисовали всю графику в игре, а также отдельный звуковик, в задачи которого входило написание midi-музыки и иногда таких же midi-эффектов. Магазинов ассетов и соответственно ассет-флипа как класса ещё не существовало, поэтому всё в игре делали своими руками «как умели». Наверное одним из лучших примеров таких студий будет харьковская NetSoftware, известная своими играми серии «Бункер 3D»:
Что такое ассет-флип?
Сегодня у двух самых популярных движков — Unity и Unreal Engine, есть собственные магазины с ресурсами для игр. В них можно купить как обычные модели, текстуры и саундпаки, так и целые уровни вместе с шаблонами игр. Ассет-флипом называются те игры, которые либо построены на базе популярного шаблона игр (помним бесчисленные низкокачественные шутеры с всякими Ultimate FPS Controller или «симуляторы вождения» на базе Edy's Vehicle Phyiscs?) с минимальными геймплейными изменениями относительно шаблона, либо игры с собственной логикой и геймплеем, которые неизменно используют уже готовые уровни.
Свастику мы осуждаем, а вот авторов из NetSoftware хвалим за крутейший 2.5D-рейкастер, который шустро бегал даже на слабых телефонах и в отличии от оригинального Wolfenstein поддерживал стены под углом, а также объёмные «пропы».
И вот, ребята разработали игру и хотят заработать денюжку на её продаже. Тогда ещё возможности самиздата не было, а также не существовало монетизации за счёт рекламы и донатов (кроме немногочисленных MMORPG), поэтому игры продавались по цене примерно в 3-4$ напрямую, а покупка осуществлялась отправкой СМС на... да вообще любой номер! Магазинов было просто куча, ни о каком едином сторе (кроме Samsung Fun Club, портала Nokia и Sony Ericsson) и речи не было, а каталоги Java-игр можно было найти в женских журналах, в ТВ-рекламе и даже на сайтах ОпСоСов (Оператор Сотовой Связи)! После отправки СМС, пользователь получал ссылку на WAP-сайт, откуда он мог скачать jad-файл игры (дескриптор с описанием приложения), после чего телефон докачивал соответствующий jar. И всё это без скриншотов, без возможности возврата средств, ориентируясь исключительно на обложку игры и известное название...
Насколько мне известно, небольшие команды чаще всего шли к издателям по типу Qplaze, NetLizard (Украина) и Herocraft (Россия), которые и занимались налаживанием контактов с таким ворохом каналов распространения, а также реализацией биллинга с «антипиратской защитой». Дело в том, что помимо «слепой» покупки игры также были популярны Shareware-игры: играешь 90 секунд бесплатно, затем игра просит отправить СМС для получения кода активации и если пользователь соглашается — то получал полную версию игры. И вот тут то модель распространения давала сбой: Java ведь компилируется в байткод, и даже после обфускации его можно превратить в читаемый и относительно собираемый исходный код. Путём простого патчинга байткода биллинга (того самого окошка «оплатите игру") можно было "вылечить игру от жадности" и выложить куда-нибудь на seclub, sefan, spaces или tegos версию с "таблэткой":
А ведь были ещё и телефоны, которые jad-файл могли не только сразу установить, но и скачать в память телефона — причём вместе с jar. И вот тут активизировалось сарафанное радио: один купил игру, скинул другу (нередко за пирожок в столовой, кэшбек же), тот скинул своему другу, а он залил на wap-сайт... короче пиратство было настолько распространено, что я даже в теории не могу предположить сколько там упущенной прибыли :)
STALKER Mobile — одна из самых желанных 3D-игр на телефоны нулевых.
А ещё был хорошо налажен конвейер копирования успешных идей. Однако если сейчас в основном копируются свежие геймплейные идеи гиперказуальных игр, то тогда пытались один в один скопировать целые игровые вселенные. Вспомнить только Gameloft с её AAA-играми по мотивам GTA (Gangstar), Need for Speed (Asphalt) и даже Call of Duty (Modern Combat). В СНГ же такой фирмой была NetLizard, которая в основном делала упор на популярные игровые вселенные и постсоветский колорит (Ликвидатор ЧАЭС — её разработка). Кроме того, не было никаких особых ограничений на распространение эротических и даже порнографических игр — и они свободно распространялись даже в журналах (с особо сочными описаниями)!
На первый взгляд эти тайтлы могут показаться трешачком или славджанком, однако на практике это были вполне годные игры, пусть и с глупым, кликбейтным описанием.
❯ Как это работало?
Однако пожалуй самое интересно это то, как мобильные игры тех лет работали «под капотом». Ведь в отличии от современных устройств, на кнопочных телефонах нельзя было разгуляться с абстракциями, раскидываться аллокациями на куче, и даже использование floating-point арифметики было нежелательным. Более того, многие разработчики намеренно отказывались не только от любых абстракций, но и просто от концепции классов или стандартных паттернов организации сцены/состояний, предпочитая создавать God-объекты для целых игр. В одном классе мог быть код и обработки состояний (меню, игра), и загрузки уровней, и отрисовки, и обработки логики. Нередко отказывались даже от стандартных коллекций типа Vector и структур данных, предпочитая реализовывать статические пулы-массивы с данными для каждого игрового объекта. Как бы это забавно не звучало в контексте Java, но чаще всего использовали процедурный подход программирования:
Это главный класс игры «Ликвидатор ЧАЭС» весом в 56КБ, который сочетает в себе вообще всю логику игры. Как вам такое?
На первый взгляд может показаться, что программисты были просто неопытными и писали «как умели». Однако на практике это была одна из фундаментальных оптимизаций: во первых, статические пулы с примитивными типами данных избегали дорогого боксинга (управляемые контейнеры над примитивными типами. int - Integer, float - Float). Использование структур было не всегда оправданным из-за относительно высокой цены аллокации (а в J2ME они всегда на «куче», в отличии от .NET. Засовывать мелкие объекты в Eden-space те JVM ещё не умели) и примитивности GC. А во вторых, в некоторых JVM верификация почему-то выполнялась не при установке приложения, а при первой загрузке класса ClassLoader'ом. И процесс верификации мог заметно затормозить приложение, при этом съев ещё немного памяти для данных о загруженном классе.
Другое дело — классы из системных пакетов. Они всегда загружены и обычно являются тонкими прослойками к native-реализациям методов.
Ведь когда мы говорим о Java-телефонах, то чаще всего имеем ввиду не топовые Symbian-смартфоны у которых было 2МБ и более хипа, а о бюджетных кнопочных устройствах по типу Nokia 6060 или Samsung C3010, где хипа едва-ли был 1 мегабайт, а порой и вообще ~500КБ. И в это пространство нужно уместить всё: графику, уровни, звуки с музыкой и конечно код игры. Поэтому разработчики и шли на такие ухищрения. Кроме того, как раз тот самый верификатор был занозой в заднице любителям абстракций: даже если движок игры технически позволял использовать Nokia API на S40 телефонах, Sony Ericsson API на SE и обычный MIDP 2.0 на Samsung'ах, Java-машина при установке может просто прервать процесс сообщением «класс не найден»...
Чтобы примерно понимать с каким железом приходилось иметь дело программистам из нулевых, давайте рассмотрим спецификации бюджетного Samsung SGH-E250 образца 2006 года:
Процессор: NXP PNX5230 с одним ядром ARM946E-S, работающим на частоте до 130МГц. В 2007 году уже чаще встречалось более мощное ядро ARM926EJ-S, которое работало на частоте до 208МГц.
Память: 16МБ оперативной, из которых Java-приложениям было доступно около 1.5МБ, а также 32МБ постоянной. Для Jar-приложений было строгое ограничение — 250КБ.
Дисплей: 128x160 TFT-TN, 16-битный.
Поддерживаемые API: JSR75, JSR85, JSR120.
Не то чтобы железо было уж очень слабым, но не стоит забывать о том, что телефоны были многозадачными и под приложения отдавалось отнюдь не всё процессорное время, а итоговая производительность сильно зависела от порта Java-машины на конкретный телефон.
Nokia 6060 — типичный бюджетник, на который ориентировались при разработке игры.
Второй проблемой была графика и разные разрешения экрана. В качестве основного формата изображений, в J2ME был выбран png из-за простоты реализации загрузчика, высокой lossless-компрессии, а также свободности Zlib. Формат png в своей основе подразумевает 32х-битный формат цвета с 4-мя компонентами: R, G, B и A. A — это альфа-канал или степень прозрачности пикселя, и вот с ней у многих телефонов были проблемы. Дело в том что примерно до 2006 года, многие телефоны не умели альфа-блендинг (т.е полноценную полупрозрачность) вообще, из-за чего представляли прозрачность либо как 0 (пиксель прозрачный), либо как 1. Если в игре предполагались полупрозрачные поверхности (например стекла или параллакс-фоны), то для некоторых телефонов их приходилось заменять дизерингом или вообще делать упрощенную, менее красочную версию:
Вам кажется что куб полупрозрачный, однако на практике часть его фрагментов — полностью прозрачные, а часть — нет. Это частый стилистический прием, актуальный как в играх 90-х, так и сейчас.
Вы никогда не задумывались, почему современные 2D-игры не зависят от разрешения экрана и выглядят одинаково сочно как на 4K-дисплее, так и на 720P экране бюджетного смартфона? Секрет прост: современные игры используют в качестве системы координат не пиксели, как это делали многие старые релизы (не только Java, но и консольные/ПК), а метры (сантиметры, что угодно). С развитием мобильных GPU, 2D стало частным случаем 3D и теперь все двухмерные элементы — это просто плоские 3D-треугольники. А поскольку растеризатору совершенно не важно какой треугольник ему «скармливают» и при нанесении текстуры/спрайта он оперирует исключительно алгоритмами фильтрации (которые включают в себя масштабирование) — мы можем видеть идентичную картинку с идентичным уровнем масштабирования на любом устройстве:
Один из моих Just for fun-проектов — игра про оборону от зомби в стиле Crimsonland. Выглядит одинаково как на смартфонах с 720p дисплеями, так и 240p.
На ретро-телефонах всё было по другому. Чаще всего у устройств не было не то что FPU, даже аппаратного деления в процессоре зачастую не было. Поэтому любая floating-point арифметика эмулировалось программно, а умножение/деление были очень дорогими, из-за чего система координат в играх обычно была целочисленной, а результаты любых тригонометрических функций были посчитаны заранее для всех углов поворота объекта. Конечно никто не мешал реализовать масштабирование и поворот (т.е умножение на 2x2 матрицу) на fixed-point арифметике, но учитывая что процессор можно было положить на лопатки несколькими десятками небольших спрайтов, разработчики всегда использовали классический блиттинг — то есть прямое копирование изображений на экран без масштабирования, поворота, блендинга и других операций. Именно поэтому в таких играх чаще всего не было автоматического масштабирования, а каждая версия игры несла в себе свой пак ресурсов:
По возможности многие разработчики старались использовать API от производителей телефонов. Дело в том, что нативное API зачастую предоставляло возможность проигрывать куда более качественную MMF-музыку (Samsung), заметно быстрее отрисовывать 2D-графику (Nokia UI API) и получить доступ к фишкам по типу мультитача и даже звонкам! Например DirectGraphics в Nokia UI API поддерживал поворот на фиксированный угол и возможность «бесплатной» отрисовки изображения в нативном пиксель-формате (RGB565), благодаря чему Nokia UI реализовывали и другие производители — например Sony Ericsson:
Ну и конечно стоит упомянуть 3D на телефонах нулевых, благо там был целый зоопарк различных API. Пожалуй самым первым был легендарный Mascot Capsule, который использовался в телефонах Sony Ericsson и Motorola, и представлял из себя очень быстрый софтварный растеризатор, который позволял выдавать графику уровня PS1. Помимо растеризатора затененных и текстурированных треугольников, Mascot Capsule также предоставлял «собственный» формат текстур (bmp), моделей (mbac), и анимаций (mtrac), математическую библиотеку, а также поддерживал примитивный скиннинг. Однако главной особенностью было то, что в целях экономии памяти, Mascot Capsule не поддерживал Z-буфер и вручную сортировал треугольники по отдаленности к наблюдателю, из-за чего иногда можно было увидеть Z-fighting, характерный для игр с PS1:
V-Rally — одна из игр на движке Abyss Engine от Fishlabs. На нём же потом сделали Galaxy on Fire и Deep3D, и это один из немногих примеров использования абстракций в Java-играх.
Второе API появилось в 2004, называлось M3G (Mobile 3D Graphics) и использовалось практически везде... кроме телефонов Samsung до 2010 года. И вот здесь есть важный момент: во первых, M3G это спецификация и реализаций этого API было много. Референсная, насколько мне известно, была построена на базе OpenGL ES 1.1, в то время как большинство производителей использовали проприетарные реализации на базе кастомных софтрендеров. А во вторых — M3G это не просто растеризатор треугольников, а граф сцены с собственной древовидной структурой объектов. И разработчикам предлагалось строить логику как раз поверх этих самых Node'ов — что идёт вразрез с моими словами о максимальной примитивности и линейности логики игр тех лет. Поэтому большинство разработчиков использовали M3G, если говорить очень условно, как «Unity» тех лет — создавали уровни в 3d Max, загружали их в игру, создавали какие-то объекты и управляли их компонентами (трансформация, материал и т.п.) также, как в Unity:
По уровню графики, M3G позволял добиться довольно неплохих результатов. Ниже игра Rally 3D Nokia, которая по совместительству является Java-портом одноименной игры с Mophun:
Что-то так защемит в груди...
Третьим API был JSR239 — OpenGL ES, которому не суждено было стать популярным на Java-телефонах. Дело в том, что его поддерживали только телефоны Sony Ericsson и только после 2008 года, а также несколько устройств от BlackBerry. Несмотря на то что ES 1.1 Nokia реализовала в своих Symbian-смартфонах ещё в 2006 году (из-за появления устройств с 3D-ускорителями от PowerVR), этот стандарт никогда не был реализован в Java-машине... Зато он оказался реализован в самой первой версии Android, благодаря чему там до сих пор есть пакет javax.microedition.khronos.opengles!
А некоторые разработчики шли во все тяжкие и реализовывали программные 3D-растеризаторы прямо на Java, которые ещё и умудрялись очень шустро работать! Понятное дело что под капотом они были простыми и сильно упирались в филлрейт, однако популярная в своё время игра Left2Die как раз использовала свой собственный программный растеризатор, благодаря чему работала даже на телефонах Samsung:
❯ Судьба J2ME как платформы
До 2010 года, J2ME продолжала оставаться самой популярной программной платформой для телефонов. Её поддержку добавляли и в простые телефоны, и в смартфоны, а сама платформа продолжала обрастать функционалом и новыми пакетами. Sun (уже почти Oracle) вместе с производителями телефонов успела представить третью версию профиля MIDP в 2009 году, и выпустить новую версию SDK, но уже в 2010 году платформа начала стремительно сдавать позиции...
Одна из причин падения J2ME
И этой причиной был Android. Дело в том, что в своё время, ОС от Google умудрилась полностью перевернуть мир смартфонов, представив систему с довольно неплохим и логичным API, современным подходом к разработке приложений и открытостью к производителям смартфонов. И что самое интересное, весь юзерспейс Android'а был написан на Java, что сильно упростило переход уже существующих Java-разработчиков на смартфоны. Были разработаны библиотеки-слои совместимости с MIDP для упрощения портирования, были организованы конкурсы среди разработчиков приложений, а к 2010 году появились первые Android-смартфоны по цене менее 10.000 рублей (~300$), что заметно ударило по популярности обычных Feature-фонов и кнопочных смартфонов. J2ME прожила примерно до 2014 года, пока производители всё ещё предустанавливали её в теперь уже ставшие бюджетными кнопочные телефоны. Большинство разработчиков перешли к разработке для iOS и Android, и лишь Gameloft время от времени радовала нас новыми релизами, пока в 2014 платформа окончательно не умерла...
Затем на место Java-телефонов пришли устройства с KaiOS, которые тоже успели кануть в бытие, а теперь, как бы это забавно не звучало, продвинутые кнопочные телефоны работают на Android. И что самое забавное — в свежих LTE-кнопочниках на чипсетах Unisoc просто нереально крутые ТТХ по сравнению с той же Nokia N73: 64 мегабайта DDR2-оперативной памяти, гигагерцовый ARM-процессор на ядре Cortex-A7, поддержка инструкций NEON... Но никакой возможности запуска сторонних приложений. Это очень грустно.
❯ Заключение
Вот такой была разработка мобильных игр в далёких нулевых годах... От многообразия аппаратных платформ, форм-факторов и операционных систем мы пришли к доминированию iPhone и Android, а от полной открытости к пользователю — к закручиванию гаек «открытой мобильной операционной системы» её же разработчиком. Но факт остаётся фактом — разработка в те годы была куда более ламповой, душевной и, что интересно, предлагала куда больше игр с уникальным геймплеем...
А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можноотправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, игровые консоли, ретро-ПК железо - всё это я очень люблю и порой пытаюсь поднять даже нерабочие гаджеты :) Всем огромное спасибо!
Шел по улице, появилась надпись "(F) Подобрать" и в инвентарь попал вот такой КПК. Подскажите, как в нем открыть карту и топ-20 сталкеров? :)
Если вдруг не знали - именно iPaq h1940 стал первым прообразом КПК в Сталкере, а конкретно его моделью в мире.
В UI же используется Samsung SPH I-700, только с заметно увеличенным дисплеем. Второй бум популярности случился в 2009-2010 году, когда КПК на PPC2003 начали стоить копейки и их брали для угара по сталкеру + как дополнительный гаджет в паре с телефоном
Ну а в Зове Припяти прообразом стал один из промышленных защищённых КПК. Также возможно вдохновением послужили MID-коммуникаторы с огромным дисплеем, которые представляли из себя что то среднее между современным смартфоном и планшетом. Таких к слову никогда не встречал:
Мне довелось протестировать прототип новинки VR шлема от Pimax - Dream Air с Micro OLED экранами. Мой краткий обзор и вердикт таковы: Pimax Dream Air — редкий случай, когда VR-шлем не хочется снимать. Минимальный вес, отличная развесовка, отсутствие инерции и очень комфортная посадка. Даже топ-страп по факту не обязателен.
Micro OLED даёт именно тот визуал, который ждёшь от премиального VR: глубокий чёрный, контраст, аккуратные цвета. В видео рассказываю, как он ощущается в реальных сценариях — от игр до работы в VR, и чем Dream Air отличается от Crystal Super Micro OLED.
И кстати, именно Dream Air на мой взгляд - идеальный кандидат на "лучший VR шлем для продуктивности / spatial computing / работы в VR на виртуальных экранах". Судите сами:
- Inside out tracking (нет нужды в базовых станциях, если берете SLAM версию);
- Трекинг взгляда (не столько взаимодействие с интерфейсом, сколько облегчение рендеринга);
- Высочайшее разрешение с micro oled экранами и глубоким черным цветом;
- Габариты, вес, размер - комфорт на многочасовые рабочие сессии;
- Раздвоенный дисплей порт тоже + к кофорту.
Quest 3, Pico 4, Steam Frame - низкое разрешение для работы и LED экраны. MeganX и BigscreenBeyond 2 - базовые станции (не портативно, в дорогу не возьмешь). Apple Vision и Galaxy XR - габаритнее и тяжелее. XR очки - слишком низкий FOV.
Вот и получается, что Dream Air может оказаться идеальным кандидатом для тех, кто ищет самый лучший "рабочий" портативный VR монитор. Время покажет.
Если есть вопросы - обязательно спрашивайте в комменатриях и можете пинговать меня в GanJJGames телеге https://t.me/ganjjgames , она вся посвящена VR, играм и другим моим гиковским хобби :)
С школьных лет мы знаем, что вода является проводником электрического тока. При этом дистиллированная вода не проводит ток, а вода с примесями — прекрасно проводит.
Я провёл эксперимент, в котором нет ничего необычного, но он наглядно показывает, что вода способна передавать и осмысленные сигналы, например данные в ASCII-кодах. Мы будем использовать ретротехнику — компьютеры на процессорах 386, но повторить суть эксперимента можно и на современном оборудовании.
Это небольшой пример, который напоминает нам о том, что вода электропроводна.
Под катом — фото и видео составляющих эксперимента и пояснения.
Итак, составляющие:
Для эксперимента выбраны два одинаковых ретрокомпьютера с процессорами 386. Эти компьютеры работают на чистом DOS и оснащены аппаратным COM-портом с разъёмом DB9. Можно использовать и другое оборудование — например, менее мощное (вплоть до XT-машины) или более современное.
Конфигурация обоих компьютеров одинакова:
В целях наглядности, компьютеры развернуты «спиной».
Коммутируем:
Для передачи данных в виде текста используется терминальная программа, которая интегрирована в DOS Navigator (DN) — развитую файловую оболочку под MS-DOS.
COM-порт настраивается параметрами 8N1 (передача 8 бит, без контроля чётности, с одним стоп-битом).
Компьютеры соединены по принципу нуль-модемного кабеля, но не совсем стандартно. Данные передаются всего по двум проводам (в простейшем нуль-модемном соединении используются три провода: приём (RX), передача (TX) и общий (GND)).
Передача по двум проводам осуществляется при помощи адаптеров RS232 -> RS485.
Стандарт RS485 позволяет передавать данные на расстояние до 1200 метров по двухпроводной линии, но с невысокой скоростью. Чем меньше расстояние, тем выше допустимая скорость передачи. Передача данных происходит в полудуплексном режиме, то есть одновременно возможна только в одном направлении. Через такой канал нельзя играть, как через нуль-модем, но можно передавать информацию, в частности текст.
Общий вид, готовый к коммутации:
Проводящая среда — солёная вода в стаканах и самая обычная соль (поваренная).
Ещё раз отмечу, что вода сама по себе не проводит электрический ток — его проводят содержащиеся в ней примеси. Мы добавим в воду произвольное количество поваренной соли, а чтобы соль растворилась быстрее и лучше, предварительно подогреем воду.
Налили воду, крокодилы попарно цепляем за края стакана, «в разрыв», а сами адаптеры подсоединяем к COM-портам.
Далее действуем по принципу — лучше один раз увидеть. Предлагаю посмотреть видеоролик, где наглядно показан эксперимент и представлены дополнительные его детали.
Ну и напоследок — осмысленная фраза, переданная в обоих направлениях:
Подытожим.
Этот эксперимент по своей познавательной сути не выходит за рамки школьной программы, однако он позволяет проверить знания на практике.
Жаль, что RS485 нельзя использовать в качестве канала полнодуплексного обмена. Иначе через него можно было бы запустить DOOM, Duke Nukem и другие подобные игры, растянув линию на значительное расстояние. Интересно услышать мнения и идеи других людей по этому поводу, а также узнать о других познавательных экспериментах.
Начинаем очередную трудовую неделю с нового экспоната в виртуальном музее sovtech.su . Сегодня это фотоснимок. Возможно сила пикабу сработает и найдутся родственники людей с фото, прошло всего 65 лет.
Это фотопластинка с негативом для тиражирования снимка посредством контактной фотопечати. В рамку зажималась фотобумага и засвечивалась через негатив.
Для плотности прижима поверхность покрыта бархатом. Видно, что рамка лежала где-то и ее заливало водой.
Коллективное фото сделано в технике коллажа - каждого сфотографировали по отдельности, разместили на листе, сделали подписи и пересняли на фотопластинку. Хоть такой способ более трудоемкий, но гораздо более удобный - попробуйте прервать работу любого заведения на час, чтобы собрать всех в одном месте, усадить как надо и подловить момент, когда никто не моргает и не дергается.
Надпись гласит, что это первый выпуск 11го класса октябрьской с.ш. сельской молодежи №1 туапсинского района краснодарского края. 1961 год. Благодаря бесподобному @AthosLaFere есть отреставрированный снимок:
Подобные снимки есть практически у каждого в архиве. В зависимости от мастерства оформителя - сложность декора весьма разная, от каллиграфических подписей до топорных букв разной ширины.
Телеграм канал в профиле для тех, кому удобнее там.
