Комментарии 62
В J2ME ограничение на память были драконовские, в большинстве моделей это 64кб для кода (не для ресурсов). Практически ZX Spectrum из 80-х.
Тем не менее этого вполне хватало на вполне играбельные игрушки и вполне функциональные приложения. Вот, например, музыкальный секнвенсор для трубок с тачскрином (это те же J2ME типа Nokia Asha, никаких Андроидов и Симбианов):
https://www.youtube.com/watch?v=xFdb5HgElIE
Если тратить ресурсы на сотни мб рекламы и сторонних библиотек, то обычно на многое может хватить.
64Кб ограничение на класс, это справедливо и для J2SE было долгое время :) Просто в те годы почему то многие писали игры без адекватного ООП в 3-4 класса и получились уберклассы где обрабатывается и меню и игра и все
У самой KVM, насколько мне известно, код был частью кучи и поэтому был ограничен до примерно 500Кб-1Мб.
Где-то попадалась инфа, что один уберкласс, в котором вся игра - сознательное решение, потому что из-за особенностей реализции javaмашины так работало быстрее, а много классов тормозило, что для игры критично
Ну, это вполне логично, но вместе с тем вносит и сложности в менеджмент памяти например. Игры с нормальным ООП все равно были.
На скорости работы кол-во классов сказывалось не сильно, если правильно помню. Только более длинные цепочки вызовов могли повредить. Но вот места в оперативке отдельные классы жрали катастрофически много, поэтому старались уместить все в минимально разумном количестве:
Стартовый класс со всей логикой инициализации
Класс меню
Класс работы со звуком и музыкой(часто подменялся для разных девайсов)
Класс спрайта
Класс тайлового бэка(использовался и для игры и для заставки)
Класс со всей игровой логикой. И в нем уже встроенные FSM на логику разных объектов массивы с их позициями стейтами и тд. В нем же все общая логика отрисовки.
Реверс инженерил пару игр от Gameloft того времени, у них была плюс-минус похожая структура.
В спецификации MIDP 1.0 указано что ограничение в 64кб для файлов приложений которые могут быть установлены через интернет.
Не класс в пределах 64кб, а весь файл приложения.
Когда большинство трубок стало поддерживать большой размер уже появились Андроид с Айфоном.
Не верно. MIDP 2.0 уже не накладывал никаких ограничений при том, что вышел в 2003-2004. На 6233 2006 года уже можно было ставить мегабайтные JAR, на Symbian смартфонв еще больше.
За MIDP 1.0 очень быстро забыли из за кучи ограничений
Разработчики (я в том числе) вынуждены были поддерживать то что стоит у всех. А у большинства было устройство с поддержкой MIDP 1.0
Приложение должно работать везде, иначе нерентабельно.
Для этого создавались разные версии приложения с разным функционалом, насколько я знаю. Мне попадали в руки несколько мастер-версий игр и они занимали промежуточное положение по функционалу. Если для совсем старья функционал урезался и упрощался: шла 2D графика и минимум механик, то для топовых моделей могли позволить "навесить красоту" - улучшенные текстуры для 3D и нормальные звуки для интерфейса и игры.
А в каком году вы работали над Java-приложениями?
За MIDP 1.0 очень быстро забыли
Не за, а про или о.
Жаль, что у 6233 было ограничение на JAR в 1 МБ, приходилось урезать. Потом телефон подсчитывал размер установленного JAR вместе с "сохранками". Была разница где его хранить: на карте памяти оно весило в разы больше, когда каждый мелкий файл весом в несколько байт по факту занимал 32 Кб (в зависимости от размера кластера).
В 2007 уже iPhone вышел, если что.
А в 2005 нам еще полным ходом приходилось выпускать версию под S40 с ее MIDP 1. Так что я бы сказал, что жесткие ограничения по JAR приходилось терпеть практически весь цикл жизни J2ME игр.
У Nokia s40 было ограничение 64к на весь jar, не на один класс. И все что можно пихали в один класс как раз из-за этого ограничения, т.к. в виде отдельных классов тот же набор полей и методов давал заметно(сотни байт на класс) больший размер jar. Выглядело это жутко, но другой возможности запихнуть в 64к и код и арт и звуки не было. Говорю это как разработчик пошаговой стратегии с изометрией и сетевым режимом, которая работала на s40 :)
S40 были тоже разные. У меня был Nokia 6300, там был точно 1МБ на весь JAR. Какую-то игру путем подмены PNG-картинок я даже патчил, чтобы влезала в это ограничение. Но на других S40-телефонах, наверное, были другие лимиты.
Да, я про самые массовые midp 1.0 телефоны, типа 3100. Пока требовалась их поддержка разработка была адом :) Хотя самым адищем тогда были младшие самсунги.... Большего количества грязных хаков чтобы хоть как-то заставить на них что-то работать, не требовал ни кто :)
А что в них не так было (самсунгах)?
За 20 лет уже много забылось осталось только общее впечатление. Но если не ошибаюсь это медленная работа с файлами (внутри самого jar), отдельная видео память, которой не хватало (та же нокия s40 dp1 позволяла часть картинок динамически, каждый кадр подгружать из jar на время отрисовки и потом удалять из памяти). Работа с сетью была хождением по минам, чуть что-то не в том порядке вызвал и зависает все намертво. При этом ни логов, ни дебага нет :)
Являясь j2me энтузиастом, для меня было большой проблемой найти и настроить рабочую IDE в этом году. Десять лет назад всё само ставилось на Netbeans, но сейчас даже дистрибутив под нужную версию оказалось найти трудно. (Сайт с плагинами бобов под java уже год как умер) А ещё говорили, что интернет помнит всё...
Радует, что статьи по мобильной джаве продолжают выходить) И вдвойне радует, что благодаря fernflower можно получить рабочий код большинства игр и приложений. Хотя не совсем ясен легальный статус результата такого реверс-инжиниринга, может знающие люди подскажут?
Скрин из Galaxy on fire 2, будто переместился лет на 15 назад
Дааа, аж олдскулы свело. Я как раз занимался J2ME-разработкой годах в 2006-2010. Вся команда ненавидела Самсунги и Нокии, в первых часто фрагментировалась память, а во вторых была куча багов.
Хехе, здорово. Так в любой реализации Java-машины фрагментируются память, это ж куча. Или там прям до крашей или ребутов системы доходила?
У Nokia иногда хип подрезали сильно
Не знаю, как-то SE и Моторолы справлялись с этим, видимо перемещали память. А у Самсунгов прям жопа была. Приходилось в определённом порядке загружать и выгружать картинки, чтобы не было OOM.
На самом деле, в "больших" JVM память настолько не фрагментируется - там перемещающие GC, они сдвигают выжившие объекты друг к другу так, что свободное место (в каждом поколении) всегда одним куском.
Подозреваю, что конкретно для мобильных телефонов это могли посчитать расточительным, и сделать, грубо говоря, просто malloc/free.
... к 2009 году, в РФ уже появился +- стабильный 3G и можно было поиграть в игры с достаточно быстрым и стабильным интернетом
Не напомните кнопочные телефоны с J2ME, которые поддерживали 3G? Сейчас продаются китайские с 3G, но без J2ME и в основном на Android...
Из первого попавшегося - Nokia 6700 classic
Последние SE, в частности Elm, поддерживают и Wifi, и 3G
Все на BB5 насколько я помню, плюс на инфинеоне.
Samsung держал 3G если не ошибаюсь.
Многие поздние Nokia, C5-00, например.
У самого был такой мутант как Asha 300, с кнопками и сенсором. Очень многие Java-игры на нём крутились без каких-либо проблем.
Nokia 6500s тоже
А ещё для разработки простых приложений и игр был MidletPascal - настолько лёгкая платформа, что освоить мог и школьник, хотя бы немного знающий Паскаль (Delphi). Компиляция производилась в байт-код JVM.
Для желающих поностальгировать, лучше найти последнюю из 2.х версий. Версии 3.х созданы на основе исходников, которые автор передал энтузиастам с boolean.name, но сообщество так и не осилило большинство новых функций.
Но в принципе там и j2me не сложная - а мидлет паскаль всё-таки довольно ограниченный.
Я когда-то давно писал код на midlet pascal, декомпилировал, смотрел что получилось на java и так потихоньку её освоил, а потом возвращаться на паскаль что-то уже не хотелось.
Из того что запомнилось - в midlet pascal boolean выражения вычислялись жадно (с точки зрения байткода там вообще преобразование boolean в байт и умножение или сложение), код вида if (a != null and a.isNotEmpty) надо было записывать в виде if (a != null) if (a.isNotEmpty), чтобы на нулевой строке не вызывалась вторая проверка.
И ещё в midlet pascal не было нормального ООП и возможности динамически создавать объекты, были только структуры и массивы структур, которые приходилось объявлять статически или как переменные внури функции.
Что-то сильно большое по объёму на паскале было сложно написать.
Но из плюсов - он действительно был очень простым.
Мне кажется, будь у меня сейчас современный телефон с j2me или я с текущими знаниями лет двадцать назад - я бы попробовал написать свой компилятор из какого-нибудь языка в байткод. Но по-факту j2me ушла в историю и особо никому не нужна.
Я виджу здесь собрались компетентные люди.
Подскажите, пожалуйста, под какие телефоны того времени было проще/приятнее/менее геморно писать JME игры?
Мне кажется, что это точно не нокиа )
SE
спасибо
а если точнее, какого года, какой линейки?
Любых кроме ODM и Sagem)
Попробовать хочется?
Ещё бы, так олдскулы свело!
У меня в те времена не располагал средствами на приличный sonyericsson
А сейчас даже нагуглил интересную модель J108i Cedar - вышел в 2010г на закате эры фичафонов, имеет microUSB, microSD и 3.5мм - песня!
А еще интересно посмотреть как это можно эмулировать на современном железе, и вдруг JVM от SE доступна для установки на другие системы!
Не скажу за железо, но разрабатывать и дебажить можно было с помощью MicroEmulator
Автор "мило" забыл про то, что встроенные шрифты были только под винду и Дайрикс. Остальные, все, даже сейчас, представляют собой банальные спрайты. Что драматично сказывается на скорости вывода на компе. Так как альфу и блендинг никто не отменял порой (для кроссплатформ особенно).
Ну а вращение спрайта, это настолько ходовое, что говорить не обо что. К слову, опять же, до сих пор. Выгодно. Места много, памяти тоже, зачем грузить гпу (в худших случаях цпу)?
Остальные, все, даже сейчас, представляют собой банальные спрайты
Почитайте что такое векторные и Distance-field шрифты :)
Что драматично сказывается на скорости вывода на компе
Битмапные шрифты значительно быстрее с точки зрения загрузки. Векторные шрифты тоже растеризуются.
К слову, опять же, до сих пор. Выгодно. Места много, памяти тоже, зачем грузить гпу (в худших случаях цпу)?
Сейчас 2D - это частный случай 3D. Почитайте основы программирования 3D графики и поймете, почему любые аффинные трансформации бесплатные на GPU. В Java-телефонах были повороты спрайтов, но не аффинные, а примитивные.
Альфа-блендинг на GPU не бесплатный в целом, но в 2D обычно не является боттлнеком.
Пользуюсь упомянутым выше в комментариях Sony Ericsson J108i Cedar. Спустя 14 лет телефон успешно работает, только немного просел динамик, приходится включать громкую связь. Игры и приложения идут отлично, можно загружать их по Bluetooth или с MicroSD карты.
Игры J2ME теплые и ламповые, в них есть дух олдскула, которого начисто лишены современные Android приложения. Да и неприсоблены совершенно сейчас сенсорные смартфоны и планшеты для игр. Геймпад-то, конечно, подключить по BT или USB можно, но большинство мобильных игр его просто не поддерживает. Неужели большинству приятно извращаться с тыканьем пальцем по экрану? Какой-то прямо массовый стокгольмский синдом...
В студенческую бытность увлекался как геймингом, так и написанием своих игр - в основном клонов с ZX/DOS/Dendy/Sega/SNES, была даже попытка запилить подобие JRPG в стиле Chrono Trigger или Final Fantasy 6. Android сейчас не вызывает абсолютно никакого интереса. Высказался бы даже покрепче, но тогда заминусуют (но день смерти его и его старшего Apple'овского брата будет для меня праздником).
Вот бы кто-нибудь выпустил портативную консоль, вроде Nintendo Switch с поддержкой J2ME - это была бы бомба... При всех ограничениях это была максимально дружелюбная платформа для начинающих игроделов.
Так странно, что Android на Java не мог запускать J2ME приложения. Вроде, был какой-то эмулятор для Android<2, но даже с ним как-то криво запускался Jimm.
И на контрасте WindowsMobile прекрасно запускал J2ME.
Геймдев, про который мы забыли: как работали 2D-игры на кнопочных телефонах нулевых