Евгений Шатунов

ISBN 978-1-56881-720-0
Jason Zink, Matt Pettineo, Jack Hoxley: "Practical rendering and computation with Direct3D 11".

На русском книги нет. Книга легко читается и в оригинале. Уже с первых глав дает понимание современного пайплайна графики, стадий инициализации систем DirectX 11, способов загрузки и представления в памяти требуемых для отрисовки данных. В книге хорошо описан и язык HLSL.
Книга хорошо подходит для холодного старта в работе с DirectX 11.

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

Языки программирования - это инструменты. А инструменты всегда надо выбирать от условий задачи. У тебя не выйдет решать все задачи только каким-то одним языком. Знать во всех тонкостях и уметь использовать строго по назначению Python, Java, C#, C++, Lua, TypeScript и, например, PHP не просто нормально, а важно.
Бьерн Страуструп один раз говорил о том, что для настоящего инженера важно знать порядка 5 разных языков и разбираться в их особенностях, чтобы считать себя настоящим специалистом.

Поэтому вообще не важно что ты выберешь на свой первый раз. Качество инженера раскрывается в его умении полноценно владеть множеством инструментов.

Для подобных целей уже давно заведены intptr_t и uintptr_t [?], а еще ptrdiff_t [?].
Именно эти типы и стоит использовать для прямой работы с адресами.

Теги C и C++ смешивать не совсем уместно. Это мешает выбору более подходящего варианта ответа.
В C++, например, если нужно только хранить адрес и позволять с ним только определенные операции, лучше мог бы подойти enum class MemoryAddress : uintptr_t;. Пустое перечисление с достаточной шириной и выравниванием избавит от возможности случайно что-то куда-то прибавить или умножить, да и от неявных преобразований убережет. А перегрузка операторов поможет разрешить только определенные операции.
Но в C так не получится.

Тут проблема не в CMake и не в CLion. Это проблема MinGW и кодировки файлов с исходным кодом.

Файлы сейчас сохранены в какой-то другой кодировке, когда GCC в составе MinGW по умолчанию ожидает кодировку UTF-8.
Достаточно будет сконвертировать файлы в кодировку UTF-8 и MinGW начнет их переваривать.

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

Насколько видно, базово механизм делится на две ветви: поиск квалифицированных имен и поиск неквалифицированных имен.
И именно в этот момент речь заходит о т.н. квалификации имени выражения.
Квалификация имени выражения тем полнее, чем точнее от самого корневого пространства имен (т.е. от ::), через все пространства имен и пространства составных типов, написано имя выражения.

Имя Process::WaitForExit, хоть и является уже квалифицированным за счет указания пространства типа, в котором метод объявлен, все еще остается недостаточно квалифицированным чтобы считаться полностью квалифицированным.
Вызов метода по его полной квалификации выглядел бы так:
process.::base::Process::WaitForExit(&exit_code);

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

Для чего нужно было писать полную квалификацию конкретно в приведенном коде?
А кто его знает. Метод base::Process::WaitForExit[?] не является виртуальным чтобы сделать предположение о невиртуальном вызове.
Просто автору так захотелось, наверное.

Я конечно могу найти луч и потом искать пересечения со всеми объектами на сцене и рассчитывать координату z уже из этого, но мне кажется это слишком ресурсозатратно

Однократное использование glReadPixels в сотни раз более ресурсозатратнее обычного оптимизированного алгоритма проверки на пересечение луча с объектами сцены.

В разработке игр на мобильных устройствах алгоритм проверки пересечений запускается даже не на каждые 10 пикселей экрана, а просто постоянно в каждом кадре, пока игрок не поднимет палец с экрана. И у людей при этом проблем с производительностью нет даже на 96+ FPS.
В продуктовых решениях мы никогда не используем glReadPixels в покадровых рутинах. Ни в мобильной разработке, ни в десктопной, ни под консоли.

