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

В 2016 году я начал работу над хобби-проектом по реверс-инжинирингу игры Duke Nukem II и воссозданию с нуля его движка. Проект имеет название Rigel Engine и выложен в open source (его страница на GitHub). Сегодня, более чем два с половиной года спустя на моём движке уже можно пройти весь shareware-эпизод оригинальной игры с практически идентичным оригиналу игровым процессом. Вот видео с прохождением первого уровня:


Что же он может делать? Rigel Engine работает как полная замена оригинального двоичного файла DOS (NUKEM2.EXE). Можно скопировать его в каталог игры и он считает из него все данные, или же указать путь к данным игры как аргумент командной строки. Движок собирается и выполняется под Windows, Mac OS X и Linux. Он основан на SDL и OpenGL 3/OpenGL ES 2, а написан на C++ 17.

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

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

Год назад мы проделали отличную работу. Корявенько, наполовину, но всё же отличную. Ноосфера послала мне сигнал, что пришла пора доделать её до конца. Я думал, что эта работа оказалось никому не нужна, но неделю назад известный писатель-фантаст-киберпанкер спросил меня, когда же продолжение переводов? Я ответил, что основного бойца забрали в армию год назад и пока перевод не предвидится. А через 10 часов после моего ответа — получаю письмо: «Я вернулся из армии, готов возобновить переводы.»

Тезисы:

1. Мы рождаемся с множеством ментальных ресурсов.
2. Мы учимся взаимодействовать с другими.
3. Эмоции — это разные Образы Мышления.
4. Мы учимся думать о недавних мыслях.
5. Мы учимся думать на различных уровнях.
6. Мы накапливаем колоссальный опыт.
7. Мы переключаемся между различными Образами Мышления.
8. Мы находим различные пути представления вещей.
9. Мы строим различные модели себя.

Спасибо всем кто помогал: Станиславу Суханицкому, Savva Sumin, Victor Ivanov, urticazoku

Поэтому ждите новых глав, присоединяйтесь и помогайте с переводами (пишите в личку или на почту alexey.stacenko@gmail.com) Вот что есть готового на данный момент:

В первой части я рассуждал для чего прототипирование и в целом с чего начать
— Часть 1

В второй части немножко пробежались по ключевым классам
и архитектуре — Часть 2

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

Скриншоты про ракету в целом унылые, поэтому предлагаю посмотреть видео другого прототипа, который был собран за 2е недели вместе с графикой, и был заброшен в связи с тем что в жанре платформеры и так не протолкнуться. Это кстати одна из ключевых идей вокруг прототипа — собрать, посмотреть, не гавно ли это, нужно ли это? И честно забросить в корзину если вам ответы кажутся недостаточно убедительными. Но! Это не касается творческих проектов — иногда творчество бывает ради творчества ).

Итак видосик, смотреть надо на тексты расставленные по уровню, а не на геймплей ):

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

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

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

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

Об авторе. Энди Томасон — ведущий программист Genomics PLC. Он с 70-х годов занимается графическими системами, играми и компиляторами; специализация — производительность кода.

Гены: краткое введение

Геном человека состоит из двух копий примерно по 3 миллиарда пар оснований ДНК, для кодирования которых используются буквы A, C, G и T. Это около двух бит на каждую пару оснований:

3 000 000 000 × 2 × 2 / 8 = 1 500 000 000 или около 1,5 ГБ данных.

На самом деле эти копии очень похожи, и ДНК всех людей практически одинаков: от торговцев с Уолл-Стрит до австралийских аборигенов.

Существует ряд «референсных геномов», таких как файлы Ensembl Fasta. Эталонные геномы помогают построить карту с конкретными характеристикам, которые присутствуют в ДНК человека, но не уникальны для конкретных людей.

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

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

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

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

Введение

История началась с хакатона по разработке игр на блокчейне. На старте мероприятия я встретил человека, который в качестве хобби создает настольные деловые игры (я был на плейтесте одной такой игры), мы объединились, вместе нашли команду, с которой за выходные “слепили” простую стратегическую игру. Хакатон прошел, а задор остался. И у нас родилась идея многопользовательской карточной игры о счастье, мировом сообществе и выборах.

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

• Краткая информация об игре
• Как принималось решение на чем делать backend. Где это будет “жить” так, чтобы за это не платить на этапе разработки
• Первые шаги в разработке — аутентификация игроков и организация поиска игры (matchmaking)
• Дальнейшие планы

На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

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

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



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

Скорее всего, из названия статьи вы уже догадались, что в центре внимания ошибки в исходном коде. Но это вовсе не единственное, о чем пойдет речь в этой статье. Если кроме С++ и ошибок в чужом коде вас привлекают необычные игры и вам интересно узнать, что это такие за «рогалики» и с чем их едят, добро пожаловать под кат!

