Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

Первая часть

От переводчика. OlegKozlov рассказал о приёмах камеры в своей игре «Несыть». Из-за большого количества трафика и не слишком верно действующего JS якорь перебрасывает куда угодно, только не на комментарий, поэтому сделаю копию здесь.

Ну и по поводу навязчивости и комфорта. Было тяжело переводить и ещё тяжелее вычитывать, анимация в периферийном зрении очень мешала, да и нагруженные анимацией страницы заглючивали «рыжую». И простите, что на день бросил первую часть под замок.

Направление

Подсказываем, куда идти, близко ли цель и что рядом важного

Мы уже рассмотрели, как сделать, чтобы поле зрения игрока соответствовало управлению, и как показать то, что игрок хочет видеть — в нашем треугольнике это взаимодействие. Также мы осветили множество способов сделать прокрутку ненавязчивой, но действенной (комфорт). Теперь, как режиссёры игры, попробуем обратить внимание публики на то, что мы сами хотим ей показать — то ли ради контекста, то ли чтобы подчеркнуть течение игры, то ли ради драмы и сюжета.

Wonder Boy, ещё одна моя любимица, быстрый платформер, в котором можно идти только вперёд через старое доброе одностороннее окно свободного хода. В отличие то Super Mario Bros., там нет зоны разгона, плавно ускоряющей камеру, но есть другая интересная техника, которую я называю «рельсы». Камера ставится и движется так, чтобы предвосхищать будущие преграды.

Wonder Boy (Sega, 1986)

Рельсы: запрограммированный маршрут камеры Зона свободного хода (односторонняя) Статическое упреждение

Пятое поколение приставок, среди них PlayStation и Nintendo 64, открыло новые аппаратные возможности, положив начала грубому, но настоящему 3D. Приёмы трёхмерной камеры — сами по себе захватывающая и многогранная тема, но поддержка 3D повлияла и на двухмерные игры. Разработчики теперь могут приближать камеру, наклонять вид и даже сочетать 2D и 3D — то, что мы сейчас называем 2,5D, когда игра идёт на двухмерной плоскости, но в объёмном мире.

В прошлой статье про SecureBoot мне очень не хватало возможности сделать снимок экрана при настройке UEFI через BIOS Setup, но тогда выручило перенаправление текстовой консоли в последовательный порт. Это отличное решение, но доступно оно на немногих серверных материнских платах, и через него можно получить только псевдографику, а хотелось бы получить настоящую — она и выглядит приятнее, и вырезать ее каждый раз из окна терминала не надо.
Вот именно этим мы и займемся в этой статье, а заодно я расскажу, что такое DXE-драйвер и как написать, собрать и протестировать такой самостоятельно, как работают ввод с клавиатуры и вывод на экран в UEFI, как найти среди подключенных устройств хранения такое, на которое можно записывать файлы, как сохранить что-нибудь в файл из UEFI и как адаптировать какой-то внешний код на С для работы в составе прошивки.
Если вам все еще интересно — жду вас под катом.

Сейчас в Гамбурге проходит конференция Chaos Communication Congress под кодовым обозначением 32С3 (она 32-я по счету). Хакерская группа Fai0verflow представила доклад с демонстрацией запуска Linux на консоли четвертого поколения от Sony. После недавнего джейлбрейка консоли это было ожидаемо. Enjoy!

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

Желание максимально приблизится к аутентичности заставило поставить для себя несколько главных задач по моддингу:
1. Корпус иксбокса оставить нетронутым, все основные разъемы с материнки вывести через разъемы иксбоксовского корпуса.
2. Питание сделать от иксбоксовского 12 вольтового БП.
3. Поставить DVD привод с внешней кнопкой выброса.
4. Поставить внутрь корпуса ресивер для беспроводных геймпадов иксбокса с кнопкой синхронизации.

Поехали.

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

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

Всем привет!

В прошлой статье я запустил простой OpenCL пример на FPGA фирмы Altera:

// ACL kernel for adding two input vectors
__kernel void vector_add( __global const uint *restrict x,  
                          __global const uint *restrict y,  
                          __global       uint *restrict z )
{
    // get index of the work item
    int index = get_global_id(0);
 
    // add the vector elements
    z[index] = x[index] + y[index];
}

Я намеренно не углублялся в детали и показал верхушку айсберга: процесс разработки, сборку проекта, запуск на системе.

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

В этой статье мы попробуем вскрыть ядро и найти ответы на следующие вопросы:

