Одним из пунктов списка моих желаний после прочтения первого отчета с пати в 1991 году стало посещение европейской демопати и участие в соревнованиях compo. Я участвовал в NAID ’96 и даже занял там место, но моей мечтой всегда было соревноваться с лучшими из лучших. Я рад объявить о том, что спустя шесть месяцев упорной работы с хорошими друзьями и невероятно талантливыми людьми нам это удалось. Наше демо 8088 MPH победило в oldskool demo compo Revision 2015. (Моей личной победой стало то, что наше демо показали в compo последним, что стало знаком уважения организаторов.) 7 апреля 2015 года в мире не было эмуляторов IBM PC, способных правильно запускать наше демо; они зависали или вываливались ещё до завершения демо, а цвета были искажены. То же относится и ко всему остальному железу, кроме целевого (см. ниже). Чтобы увидеть, что такое 8088 MPH, я рекомендую вам посмотреть видео записи демо, запущенного на реальном железе:


В демо так много технологических открытий, сделанных впервые в мире, а мы эксплуатируем железо так, как никто до нас не додумывался, поэтому будет честным рассказать, как же нам это удалось. Одной из моих должностей была «организатор» демо, поэтому я расскажу о нём сцена за сценой, вкратце объяснив основы каждого трюка. О частях, написанный мной, я расскажу чуть подробнее, но для глубокого анализа технологий я буду обновлять этот пост, чтобы можно было оставить ссылки на посты reenigne, VileR и Scali. Мы надеемся, что этот рассказ привлечёт интерес к «олдскульному» программированию ПО для платформы. После прочтения этого обзорного поста рекомендую пройти по ссылкам на статьи, где подробнее рассматриваются отдельные части демо.

Создатель Papers, Please Лукас Поуп работает над новым трёхмерным проектом Return of the Obra Dinn, в котором пытается с помощью эффекта дизеринга воссоздать в игре ощущение старинной книги.

Для начала краткое объяснение: Obra Dinn выполняет внутренний рендеринг всего в 8-битной палитре в градациях серого, а затем на этапе постобработки преобразует конечные выходные данные в 1-битные значения. Преобразование из 8-битного в 1-битный цвет выполняется сравнением каждого пикселя исходного изображения с соответствующей точкой в тайловом паттерне дизеринга. Если значение пикселя изображения больше значения точки паттерна дизеринга, то выходному биту присваивается значение 1, в противном случае оно равно 0. Выходные данные упрощаются до 1-битных значений, а глаз зрителя объединяет пиксели, аппроксимируя из них больше битов.

Однажды я искал исходный код Unreal и, вдохновлённый отличным анализом того, как популярные игры рендерят кадр (перевод статьи на Хабре), я решил тоже сделать с ним что-то подобное, чтобы изучить, как движок рендерит кадр (с параметрами и настройками сцены по умолчанию).

Поскольку у нас есть доступ к исходному коду, мы можем изучить исходники рендерера, чтобы понять, что он делает, однако это довольно объёмная часть движка, а пути рендеринга сильно зависят от контекста, поэтому проще будет исследовать чистый низкоуровневный API (иногда заглядывая в код, чтобы заполнить пробелы).

Пока TensorFlow активно завоевывает мир, воюет за аудиторию с такими крупными игроками рынка машинного обучения и глубоких нейронных сетей как Keras, Theano и Caffe, другие менее грандиозные проекты тем временем партизанят, пытаясь занять хоть какую-нибудь нишу. Про один из таких проектов я как раз и хотел сегодня рассказать ввиду полного отсутствия информации о нем на Хабрахабре. Итак, tiny-dnn — это полностью автономная C++11 реализация глубинного обучения, созданная для применения в условиях ограниченных вычислительных ресурсов, встроенных систем или IoT. Подробности под катом.

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

Результат: информация о цвете занимает 1/64 от исходной площади при достаточно высоком качестве результата. Тестовое изображение взято с этого сайта.

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

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

Сколько существует разных способов представить обыкновенный поворот в трехмерном пространстве? Большинство людей, когда-либо занимавшихся 3D-графикой или 3D-моделированием, сходу назовут три основных широко распространенных варианта:

• Матрица поворота 3x3;
• Задание поворота через углы Эйлера;
• Кватернионы.

Люди с богатым опытом добавят сюда почему-то не пользующийся популярностью четвертый пункт:

• Ось поворота и угол.

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

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

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

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

Как построить график по n точкам? Самое простое — отметить их маркерами на координатной сетке. Однако для наглядности их хочется соединить, чтобы получить легко читаемую линию. Соединять точки проще всего отрезками прямых. Но график-ломаная читается довольно тяжело: взгляд цепляется за углы, а не скользит вдоль линии. Да и выглядят изломы не очень красиво. Получается, что кроме ломаных нужно уметь строить и кривые. Однако тут нужно быть осторожным, чтобы не получилось вот такого:

Столкнулся с ситуацией, когда мои коллеги для организации локального персистентного key-value хранилища используют SQLite, MemcacheDB, Redis игнорируя встраиваемые хранилища такие как LevelDB, Sophia, HamsterDB и т.д.

Я разбил статью на две части:

1. небольшое введение в api LevelDB;
2. использование LevelDB, для хранения временных рядов.

