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

Сегодня мы не рассказываем про нейронку, которая запилит Uncharted 5 или Dark Souls 4, но она сформировала интересный кейс среди нейронок последних годов. Обычно, когда мы говорим про генеративные ИИ, мы представляем себе Идеограмм, Stable Diffuison или SORA.

Но вот разработчики с Google собрали из Stable Diffiusion движок, который генерирует игровой процесс уже существующей игры — Doom из 90s.

О том, как работает подобная нейронка рассказываем ниже.

Периодически читаю комментарии в духе «Разница между Past Simple и Present Perfect – простая грамматическая тема, в школьной программе нормально даётся, или у вас школы какие-то не такие были». Это неправда. Тема тяжелейшая. Не бывает людей, которым она даётся легко. Нередко в ней путаются даже выпускники инязов. Например, в ситуациях, когда оба времени возможны. Пока есть слова-маркеры (when, just, already) – всё более-менее. Без них плывут, потому что плохо понимают саму суть.

Есть мнение, что занятия по иностранному языку на русском ведут только преподаватели с низкой квалификацией. Английский надо преподавать на английском!

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

У меня была студентка, которая ездила на велосипеде не держась руками за руль и при этом вязала. Это не так уж сложно: она любит ездить на велосипеде, часто отпускает руль, вяжет с детства. А представьте учить кого-то СРАЗУ ездить на велосипеде не держась за руль, и чтобы он при этом ещё вязал! Научится, конечно, в конце концов, если не свернёт себе шею в процессе. При изучении языка шею сворачивают редко, зато часто приходят к твёрдому убеждению, что «языки – не моё». По мне, это такая же нелепость, как «я не способен осилить химию в объёме школьного курса – не дано».

Исторически потребность в строках и их использование в игровых движках было довольно ограниченое, кроме, разве что, локализации ресурсов, где была необходимость полноценной поддержки чего-то отличного от набора ASCII символов. Но, при желании, даже эти ресуры разработчики умудрялись упаковать в доступные 200 элементов набора ASCII, а учитывая что игра обычно запускается только в одной локали, то никаких потребностей в конвертации не было. Но есть тут и отличия от стандарта, стараниями Sony практически с начала нулевых, еще до 20 стандарта разработчикам игр были доступны несколько моделей символьных литералов. Стандартый ASCII на PS1 и частичная поддержка Unicode (ISO 10646), с выпуском сдк для второй плойки добавили поддержку UTF-16 и UTF-32, а после выхода PS3 добавили поддержку UTF-8.

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

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

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

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

Приятного чтения!

Спустя годы проекты обрастают тёмными местами, в которые никто не хочет соваться, поскольку их сложно понять и легко сломать. Сегодня мы посмотрим на кейс рефакторинга такого кода с переводом на ООП рельсы при помощи паттернов, причём со стилем (современным).

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

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

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

Знаете, я никогда не задумывался, насколько плоха или хороша инициализация переменных в языке C++. Я просто использовал ее. И не имел никаких проблем. Но недавно я посмотрел пару видео, пролистал несколько статей и да, я должен признать… она действительно ужасна. Один очень серьезный человек даже сказал, что мы, как сообщество программистов, виновны в том, что C++ не настолько хорош, насколько он мог бы быть.

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

Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:

«Возьмём для примера этот код в локальной области видимости функции:

int a;

a = 5;

Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".

Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.

Можете ли вы сказать, какая строка считается инициализацией?»

Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.

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

Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»

Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.

Привет! Меня зовут Юля Вакуленко, я дизайнер в AGIMA. Хочу вам рассказать о том, как знания из художественной школы помогают мне с решением рабочих задач.

Нет, эта статья не ответит на вопрос «Должны ли дизайнеры уметь рисовать?». Но если вы всё-таки об этом спросите, я скажу нет, не должны. Дело в том, что принципы, которые заложили в мою голову в художественной школе, определяют мой подход к задачам и в целом к работе дизайнера. О них я и хочу рассказать. Этот текст отзовется в сердечке всех коллег-дизайнеров, кто отмотал годы в художке.

О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.

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

Статья о том, как я во время каникул писал-писал язык для описания конфигураций, да и переборщил с объёмом

Всем салют! Давайте решим задачу "Middle of the Linked List"

Дан указатель head на начало односвязного списка, нужно вернуть средний узел списка.

Если средних узлов два, нужно вернуть второй средний узел.

Если вы никогда не пробовали смотреть как код на C++ разворачивается компилятором в код Assembly – вас ждёт много сюрпризов, причём, не нужно смотреть какой-то замудренный исходный код полный templates или других сложных конструкций: рассмотрите следущий snippet:

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