Из новостей: Crystal Dynamics провела очередную волну сокращений, Valve представила новые железяки, движок Cocos купили за 72 млн долларов, Unreal Engine 5.7.

Из интересностей: у трупных забегов могут возникнуть проблемы, как устроены зеркала в Sims 4, в Donkey Kong Bananza лучший компаньон.

Начав знакомство с серией Fallout с ее первых частей, выход третьей вызвал во мне смешанные чувства. С одной стороны, это было захватывающее приключение от первого лица в мире любимой игры, с другой же проект ощущался для меня больше как шутер с элементами RPG, где от глубокой ролевой системы классики осталось не так много. И только с выходом New Vegas я наконец получил ту игру, которая по духу оказалась ближе всех к классическому Fallout — даже несмотря на то, что работала она всё на том же движке, что и «тройка».

Для подготовки этой статьи я перелопатил весь интернет в поисках редких фактов и комментариев людей, которые работали над New Vegas. Нашлись даже интервью на японском языке 🤯 — не говоря уже о множестве англоязычных материалов. Я постарался собрать из всего этого цельный, увлекательный текст, который не просто расскажет о создании игры, но и, надеюсь, пробудит у вас желание снова вернуться на Мохавскую пустошь. New Vegas — по-настоящему глубокая и многослойная игра, и мне искренне хочется, если не отправить вас туда лично, то хотя бы подарить повод поностальгировать и узнать что-то новое, читая мой свежий обзор. А в конце вас ждёт бонус: полностью готовая сборка игры с фанатской модификацией, чтобы вы могли сразу после прочтения отправиться навстречу приключениям!

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

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

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

В данной серии статей пойдёт речь о проекте собственного Personal-Document-Assistant (в дальнейшем буду округлять до КПК). Проект подразумевает открытые исходники, разборы, обсуждение и иное N-ное количество контента, поэтому рад приветствовать вас в этой истории.

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

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

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

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

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

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

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

Данная статья является альтернативой hello-world в DirectX от Microsoft в связи с излишней перегрузкой терминами и не нужной информацией. Объяснение для новичков, просто и понятно.

Статья посвящена очереди сообщений окна в Windows. Рассматриваются все действия с нею. Статья предназначена в основном для новичков в DirectX & Direct2D.

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

— «О какой именно памяти мы говорим?»

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

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

У нас была рабочая видеокарта, драйвер для нее, Linux, полный набор кода, который заставлял работать нашу видеокарту, возможно, была даже прошивка. Не то чтобы это был необходимый запас для запуска AMD GPU на ПЛИС с RISC-V. Но если начал запускать видеокарту на ПЛИСе с RISC-V Linux, становится трудно остановиться…

Вэтом тексте изложены базовые теоретические основы по CAN шине безотносительно к конкретному микроконтроллеру.

CAN — это двухпроводный, дифференциальный, последовательный, полудуплексный интерфейс для передачи бинарных данных между электронными платами (PCB). В качестве кабеля чаще всего применяют одну экранированную витую пару проводов с именами: CAN_L и CAN_H.

Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:

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

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

Со всеми его недостатками, инструмент есть в языке и достоин изучения.

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

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

Пришло время перейти от теории к практике!

Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.

Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.

Привет! Без лишнего: в статье расскажу про атаки на кэш-память в процессорах семейства ARMv8. Подробно изучил их для совершенствования безопасности KasperskyOS: познакомлю с теорией и практикой, механизмами работы и способами митигации. Также кратко расскажу, как мы тестировали каждый способ атаки на KasperskyOS, какие из них оказались неприменимы, какие могут представлять угрозу и как микроядро с подобными угрозами справляется. Если интересно гранулярно погрузиться в типологию атак на кэш — добро пожаловать!

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

Настало время освоить очередное семейство ARM-совместимых микроконтроллеров. За плечами уже AVR, MSP430x, LPC21x, STM32x, MDR32x, ESP32x, SPC58x, CC26x2, NRF53x, AT32Fx. Теперь вот YTM32x от компании YUN TU (Suzhou YTM Semiconductor Co Ltd).

С какой же стороны следует подходить к микроконтроллерам YTM32x?
Давайте разбираться...

Однажды по работе мне прилетела задача по сборке и запуску Linux на одноплатном ПК. Тогда я, будучи разработчиком ПО для микроконтроллеров, встал в небольшой ступор — задачка явно не решалась установкой IDE и нажатием в ней кнопки «Собрать проект». Гугл помог узнать о том, что существует некий Buildroot. В материалах по теме всё выглядело довольно просто: скачай, настрой, дерни пару команд, загрузи результат на одноплатник — и можно запускать! Получается, процесс не многим сложнее установки дистрибутива Linux или Windows на обычный ПК? Конечно же, нет. Ведь если у тебя в руках кастомный одноплатник неизвестного китайского бренда, а не BeagleBone или Raspberry Pi, то зарыться в Buildroot придётся с головой...

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

Зачем еще одна?

Дело в том, что я заметил такую тенденцию в вузовских учебниках – довольно подробное описание работы p-n перехода и очень поверхностное описание работы биполярного транзистора. Зачастую «механика» работы такого транзистора описывается довольно схематично (в совершенно неработоспособном виде) и далее следует быстрый переход на описание внешних параметров. Причем у этих же авторов описание «механики» работы полевого транзистора дается куда обширнее. Видимо, авторы учебников сами не очень «догоняют», как там все работает. И это не удивительно. Человечество вначале эры полупроводников пыталось повторить схему работы вакуумной лампы на полупроводниках, т.к. работа лампы достаточно логична. И собственно полевые транзисторы, в какой-то степени повторяют принцип работы вакуумных ламп. Но вот биполярный транзистор, хотя и был изобретен первым, но это было скорее случайное изобретение, а не осознанный путь к цели.

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

Если Вы задавали себе вопросы наподобие таких:

почему через коллекторный p-n переход, включенный в обратном направлении, течет ток, да еще и самый, что не на есть главный рабочий ток?

почему неосновные носители тока базы в биполярном транзисторе, вдруг стали вполне себе главными представителями тока?

Почему ток в базы через открытый эмиттерный p-n переход меньше тока через закрый коллекторный p-n переход?

Ну и совсем «подковыристый» вопрос. Почему при включении биполярного транзистора по схеме с общим эмиттером, когда транзистор полностью открыт (находится в режиме насыщения), напряжение на коллекторе становиться меньше напряжения базы? Ведь если смотреть на транзистор с точки зрения пирога n-p-n переходов (как рисуют в учебниках), то сумма падения напряжения на двух p-n переходах (открытом эмиттерном и закрытом коллекторном) должно быть больше напряжения на одном открытом эмиттерном переходе. А оно у нас меньше.

puts "ПЛИС-культ привет, FPGA / RTL / Verification ХАБ!"

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

Несмотря на свою архаичность, Tool Command Language все же остается самым востребованным языком управления средой проектирования для ПЛИС и ASIC. ЕМНИП все эти инструменты управляются через Tcl, Vivado так уж точно, поэтому было бы не плохо научиться или хотя бы посмотреть какие инструменты отладки этих самых пресловутых Tcl-сценариев вообще существуют или существуют ли они вообще, кроме православного puts

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

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

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

Если мне не изменяет память - Кармак сказал, что лучший способ [создания игр] — написать собственный движок ( "The right move is to build your own engine" ), на что многие возразят: это вовсе не так просто. Но папа Doom'a известен не только своим вкладом в разработку игровых движков, но и довольно часто высказывался критически о развитии игровых движков в целом, и о преимуществах создания собственных технологических решений вместо использования готовых.

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