Станислав Макаров

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

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

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

DirectX, Vulkan и OpenGL, равно как Metal и ряд проприетарных GAPI некоторых закрытых платформ, не являются графическими библиотеками. Это все - Graphics Application Programming Interface - GAPI.
Это - низкоуровневые интерфейсы драйвера GPU, позволяющие эксплуатировать ресурсы видеокарты в своих целях. Не только для рисования чего-то, а для ИИ, ML, сложных статистических вычислений, предсказаний и прочих расчетов на больших объемах данных.
Под капотом любого инструмента, будь-то проприетарный или публичный, в его графическом слое используется один или несколько GAPI. Без этого никак.
OpenGL, как и DirectX 11, нисколько не устарели, поскольку предоставляют упрощенный интерфейс управления ресурсами GPU. Они используются тогда, когда разработчикам не нужны самые тонкие механизмы управления ресурсами GPU, которые предоставляют DirectX 12 или Vulkan. Потому что последние, помимо прочего, требуют от разработчиков более глубокой экспертизы и больше ресурсов на разработку всего того же, что на OpenGL и DirectX 11 реализуется меньшими силами и за меньшее время.

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

Информации по каждой отдельной области разработки игр хоть отбавляй. Ее настолько много, что одному человеку за жизнь не усвоить. Поэтому от современного специалиста сегодня требуется спрофилироваться, т.е. определиться со своим профилем работы и стать экспертом.
Я больше 15 лет занимаюсь разработкой игровых движков и медиаферймворков. Более 10 лет занимаюсь коммерческой разработкой кросслпатформенных инструментов. Я начинал свое обучение по книгам и документации для всех интересующих меня областей еще 20 лет назад. Я самостоятельно освоил множество API, включая графические, сетевые, звуковые и API целевых платформ, используя книги и документацию. Экспертные знания C++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.

если передать byte[], то сравнивать не хочет, объясните, пожаулйста

Потому что компилятор генерирует вот такое:

EqualityComparer<byte[]>.Default.Equals(<x>k__BackingField, other.<x>k__BackingField);

Если тебе нужно сравнение по содержимому массивов - тебе придётся самостоятельно определить метод с вот такой сигнатурой:

public virtual bool Equals(TypeEncoding other) {
  // код сравнения this с other
}

А также тебе придётся переопределить GetHashCode, чтобы он на одинаковых массивах отдавал одинаковое число.

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

NULL - это не пустое поле. Это "поле не заполнено".
Используется в тех случаях, когда разница между этими состояниями - есть.
Кроме того, у числовых полей или дат просто нет "пустого" варианта.
0 и '1970-01-01 0:00:00' - это значения, которые вполне могут иметь смысл.
Например, при подсчете средних значений или интервалов NULL позволяет исключить ненужные строки.

Если вам без разницы, заполнил юзер свои поля или нет - значение по умолчанию подходит, использовать NULL просто незачем.

Объекты разные по содержанию, но нам нужны только пару ключей, которые есть у каждого объекта

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

type Item = { a: number };
const data: Array<Item> = [ // О том что существует "b" и "c" мы молча забудем :)
  {"a": 1, "b": 42},
  {"a": 2, "c": 33}
];

console.log(data[0].a)

Видимо Хром и потратил место, на кэш, временные файлы и т.п.

Они не отказываются. Скорее происходит отказ от "парадигмы" разработки. Языки стали мульти-парадигменные. Посмотрите на С++20 или Scala. Их невозможно положить в коробочку ООП или ФП. В них есть почти полный набор фич и оттуда и отсюда. И с каждым годом число фич растет и граница размывается. Нашим потомкам будет вообще непонятно где идет раздел.

По поводу golang. Это язык ограниченной разработки. Его создавали специально чтобы порог вхождения был низкий. Фактически делали лайтовый С++ которому можно обучить школьника за 14 дней. Но с перформансом выше чем у Питона. Поэтому выражать какие-то сложные конструкции на типах там скорее всего не получится. У golang есть свой манифест. Я забыл как он называется и где он. Вобщем там довольно четко обоснованно почему такие принципы и почему такая идеология.

Компьютерная графика - очень большая и сложная область. Обучаться до конкурентного уровня нужно очень усердно и очень долго.

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

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

После этого двигаться стоит в сторону инструментов разработки. Их должно быть несколько. C# и F# ты знаешь, это хорошо. Java будет прекрасным дополнением. Настоящий инженер не имеет права зажимать себя рамками одного лишь инструмента, это будет его минус в конкуренции. Rust слабо востребован и мало применяется, но знать его на некотором уровне будет просто полезно в качестве инвестиции и для общего развития. C++ сильно распространен и сильно востребован, однако рынок труда сейчас переполнен слабыми середнячками, которые мало на что годятся в реальной работе, а C++ является крайне сложным инструментом и не позволит тебе быстро начать с ним работать на том же уровне, на котором тебе позволяет тот же C#. Поэтому если брать C++, то уходить в него надо прямо очень серьезно для того чтобы получить конкурентное преимущество перед описанными выше людьми.

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

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

