Давно собирался сделать разбор интерфейсов и логики взаимодействия некоторых iOS приложений. С одной стороны это хорошее упражнение для меня как дизайнера, с другой стороны, вдруг, я окажусь прав в своих мыслях, и разработчики прислушаются и улучшат свои творения, даже если их нет в данной заметке.

1. Альфа-Банк

Перевод статьи Introduction to CocosBuilder.
Автор оригинальной статьи Али Хафиджи, разработчик под iOS и Android.

CocosBuilder – это бесплатный инструмент, который позволяет быстро и легко управлять спрайтами, макетами и сценами при разработке вашей игры, использующей Cocos2D.

CocosBuilder идеально подходит для быстрой планировки меню и других элементов интерфейса игровых сцен, при этом вы не будете испытывать проблем по их компоновке в пространстве.
В ходе обучения вы напишите игру Cat Jump. Вы увидите, как CocosBuilder позволит вам сэкономить массу времени и кода.

Разработка мобильных приложений это весьма перспективное и выгодное занятие. Одним из самых интересных направлений являются игры. Однако, игры — это довольно сложные приложения, а учитывая, что на рынке существует как минимум две мобильные платформы, на которые стоит ориентироваться, сложность возрастает вдвойне. По этому, нам надо как то облегчить свой и без того нелегкий труд.

Привет всем! Хочу поделиться своим опытом разработки приложений под Marmalade SDK.

Хочу напомнить, что Мармелад — это замечательный инструмент для создания мультиплатформенных приложений. Можно написать приложения, как под телевизоры LG TV, так и под мобильные устройства (на базе Android, Bada, iOS, Symbian и WindowsMobile).
В данной статье вы найдёте:

• процесс создания приложения под Marmalade SDK;
• определение столкновений (collision detection) выпуклых многоугольников, при помощи построения проекций;
• определение реакции на столкновение (вывод объекта по минимальному пути).

Немного предисловия. Однажды, для одного проекта, мне потребовалось реализовать проверку на столкновения различных объектов. И я был очень удивлён тем фактом, что, не смотря на то, что практически ни одна игра не обходится без проверок на столкновение и пересечение объектов, не так-то просто найти уже готовые решения и простые примеры для такой задачи. Тем более с более-менее ясными объяснениями. Пришлось реализовывать самостоятельно.

Заранее хочу предупредить, что весь код, приведенный в статье, написан на C++.

Некоторое время назад RIM совместно с Marmalade проводили акцию по которой и мне удалось получить планшет Blackberry Playbook. По условиям акции в течение полугода с момента регистрации необходимо разработать и загрузить в Blackberry App World игру сделанную при помощи Marmlade SDK. После изучения в сети некоторого количества материала об этом SDK я наткнулся на записи о том что есть возможность использовать Cocos2D-x, что возможно сократило бы мне время на разработку(хотя я не имею опыта работы ни с Marmalade ни с Cocos2D-x). Далее я скачал последний релиз Cocos2D-x и не обнаружил в нём никаких следов возможности взаимодействия с Marmalade SDK.

Ранее я уже рассказывал о разработке небольшого игрового Framework-а с использованием инструментальной платформы Marmalade. Разумеется, в том виде, в котором он выложен на GitHub он вряд ли пригоден для разработки чего-то более сложного чем демонстрационное приложение. В нем не хватает многих возможностей, необходимых для разработки более-менее серьезного приложения. К счастью, Framework спроектирован достаточно гибко, чтобы недостающие возможности можно было легко добавить.

Как я уже говорил, описанному мной ранее framework-у не хватает очень многого, для того чтобы считаться полноценным игровым движком. В нем нет моделирования физики, он использует негибкий и не быстрый Iw2D для вывода графики. Фактически, все что он умеет делать — это выполнение 2D анимации спрайтов, сопровождаемое звуковыми эффектами. Чтобы как-то расти над собой, очевидно, необходимо осваивать новые возможности, но делать это, не имея какой-то цели, скучно и неинтересно.

Мы поставим перед собой цель, и разработаем небольшой прототип всем известной игры Arcanoid. Для начала, попробуем внять совету уважаемого crmMaster и попытаться разобраться с тем, что-же такое IwGl и как его можно использовать. Правда натягивать текстуры на куб мы сегодня не будем. Начинать надо с простого, и сегодня мы поучимся рисовать треугольники.

В этом цикле статей я опишу разработку небольшого Framework-а, предназначенного для создания 2D-игр, с использованием Marmalade. Marmalade предоставляет API для разработки кросс-платформенных приложений, позволяя собирать их, в том числе, под Android и iOS. Работа в Marmalade довольно комфортна, а его справочная система сопровождена большим количеством примеров, но сам процесс разработки носит довольно низкоуровневый характер. Использование готового Framework-а может сильно облегчить жизнь начинающему разработчику.

В сети и на Хабре уже довольно много статей вводного уровня про то, как начать писать на Scala, и раскрывающих особенности функционального подхода.