Вот ответ, который тебе поможет разобраться с переводом координат мышки в 3D пространство сцены.
Чтобы снизить трудоемкость проверки на пересечение с объектами сцены, используй или Q-Tree, или Oc-Tree, или BSP, или Агломерацию.
Чтобы снизить трудоемкость проверки на пересечение конкретного объекта, используй AABB, OOBB и все те же Q-Tree/Oc-Tree или BSP для отсечения лишних полигонов модели.

Это все позволит определять объект сцены под мышкой значительно быстрее чем всего один вызов glReadPixels с проходом по матрице пикселей.

Ошибка LNK2019 относится к стадии линковки и означает что среди всех объектов линковки так и не нашлось определение обозначенной в ошибке функции.

__imp_glClear и __imp_glDrawArrays - это стандартные функции OpenGL, определены они в библиотеке opengl32.lib, которую и требуется подключить как внешнюю зависимость к твоему проекту.

Зависимости в проект подключаются через свойства проекта Visual Studio.

Чтобы понять поведение кода в C++, нужно сперва разобраться с поиском имен в C++.
Коротко, поиск имен запускается всегда для каждого имени, которое встречается в коде, и связывает использованное в коде имя с конкретным, единственным из всех прочих, объявлением этого имени.

cat1 -> sound();
Тут по пунктам. Сперва UNL определит имя cat1 как переменную в локальном пространстве с типом Cat*.
Далее UNL же определит что в пространстве класса Cat есть метод sound.
Далее для определения перегрузки Cat::sound запустится ADL и найдет в пространстве только одну перегрузку - метод без параметров. ADL вернет объявление этой перегрузки, т.к. она удовлетворяет условиям вызова метода.

Отдельно отметить стоит то, что это именно писатель определил в пространстве класса только одну перегрузку метода sound. Алгоритм ADL довольно строг и не будет искать объявления где-либо еще.
Именно поэтому при данном определении класса Cat код cat1 -> sound(1); трансляцию никогда не пройдет. Просто потому что в пространстве класса написана только одна перегрузка метода.

Что делать, когда перегрузки из родительского класса нужны все, но замещать их все в классе дочернем нужды нет?
Тут на помощь приходит ключевое слово using[?].
Это слово нужно использовать в контексте делегирования из пространства родительского класса. Определение класса Cat должно быть таким.

class Cat : public Animal
{
public:
	// Delegate all overloads of `sound`.
	using Animal::sound;
	
	void sound () override
	{
		std::cout << "Cat.sound()" << '\n';
	}
};

В этом случае код cat1 -> sound(1); пройдет трансляцию и приведет к вызову void Animal::sound(int i).

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

Тебе нужно или в видеопамять изображение передавать как BGRA, или руками поменять R и B каналы каждого пикселя после загрузки изображения из файла.
Идеальный вариант - это сменить формат файла так, чтобы изображение в нем хранилось в формате RGBA.

В рассуждениях есть ошибка.

Да, стандарт утверждает что тип int может иметь размер не меньше 16 бит.
Таблица имеет название "Minimum width", т.е. минимальный размер. Минимальный - это значит что int может иметь размер в 16 бит. А может иметь и 64 бита.

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

Ошибка в рассуждениях заключается в том, что ты проводишь нить только от int32_t к int и дальше к стандарту. В то время как стандарт определяет и требования к типу int32_t тоже.
Тип int32_t всегда и для любой модели памяти выбирается таким образом чтобы гарантировать размер в 32 бита.

То что где-то int32_t является псевдонимом int - это не более чем временное совпадение.

Типом результата Test::clone является std::shared_ptr<Test>.
Строчка Test1 asd = v[1]->clone(); эквивалентна строчке Test1 asd = std::shared_ptr<Test>{ ... };.
Оператора или конструктора преобразования из std::shared_ptr<Test> у типа Test1 нет. Трансляцию строчка Test1 asd = v[1]->clone(); не пройдет.

Идиома Cloneable служит для того, чтобы позволить копирование действительных объектов не выходя за рамки общего интерфейса и не зная действительного типа клонируемого объекта.
Или ты неправильно понял идиому, или пробуешь неправильно ее использовать.

