Мотивация к написанию статьи

Уважаемые коллеги, доброго времени суток!

Этой статьей я хочу показать приёмы портирования программ между аппаратно-программными платформами, и привлечь внимание к книге «Секреты программирования игр» Андрэ Ламота, 1995, которую вспомнят добрым словом многие разработчики компьютерных игр, и другим не менее полезным книгам этого автора.

Нам интересны приёмы портации, но мы так же проведём ревью, проверим насколько долговечен код 25-тилетней давности, и насколько сложно его портировать на любые современные платформы.

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

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

На этапе планирования учебных программ я столкнулся с проблемой выбора контроллера для обучения детей среднего школьного возраста (5-8 класс). Для младших уже существует Wedo, и этот конструктор хорошо себя зарекомендовал. Старшие уже хорошо усваивают Arduino и 3D-моделирование. А для средневозрастных ребят, исходя из своего почти восьмилетнего опыта преподавания робототехники, хотелось бы что-то среднее. Чтобы можно было программировать и блоками (желательно еще сразу видеть код), и напрямую в Arduino IDE. При этом в удобном защищенном корпусе, с минимизированным шансом пораниться или что-то сжечь, и возможностью собирать робота из готовых деталей.

В этом плане мне понравился образовательный набор от RED (хотя когда я его первый раз пощупал, долго от него плевался). Их контроллер One, по сути, шилд для ардуины с выведенными портами и встроенными драйверами двигателя, в красивом пластиковом корпусе (в первых партиях напечатанном на 3D принтере). Контроллер совместим с лего деталями, и поставляется с немного измененным ресурсным набором 45544 и спорным набором Arduino датчиков, тоже в корпусах. А их среда программирования реализована на принципах scratch, но по сути дублирует ArduBlock.
Однако у этого решения тоже существуют проблемы. Начиная от странной распиновки, заканчивая не самой удачной конструкцией корпуса. Большинство проблем они решили в контроллере X, но зачем-то перевели его с аккумуляторов на батарейки, закрыли возможность программировать из ArduinoIDE и взвинтили ценник.

В общем, решил, чем я хуже? Сделаем свой контроллер!

Про системные вызовы уже много было сказано, например здесь или здесь. Наверняка вам уже известно, что системный вызов — это способ вызова функции ядра ОС. Мне же захотелось копнуть глубже и узнать, что особенного в этом системном вызове, какие существуют реализации и какова их производительность на примере архитектуры x86-64. Если вам также интересны ответы на данные вопросы, добро пожаловать под кат.

Когда я написал статью о том, почему установщик Windows 95 использовал три операционные системы [перевод на Хабре], в которой сказал, что установщик на основе MS-DOS был бы текстовым, то мне возразили: «Но ведь MS-DOS могла отображать графику! Вы что там, все глупые?»

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

Итак, теперь нам нужно написать графическую библиотеку для отрисовки чего-то сложнее, чем отдельный пиксель. К счастью, для Windows 95 требовалась минимум VGA-видеокарта, поэтому ей не приходилось беспокоиться о CGA или EGA. Напомню, что VGA-адаптер требовал работы с планарными режимами, что было очень утомительно. К счастью, у нас есть способная помочь команда спецов по планарным режимам VGA, работающая в соседних кабинетах над видеодрайверами Windows.

Пользователь Twitter @tthirtle спросил, почему установка Windows 95 проходит через три операционные системы: MS-DOS, Windows 3.1, а уже потом Windows 95. Почему не перейти от MS-DOS сразу к Windows 95?

Ещё один хороший вопрос: почему в установке Windows 95 используется три разных UI. DOS, Win3.x и Win9x?

— Thomas (@tthirtle) July 7, 2024

Установка Windows 95 может быть апгрейдом с трёх начальных точек: MS-DOS, Windows 3.1 или Windows 95. (Да, можно проапгрейдить Windows 95 до Windows 95. Это может понадобиться для того, чтобы восстановить повреждённую систему и сохранить при этом данные.)

Один из вариантов решения — написать три версии установки Windows 95: одна для установки из MS-DOS, другая для установки из Windows 3.1 и третья для установки из Windows 95.

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

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Привет, меня зовут Юрий Грачев, я программист из студии Whalekit — автора зомби-шутера Left to Survive и мобильного PvP-шутера Warface: Global Operations. Кстати, именно о его технологиях мы и поговорим подробнее далее.

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

Меня заинтриговал комментарий GuB-42 на Hacker News:

При помощи последовательностей ZWJ (Zero Width Joiner) теоретически можно закодировать в один эмодзи неограниченный объём данных.

Действительно ли можно закодировать в один эмодзи произвольные данные?

tl;dr: да, однако я нашёл решение и без ZWJ. На самом деле, можно закодировать данные в любой символ Unicode. Например, в этом предложении есть скрытое послание: This sentence has a hidden message󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑. (Попробуйте вставить его в декодер.)

Стандарт С++ почти никогда не указывает, как именно должен быть реализован тот или иной std алгоритм. Дается только описание того, что на входе, что на выходе и асимптотические ограничения по времени работы и памяти. В статье я постарался прикинуть, какие математические алгоритмы и структуры данных имели ввиду авторы стандарта, указывая ограничения для той или иной сортировки и для некоторых других алгоритмов. А так же как эти алгоритмы реализованы на практике.

При написании статьи я использовал стандарт C++17. В качестве реализаций рассматривал GCC 10.1.0 (май 2020) и LLVM/Clang 10.0.0 (март 2020). В каждой и них есть своя реализация STL, а значит и std алгоритмов.

• Рефлексия времени компиляции и оператор «монобровь»
• Constexpr, много constexpr
• SIMD
• Structured bindings as a pack
• Безопасность, контракты, libc++ hardening, профили, UB и std::launder
• Сколько бит в байте?

В комментариях к моей статье про быстрое вычисление синуса был задан вопрос: "А чем не устроило разложение в ряд Тейлора?"

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

Рассмотрели способы загрузки DLL и написали инструмент загрузки библиотек с нестандартным способом получения адресов функций.

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

В этой статье я хочу рассказать, как можно скачивать видео, аудио (1 часть статьи), плейлисты и целые каналы с YouTube (2 часть статьи) без использования VPN и на чистом Python-е. Сразу оговорка: VPN нам не понадобится, но мы сделаем собственное средство, которое будет решать "проблему с устаревшим и изношенным оборудованием Google Global Cache" (вы поняли, о чём я). Я думаю это средство будет особенно актуально сегодня, когда у многих россиян YouTube почти или совсем не работает.

In concept this is very simple: a nested buffer is just a chunk of binary data stored in a ubyte vector, typically with some convenience methods generated to access a stored buffer. In praxis it adds a lot of complexity.