Василий Банников

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

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

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

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

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

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++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.

Нужно посчитать мощность компонентов в ПК, сложить потребление всех компонентов.
Хорошо чтобы суммарная мощность всех компонентов не переваливала за 80% от мощности блока питания.
Видяхе нужно примерно 160 ватт для работы, остальное останется для процессора и других железок.
Если у тебя средненький проц с мощность в 60-90-110 ватт и ничего лишнего на напихано в корпус, то не парься, твоего блока питания хватит.

Все что вы пишите про "сочетания" - это мракобесие и ненаучный подход.
intel + amd
intel + nvidia
amd + amd
amd + nvidia
Все эти варианты я перепробовал и все работает отлично.

Вы правильно пишите, что у одних производителей есть некоторые технологии, которых нет у других.
В остальном - никаких различий.

1. Встраивают интерпретатор нужного языка, при необходимости урезают стандартную библиотеку (чтобы не давать коду плагинов лишних возможностей) и подсовывают туда средства общения с хост-программой.
2. Если нет нужды изолировать плагин от остальной программы, то полагаю что да, накладные расходы на поддержку плагинов уменьшатся в случае, когда плагин написан на том же языке, что и программа. В противном случае организация "песочницы" может занять столько же усилий, сколько встраивание интерпретатора.
3. Лучше, если язык плагина является или интерпретируемым (как Lua или JS), или компилируется в байткод (как Python/Java/C#). Также желательно, чтобы язык плагина имел средства интроспекции.

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

https://habr.com/ru/company/htmlacademy/blog/546500/

Основных поинтов использования семантики 3.
1) Использование подходящих элементов делает их использование удобнее. Несколько раз встречал когда ссылки делали дивами с js поверх. Нет возможности нажать на них колёсиком чтобы открылаьс в новой вкладке или правой кнопкой с соответствующем ссылке контекстным меню. Это отвратительно неудобно.
2) это помощь людям с ограниченными возможностями для понимания контекста происходящего на экране. Наглядный пример это ссылки внутри тэга nav. Можно побаловаться со скрин ридером и будет понятно о чём речь.
Если коротко: ссылки в div будут озвучены как: *ссылка*.
Ссылки в nav: "ссылка, навигация"
https://vc.ru/promo/132280-kak-zvuchat-sayty-nezry...
https://www.youtube.com/watch?v=RQiN1Hhrxu0
3) Помощь поисковым ботам понимать контекст и формировать снипеты в поисковой выдаче. Пример есть в статье выше.
https://siteclinic.ru/blog/technical-aspects/html5...

с какой-либо из «сторон дела»: пользователя, верстки, программирования, поисковых систем?

1) Про пользователей выше
2) Про вёрстку - удобнее читать
3) Про программирование - использование верных тэгов соответствующим образом влияет на работу с этими элементами в JS либо избавляет от необходимости в JS в принципе.
4) Про поисковые системы выше.

september.days = new day[6]; вы инициируете массив, а кто элементы массива создавать будет, он пустой. Создание массива не означает сразу создание в нем элементов, рекомендую основы шарпа почитать, на тему создание объектов и массивов.

Потому что разработчики CheatEngine используют специальные функции венды, чтобы получить доступ к памяти в другом процессе. ReadProcessMemory, например.

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

В вашем коде от цикла нет смысла, если без цикла просто

document.write(week.slice(0,-2).join(',') + ',' + week.slice(-2).join(',').bold());

то код хороший
в цикле надо перебирать по одному дню и выводить

const week = ['Понедельник', 'Вторник', 'Среда', 'Четверг', 'Пятница', 'Суббота', 'Воскресенье'];

for (let i = 0; i < week.length; i++) {
  if (week[i] === 'Суббота' || week[i] === 'Воскресенье') {
    document.write(week[i].bold());
  } else {
    document.write(week[i]);
  }
}

чтобы не сравнивать выходные по названию, можно вместо строк использовать объекты

const week = [{title: 'Понедельник', weekend: false}, ... {title: 'Воскресенье', weekend: true}];

for (let i = 0; i < week.length; i++) {
  document.write(week[i].weekend ? week[i].title.bold() : week[i].title);
}

Наверное прогнать тест TestMem5 TM5