Комментарии 32
Если честно, я очень хотел успеть доделать играбельную демку к сегодняшнему дню... но то там дела, то сям и по итогу не успел :) Так то те же самые танчики хоть за 24 часа написать можно, если делать всё по принципу KISS ;)
Но если вдруг вам интересна рубрика разработки самопальных игр - жду от вас фидбека. К сожалению сейчас не так много людей пилят что-то абсолютно с нуля, а пишут об этом вообще единицы... ну, буду как раз одним из таких авторов)
Ну и объявлю розыск. Дело в том, что я недавно купил интересный MIPS-ноутбук на процессоре Ingenic JZ4750, точь в точь как был у @dlinyj . У моего экземпляра слетела прошивка: ядро загружается, а вот раздел с Qtopia поврежден. Если вдруг у кого-то есть такой ноутбук и вы готовы посодействовать снятию дампа - буду ждать вашего сообщения в личку!
Скрытый текст
велик уже придуман - kkrieger by the produkkt - там еще меньше 600кб можно сделать)
но да не j2me и под win
kkrieger крутая технодемка, но она далека от концепции разработки миниатюрных игрушек для мобильных платформ)
Я то не просто так опенсорснул наработки, может в будущем кто-то захочет что-то намутить с моим великом для ретро-устройств)
интересна рубрика разработки самопальных игр
Очень интересно! Недавно начал познавать ЯП с мощным ООП и такие проекты очень вдохновляют. А то как у вас расписаны прямо целые кейсы, так вообще подарок, можно хоть немного разобраться человеку, далёкому от геймдева
Когда-то играл в Dungeon Warrior 3D: 128 кБ псевдотрёхмерная игра работала даже на телефонах вроде Nokia 2610 (S40v2, экран 128x128, не поддерживал загрузку файлов > 300 кБ и запуск j2me > 250 кБ, мало heap из-за чего часто случался OutOfMemoryError). Помню псевдо3D гонки с весом менее 100 кБ, но название вылетело из головы :(
К чему это пишу? Возможно, кому-то будут интересны движки этих игр, программно имитирующие трёхмерную графику на слабых устройствах. У них есть чему поучиться.
Кстати, они еще и крайне необычные под капотом. Дело в том что многие такие игры не использовали API M3G или Mascot Capsule, а писали софтрендер с нуля... На Java! Для кнопочных телефонов!!!
Вспоминается движок Quantum с софтверным рендером) Даже игры на нём делали. Правда по фпс он зачастую проигрывал Маскоту или m3g
В памяти всплыл ещё Labyrint с Siemens C35. Тут и генерация коридоров (емнип), и псевдо3D, из-за чего у меня в 1 классе сломался мозг: месяц в принципе не понимал как в это играть, потом осенило.
raycasting и спрайты - напоминает Wolfenstein 3D
Doom RPG и Doom 2 RPG - отличные примеры игр и игровых движков (доступных к изучению, правда в обфусцированном виде). Там и для отрисовки кастомные вещи и для хранения текстур и для логики. Копайся не хочу)
Такое на мой телефон не удалось бы скачать, а даже если бы и удалось - OutOfMemoryError. Я имел ввиду псевдотрёхмерные игры, запускающиеся на бюджетных мобильниках, а не на Sony Ericsson)
Спеки Nokia 2610
А, там лимит в 150 кб. Только в это упирается, понял вас
Не-не. На практике лимит на загрузку файлов и воспроизведение мультимедиа до 300 кБ, на установку и запуск jar - до 250 кБ, но всё упирается в heap. Если запустить jar-приложение слишком большого размера (чаще всего > 150 кБ), получится вылет в OutOfMemory Error. Именно из-за малого объёма heap сидел на Opera Mini 3.1 (60 кБ jar) и стандартном Jimm 0.5.1 без модулей и наворотов (111 кБ jar). Музыка только в midi, MP3 и AMR чаще всего весили > 300 кБ.
Именно поэтому 3D, пусть и имитируемое, произвело на меня в своё время большое впечатление: думал, что на моей звонилке это вообще невозможно.
десятки готовых игровых движков под самые разные задачи
не десятки
все игры на Unreal engine и Unity выглядят примерно одинаково что выхолащивает жанр
во 2 г. не хватает варианта по типу "во мы свое время писали на асме и..." а впрочем сайзкодинг всяких демок и сейчас популярен, сколько там keriger занимает :)
mipLevels[i].Buffer.put(palette[pixel1 + 1]);
каждый раз, когда видел в статье что-то такое на Java, представлял себе насколько неэффективно это все работает
Да не, норм вполне, аплоад ресурсов и на мобильных платформах быстрый. Если смущает использование нативных буферов - в джаве либо использовать их (можно со стороны JNI получить прямой указатель), либо аллокейтить массив флоатов и копировать их из JNI части. Соответственно в случае буферов я стараюсь преаллокейтнуть и потом до последнего юзать без реаллока существующий буфер :)
Неэффективно это если б я вместо статического массива нахлобучил ArrayList, дергал бы каждый пиксель get и только потом пушил бы пиксель, а затем еще и вызвал бы toArray. Или речь о том, что Buffer[i] можно было кэшировать? Это сделает оптимизатор :)
Или вы не о моем коде, а об общих принципах интеропа с нативным кодом в Java? Если так, то соглашусь, дотнет сильно круче) можно спокойно дергать указатели на буфер с value типами) на джаве сделать софтовый морфинг или скиннинг дороговато. Во времена шейдерных гпу это не то чтобы актуально, но все равно как факт некоторой ограниченности Java
Пишем 3D-игру весом в 600Кб…