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

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


Фото slgckgc / CC

(Прим. пер.: статья написана в 2007 году, до выхода Civilization V и VI)

В 1990 году Сид Мейер (Sid Meier) по просьбе своего начальника и партнёра продолжал поставленный на поток выпуск лётных симуляторов. Но жизнь Мейера, да и сам мир компьютерных игр вокруг него сильно изменились со времени начала его работы в 1982 году. Сид чувствовал неуёмную потребность расширения своих дизайнерских горизонтов. Настало время двигаться дальше. Несмотря на сильное сопротивление внутри созданной им компании, Мейер нарушил статус-кво и навсегда изменил путь развития компьютерных стратегий. Доказав скептикам свою правоту, он достиг успеха и сделал важнейший вклад в гейм-дизайн благодаря эпичной игре, основанной на истории человечества.

Алан Кэй любит ссылаться на себя, и часто начинает свою речь с фразы: «Закон Кэя номер один гласит...». Наверное, он имеет на это право. Много лет его недооценивали, загоняли в рамки и даже гнобили.

Алан Кэй – человек, который не может держать свое мнение при себе, если тема дискуссии действительно волнует его. За это ему и пришлось поплатиться пару раз. Однако ему везло, и в результате он оставался в выигрыше. В его случае справедливо изречение: «Все, что ни делается — все к лучшему».

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

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

Пролог — уникален. Это единственный язык представляющий парадигму декларативного программирования; это язык, который имеет сотни различных имплементаций, но они все равно называются Prolog, добавляя лишь префиксы и суффиксы к названию; это живой язык в котором не происходит никаких существенных изменений более 20 лет; это, наверное, единственный настолько популярный язык программирования, который не имеет применения в реальном программировании. Почему же Prolog?

Пролог — уникален по своей природе, он появился благодаря счастливому совпадению (таинственному устройству мира). Когда-то в 60-х годах очень бурно развивалась теория автоматического доказательства теорем и Робинсоном был предложен алгоритм резолюций, который позволял доказать любую верную теорему (вывести из аксиом) за конечное время (за какое не известно). Как оказалось позже, это наилучшее решение общей задачи, невозможно доказать теорему за ограниченное число операций. Простыми словами, алгоритм представляет собой обход (в общем случае бесконечного) графа в ширину, естественно, что предсказуемость работы алгоритма практически равно 0, соответственно для Языка Программирования — это абсолютно не подходит. И в этот момент Кальмэроу нашел блестящее сужение задачи, благодаря которому доказательство некоторых теорем выглядело как процедурное исполнение программы. Стоит отметить, что класс доказуемых теорем достаточно широк и очень хорошо применим для класса программируемых задач. Вот так в 1972 появился Prolog.

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

Гвидо ван Россум известен как создатель языка Python. С момента создания языка Гвидо многократно награждался различными премиями. В 2001 году он получил награду за вклад в развитие свободного программного обеспечения от 'Free Software Foundation', а в мае 2003-го удостоился премии 'NLUUG Award'. В 2006 году ему присвоили звание Выдающегося Инженера.

Свободное от работы время Гвидо уделяет семье и самообразованию. Он большой фанат сериала 'Летающий цирк Монти Пайтона' (Monty Python's Flying Circus), именно в честь этого шоу и был назван язык программирования Python.

Сегодня на «Хабре» уже был пост, посвященный дню рождения создателя языка Perl. Здесь хотелось бы подробнее поговорить о биографии и взглядах Ларри Уолла, о его мотивации к созданию языка программирования, а также привести несколько фрагментов из недавнего интервью.

Ларри Уолл – американский программист, лингвист и создатель языка программирования Perl, один из лидеров движения за бесплатный доступ к программному обеспечению.

Читая Хабр в течении последних двух лет, я видел только несколько попыток разработки ОС (если конкретно: от пользователей pehat и iley (отложено на неопределённый срок) и Igor1024 (не заброшено, но пока больше походит на описание работы защищённого режима x86-совместимых процессоров, что бесспорно тоже необходимо знать для написания ОС под x86); и описание готовой системы от alman (правда не с нуля, хотя в этом нет ничего плохого, может даже наоборот)). Мне почему-то думается, что почти все системные (да и часть прикладных) программисты хотя бы раз, но задумывались о написании собственной операционной системы. В связи с чем, 3 ОС от многочисленного сообщества данного ресурса кажется смешным числом. Видимо, большинство задумывающихся о собственной ОС так никуда дальше идеи и не идёт, малая часть останавливается после написания загрузчика, немногие пишут куски ядра, и только безнадёжно упёртые создают что-то отдалённо напоминающее ОС (если сравнивать с чем-то вроде Windows/Linux). Причин для этого можно найти много, но главной на мой взгляд является то, что люди бросают разработку (некоторые даже не успев начать) из-за небольшого количества описаний самого процесса написания и отладки ОС, который довольно сильно отличается от того, что происходит при разработке прикладного ПО.

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

Это статья была написана для людей, которым всегда интересно знать как работают разные вещи. Для тех разработчиков которые обычно пишут свои программы на высоком уровне, C, C++ или Java — не важно, но при этом столкнулись с необходимостью сделать что-то на низком уровне. Мы будем рассматривать низкоуровневое программирование на примере работы bootloader-а.

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

Привет, Хабр!

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

Часто первое знакомство с линейной алгеброй выглядит как-то так:



Не очень вдохновляет, правда? Сразу возникает два вопроса: откуда это все взялось и зачем оно нужно.

Начнем с практики

Когда я занимался вычислительной гидродинамикой (CFD), один из коллег говорил: «Мы не решаем уравнения Навье-Стокса. Мы обращаем матрицы.» И действительно, линейная алгебра — «рабочая лошадка» вычислительной математики:

Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

Предлагаю вам перевод дневника Руи Уэяма (Rui Ueyama), программиста из Google, который он вел во время работы над реализацией компилятора языка C около трех с половиной лет назад (но опубликовал только в минувшем декабре).
Этот дневник не несет какой-то практической пользы и не является туториалом, но мне было очень интересно его прочитать, надеюсь и вам эта история тоже понравится :)

Я написал C компилятор за 40 дней, который назвал 8cc. Это дневник написанный мной в то время. Код и его историю можно посмотреть на GitHub.

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

Небольшой спойлер: в начале это казалось мне какой-то магией, но потом я понял подвох…

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

Вообще говоря, есть другие модели — Недетерминированная машина Тьюринга, Квантовые машины Тьюринга. Однако они (пока) являются только абстрактными моделями, не реализуемые на практике.

Полгода назад в Science Advances вышла интересная статья с моделью вычислений, которая существенно отличается от МТ и которую вполне возможно реализовать на практике (собственно статья и была о том, как они посчитали задачу SSP на реальном железе).

И да. Самое интересное в этой модели то, что, по заверению авторов, в ней можно решать (некоторые) задачи из класса NP полных задач за полином времени и памяти.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.