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

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


Этот человек сидит среди ромашек, чтобы привлечь ваше внимание к статье.

Привет, %username%!
Мне, как ни разу не профессиональному математику и криптографу, редко бывает сразу понятно как устроен тот или иной алгоритм. И тем более, почему его выбирают.
Так и с новым стандартом SHA-3. Выбрали какой-то Keccak, спасибо камраду NeverWalkAloner, привел его описание. Но лично мне так и не стало понятно как он работает и в чем его фишка. Давайте разбираться.

В конце статьи будет небольшой бонус параноикам в виде информации к размышлению о стойкости SHA-2

Программный рендеринг (software rendering) — это процесс построения изображения без помощи GPU. Этот процесс может идти в одном из двух режимов: в реальном времени (вычисление большого числа кадров в секунду — необходимо для интерактивных приложений, например, игр) и в «оффлайн» режиме (при котором время, которое может быть потрачено на вычисление одного кадра, не ограничено настолько строго — вычисления могут длиться часы или даже дни). Я буду рассматривать только режим рендеринга в реальном времени.

У этого подхода существуют как недостатки так и достоинства. Очевидным недостатком является производительность — CPU не в состоянии конкурировать с современными видеокартами в этой области. К достоинствам стоит причислить независимость от видеокарты — именно поэтому он используется как замена аппаратного рендеринга в случаях, когда видеокарта не поддерживает ту или иную возможность (так называемый software fallback). Существуют и проекты, цель которых — полностью заменить аппаратный рендеринг программным, например, WARP, входящий в состав Direct3D 11.

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

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

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

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

Firefox Sync, это служба, которая позволяет пользователям переносить полностью свою историю, пароли, закладки, открытые вкладки и даже дополнения между различными устройствами, на которых установлен браузер Firefox, как для десктопной версии, так и для Android.

Firefox Sync реализуется двумя сущностями — сервисом авторизации (Firefox account API) и сервером синхронизации (Firefox Sync).

Давно возникла идея настроить свой сервер для синхронизации паролей, закладок и прочих радостей жизни. По роду деятельности, не очень доверяю публичным сервисам, таким, как LastPass или Google Account. На мой взгляд, приватные данные должны храниться на своем сервере.

Ну да хватит лирики, приступим к настройке.

Введение

Этот текст можно рассматривать как обзор библиотеки Strutext, задуманной автором как набор эффективных алгоритмов лингвистической обработки текста на языке C++. Код библиотеки находится в репозитории на Github. Библиотека имеет открытый исходный код и поставляется под лицензией Apache License 2.0, т.е. может быть использована совершенно бесплатно без каких-либо существенных ограничений.

снизу фотографии настоящих жуков, сверху — моя реализация

Продолжение предыдущей статьи, на этот раз пишем шейдер.

Корпорация Google сегодня анонсировала выпуск специальной версии эмулятора Android OS. Речь идет о x86 64-bit Android L, предназначенном для разработчиков, которые собираются выпускать приложения с поддержкой 64-битных чипов. По словам разработчиков, 64-битные приложения для Android позволяют разработчикам использовать более число регистров и новые наборы инструкций.

Расскажу о различных реализациях эффекта размытия на GLSL.

Приветствую Хабр! Многие из нас наверняка задумывались «а не написать ли мне игру самому». Сейчас я веду проект «Open tomb» — попытка создать переносимый движок для игры в первые 5 частей «Tomb raider», который выложен на sourceforge.com, однако, судя по своему опыту, многим будет интересна история с некоторыми деталями о том, как движок писался с нуля и с практически отсутствующими знаниями в этой области. Даже сейчас многих знаний не хватает, а иногда просто не хватает мотивации что-то сделать лучше, или правильнее, однако лучше перейти к тому, как все же проект оживал шаг за шагом.