Какое-то время назад мы полностью перевели на Scala один из основных для веба проектов. За это время я наблюдал эволюцию разработчиков, включая свою собственную, и у меня скопился объёмный список конструкций, которые тянет написать, если вы раньше писали на Java, и для которых правильное решение на Scala может не быть сходу очевидным. Данные рекомендации могут быть не очень понятны тем, кто до сих пор пишет на Java и не видел до этого код на Scala. Я не буду разъяснять работу стандартных функций и функциональных концепций, всё ищется по ключевым словам в сети.

С каждым днем слово java все больше и больше воспринимается уже не как язык, а как платформа благодаря небезызвестному invokeDynamic. Именно поэтому сегодня я бы хотел поговорить про виртуальную java машину, а именно — об так называемых Performance опциях в Oracle HotSpot JVM версии 1.6 и выше (server). Потому что сегодня почти не встретить людей, которые знают что-то больше чем -Xmx, -Xms и -Xss. В свое время, когда я начал углубляться в тему, то обнаружил огромное количество интересной информации, которой и хочу поделится. Отправной точкой, понятное дело, послужила официальная документация от Oracle. А дальше — гугл, эксперименты и общение:

-XX:+DoEscapeAnalysis

Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Как многие из Вас знают, примитивы и ссылки на объекты создаются не в куче, а выделяются на стеке потока (256КБ по умолчанию для Hotspot). Вполне очевидно, что язык java не позволяет создавать объекты на стеке на прямую. Но это вполне себе может проделывать Ваша JVM 1.6 начиная с 14 апдейта.

Про то, как работает сам алгоритм можно прочитать тут (PDF). Если коротко, то:

• Если область видимости объекта не выходит за область метода, в котором он создается, то такой объект может быть создан на фрейме стека вместо кучи (на самом деле не сам объект, а его поля, на совокупность которых заменяется объект);
• Если объект не покидает область видимости потока, то к такому объекту другие потоки не имеют доступа и следовательно все операции синхронизации над объектом могут быть удалены.

Для реализации данного алгоритма строится и используется так называемый — граф связей (connection graph), по которому на этапе анализа (алгоритмов анализа — несколько) осуществляется проход для нахождения пересечений с другими потоками и методами.
Таким образом после прохода графа связей для любого объекта возможно одно из следующих следующих состояний:

• GlobalEscape — объект доступен из других потоков и из других методов, например статическое поле.
• ArgEscape — объект был передан как аргумент или на него есть ссылка из объекта аргумента, но сам он не выходит из области видимости потока в котором был создан.
• NoEscape — объект не покидает область видимости метода и его создание может быть вынесено на стек.

После этапа анализа, уже сама JVM проводит возможную оптимизацию: в случае если объект NoEscape, то он может быть создан на стеке; если объект NoEscape или ArgEscape, то операции синхронизации над ним могут быть удалены.

Следует уточнить, что на стеке создается не сам объект а его поля. Так как JVM заменяет цельный объект на совокупность его полей (спасибо Walrus за уточнение).

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

    for (int i = 0; i < 1000*1000*1000; i++) {
        Foo foo = new Foo();
    }

скорость выполнения может увеличится в 8-15 раз. Хотя, на казалось бы, очевидных случаях из практики о которых недавно писалось (тут и тут) EscapeAnalys не работает. Подозреваю, что это связано с размером стека.

Кстати, EscapeAnalysis как раз частично ответственен за известный спор про StringBuilder и StringBuffer. То есть, если Вы вдруг в методе использовали StringBuffer вместо StringBuilder, то EscapeAnalysis (в случае срабатывания) устранит блокировки для StringBuffer'а, после чего StringBuffer вполне превращается в StringBuilder.

Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

Понадобилось мне прикрутить Lua к проекту на C++. Писать обертки в ручную — лень (слишком много писать), готовые не подходили по тем или иным причинам. Решил написать свою. А потому задался вопросом, как максимально упростить интерфейс? От одной только мысли об этом в голову лезли жутчайшие конструкции из шаблонов. Так оно в последствии и оказалось, но гораздо проще, чем представлялось.

В C++11 появились шаблоны с переменным числом аргументов, это позволяет писать шаблонные функции/классы так, как в C++03 было невозможно вовсе. Такие шаблоны сильно упрощают задачу.

