Diablo 1 — это классический roguelike 1996 года в жанре hack and slash. Это была одна из первых успешных попыток познакомить широкие массы с roguelike, которые до этого имели нишевую графику в виде ASCII-арта. Игра породила несколько сиквелов и множество имитаций. Она известна своей тёмной, мрачной атмосферой, сгущающейся по мере спуска игрока в подземелья, располагающиеся под городом Тристрам. Это была одна из первых для меня игр с процедурной генерацией карт, и возможность генерации столь правдоподобных уровней просто потрясла меня.

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

Благодарю Дэвида Бревика и команду Blizard North за создание такой потрясающей игры, а также galaxyhaxz и команду Devilution за их удивительную работу по восстановлению читаемого исходного кода проекта.

В данной статье рассматривается перехват функций графического API на примере DirectX 9 под x64 применительно к игре Dota 2.

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

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

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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

Речь в статье пойдет о той самой OpenSCADA, которая под Linux и с oscada.org.

Зачем:
• потому что SCADA на самом деле достойна внимания и популяризации;
• в некоторых малобюджетных или маленьких проектах просто безальтернативная;
• судя по статьям про АСУТП на хабре, многим читателям АСУТП представляется черной магией, недо-IT или чем-то похожим (ломают несчастный modbus, мучают WinCC, которая и так еле тарахтит… Люди читают и охают: «Как так можно…. дырявое ПО в промышленности», но никого не удивляет ломание Win95 и 6го ослика. Поломали бы LON шифрованный, OPC, OPC_UA…… А WinCC сама расшаривает папку с проектом с именем вида WinCC_Project_xxxxxx при первом открытии + это вы еще не видели как ее плагин к Excel может намертво винду подвесить при неаккуратной вставке ячеек чуть больше, чем он может за раз осилить!) – добавим ликбеза;

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

Если возьмётесь за работу очень усердно, то, возможно, получите неплохие результаты через несколько месяцев.

Как сообщает «Лаборатория Касперского», хакеры из APT-группировки ShadowHammer 5 месяцев контролировали сервис обновлений ASUS Live Update и заразили более полумиллиона компьютеров по всему миру.

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

И не надо…

В феврале 2019 года состоялся релиз ReactiveUI 9  —  кроссплатформенного фреймворка для построения приложений с GUI на платформе Microsoft .NET. ReactiveUI  — это инструмент для тесной интеграции реактивных расширений с шаблоном проектирования MVVM. Знакомство с фреймворком можно начать с серии статей на Хабре или со вступительной страницы документации. Обновление ReactiveUI 9 включает в себя множество исправлений и улучшений, но, пожалуй, самое интересное и значимое изменение — тесная интеграция с фреймворком DynamicData, позволяющим работать с изменяющимися коллекциями в реактивном стиле. Попробуем разобраться, в каких случаях нам может пригодиться DynamicData и как устроен внутри этот мощный реактивный фреймворк!

Пьеса «Технический долг» в 9 частях. Ставится и показывается впервые.

Часть 0: В пустой комнате стоят Разработчик (Р) и Менеджер (М).

М: Я собрал нас тут, чтобы рассказать пренепреятнейшее известие: система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег. Кроме того нет никого, кто знает как она работает. Поэтому (с придыханием) наш СЕО дал мне священную миссию — написать новую систему. Как ты думаешь, за два месяца справишься?

Р: А что делать-то нужно?

М: Да там немного, всего лишь пару десятков систем связать и рюшечки навесить.

Р: Эй, да это же на год работы! И вообще требования будут?

М: (В телефон) Да, конечно, за пол года справимся. (Разработчику) Ну ты тут пока начинай, а я тебе требования потом донесу.

Менеджер уходит.

Р: Но тут же…

Разработчик тяжело вздыхает, затаскивает в комнату инструменты и начинает что-то сооружать.

long long ago; /* in a galaxy far far away */

 //
    //                       _oo0oo_
    //                      o8888888o
    //                      88" . "88
    //                      (| -_- |)
    //                      0\  =  /0
    //                    ___/`---'\___
    //                  .' \\|     |// '.
    //                 / \\|||  :  |||// \
    //                / _||||| -:- |||||- \
    //               |   | \\\  -  /// |   |
    //               | \_|  ''\---/''  |_/ |
    //               \  .-\__  '-'  ___/-. /
    //             ___'. .'  /--.--\  `. .'___
    //          ."" '<  `.___\_<|>_/___.' >' "".
    //         | | :  `- \`.;`\ _ /`;.`/ - ` : | |
    //         \  \ `_.   \_ __\ /__ _/   .-` /  /
    //     =====`-.____`.___ \_____/___.-`___.-'=====
    //                       `=---='
    //
    //
    //     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    //
    //               佛祖保佑         永无BUG
    //

«Слава богу, багов нет»

