Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

Большинство компиляторов имеют следующую архитектуру:



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

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

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

«Мы начинаем разработку новой игры, и нам нужна классная вода. Такую сможешь?»


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

Недавно я начал разбираться с рендерингом «Ведьмака 3». В этой игре есть потрясающие приёмы рендеринга. Кроме того, она великолепна с точки зрения сюжета/музыки/геймплея.



В этой статье я расскажу о решениях, использованных для рендеринга The Witcher 3. Она не будет такой всеобъемлющей, как анализ графики GTA V Адриана Корреже, по крайней мере, пока.

Мы начнём с реверс-инжиниринга тональной коррекции.

Гамма-коррекция

Итак, мы вычислили цвета всех пикселей сцены, самое время отобразить их на мониторе. На заре цифровой обработки изображений большинство мониторов имели электронно-лучевые трубки (ЭЛТ). Этот тип мониторов имел физическую особенность: повышение входного напряжение в два раза не означало двукратного увеличения яркости. Зависимость между входным напряжением и яркостью выражалась степенной функцией, с показателем примерно 2.2, также известным как гамма монитора.

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

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

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

Первая часть
Вторая часть

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

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

Всем привет! Вот и закончились длинные мартовские выходные. Первую послепраздничную публикацию мы хотим посвятить полюбившемуся многим курсу — «Разработчик Python», который стартует менее, чем через 2 недели. Поехали.

Содержание

1. Память – пустая книга
2. Управление памятью: от оборудования к программному обеспечению
3. Базовая реализация Python
4. Концепция глобальной блокировки интерпретатора (Global Interpreter Lock, GIL)
5. Сборщик мусора
6. Управление памятью в CPython:
   
   • Пулы
   • Блоки
   • Арены
7. Заключение

Вы когда-нибудь задумывались как Python за кулисами обрабатывает ваши данные? Как ваши переменные хранятся в памяти? В какой момент они удаляются?
В этой статье мы углубимся во внутреннее устройство Python, чтобы понять, как происходит управление памятью.

Прочитав эту статью, вы:

• Узнаете больше о низкоуровневых операциях, особенно касательно памяти.
• Поймете, как Python абстрагирует низкоуровневые операции.
• Узнаете об алгоритмах управления памятью в Python.

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

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

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

Введение

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

Rise of the Tomb Raider (2015 год) — это сиквел превосходного перезапуска Tomb Raider (2013 год). Лично я нахожу обе части интересными, потому что они отошли от стагнирующей оригинальной серии и рассказали историю Лары заново. В этой игре, как и в приквеле, центральное место занимает сюжет, она предоставляет увлекательные механики крафтинга, охоты и скалолазания/исследований.

В Tomb Raider использовался разработанный Crystal Dynamics движок Crystal Engine, также применявшийся в Deus Ex: Human Revolution. В сиквеле использовали новый движок под названием Foundation, ранее разрабатывавшийся для Lara Croft and the Temple of Osiris (2014 год). Его рендеринг можно в целом описать как тайловый движок с предварительным проходом освещения, и позже мы узнаем, что это означает. Движок позволяет выбирать между рендерерами DX11 и DX12; я выбрал последний, по причинам, которые мы обсудим ниже. Для захвата кадра использовался Renderdoc 1.2 на Geforce 980 Ti, в игре включены все функции и украшательства.

Анализируемый кадр

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

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

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

"Как так?" — подумал я, и принялся раскуривать фимиам.

Предыстория

Здравствуйте! Всех категорически приветствую, сегодня хотел бы рассказать Вам о своём опыте написание работоспособной ОС под архитектуру x86.

Как-то весенней ночью у меня родилась гениальная идея — попробовать себя в написании собственной ОС, которая может позволить запускать программы, работать с устройствами, да и в общем выжимать всю мощь из Intel'овской архитектуры в своих нуждах: к примеру, для своей фабрики или чего-либо иного. Моей целью было и есть написание такой ОС, которая могла бы позволить максимальную производительность для каких-то конкретных задач, не тратя процессорное время на всяческие излишества. В основном я преследую лишь спортивный интерес, получение опыта для себя в системном программировании и написания драйверов для устройств, которые используются повсеместно. Что из этого вышло — решать вам, сразу говорю, что не надо писать комментарии про создание собственного дистрибутива линукса, и преследовал интерес написать всё «From scratch» — с нуля, дабы хорошо погрузиться в тему ОСдева. Сразу хочу выразить огромную благодарность Бенджамину Лунту и форуму OSDev, так же как их Вики. Бен помог мне разобраться с EHCI, что несомненно внесло огромный вклад в мою ОС — USB устройства, они везде! Так же передо мной стояла задача создать собственную архитектуру, удобную мне, не исключая использование стандартов ELF-файлов.

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

Доброго времени суток Хабру и ценителям пиксель-арта, поклонникам квадратных точек, адептам лимитированных разрешений и цветов. Рад представить на ваш суд очередную статью из цикла «Галоп Пикселя». Не буду тратить время на оправдания моего долгого отсутствия и в виду явного присутствия перейду к сути дела. Сегодня мы продолжим изучать анимацию. На этот раз это будет анимация света и тени. Большей частью на статических объектах. Всё помнят – сначала база. Сначала фундамент. Сначала простое. Ну а сложное ввалится в ваши двери само, вслед за детишками.

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

Цель этой статьи показать насколько силён дуэт брата и сестры, Света и Тени в движении. Мы уже видели, как они преображают сцены в статике. Но динамика нам ещё не знакома. Давайте исправим это упущение.

Лопаты в руки.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

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

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

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

Лопаты в руки.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)линк)

Первая статья данного цикла была воспринята тепло, вследствие чего затягивать с продолжением не имело никакого смысла, но, увы – это произошло. Зимнее наступление захлебнулось и плавно переросло в летнюю кампанию. В конце статьи я объясню почему, не хотелось бы вас огорчать с самых первых строк. Итак. Публика выразила желание ознакомиться с предметом глубже, чем предполагалось изначально. Большое количество писем пришло на почту, наряду с регулярными тычками в социальных сетях. В этом месте мне вспоминается одна фраза – «будьте осторожны в своих желаниях».

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

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

Я регулярно проверяю различные открытые проекты, чтобы продемонстрировать возможности статического анализатора кода PVS-Studio (C, C++, C#). Настало время компилятора GCC. Бесспорно, GCC — это очень качественный и оттестированный проект, поэтому найти в нём хотя бы несколько ошибок уже большое достижение для любого инструмента. К моей радости, PVS-Studio справился с этой задачей. Никто не застрахован от опечаток и невнимательности. Именно поэтому PVS-Studio может стать вашей дополнительной линией обороны на фронте бесконечной войны с багами.

Звук можно представить ввиде бесконечного количества волн различной частоты
и амплитуды. Волны, в свою очередь, могут иметь практически любую форму.
Из самых распространенных и чаще всего используемых можно назвать: синусоидальная (sine), квадратная (square), пилообразная(saw), треугольная (triangle), и шум (noise). Сначала попробуем разобраться с основными параметрами волны: период и амплитуда.