Первым делом понадобилось написать обертку над простейшими действиями с интерпретатором (можно было бы обойтись простыми вызовами к C API Lua, но держать в памяти кучу индексов различных значений в стеке мне не хочется. Поэтому я обернул их в несколько функций, которые помимо того, что избавляют от необходимости передавать в каждую функцию указатель на состояние интерпретатора, практически не требуют индексов, так как они имеют значения по умолчанию.

В итоге хотелось увидеть интерфейс близкий к следующему:

lua.export_function(some_function);

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



Для имитации этого эффекта в играх используется механизм, называемый tonemapping.

tonemapping — процесс проекции всего бесконечного интервала яркостей (HDR, high dynamic range, от 0 и до бесконечности) на конечный интервал восприятия глаза/камеры/монитора (LDR, low dynamic range, ограничен с обоих сторон).

Для того, чтобы работать с HDR, нам понадобится соответствующий экранный буфер, поддерживающий значения больше единицы. Наша же задача будет состоять в правильной конвертации этих значений в диапазон [0..1].

Сегодня мы будем заниматься постпроцессингом изображения в DirectX.

Как известно, в темноте зрение человека обеспечивается клетками-палочками сетчатки, высокая световая чувствительность которых достигается за счет потери цветочувствительности и остроты зрения (хотя палочек в сетчатке и больше, они распределены по гораздо большей площади, так что суммарное «разрешение» выходит меньше).

Все эти эффекты можно наблюдать самому, оторвавшись от компьютера и выйдя ночью на улицу.

В результате мы получим что-то вроде следующего (смотреть на весь экран!):

До: унылый польский шутер


После: финалист IGF и лауреат всех наград E3

Сегодня я хочу вам рассказать о создании игры для iOS на основе Cocos2D на примере недавно вышедшей игры «Пчелогонки» (анг. – Bee Race).
Геймплей не содержит в себе ничего сложного – это по сути бесконечный ранер, в котором нужно собирать поинты и уворачиваться от препятствий. Только вместо рыжей девочки или кладоискателя – здесь летает двухмерная пчелка.
Для заинтересовавшихся, прошу под кат (Ахтунг! Минен унд много буквирен).
Основные разделы для рассмотрения:

1. Очень краткое введение в Cocos2D
2. Используем Cocos2D одновременно с StoryBoard
3. Краткое описание геймплея и структуры проекта
4. Покупаем инструменты и что делать, если душит жаба
5. Чем не пахнет приложение или подключаем in-app билинг
6. Социализируем. Подключаем Game Center и создаем мультиплеерную версию на два игрока
7. В чём промахнулся Акела
8. Паблиш

Спойлер:

Думаю, каждому программисту знаком принцип единственной ответственности, ведь не зря он существует: соблюдая его, можно написать код лучше, он будет более понятным, его будет легче дорабатывать.

Но чем больше каждый из нас работает с кодом, тем больше приходит понимание того, что на существующем уровне языка — объектно-ориентированном — этого сделать невозможно. А мешает нам в соблюдении принципа единственной ответственности такой факт, как сквозная функциональность.

Эта статья о том, как можно избавиться от дублирования сквозного кода, и как сделать его чуточку лучше с помощью АОП.

Зачастую при поиске движущихся объектов на видео будь то методом вычитания фона, временной разности, оптического потока, в итоге мы получаем множество точек, которые после действия вышеупомянутых алгоритмов помечены как изменившие свое положение относительно предыдущего кадра и относящиеся к переднему плану.



После такой обработки встает вопрос о сегментации объектов методом кластерного анализа, о котором пойдет речь ниже и собственно его реализация на C++.

В языках с автоматическим управлением памятью сборщик мусора удаляет объекты, когда они перестают быть доступными по ссылкам. Обычно это именно то, что нужно: объект существует, пока есть возможность к нему обратиться.
Иногда такое поведение не подходит. Например, программе понадобилось хранить некоторую вспомогательную информацию об экземплярах некоторого класса, но у вас нет возможности добавить в этот класс своё поле. В этом случае можно создать отображение, в котором ключом будет объект, а значением — вспомогательная информация.
Вот тут-то и начинаются проблемы. Поскольку отображение хранит ссылки на ключи, те объекты, к которым была привязана вспомогательная информация, перестают освобождаться из памяти. Если программа в процессе своей работы создаёт много объектов, память рано или поздно заканчивается.

Все мы слышали поговорку: как новый год встретишь — так его и проведешь. Оливье в сторону!

Рассчитывать на 5 часов адского программирования в праздник было бы негуманно, потому задача всего одна и она весьма лапидарна:

Программа должна прочитать из стандартного потока ввода целое число N (от 1 до 2³⁰), и напечатать сумму простых чисел меньших либо равных N.

Побеждает тот, кто напишет самое быстрое решение, проходящее все тесты (хотя-бы один неправильный ответ — и решение отклоняется). Скорость решения оценивается на тестах в районе верхней границы допустимого диапазона N (но не ровно 2³⁰).

Победитель получает всеобщее признание, сотни кармы и приятное чувство что он порвал всех на Хабре. Долгие годы молодые поколения разработчиков будут восхищаться его кодом, а девушки — чепчики в воздух бросать. По меньшей мере первые 4 read-only пользователя будут приглашены на Хабр.

Здравствуйте! В этой статье я вкратце расскажу вам о процессах, потоках, и об основах многопоточного программирования на языке Java.
Наиболее очевидная область применения многопоточности – это программирование интерфейсов. Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации. Например, поток, отвечающий за интерфейс, может ждать завершения другого потока, загружающего файл из интернета, и в это время выводить некоторую анимацию или обновлять прогресс-бар. Кроме того он может остановить поток загружающий файл, если была нажата кнопка «отмена».

Еще одна популярная и, пожалуй, одна из самых хардкорных областей применения многопоточности – игры. В играх различные потоки могут отвечать за работу с сетью, анимацию, расчет физики и т.п.

Давайте начнем. Сначала о процессах.