Comments 40
По моему «как играть не тыкая пальцем» это та самая «one more thing», для который и делалась текущая статья :) По крайней мере, мне очень интересно будет почитать.
Ссылку на stackoverflow поправьте.
Извините, не удержался, вот это
if (screenBounds.size.height == 568) {
iPhone5 = 1;
} else {
iPhone5 = 0;
}
(с нормальной подсветкой и сохранением переноса в комментарии не разобрался)
замените на
if (screenBounds.size.height == 568) {
iPhone5 = 1;
} else {
iPhone5 = 0;
}
(с нормальной подсветкой и сохранением переноса в комментарии не разобрался)
замените на
iPhone5=screenBounds.size.height == 568;
Мне платят построчно. С вашим подходом я на хлеб не заработаю.
Вы серьезно? Еще есть такие компании?
Мы даже еженедельные отчеты пишем. Правда к играм это почти не относится.
Мы ежедневные пишем, но такой заморочки со строчками кода нет)
Ну, PapaBubaDiop, ясное дело, прикалывается, но просветите меня, тёмного, вы вдвоём вообще сейчас обсуждаете реальный способ определения пятого айфона? Так, типа, и должно быть?
По сути, определяется не модель айфона, а разрешение экрана. И да, оно примерно так и определяется.
Я сам не знаю, я не программист вообще. Шучу, конечно)) Я писал всего-лишь про рефакторинг кода, а не про то что он делает.
Да, пример взят со stackoverflow.
Можно так stackoverflow.com/a/8478662/602249
Уже есть компании, за строчки штрафующие? :)
А какой смысл? Оптимальнее и быстрее работать не стало, а читаемость падает, по моему мнению.
И увеличивается стократ вероятность ошибки.
Тут все субъективно. Мне кажется, что читаемость стала лучше.
Так-так! Тут чего-то люди думают, что «оптимальнее и быстрее не стало», так вот, может быть вы не в курсе, но вообще-то в современных процессорах есть такая штука, как «предсказание ветвления», которое используется, чтобы предсказывать куда пойдёт выполнение программы и выполнить сразу пачку команд за раз. И вот в линейном коде оно работает прекрасно, смотрите:
ясно же, что тут две команды: сравнить 2 числа, записать результат в переменную. И предсказание ветвления захватывает эти команды в «пачку», да и плюс всё, что будет за ними. Классно, эффективно.
А теперь смотрите на код:
И вот тут уже хрен его знает, сработает предсказание ветвления верно или нет. В худшем случае на этапе обработки if предсказание сработает неверно в 50% случаев, повлияв не только на код в блоке if, но даже исключив из «пачки» код следующий дальше. Неэффективно, недетерминировано.
Конечно, в данном случае тип айфона, скорее всего, определяется 1 раз за всю работу программы, и тут оно пофигу, но вот если это цикл, который миллион итераций в секунду должен делать — может быть разница.
iPhone5=screenBounds.size.height == 568;
ясно же, что тут две команды: сравнить 2 числа, записать результат в переменную. И предсказание ветвления захватывает эти команды в «пачку», да и плюс всё, что будет за ними. Классно, эффективно.
А теперь смотрите на код:
if (screenBounds.size.height == 568) {
iPhone5 = 1;
} else {
iPhone5 = 0;
}
И вот тут уже хрен его знает, сработает предсказание ветвления верно или нет. В худшем случае на этапе обработки if предсказание сработает неверно в 50% случаев, повлияв не только на код в блоке if, но даже исключив из «пачки» код следующий дальше. Неэффективно, недетерминировано.
Конечно, в данном случае тип айфона, скорее всего, определяется 1 раз за всю работу программы, и тут оно пофигу, но вот если это цикл, который миллион итераций в секунду должен делать — может быть разница.
Хм, ну в этой области я не знаток. А разве это сложное ветвление, чтобы ошибиться на нем?
Дело не в том, сложное оно или нет, оно просто есть как факт, а значит уже, в зависимости от проца и компилятора, есть вероятность ошибки предсказания ветвления. Если у вас есть один кусок кода, который 100% избежит а этой ошибки, а второй длиннее на 4 строки и с некоторой вероятностью в эту ошибку попадёт — какой лучше?
Как играть, не тыкая пальцем в экран, я напишу в другой статье. Если интересно.
Конечно интересно!
Например, для кнопки размером 60х60 пикселей, создаю картинку размером 240х240… Но экономлю энергию экрана.
Я вот этот момент не понял. Почему 240x240? Почему не 120x120 (для ретины)? Как это экономит энергию экрана?
Одно замечание по поводу дизайна: мне не понятен Ваш выбор указателя «мыши» для игры, виндовый курсор выглядит чужеродно на i-девайсе.
UFO just landed and posted this here
Спасибо! Отличная статья, здравый подход к разработке :) Мне будет очень интересно прочитать продолжение.
> 500 евро за 5 минут стерео?
в Microsoft напишите: я буду использовать только 10% функций и переключу экран в в 256 цветов и 640х480, продайте «Офис» за $10. :)
в Microsoft напишите: я буду использовать только 10% функций и переключу экран в в 256 цветов и 640х480, продайте «Офис» за $10. :)
Понятно почему. Классический Lines имеет слишком большую доску размером 9х9 клеток. iPhone же комфортен на полях 6х6. Это предел для тыканья пальцем в экран.
Вот тут не соглашусь в ZOOKEEPER 8х8 и вроде нормально тыкается.
средняя цена на приложение из iTunes наверное около $2. но я же не буду играть в него 24/7, а всего часик в день. продадите мне игру за 8.3 цента?
Это разумный подход, он часто где применяется, порой завуалировано. Попользовался программой- кредит списали. К сожалению, на русскую действительность это не распространяется- купил машину- плати за дороги, даже если не ездишь.
Почему нет? Я бы продал, будь на то техническая возможность. Продавать цифровые копии нужно по той цене, которую покупатель с радостью заплат. Кто-то заплатит 2$, кто-то 2 цента, а кто-то и 20$. В результате все довольны. У Джоэля Спольски была неплохая статья на эту тему.
Шикарный стиль изложения, пишите чаще, пожалуйста.
Sign up to leave a comment.
7 бубей iOS разработчика игр