В этом году статическому анализатору PVS-Studio исполнилось 10 лет. Правда, стоит уточнить, что 10 лет назад он назывался Viva64. И есть ещё одна интересная дата: прошло 5 лет с момента предыдущей проверки кода проекта Notepad++. С тех пор PVS-Studio был очень сильно доработан: добавлено около 190 новых диагностик, усовершенствованы старые. Впрочем, ожидать огромного количества ошибок в Notepad++ не стоит. Это небольшой проект, состоящий всего из 123 файлов с исходным кодом. Тем не менее, в коде найдены ошибки, которые будет полезно исправить.

Наверное, вы слышали про технологию Яндекса DeepHD, с помощью которой они как-то раз улучшили качество советских мультфильмов. Увы, в публичном доступе ее еще нет, а у нас, рядовых программистов, вряд ли найдутся силы написать свое решение. Но лично мне, как обладателю Retina-дисплея (2880х1800), недавно очень захотелось посмотреть «Рика и Морти». Какого же было мое разочарование, когда я увидел, как мыльно на этом экране выглядит 1080р, в котором существуют оригиналы этого мультсериала! (это прекрасное качество и обычно его вполне достаточно, но поверьте, ретина так устроена, что анимация с ее четкими линиями в 1080р выглядит мыльновато, словно 480р на FHD-мониторе)

Я твердо решил, что хочу увидеть этот мультсериал в 4К, хотя и совершенно не умею писать нейросети. Однако решение было найдено! Любопытно, что нам даже не придется писать код, понадобится лишь ~100 ГБ места на диске и немного терпения. А результат — четкое изображение в 4К, которые выглядит достойнее, чем любая интерполяция.

В качестве небольшого любительского проекта я поэкспериментировал с нейросетями AI Gigapixel для апскейла одного из моих любимых научно-фантастических сериалов — Star Trek: Deep Space Nine (DS9), в русском переводе «Звёздный путь: Глубокий космос 9».

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

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

BEGIN_MESSAGE_MAP(efcDialog, EFCDIALOG_PARENT )
  //{{AFX_MSG_MAP(efcDialog)
  ON_WM_CREATE()
  ON_WM_DESTROY()
  //}}AFX_MSG_MAP
END_MESSAGE_MAP()

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

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

Вот уже три месяца, как 2018 год позади. Для многих он пролетел почти незаметно, но для нас, разработчиков PVS-Studio, он оказался весьма насыщенным. Мы трудились в поте лица, бесстрашно боролись за продвижение статического анализа в массы и искали новые ошибки в открытых проектах, написанных на языках C, C++, C# и Java. Десять самых интересных из них мы собрали для вас в этой статье!

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

В процессе исследований нового МК от известной фирмы на основе архитектуры Cortex-М4 (я об этом обязательно еще напишу) возник вопрос, насколько быстро может работать операция целочисленного деления в аппаратной реализации. Натурный эксперимент дал несколько неожиданный результат: деление 32-разрядного числа на 32-разрядное выполняется за 3 такта частоты процессора — ну ни фига ж себе, как быстро. Выяснилось, что это имеет место только с определенными операндами, но дальнейшие исследования показали, что никогда время выполнения деления не превосходит 7 тактов. Полученные результаты вызвали легкую оторопь («и это не некая фигура речи, которая неизвестно что означает, а вполне конкретный глагол» — Дивов, как всегда, бесподобен).

Ну нельзя же просто так взять и быстро поделить такие длинные числа, странно как то, но факты — упрямая вещь. Представил себе картину, что вызывает меня завтра к себе Президент РФ и ставит передо мной задачу сделать МК не хуже, чем у ARM (согласен, что картина бредовая, но чего на свете не бывает), а я растеряно на него гляжу и понимаю, что не смогу сделать такое деление таких чисел за такое время, и не оправдаю ожиданий, на меня возлагаемых (ну на самом то деле я всегда смогу втихую купить лицензию у ARM, и сделать вид, будто бы придумал все сам, многие так и делают, но от меня то ВВП ждет совсем другого, да и потом — его то я обмануть смогу, а вот себя вряд ли).

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

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

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



Также игра может добавлять поле в нижней части границы для названия карты. В Dragons Abound есть несколько вариаций этого поля, в том числе такие сложные элементы, как фальшивые головки винтов:


В этих полях названий присутствует вариативность, но все они созданы вручную.

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

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»
— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.

Для тех, кому лень читать всё: предлагается опровержение семи популярных мифов, которые в области исследований машинного обучения часто считаются истинными, по состоянию на февраль 2019. Данная статья доступна на сайте ArXiv в виде pdf [на английском языке].

Миф 1: TensorFlow – это библиотека для работы с тензорами.
Миф 2: Базы данных изображений отражают реальные фотографии, встречающиеся в природе.
Миф 3: Исследователи МО не используют проверочные наборы для испытаний.
Миф 4: В обучении нейросети используются все входные данные.
Миф 5: Для обучения очень глубоких остаточных сетей требуется пакетная нормализация.
Миф 6: Сети с вниманием [attention] лучше свёрточных [convolution].
Миф 7: Карты значимости – надёжный способ интерпретации нейросетей.

А теперь — подробности.