В шахматных программах широко используются «битовые доски» (битборды 1, 2) для представления фигур на доске. А так же и для других игр на той же доске 8×8, и даже для карточных игр. С битбордами часто проводят различные операции, например, найти первый установленный бит или посчитать количество установленных битов. Для этих операций придумано много «хитрых» алгоритмов, а на современных процессорах некоторые из этих операций доступны в расширенном наборе инструкций. Например, popcnt, доступный в SSE4.2 ABM. Также есть пара инструкций bsf/bsr, которые доступны уже давно, но из JIT-компилятора к ним нет никакого доступа.
Конечно, всё серьёзные шахматные программы пишут на C++, но для прототипирования каких-нибудь алгоритмов хочется использовать C#, потому что я с ним лучше знаком и у меня меньше шансов выстрелить себе в ногу. Но производительность тоже не хочется терять просто так, в C/C++ интересующие нас инструкции доступны так называемые встроенные функции. Я попробовал сделать подобное решение и для C#.

Немного вскружилла голову статья Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду (Перевод моего друга Вадима). Есть и другие материалы по этой теме. И вот дошли руки до экспериментов.

Под PHP разработано три разных клиента:
extension code.google.com/p/php-handlersocket
PEAR openpear.org/package/Net_HandlerSocket
PHP native github.com/tz-lom/HSPHP

Ниже приведены мои впечатления о первых экспериментах.

(пример работы протокола HandlerSocket на картинке)

Вступление