Когда ты заранее знаешь тип, тебе незачем пользоваться клонированием, потому что ты можешь просто скопировать стандартным способом.
Правильно твоя строчка должна выглядеть так: std::shared_ptr<Test> asd = v[1]->clone();.
Или так:

Test1 asd{ *std::static_pointer_cast<Test1>( v[1] ) };

.

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

Что это означает на практике. После 4й стадии трансляции формируется модуль трансляции, содержимое которого и компилируется в объектный файл. Код модуля трансляции должен быть исчерпывающим, в нем должны находиться все необходимые для компиляции определения. А определение шаблона относится именно к таким требуемым.
Значит определение используемого в модуле шаблона должно быть внесено в модуль трансляции. А это значит что или определение должно быть вписано в тот .cpp файл, в котором шаблон инстанцируется, или определение должно быть добавлено через директиву #include.

В первом случае, когда используемое в .cpp файле определение шаблона вписано в том же .cpp файле, определение шаблона будет достижимо только в данном .cpp файле и больше нигде. В этом случае попытка инстанцировать шаблон в другом модуле трансляции приведет к ошибке трансляции, т.к. там определние шаблона будет уже недостижимо.
Файлы исходного кода включать через директиву #include - это дурной тон и прямой путь к нарушению ODR.

Во втором случае стоит сразу вспомнить про ODR и правила его соблюдения. В частности про то, что определения методов по месту их объявления являются встраиваемыми неявно. А если определение метода выполняется снаружи определения класса, то в виду требований к шаблонам функций и шаблонам методов, чтобы гарантировать ODR, встраиваемость определения нужно указывать уже явным образом.

Широкой практикой является разделение кода шаблонов на несколько типов файлов. В .h файлах обычно делают или объявления шаблонов функций, или определения шаблонов классов. В .hpp/.inl файлах обычно делают определения шаблонов функций и шаблонов методов.
При этом .hpp/.inl файл очень часто включается в самом низу .h файла с его объявлениями.
Моя личная рекомендация: использовать в таких случаях расширение .inl (от слова inline), т.к. для .hpp столь же широко закреплено взаимоисключающее с .h значение заголовка C++ кода. И видеть эти два расширения в одном проекте обычно бывает странно.

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

Да, книги Андрея Александреску, Скотта Майерса, Герба Саттера, Николая Джосаттиса, и, например, Девида Вандервуда имеют актуальность и по сей день вне зависимости от года издания или перевода.

C++ развивается вот уже 38 лет. Новые стандарты сегодня приходят с достойной одобрения частотой, но начиная с C++11 изменения в стандартах до сих пор ничего кардинально не ломают. Даже новые возможности концептуально связаны с опытом прошлых стандартов.
С другой стороны, трансляторы. Новые стандарты языка не приходят сразу, сперва требуется дождаться их поддержки в современных трансляторах. А это происходит не в одно время и не сразу по выходу нового стандарта. Да и когда появляется версия с поддержкой нового стандарта, эта поддержка не лишена ошибок, опознать которые способен только опытный инженер с экспертизой в новом стандарте.
Разработка же и вовсе не поспевает за трендами. На собеседованиях я то и дело слышу как где-то кто-то еще только вчера и еще только решил перейти на C++11. В 23-м году.
Самым широко используемым стандартом сейчас является C++17, большинство функций которого многими компаниями так до сих пор и не используется. Люди до сих пор еще только привыкают к нему.
Книги представленных авторов в понятной форме передают читателю ценный базовый опыт, который можно применять вообще не привязываясь к стандарту языка. Главное - это не брать в рассмотрение книги до 2011 года.

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

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

Такое поведение имеет список, односвязный или двусвязный.

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

Именно поэтому доступ к любому элементу вектора имеет сложность O(1). Это просто смещение на индекс элемента относительно начала блока памяти с помощью адресной арифметики.