• Какая у него архитектура?
• Как происходит его настройка? Как попадают данные на обработку?
• На какой частоте он работает? Чем это определяется?
• Можно ли просимулировать только ядро в RTL-симуляторах?
• Какие блоки занимают больше всего ресурсов? Можно ли как-то это соптимизировать?

Давайте взглянём на его внутренности! Добро пожаловать под кат!

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

---

Предыстория

Ранее мой опыт работы с платформой был близок к нулю, поэтому чтобы разобраться в огромном количестве сервисов платформы, я снова обратился к своему знакомому из IBM. Мне казалось очевидным использовать сервис Message Hub, но в итоге оказалось, что для решения нашей задачи лучше подойдет MQ Light. Основные причины:

• тариф в бесплатные 10 тысяч сообщений в месяц
• хорошая масштабируемость
• простой в использовании API

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

Автор назвал эту технику “loops fracking” по аналогии с, например, “loops unrolling” или “loops nesting”. Тем более, что термин отражает смысл и не занят.

Сегодня я расскажу о неожиданных проблемах, которые возникли при подключении матричной клавиатуры к ARM-борде под управлением Linux в приборе Беркут-ETN (ETN — новая аппаратная ревизия Беркут-ET). А конкретно о том, почему драйвер adp5589 не захотел получать прерывания и как мы смогли заставить его это делать.

Кому интересно — добро пожаловать под кат.

Введение

В своих статьях о переходе на российский микроконтроллер К1986ВЕ92QI я ни раз рассказывал о генерации звука средствами микроконтроллера. Тогда передо мной стояла задача лишь воспроизвести данные. Для создания этих самих данных, получаемых из MIDI файлов, использовались весьма экзотические методы, например, как в этой статье. Да, подобные методы имеют право на жизнь, если требуется получить данные для воспроизведения пару раз в жизни. Но так как я достаточно часто сталкиваюсь с задачами, когда на контроллере нужно получить достаточно сложный звук, или же звук — лишь дополнительная опция, то задача преобразовывать MIDI файлы такими экзотическими способами, становится весьма нетривиальной. В этой небольшой серии статей я поставил для себя задачу создать (а за одно и подробно рассказать о процессе создания) универсальную программу для преобразования MIDI файлов в приемлемый для микроконтроллера формат, а так же генерирующую все необходимые для микроконтроллера данные инициализации.



Итогом данной статьи станет реализация основного функционала программы: создание массивов нота-длительность, созданного из MIDI файла. Кто заинтересовался — прошу под кат.

Недавно, на гиктаймс была размещена статья о том, как человек исходил радостью от знакомства с таким «великим изобретением человечества», как полиграф, он же «детектор лжи». И хотя начиналась статья с вполне «джинсовых» набросов типа «точность до 98%», «производят оборудование 50 лет» и прочая рекламная чепуха, но тем не менее ее можно считать неким FAQ для новичков, которые никогда не слышали про полиграфические исследования. Если таковые вообще существуют.
А теперь к более серьезным вещам. Как обычно бывает на Хабре и Гике, комментарии оказались интереснее самой статьи и там были высказаны некоторые мысли, которые я хочу более подробно осветить. Дело в том, что я периодически сталкиваюсь с необходимостью подбора персонала на «секретные» проекты, где вопросы безопасности ставятся на первое место. По этому, я и сам несколько раз проходил исследования на полиграфе и сталкивался с конторами, которые прогоняют через них своих сотрудников. Всегда результат один — нулевой. Далее, кратко:

В предыдущей статье были рассмотрены критерии выбора между GUID и автоинкрементом в качестве первичного ключа. Основная мысль была в том, что если по каким-то базовым критериям (наличие репликации, требования к уникальности и т.д.) есть необходимость использовать GUID, то нужно учесть нюансы, связанные с его производительностью. Тесты вставки записей показали, что наиболее быстрым вариантом являются последовательные GUID, генерируемые на клиенте, причем вставка в этом случае работает даже быстрее, чем при использовании автоинкремента. Но в статье не был рассмотрен проигрыш в производительности выборки при использовании GUID в качестве ключа. В этой статье я попробую закрыть этот пробел.

О радостях и трудностях первого знакомства с STM32 после AVR. Как я реализовывал простейшую задачу — передачу данных на ПК.

Как стало известно источнику издания «Ведомости» в одном из российских министерств, Lenovo интересуется российским процессором Baikal. Детали сделки не разглашаются, но утверждается что процессоры будут использованы в персональных компьютерах и мобильных устройствах.

Я работаю со встраиваемыми системами в течение нескольких лет: наша компания разрабатывает и производит бортовые компьютеры для автомобилей, зарядные устройства, и т.д.