В предыдущем проекте возникла потребность в разгрузке базы данных, тогда жизнь и столкнула меня с HandlerSocket`ом.

HandlerSocket — это протокол, реализованный в одноимённом плагине для РСУБД MySQL, позволяющий использовать NoSQL методику для доступа к данным, хранящимся в InnoDB таблицах. Основная причина, по которой используют NoSQL решения — это очень быстрый поиск по первичному ключу.


Под катом вас ожидает:

• Новая библиотека для работы с HS, написанная на PHP;
• Сравнение производительности существующих решений + нового;
• Symfony2 bundle для работы с HS;
• Плагины к Munin для мониторинга активности HS;
• Разные мысли вслух и рассказы о «шишках».

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

И если с Nvidia Physix (привет Unity3D) ничего не поделаешь кроме пары параметров, то Bullet Physics и Box2D доступны в исходных кодах, и от безысходности начинаешь разбираться с тем как что устроено и работает.

Разобраться с тем, как все работает очень полезно. Все игровые физические движки очень похожи. Они все impulse base, что означает то, что в каждый фрейм симуляции все (силы) переводяться в импульсы, импульсы складываются, делятся на массу и прибавляются к скоростям (линейной и вращaтельной) объекта, скорость же определяет насколько объект сдвинется в текущем фрейме симуляции.

И тут встает вопрос, если все так просто, как получается, что можно выложить в столбик кубики и они себе спокойно стоят и не разлетаются?

Я покажу, что за всю эту магию отвечает маленький кусочек кода!

Про Unsafe в Java не слышал только ленивый, однако это не единственный магический класс в Sun/Oracle JDK, стирающий границы Java платформы и открывающий тропинки, не нанесенные на карту публичного API. Я расскажу про некоторые из них, принесшие пользу в реальных проектах. Но помните: недокументированные возможности лишают ваше приложение переносимости на другие Java платформы и, кроме того, являются потенциальным источником нетривиальных ошибок. Я даже зря написал слово «приложение». Лучше сказать, что описанные ниже классы вовсе не годятся для приложений! Скорее, они представляют интерес лишь для системного ПО и для любознательных программистов, т.е. для вас :)

Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:


Рисунок 1 – Структурная схема работы X allocator

Из схемы видно, что доступ к глобальной куче защищен мьютексом. Такая архитектура, при интенсивном создании однотипных объектов из нескольких потоков, может привести к тому, что потоки будут вставать в очередь на этом мьютексе. А ведь одна из главных особенностей продукта – это возможность его масштабирования за счет увеличения количества потоков обработки (потоков выполняющих одинаковые действия). Поэтому такой подход потенциально может стать узким местом.

Как я и обещал – публикую вторую статью о некоторых моментах разработки игр в трех измерениях. Сегодня расскажу об одной технике, которая используется почти любом проекте ААА-класса. Имя ей — HDR Rendering. Если интересно — добро пожаловать под хабракат.

Незамеченной на хабре прошла новость о появлении OpenCL 2.0 драйверов от AMD и Intel.

Многим кажется, что подобный API просто очередной маркетинговый buzzword. Отчасти это так, потому что почти все современные аппаратные продукты выходят с пунктом «OpenCL» в списке поддерживаемых технологий и рекламе: последние CPU, GPU, APU (CPU+GPU), FPGA, CPU+FPGA. И многим из области разработки enterprise ПО хочется откреститься от этих «модных» названий, но и это скоро станет невозможно стараниями Oracle и AMD.

Массовый параллелизм аппаратного обеспечения уже давно присутствует в серверах, пресональных компьютерах, телефонах и планшетах, специализированных аппаратных ускорителях. OpenCL в области FPGA рассматривается как способ упростить, удешевить и популяризовать разработку. При этом использование преимуществ, предоставляемых аппаратурой, пока требует от программиста использовать таких API как OpenCL, CUDA, OpenMP. Но появляются попытки скрыть эту сложность от прикладных программистов, например Project Sumatra и ScalaCL.

Иллюстрированная проекция модели сетевого взаимодействия OSI на универсальную последовательную шину.

Три «замечательных» уровня стека USB

Меня не устроил вид стека USB, который можно встретить чаще всего на просторах сети:


Уровень шины, логический, функциональный… Это, конечно, замечательные абстракции, но они скорее для тех, кто собирается делать драйвер или прикладной софт для хоста. На стороне же микроконтроллера я ожидаю шаблонный конечный автомат, в узлы которого мы обычно встраиваем свой полезный код, и он сперва будет по всем законам жанра глючить. Или же глючить будет софт на хосте. Или драйвер. В любом случае кто-то будет глючить. В библиотеках МК тоже с наскока не разобраться. И вот я смотрю на трафик по шине USB анализатором, где происходящие события на незнакомом языке с тремя замечательными уровнями вообще не вяжутся. Интересно, это у меня от гриппозной лихорадки в голове такой диссонанс?

Если у читателя бывали сходные ощущения, предлагаю альтернативное, явившееся мне неожиданно ясно в перегретом мозгу видение стека USB, по мотивам любимой 7-уровневой модели OSI. Я ограничился пятью уровнями:



Я не хочу сказать, что весь софт и библиотеки уже сделаны или должны проектироваться, исходя из этой модели. Из инженерных соображений код c уровнями будет сильно перемешан. Но я хочу помочь тем, кто начинает своё знакомство с шиной USB, кто хочет понять протоколы обмена устройств и терминологию предметной области, подобраться поближе к готовым примерам, библиотекам и лучше ориентироваться в них. Эта модель не для загрузки в МК, но в ваши блестящие умы, дорогие друзья. А ваши золотые руки потом всё сами сделают, я не сомневаюсь:)

Введение

Структуры данных можно разделить на две группы: эфемерные (ephemeral) и персистентные (persistent).

Эфемерными называются структуры данных, хранящие только последнюю свою версию.
Персистентные структуры, то есть те, которые сохраняют все свои предыдущие версии, в свою очередь можно разделить еще на две подгруппы: если структура данных, позволяет изменять только последнюю версию, она называется частично персистентной (partially persistent), если же позволяется изменять любую версию, такая структура считается полностью персистентной (fully persistent).

Далее будет рассмотрено дерево отрезков и его полностью персистентная версия.
Весь код доступен на GitHub.

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

В результате стандартный консервативный аллокатор выстраивает все запросы в очередь на pthread_mutex / critical section. И наш многоядерный процессор медленно и печально едет на первой передаче.

И что с этим делать? Познакомимся поближе с деталями реализации метода Scalable Lock-Free Dynamic Memory Allocation. Maged M. Michael. IBM Thomas J. Watson Research Center.

Самый простой код что я сумел найти — написан под LGPL камрадами Scott Schneider и Christos Antonopoulos. Его и рассмотрим.