хеллоуворд видится как какой-то буддистский коан.

Минимальный современных хеллоу ворлд выглядит так:
Console.WriteLine("Hello world!");

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

1. Можно просто убрать этот конкретный using, используя global usings или используя полные имена типов
2. Можно не писать namespace или написать любой свой собственный. Или можно использовать file scoped namespace
3. Можно придумать своё имя класса, можно сделать его статичным, можно сделать явно приватным или публичным.
4, 5, 6. Main (точка входа) обязан быть статичным. Другие методы могут быть не статичными.
Main можно сделать публичным или приватным, можно дать другое имя, но тогда придётся в опциях компилятора указать, какое имя.
Main можно сделать асинхронным - тогда вместо void или int (Да, он может возвращать int) будет Task или Task<int>
7,8,9. string[] args можно не указывать, или дать этому параметру другое имя (не args), но принимать что-то иное нельзя
10,11. Это уже относится к телу метода и оно может быть любым. Но вместо Console.WriteLine можно написать полное имя - System.Console.WriteLine или сделать using static System.Console и тогда можно будет написать просто WriteLine

Почему ни кто не читает документацию????
https://doc.qt.io/qt-6/resources.html

If the user's locale is French (i.e., QLocale::system().language() is French), :/cut.jpg or qrc:/cut.jpg becomes a reference to the cut_fr.jpg image. For other locales, cut.jpg is used.

See the QLocale documentation for a description of the format to use for locale strings.

See QFileSelector for an additional mechanism to select locale-specific resources.

Однажды я на подобный вопрос уже отвечал, правда там вопрос был о кроссплатформенности, а не о трансляторах.

Какая разница между clang и GCC.
Разница большая. GCC обладает обширной поддержкой наследия идиом и конструкций из языка C, которые, вынужденно или по своей воле, поддерживает в современном C++.
VLA, тип по умолчанию, всевозможные изыски синтаксиса C. Это все GCC не глядя принимает за C++ код и позволяет трансляцию.
GCC даже сегодня многократно нарушает стандарты C++ просто потому что выбрал стратегию поддержки экзотической функциональности C в коде C++. Так же GCC не хвастается и скоростью поддержки стандартов C++.
В 2016 году Google полностью отказались от поддержки GCC в Android NDK из-за слишком плохой поддержки стандартов и слишком свободного следования стандартам C++. В этот момент GCC стал неконкурентоспособным относительно оставшихся двух самых широко используемых трансляторов.
Clang же, наоборот, сегодня считается, буквально, бастионом идеального следования стандартам C++. Clang точно поддерживает стандарты во всех деталях, максимально быстро интегрирует изменения и добавления стандартов, позволяет в самых первых рядах поиграться с функциональностью из драфтов следующего стандарта C++.
Clang обладает обширной системой статической и динамической проверки кода: богатый статический анализ, возможность подключения санитайзеров, поддержка C++ Core Guidelines, очень качественные отчеты об ошибках трансляции, хорошая скорость трансляции.
Это все ставит clang в предпочтение перед GCC на третьих для GCC платформах.

О полной совместимости между трансляторами.
Полная совместимость между трансляторами есть. Иначе я бы не мог делать то, что я делаю. А дело мое заключается в создании полностью кроссплатформенного кода, который однозначно собирается на всех целевых платформах и на всех них выполняется так же однозначно.
Полная совместимость между трансляторами заключается в строгом соответствии кода выбранному стандарту C++. Всё, точка. На этом к трансляторам требования заканчиваются.
Только тут есть небольшая проблема. Каждый транслятор по-своему поддерживает стандарт и по-своему реализует неоговоренные стандартом механики. Каждый транслятор имеет свои ошибки трансляции. И вскрывается это все именно в процессе работы над кроссплатформенным кодом.

Я в своей работе видел многое. Я видел как при смене GCC на clang люди хватались за голову и отказывались от последнего просто потому что он нашел горы нарушений стандарта, которые молча принимал GCC. Я видел как группа из 5 человек 3 месяца рефакторила код при переходе с MSVS2015 на MSVS2017 (т.е. просто при смене версии транслятора) просто потому что разработчики из рук вон плохо знают используемый ими стандарт C++.
Я видел ошибки в clang, приводящие к неверной генерации кода. Я видел ошибки в GCC, не позволяющие использовать его для кроссплатформенной сборки. Я видел ошибки в MSCL, в результате которых последний явно нарушает стандарт, а команда его разработки отказывается это исправлять потому что "иди нафиг".

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

Самый надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

# клонируем репозиторий в соседний каталог
# иначе придётся использовать ключ --force
git clone --no-local . ../clonerepo/
# переходим в свежий клон
cd ../clonerepo
# чистим
git filter-repo --path "path/to/file" --invert-paths
# проверим что файл исчез
git log --all --oneline --name-status -- "path/to/file"