Процессоры, используемые в наших продуктах — это, в основном, 16- и 32-битные микроконтроллеры Microchip, имеющие RAM от 8 до 32 кБ, и ROM от 128 до 512 кБ, без MMU. Иногда, для самых простых устройств, используются еще более скромные 8-битные чипы.

Очевидно, что у нас нет (разумных) шансов использовать ядро Linux. Так что нам нужна какая-нибудь RTOS (Real-Time Operating System). Находятся даже люди, которые не используют никаких ОС в микроконтроллерах, но я не считаю это хорошей практикой: если железо позволяет мне использовать ОС, я ее использую.

Несколько лет назад, когда мы переходили с 8-битников на более мощные 16-битные микроконтроллеры, мои коллеги, которые были гораздо более опытными, чем я, рекомендовали вытесняющюю RTOS TNKernel. Так что это — та ОС, которую я использовал в разных проектах в течение пары лет.

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

Добрый день!

Недавно прочитал очень интересную статью про обработку 50 гигабит/с на сервере и вспомнил, что у меня в черновиках лежит статья про то, как мы год назад разрабатывали систему мониторинга видео-потоков с общим объёмом трафика до 100 Гбит/с. Ещё раз “вычитал” её и решил представить на суд разработчиков. Статья больше посвящена анализу протоколов и поиску архитектурного решения, нежели тюнингу всевозможных подсистем linux’а, потому что мы пошли по пути распределения нагрузки между сервером и сетевыми пробниками, которые подключаются к транспортным потокам 10 Gigabit Ethernet.



Если интересно, как мы смогли измерить характеристики сетевых потоков от 55 тысяч видео-камер, прошу под кат.

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

Виртуальная память процесса

Перед тем, как окунуться в разные методы ограничения памяти, необходимо знать, как устроена виртуальная память процесса. Лучшая статья на эту тему — «Анатомия программы в памяти».

Прочитав статью, я могу предложить две возможности для ограничения памяти: уменьшить виртуальное адресное пространство или объём кучи.

Первое: уменьшение объёма адресного пространства. Это довольно просто, но не совсем корректно. Мы не можем уменьшить всё пространство до 1 Мб — не хватит места для ядра и библиотек.

Второе: уменьшение объёма кучи. Это не так-то просто сделать, и обычно так никто не делает, поскольку это доступно только через возню с компоновщиком. Но для нашей задачи это был бы более корректный вариант.

Также я рассмотрю другие методы, такие, как отслеживание использования памяти через перехват вызовов библиотек и системы, и изменение окружения программы через эмуляцию и введение «песочницы».

Для тестирования будем использовать небольшую программу по имени big_alloc, размещающую, и затем освобождающую 100 MiB.

Астрономы из Оклахомского университета, используя телескоп им. Хаббла, обнаружили интересные подробности относительно галактики Маркарян 231. Это ближайшая к нам галактика из тех, что содержат в своём центре квазар. Оказалось, что её квазар – это на самом деле две супермассивные чёрные дыры, вращающиеся относительно общего центра с огромной скоростью.

Галактика Маркарян 231 находится в 600 млн. световых лет от Земли в созвездии Большой Медведицы. Её обнаружили в 1969 году во время поиска галактик, обладающих сильным излучением в ультрафиолетовом диапазоне. Название своё она получила в честь советского армянского астронома Вениамина Егишевича Маркаряна, совершившего много важных открытий в астрономии: он, в частности, первым выдвинул идею о наличии у ядер галактик ультрафиолетового излучения нетепловой природы.

Галактика Мрк231 сразу была выделена учёными из-за необычной яркости квазара в её центре. Квазары — одни из самых ярких объектов Вселенной, мощность излучения которых часто превышает суммарную мощность излучения всех звёзд в галактике. Принято считать, что таковое излучение получается при поглощении сверхмассивной чёрной дырой аккреционного диска материи.

Imagination Technologies — одни из тех немногих, доказавших, что в этом мире точно можно существовать сразу в двух сущностях: в тени и в прибыли. Если уж кто и знает, как оптимизировать рендеринг 3D-сцены, так Kristof Beets всегда знает больше. В «былые годы» мужчина был лицом PowerVR (подразделение Imagination Technologies, занимающееся разработкой 3D-графических чипов) и вещал нам о том, как он совместно с ещё парой человеков придумали новый способ рендеринга. В рекламных брошюрах, которыми пестрил каждый обзор видеоплат на базе их чипов, всегда можно было найти очень грубое объяснение традиционного метода рендеринга и его блестящую эволюцию — тайловый рендеринг, который так прогремел в 2001 году, что… вы не слышали? А было громко!

