Программирование *

Игра Rogue знаменита не только тем что породила и вдохновила огромное количество "потомков" - от визуально схожих Moria и NetHack до графически продвинутых вроде DIablo. Знаменита она ещё и тем что является одной из самых сложных игр для прохождения (в этом классе она гораздо интеллектуальнее чем Flappy Bird). Не уверен что вы найдете даже по форумам человека который скажет что проходил её (не читеря с файлами сохранения). А может такие есть среди вас?

Я заметил что современная опенсорсная версия (например доступная в пакетах для разных Linux и BSD) отличается от той, например, что была портирована коммерчески под ДОС где-то в 80е. Заметно отличаются монстры - чуть ли не со 2 уровня уже можно напороться на Ледяного Монстра который не только лишает подвижности но ещё и активно дамажит. Как будто и без того сложная игра стала ещё сложнее!

Дело в том что ранний код Rogue изначально не был доступен публично - кроме того авторы опенсорсной версии хотели избежать возможных нарушений прав (т.к. существовали уже коммерческие порты).

Чтобы разобраться я решил скомпилировать и запустить одну из самых старых доступных версий - посмотреть отличия - и вообще как что устроено. Здесь я расскажу о возникших мелких проблемах (любопытно м.б. для программистов на С) - и возможностях этой самой оживлённой версии (её я выложил на гитхаб - каждый может взять и погонять).

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

Идея статьи родилась после прочтения многочисленных источников в интернете по барьерам и моделям памяти.Так же, был просмотрены соответствующие видео с разъяснением. Много где в целом всё достаточно хорошо разжевано. Статья не претендует на исчерпывающий материал. Скорее, это обзорное описание на тему модели памяти в связке с RISC-V. Не рассчитана на entry level, рекомендуется сперва почитать что нибудь вводное.

Навряд ли кому то необходимо детальное знание внутренней архитектуры процессора на уровне RTL (register-transfer level), как и глубокого понимания принципов модели памяти, согласованности. Да и обычно вся эта информация берется из соответствующей литературе от производителя, других книгах по оптимизации. Предполагаю, что авторы в том или ином виде могу знать более глубокие вещи, чем представлены в открытых источниках. Возможно, они работали в компании производителя (Intel, например), общение, конференции, сообщества.

Но может ли быть источник лучший, чем исходники CPU? Навряд ли. Вы не найдете в открытом доступе исходники процессоров Intel, AMD и любых других. ARM за это денежки получает, продавая права на архитектуру и готовые спроектированные блоки. А вот для RISC-V такой источник есть - исходники полноценного суперскалярного out-of-order процессора от Berkley.

Не так давно был разработан язык Chisel на замену Verilog и аналогов. Он на базе Scala. А, так как это Scala, мы можем использовать IDE и внятную навигацию по исходникам. Но в исходники просто так не пойдешь, сперва надо приобрести необходимые фундаментальные знания, чтобы понимать в целом что такое разработка на уровне RTL. Неплохо бы разобраться с Verilog и с базовыми понятиями - всякие там защелки, регистры, мультиплексоры и тп. Это я и решил сделать и начал с книги “Паттерсон, Хеннесси: Архитектура компьютера и проектирование компьютерных систем”. Она безумно крутая и очень понятная. Затем прочитал несколько книг по FPGA и Verilog и даже купил учебную FPGA плату, но руки до неё так и не дошли. Это позволило сформировать для себя какую то необходимую картину того, как функционирует CPU, как происходит проектирование микроконтроллеров. 

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

Долго пытался сформулировать, почему мне нравится кругозор Claude и Gemini и умение рассуждать ChatGPT.

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

Интуиция не врёт.
(Юдковский перевернулся в гробу)

Последние пару-тройку лет на конференциях все чаще я слышу жалобы знакомых в игрострое о том, что текущий вектор развития "современного C++" не соответствует потребностям игровой разработки. Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке. Пошатавшись по разным игровым студиям, блин, скоро будет 15 лет как я тут, у меня таки немножечко есть, что вам рассказать.

Все современные студии, что крупнее двух с половиной землекопов, пишущие игры на плюсах, шарпе или чем-то близком - используют Visual Studio или переходят со своих поделок на Unreal/Unity, который так-то тоже плюсы, хоть и со странностями. Так исторически сложилось, что винда и майки были, есть и в ближайшем будущем горизонта лет десяти останутся самым крупным рынком ПК-консольных игр, а сами консоли давно стали "ну совсем ПК", но чтобы не терять эксклюзивы (и шекели) вендоры в этом не признаются никогда.

Мобилки, как-бы отдельно, и там свои свои покемоны Mac с Android, но в Visual Studio в том или ином виде создаются, дебажатся и оптимайзятся 95% игр, остальное - погрешность. С момента начала золотой эры игростроя (где-то в конце 90-х), большинство игр писались с учетом того, что они будут выпущены на ПК, под ПК понимается - под винду. И наследие многих A+-студий так или иначе связано с Microsoft, даже для не-Microsoft консолей и мобилок.

Первая часть: Ethernet, ARP, IPv4 и ICMPv4

Вторая часть: основы TCP и Handshake

В прошлом посте мы узнали о заголовках TCP и о том, как устанавливается соединение между двумя сторонами.

В этом посте мы изучим передачу данных по TCP и способ управления ею.

Также мы создадим интерфейс сетевого стека, который приложения смогут использовать для передачи данных по сети. Потом этот Socket API мы применим, чтобы наш пример приложения смог отправить простой HTTP-запрос веб-сайту.

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

Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.

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

И рассуждения я начну с вопроса — «ну и в чем проблемы?»

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

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

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

Сегодня мы погрузимся в результаты этого исследования, то есть вместо того, чтобы визуализировать код, мы поговорим о визуальных паттернах кода - тех, которые буквально заставляют мой мозг болеть!

Предупреждение! Это туманная и плохо изученная область. В исследовании использовались различные источники: популярные метрики, научные статьи и практические мнения (включая мое собственное). Но в конце пути мы сведем всё ниже к 8 визуально различимым свойствам, которые помогут программистам любого языка улучшить читаемость кода.

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

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

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

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

Привет Хабр ! Это моя первая статья на тему процедурной генерации. Здесь я рассмотрю конкретную задачу по генерации, её решение и опишу ключевые использованные принципы. Пишу эту статью для того, чтобы поделиться идеями и опытом, которых мне не хватало, когда я взялся за дело две недели назад. Я не буду делать полный разбор проекта, а лишь опишу и визуализирую принцип.

Даже не знаю, как пропустил эту новость. Обычно я всё активно отслеживаю, особенно уязвимости опенсорсного ПО, которые касаются казначейства моей страны 🤷‍♂‍