<< До этого: Электронная революция

Дорога к твердотельным переключателям была долгой и сложной. Она началась с открытия, что определённые материалы странно ведут себя в присутствии электричества – не так, как предсказывали существовавшие тогда теории. За этим последовала история о том, как в XX веке технология становилась всё более научной и институциональной дисциплиной. Дилетанты, новички и профессиональные изобретатели практически без всякого научного образования делали серьёзные вклады в становление телеграфа, телефонии и радио. Но, как мы увидим, почти все продвижения в истории твердотельной электроники случились благодаря учёным, учившимся в университетах (и обычно имеющим степень доктора наук по физике), и работавшим при университетах или корпоративных исследовательских лабораториях.

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

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

Из опыта советую не спешить, решать письменно. Головоломка «12 монет, 3 взвешивания» несколько раз возникала в моей жизни. Первый раз ее задал мне мой товарищ-олимпиадник, решил я ее после олимпиады и пришлось пару часиков поломать голову. И через несколько лет она далось мне не сразу. Если желаете решить самим — делайте на листочке.

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

Буквально на днях компания FireEye презентовала систему Commando VM, предназначенную для пентестеров и Red Team, работающую под управлением операционных систем семейства Microsoft Windows.

FireEye позиционирует Commando VM как «первый в своем роде» дистрибутив для пентестеров под Windows, однако они явно лукавят, т.к. на ум сразу приходит как минимум проект Pentest Box, который также заточен под Windows.

В тоже время, сама система Commando VM довольно интересна и заслуживает внимания…

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

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

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



→ Также читайте в нашем блоге цикл публикаций про bash-скрипты

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

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

Участие в обычном гейм-джеме привело к созданию машины обработки данных, которой в результате удалось заработать приличную сумму: 50 тысяч долларов за два с лишним года. Спустя годы, имея на руках данные (и деньги), разработчики этой машины по изготовлению игр, которая создавала только «мусорные» слот-автоматы с моделью free-to-play, использовали GDC как трибуну, чтобы подать тревожный сигнал индустрии, в которой «правильное» поведение часто ограничивается вниманием к игрокам, заискиванием перед издателями и сбором положительных обзоров критиков. В случае этих разработчиков нарушение всех этих правил привёл к слишком успешным результатам, вызвав у них сильный дискомфорт.

Побеждаем в «гонке ко дну»

Вернёмся в 2013 год: в то время два разработчика видеоигр уже несколько лет пытались добиться успеха на растущем рынке мобильных игр. Один из них, Алекс Шварц, помогал в создании качественной мобильной игры Jack Lumber. (В прошлой жизни я даже написал о ней хороший отзыв в уже несуществующем журнале The Daily, работавшем только на планшетах.) Второй, Зиба Скотт, разработал приятную мобильную головоломку Girls Like Robots.

Обе игры использовали модель «заплати один раз» без микротранзакций. Обе получили награды, известность, хорошие отзывы на выставках и обрели издателей. Обеим не удалось добиться успеха.

Несколько лет назад довелось мне попробовать свои силы в заманивании пытливых отроков в разработку микроэлектроники. А дальше было, как в известной пословице: «Коготок увяз — птичке пропасть!» Остановиться уже не смог. Хочу поделиться с общественностью этим опытом, возможно, другие инженеры-электронщики тоже захотят устроить что-то подобное. Грамотнее народ – лучше жизнь.

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

При первом знакомстве Termux, а я далеко не линуксоид, вызвал в моей голове две мысли: «Круть несусветная!» и «Как им пользоваться?». Порывшись в инетах, я не нашел ни одной статьи в полной мере позволяющей начать пользоваться Termux'ом так чтобы это приносило больше удовольствия чем гемора. Будем это исправлять.

• First of all, you can read this article in russian here.

One evening, I was reading Mastering regular expressions by Jeffrey Friedl , I realized that even if you have all the documentation and a lot of experience, there could be a lot of tricks developed by different people and imprisoned for themselves. All people are different. And techniques that are obvious for certain people may not be obvious to others and look like some kind of weird magic to third person. By the way, I already described several such moments here (in russian) .

For the administrator or the user the command line is not only a tool that can do everything, but also a highly customized tool that could be develops forever. Recently there was a translated article about some useful tricks in CLI. But I feel that the translator do not have enough experience with CLI and didn't follow the tricks described, so many important things could be missed or misunderstood.

Under the cut — a dozen tricks in Linux shell from my personal experience.

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

Эта статья — своеобразное сопровождение к видео. В ней я даю комментарии ко всем показанным решениям плюс собственную версию решения на JavaScript. Также обсуждаются нюансы каждого алгоритма.