Оптимизация кода под Pebble

[Hertz]

14. Используйте int как основной тип, даже если следует пересчитать от 0 до 5. Думаю, выигрыш связан с тем, что компилятор вставляет дополнительный код, если используются меньшие типы.

Верно, в арифметических операциях над операндами меньших чем int типов, операнды приводятся к int перед выполнением операции, результат приводится к нужному типу после ее выполнения.

[RPG]

Эти бы слова, да разработчикам Android…

Не знаком с платформой, но если в качестве компилятора используется gcc, можно тюнить параметры компилятора прямо в сходном коде. В частности, всякие pragma optimize и атрибуты функций. Возможно там и так стоит -Os, но данным способом можно для некоторых «горячих точек» скорости добавить или наоборот.

[lol2Fast4U]

Спасибо огромное, это прекрасно! Я даже думал о покупке такого Siemens'а на eBay. А тут как раз черно-белый экран, оригинальная графика… только подсветка экрана не оранжевая :D

P.S. Оно… работало… на джаве? o_0

[svitlana_tsymbaliuk]

Да, оно работало на Java, точнее J2ME. Вы можете скачать эмулятор и саму игру по ссылкам из статьи. Возможно, даже получится декомпилировать и посмотреть, что внутри.

[Fuzzyjammer]

Многие телефоны, несмотря на отсутствие возможности заливки пользовательских j2me-приложений, имели-таки жаву для запуска предустановленных программ/игр.

[tmnhy]

Раз коснулись rand(), после localtime() остается 40b.

[grep0]

По моему небольшому опыту программирования Pebble, потребляемая мощность гораздо важнее экономии памяти. Программная прорисовка на 60 кадрах в секунду это, наверное, лучший способ быстро посадить батарейку.

[svitlana_tsymbaliuk]

Быстрее всего батарейку при игре садит подсветка. Да и вряд ли пользователь ожидает, что в таком режиме часы, простите за каламбур, проживут дольше пары часов.
Кстати, вы можете попробовать изменить время тика и, соответственно, FPS. Для этого скомпилируйте проект, изменив в stack_attack.c:10

#define FPS 60

Но учтите, что больше 60 раз на секунду pebble изменять содержимое экрана не позволяет.

[vvzvlad]

Подсветка, подтверждаю. Из-за того, что в экране есть отражающая пленка для хорошей видимости на солнце, он практически непрозрачный на просвет. Соответственно для подсветки там используются довольно яркие светодиоды.

[CeyT]

Во, уже промежуточные оттенки генерируют. Скоро кто-нибудь найдёт заводской глюк, вызывающий кратковременные радужные разводы на жидкокристаллическом экранчике, и через некоторое время у нас будут программно контролируемые цветные режимы и подобные радости: www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

[vvzvlad]

Кратковременные? Вы про пластиковую версию? Это из-за поляризации в материале пластика корпуса, сделать с этим ничего не получится.

[tyderh]

О да!

Помню, в этой игре был багфича: каким-то образом можно было тянуть блоки на себя, и если сделать это у края экрана, можно было за этот край вылезти и сидеть там бесконечно долго, наблюдая за падением блоков. Вы его воспроизвели?

[svitlana_tsymbaliuk]

Вы, наверное, путаете черно-белую игру от Mophun и одного из ее, на мой взгляд неудачных, наследников. Действительно, подобная игра (Stack Attack Junior) была и на Siemens A60, например. Телефон Java не поддерживал, но по железу был идентичен Siemens C60, который ее поддерживал. Вполне допускаю, что возможность была програмно заблокированной, и игра под А60 была тоже написаной на Java, по крайней мере один признак Java-игр у нее точно был — она очень медленно работала. Так вот, в последующих играх серии Stack Attack были другие бонусы, в том числе и «Вытянуть ящик из стопки» у одного из персонажей. Я же реализовала только те, что были в игре для ч/б Siemens'ов: бомба, большой прыжок (J), каска (P), дополнительная жизнь (L) и открытие персонажа (точка). Но всегда можно создать форк на github!

[TsarIoann]

Ностальгический Stack Attack! Божественно!
Не так давно начал писать Stack Attack для андроид, но к сожалению, не хватило времени закончить.