От переводчика: Джефф Прешинг (Jeff Preshing) — канадский разработчик программного обеспечения, последние 12 лет работающий в Ubisoft Montreal. Он приложил руку к созданию таких известных франшиз как Rainbow Six, Child of Light и Assassin’s Creed. У себя в блоге он часто пишет об интересных аспектах параллельного программирования, особенно применительно к Game Dev. Сегодня я бы хотел представить на суд общественности перевод одной из статей Джеффа.

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

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

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

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

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Рад сообщить, что реверс-инжениринг КР580ВМ80А полностью завершен. Получена полная принципиальная схема и Verilog-модель. В невероятно короткие сроки схему восстановил Vslav 1801BM1 (1801ВМ1@gmail.com).

Оказалось, в КР580ВМ80А ровно 4758 транзисторов (а не 6000 или 4500, как иногда ошибочно упоминают).

Топология КР580ВМ80А похожа, но не идентична i8080. Тем не менее, отличий в реализации опкодов КР580ВМ80А не было обнаружено.

Verilog-модель успешно прошла зубодробительный тест качества симуляции и как Verilog-модель, и как FPGA заменяя реальный КР580ВМ80А в "Специалисте".

Файлы: Главная модель Verilog, схема, Полный пакет файлов.

Всем привет! Меня зовут Сергей Макеев, и я технический директор в проекте Skyforge в команде Allods Team, игровой студии Mail.Ru Group. Мне хотелось бы рассказать про технологии рендеринга, которые мы используем для создания графики в Skyforge. Расскажу немного о задачах, которые стояли перед нами при разработке Skyforge с точки зрения программиста. У нас свой собственный движок. Разрабатывать свою технологию дорого и сложно, но дело в том, что на момент запуска игры (три года назад) не было технологии, которая могла бы удовлетворить всем нашим запросам. И нам пришлось самим создать движок с нуля.

Доброго времени суток, хабр!

С языком D я познакомился на 3 курсе, но решил его использовать только через год, когда вышла книга Александреску. Сразу взялся писать лабораторные, курсовые. Основной проблемой являлось отсутствие нужных библиотек (графика, удобная математика) или неудобная их установка. Сейчас многое изменилось, пишутся библиотеки (gfm, dlib, dlangui и тд), появился dub. С одной из таких библиотек хочу познакомить в этом посте. Имя ей DES. Выросла она из институтских наработок, поэтому, возможно, кому-то она будет полезной в учёбе и/или станет катализатором изучения языка.Сразу следует оговорить: статья для новичков, всё предельно просто.

Напишем простое приложение, рисующее на экране некий абстрактный mesh.

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.



На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.

Это довольно трогательная история, и мне кажется, ей самое место здесь. Потому что делать игры, это тоже очень важно. Итак, представьте: обычное игровое видео, размещенное на youtube. В комментариях обычное обсуждение и гвалт. Но среди них попадается комментарий от пользователя 00WARTHERAPY00, пишущего о том, что он продолжает играть в автосимулятор с покойным отцом.



Привожу вольный перевод комментария:
Ну, когда мне было 4 года, отец купил настоящий Xbox.

Думаю найдутся единицы пользователей разной бытовой техники не знающие, что любая техника, подключённая к обычной бытовой электросети ~220В 50Гц, является источником электромагнитного поля(ЭМП). Да, ЭМП есть, но немногие знают, превышает оно предельно-допустимые нормы(ПДН) или нет. Я являюсь работником одной лаборатории в составе организации, занимающийся Аттестацией рабочих место по условиям труда, возможно, многие слышали, у кого-то она проводилась. В последние пару лет, когда меня допустили до проведения измерений повидал многие рабочие места. Где-то отлично, где-то ужасно. По просьбам трудящихся, расскажу о некоторых результатах измерения ЭМП.

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

В двух недавних работах (одна уже опубликована и вторая вот-вот подоспеет) в журнале «Physics Essays», Амрит Сорли, Давид Фискарлетти, и Душан Клинар из научно-исследовательского центра Бистра в городе Птуй (Словения), более подробно описали, что всё это значит.

Напомню историю вопроса. 9 ноября прошлого года, после почти 15 лет разработки, нескольких приостановок проекта и переносов запуска, с Байконура была запущена ракета-носитель Zenit-2SB с новым российским космическим аппаратом «Фобос-Грунт». Цели были поставлены весьма амбициозные: запустить автоматическую станцию к Марсу, достичь его спутника — Фобоса, взять с него пробы грунта, которые затем были бы возвращены на Землю. Это бы были первые пробы внеземного материала, физически доставленные в руки исследователей (ну, буквоеды бы тут мне попеняли японским «Хаябуса», из-за постоянных задержек «Фобоса» доставившим несколько лет назад отдельные микроскопические частицы межпланетной пыли ранее нашего аппарата), со времен исследований Луны «в прошлом веке». А с учетом того, что, по сегодняшней теории, Фобос — это захваченный Марсом астероид, то есть образец того самого исходного материала, из которого вообще образовалась все планеты Солнечной Системы (Луна — это все же отколотый в прошлом «кусок» Земли, а не настоящая «планета»), эта экспедиция имела и беспрецедентное научное значение. Это был бы также первый «возврат» аппарата от Марса и его спутника.
Немаловажным был также вопрос престижа и открытого возвращения России в «глубокий космос», к межпланетным исследованиям, прекратившимся еще во времена СССР.