Это пост про ограничения старых видеоигр. Сам я под NES никогда не программировал, но с архитектурой поверхностно познакомился. Теперь я не могу играть в игры для NES, не задумываясь, как же они устроены. Иногда это на столько вызывает восхищение, что невольно забываешь про саму игру. «Чему же там восхищаться?», — скажете вы. Да просто укладываться во все ограничения NES, но при этом делать игру красивой, — это действительно целое искусство.

Сейчас я постараюсь рассказать об этом вам, максимально всё упростив.

Относительно недавно в моем Steam-аккаунте появилась игра Bioshock. Так как она была выпущена 6 лет назад, возникли некоторые проблемы с совместимостью: звук присутствовал только во время заставки, а сам геймплей проходил в полной тишине. Никакой фоновой музыки, диалогов, криков Сестричек или грохота выстрелов. Субтитры присутствовали, но играть было невозможно: геймплей выглядел ненатурально и создавал ощущение сильного дискомфорта.



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

Здравствуйте.

Я не являюсь активным пользователем Хабра. Я почти ничего не комментирую. Читаю его каждый день, но не считаю себя достаточно опытным в IT-сфере, чтобы высказывать свое мнение. Поэтому я не имею кармы и не стремлюсь её заработать.

Но у меня есть мечта и хобби.

Я – бывший пилот. Бывший – из-за неудачного парашютного прыжка. Так сложилось.

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

Пустыня Атакама в Чили — райское место для астрономов. Уникальная чистота воздуха, благоприятные атмосферные условия в течение года и крайне низкий уровень светового загрязнения делают этот негостеприимный район идеальным местом для строительства гигантских телескопов. Например, телескоп E-ELT, под который уже готовят строительную площадку. Однако это не единственный масштабный проект подобного рода. С 2005 года ведутся работы по созданию ещё одного впечатляющего астрономического инструмента, Гигантского Магелланова Телескопа (GMT). Так он будет выглядеть после окончания строительства в 2020 году:



В основе его оптической системы лежит отражающая поверхность из 7 огромных круглых зеркал. Каждое диаметром 8,4 м и весом 20 т. Само по себе изготовление таких зеркала, да ещё и с требуемой точностью, представляет настоящий инженерный шедевр. Как же создаются подобные изделия? Об этом — под катом.

Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.