3D-Пайплайн как он был

Сегодня на операционном столе у нас… кто бы вы думали?



PowerVR Series 3! О да, его-то мы и вскроем как следует, но сначала немного истории. На момент выхода на рынок ему пришлось соревноваться с такими гигантами, как ATI R100 и NVIDIA Жираф 3. То были серьёзные решения, но PowerVR и не собирались участвовать в гонке за мегагерцами. По заявлению PowerVR, те двое рисуют 3D-графику устоявшимся бесперспективным традиционным методом или же это можно было называть immediate-mode rendering. Чтобы понять, как это, нам придётся потревожить такое понятие как Графический конвеер (далее — 3D-пайплайн).

Классический 3D-пайплайн глазами PowerVR

Ну так вот, вернёмся к нашей скотине immediate-mode rendering (далее — IMR). На протяжении всех своих лет существования на рынке pc-видеоплат PowerVR давали нам такую вырезку из классического 3D-пайплайна, который применяется в IMR-видеокартах:



Если верить схеме, то классический 3D-пайплайн представляет из себя ровно следующее:
Приложение генерирует кадр с полигонами в оперативной памяти и отдаёт его на съедение видеоплате. Каждый полигон в gpu сначала растеризуется и текстурируется, а только потом идёт проверка на перекрытие его другим полигоном в сцене. Т.е., по сути получается, что мы можем сначала подготовить в памяти сложное дерево, следом подготовить такого же сложного человека, и только потом сообразить, что человек практически полностью закроет собой всё это дерево. Да, у IMR получается как-то неэффективно. Получается overdraw.

Что предлагает PowerVR

А PowerVR уже который год предлагают нам: "Think before you start to render!".
Казалось бы, ведь это так просто! Нам всего лишь необходимо поменять местами первые две стадии на рисуночке.



Но за всем этим кроется одна большая проблема: в то время весь 3D-пайплайн был аппаратно зашит в чипы (от геометрии до вывода во фреймбуфер). Посему PowerVR в своих чипах круто изменили 3D-пайплайн, заодно придумав собственный метод рендеринга: Tile Based Deferred Rendering!!! Ключевое слово Deferred, потому что были, например, видеокарты Intel GMA, которые использовали Coined Zone Rendering, который по сути тоже Tile-Based.

Intel uses a similar concept in their integrated graphics solutions. However, their method, coined zone rendering, does not perform full hidden surface removal (HSR) and deferred texturing, therefore wasting fillrate and texture bandwidth on pixels that are not visible in the final image.
…
en.wikipedia.org/wiki/PowerVR

А на самом деле...

… конечно, всё было не совсем так. А именно:

1. Поначалу (1995 — 2000 гг.) у карт с IMR всё складывалось неплохо и карты с TBDR не имели особого преимущества, оставаясь в тени. Но и в 2001 году карты PowerVR, на самом деле, особо не выехали. Потому что вендорами IMR-чипов были своевременно проведены независимые расследования и, в результате, без интриг и скандалов, до вендоров быстро дошло, что типичный 3D-мир становится всё комплекснее и многослойнее. Всем стало ясно, что теперь боттлнеком является видеопамять с её пропускной способностью, и, что нужно оптимизировать работу с этой вот памятью и обязательно с z-buffer'ом.
   Так практически одновременно в 2001 году увидели свет такие разные технологии, как HyperZ у ATI и Lightspeed Memory Architecture у NVIDIA. И, если первая на заре своего появления отсеивала overdraw уже только непосредственно перед растеризацией, то вот вторая делала это ещё на уровне геометрии!
   
   
2. Помимо того, конечно, PowerVR немного лукавили. На приводимой ими схеме классического 3D-пайплайна IMR (см. Классический 3D-пайплайн глазами PowerVR) явно не хватало шейдеров, которые уже были в зачаточной стадии даже на жирафе 2 (это называлось NSR). Ну а у каждого уважающего себя чипа 2001 года (ATI R100, NVIDIA Жираф 3) уже были полноценные пиксельные или даже вершинные шейдеры, открывающие «полигоны возможностей» управления 3D-пайплайном.
   Однако же заметьте, что TBDR всё же был придуман задолго до шейдеров!
   
   

По указанным выше причинам PowerVR снова оказались в тени и дальнейшая судьба их сложилась в другом сегменте (привет владельцам IPhone). Но на что же на самом деле был способен чип PowerVR Series 3, карты на котором так и не доехали до нас?