Многим разработчикам и тестеровщикам, использующим Visual Studio, известен Брайан Келлер (http://blogs.msdn.com/b/briankel/ ) с его регулярно обновляемой виртуальной машиной, которая содержит последнюю версию Visual Studio и всю необходимую инфраструктуру для изучения и оценки всех возможностей средств разработки. Эта виртуальная машина сопровождается набором лабораторных работ aka.ms/VS13ALMVM, которые уже помогают оценить возможности средств разработки или даже научиться использовать новые возможности о которых вы либо не знали, либо не пользовались раньше.

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

О 4-х лабораторных я уже писал на habr: habrahabr.ru/company/microsoft/blog/235157. Сегодня мы рады сообщить, что благодаря ahriman, мы успешно выполнили проект по локализации этих лабораторных работ. Встречайте — полный набор из 24-х локализованых лабораторных работ, которые покрывают темы эффективной разработки, тестирования, совместной разработки и управления жизненным циклом ПО для Visual Studio 2013!

В статье «String enum — строковые enum» я писал о том как связывать текстовые представления с enum class — метод хороший но только если все элементы заранее известны, но зачастую бывает что строки являются некими идентификаторами и конечно же заранее не известны, а зачастую будут добавляться позднее и причем без пересборки программы.

Требования к библиотеке все теже:

• Кроссплатформенность;
• Минимум зависимостей;
• Скорость чтения;
• Простой синтаксис;

Пример конфига

{
    "objects":
    [
        {
            "id": "object1",
            "events":
            {
                "event1":{
                    "give": {"object2": 4}
                },
            }
        },
        {
            "id": "object2",
            "events":
            {
                "event2":{
                    "give": {"object1": 3}
                },
            },
            {
            "id": "object3",
            "events":
            {
                "event3":{
                    "give": {"object3": 4}
                },
            }
        },

Первая и самая простая идея которая напрашивается это:

    std::map<std::string,script> events;

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

Вторая идея парсить этот конфиг в 2 прохода тогда на 2-м проходе object1, object2, object3 будут уже известны и можно будет записать на них прямо указатели или ссылки. Но если зависимости еще более сложные то такой подход может и не сработать.

Я предлагаю способ позволяющий существенно сократить runtime издержки подобных конструкций

(пятница)

Обычно развернутое приложение в файловой системе выглядит как-то так:



Совершенно незащищенное от инструментов типа рефлектора или IlSpy, но что если оно станет таким:



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

А как всё мило начиналось

Параллакс для скроллинговых игр дело обычное, однако степень проработки параллакса разительно отличается от игры к игре. Получить действительно красивый и интересный фон довольно сложно. Многие сейчас переходят на 3D и параллакс как эффект вообще отпадает, так как получается естественным путём.
В былые времена на фоне пускали точки с эффектом параллакса (звезды), чуть позже стали делать фоны в пару-тройку разных слоёв. А сейчас уже не обойтись парой слоёв или скроллирующимся фоном, нужно немножко больше.


Lightforce, Commodore 64, 1986г.

Внимание, под катом большие картинки.

Предисловие.

Было начало 2010 года, когда я расстроился при просмотре очередного фреймворка с поддержкой Delphi. В тот момент я искал замену уже сильно устаревшему и заброшенному PowerDraw. Как говорится, тоже самое, только с перламутровыми пуговицами. Пересмотрев всё, что было из 2Д, я так и не нашел искомого. То не было шейдеров, то черезчур нагроможденный с точки зрения кода, то вообще какой-то убогий. А душа просила простоты использования и шейдеров.

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



Под катом прилично картинок.

Всем привет. Однажды мы узнали о том, что нам предстоит сделать True Image для Mac OS. Как это обычно бывает, сделать надо быстро и качественно, ага. Сразу возник резонный вопрос, почему бы просто не скомпилировать True Image для Windows под Мак, ведь большинство кода уже кроссплатформенно, в том числе интерфейс, написанный на Qt? Но нам тут же были обозначены рамки:

Интерфейс решено было сделать абсолютно новый, в разы проще чем у большого брата. Также в качестве GUI-фреймворка опытные в Маковых делах ребята из Parallels посоветовали использовать именно нативный Сocoa вместо Qt, а люди из еще одной известной компании подтвердили правильность этого решения. Решили не ставить под сомнение их опыт.

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

Свой собственный сленг рано или поздно образуется в любой команде. Айтишный же, наверное, складывается на 90% из словечек, которые более-менее понятны любой другой компании-разработчику, особенно в контексте. А на 10% — из особенностей фунциональности разрабатываемого продукта или конкретного разработчика.
Под катом – профессиональный словарик девелоперов Parallels. А какие у вас в команде крылатые выражения?

QML технология красивая и радует глаз. Меня она очень заинтересовала, и я решил ее освоить. Но не тут то было, ибо я оказался тупым и беспомощным. Нигде в сети не нашел примера «для чайников» (наверно плохо искал), чтобы с нуля построить простейшее приложение QML и C++ в связке. Везде чего-то не хватало: или не учитывался Qt Creator, или код выдавал ошибки, или отсутствовали целые моменты, которые пользователи должны были сами знать. Официальная документация и примеры здесь на хабре также были с этими недостатками. Вот и решил после долгих попыток и ошибок написать такую статью для начинающих с подробнейшим описанием.

Задача. Нужно написать программу QML в связке с С++, где
1. На форме располагается кнопка, строка ввода, и поле вывода.
2. Требуется считать из строки ввода число, прибавляется 1, и ответ выводится в поле вывода.
3. Интерфейс написан на QML.
4. Функционал на С++, то есть нам нужно обеспечить взаимосвязь между QML и C++: кнопка QML вызывает С++ функцию, а функция меняет свойства QML объектов.

Приветствую всех, кому интересна кроссплатформенная разработка для мобильных устройств! До недавнего времени относился с огромным скепсисом к инструментариям, позволяющим создавать ненативные приложения, которые работали бы сразу на ряде платформ. Однако в один момент любопытство и желание попробовать что-то новое всё же перевесили сдерживающий рассудок. Выбор пал на Qt 5.3. Почему? Потому что Qt открыт и бесплатен для некоммерческого и коммерческого (под лицензией LGPL) использования, имеет продолжительную историю (вышел в свет в 1996 году) и достаточное количество качественных проектов (навскидку — Skype, приложения 2ГИС), реализованных с использованием данных библиотек.

Цель публикации — познакомить читателей с мобильной разработкой на последней версии Qt: показать реализацию основных элементов клиент-серверных приложений и осветить возможные «подводные камни» при работе с библиотеками Qt.
Требуемый уровень подготовки и опыта — минимальный (знание основ C++, элементарное умение конфигурации локального сервера).
Материал для удобства восприятия разбит на 4 части: «Подводные камни», История одного проекта и работа над ошибками, Основы клиент-серверной разработки, Резюме.

Недавно на руборде в разделе Программирование был задан вопрос: «Зачем Win32-приложению манифест? На что он влияет?». Первое, что сразу приходит в голову большинству программистов — это темы оформления. Но на самом деле в современных виндах манифест нужен не только для этого. Я подумал и написал пять ключевых аспектов, на которые влияет манифест или его отсутствие. После этого сразу несколько человек попросили оформить этот пост в виде более развернутой статьи.

Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Желание написать об C++ API у меня возникло давно, и вот наконец выдался спокойный вечер. По роду деятельности я и мои ребята пишем код на C++ для программистов на C++ и Python, общее ядро функционала, который используется во всех продуктах нашей компании. Разумеется это подразумевает, что код должен иметь интуитивно понятный API, с общей логикой как для низкоуровневого C++, так и для высокоуровневого Python, вне зависимости от разночтения в языках некоторых базовых конструкций. Об объединении C++ и Python я много писал ранее в статьях про Boost.Python, сейчас я очень благодарен архитектуре и логике языка Python, я многое понял и перенял в С++ именно благодаря опыту построения общего API для этих двух таких разных языков, но сейчас речь пойдёт только и исключительно о C++, про API и про то, что такой зверский гибкий язык позволяет сделать с интерфейсом вашей замечательной библиотеки, если не учитывать ряд важных особенностей языка C++.

Поговорим о компьютерных вирусах? Нет, не о том, что вчера поймал ваш антивирус. Не о том, что вы скачали под видом инсталлятора очередного Photoshop. Не о rootkit-e, который стоит на вашем сервере, маскируясь под системный процесс. Не о поисковых барах, downloader-ах и другой малвари. Не о коде, который делает плохие вещи от вашего имени и хочет ваши деньги. Нет, всё это коммерция, никакой романтики…

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

Умные указатели часто передаются в другие функции по константной ссылке. Эксперты C++, Андрей Александреску, Скотт Мейэрс и Герб Саттер, обсуждают этот вопрос на конференции C++ and Beyond 2011 (Смотреть с [04:34] On shared_ptr performance and correctness).

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

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

АСКУЭ – Автоматизированные Системы Контроля и Учета Энергоресурсов. В задачи подобных систем входит сбор данных с приборов учета энергоресурсов (газ, вода, отопление, электричество) и предоставление этих данных в удобном для анализа и контроля виде.

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

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

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