За издание 2024 на курса по 3D графика сме взели три технологични решения, като нито едно от тях не е твърдо изискване, но се различават от предходни издания. В тази статия ще обясним какви са, техническите им детайли, и обосновка защо точно те...

Развойна среда: Visual Studio Code

В предни издания на курса се поддържаше Code::Blocks. Макар и това да продължава да е нелошо IDE, големият му недостатък е "чупливия" code completion. Да се пише дори неголям проект без работещ code completion е субоптимално, особено при наличие на работещи алтернативи, каквато е Visual Studio Code.

И все пак: ако искате да ползвате друг редактор, нищо не ви задържа. XCode, Qt Creator, Code::Blocks, Visual Studio Community, emacs, vim, Sublime Text са само някои от популярните възможности.

Build система: CMake

Обичайно един C++ проект е съвкупност от файлове, които трябва да бъдат компилирани до обектен код, а накрая (в случая на рейтрейсъра) - свързани до изпълним файл, заедно с външните библиотеки, които ползва (при нас ще са SDL2 и OpenEXR).

Компилацията е поредица извиквания на компилатора с подходящи командни ключове, а build системата се грижи да автоматизира това като изчислява кои файлове имат нужда от (ре)компилация. Например, ако foo.h е хедър, който се #include-ва и от bar.cpp, и от baz.cpp, то при промяна на нещо във foo.h, следва да се рекомпилират и bar.cpp, и baz.cpp. Този dependency tracking е изначалната причина да се създаде програмата make (и нейните всеизвестни мейкфайлове), но ако често добавяме нови файлове към проекта, или дори ако #include-нем нов хедър от някой от съществуващите .cpp файлове, то тези допълнения към графа от зависимости трябва да се отразят в Makefile-а, което е досадно. Затова Makefile-ове рядко се пишат на ръка, а обикновено се създават от скриптове или по-висши build системи. CMake е една такава система.

В предни издания на курса поддържахме паралелно проектни файлове за Code::Blocks и Microsoft Visual Studio. Като IDE-та, те си съдържат интегрирана build система, която работи достатъчно прилично. Проблемите тук бяха по-скоро:

• при добавяне на нов .cpp/.h файл в рейтрейсъра, трябва да се обновят два проектни файла;
• ако човек иска да си експериментира с някоя опция на компилатора, то трябва да укаже това на IDE-то, а това променя проектния файл. Потребителят му бъде предлагано да commit-не в git тази промяна, въпреки, че той може би не би искал да я commit-ва; Беше практика да има скрипотове, които четат от входен "template" проектен файл, и записва untracked копие, което реално да отвори потребителя

CMake решава и двата проблема, като

• описанието на проекта в CMakeLists.txt е компактно и почти минималистично;
• ползвайки различните генератори на CMake, можем да създадем проектни файлове за MSVC; да генерирате Makefiles; и още дузина други формати
• спестява малко работа по включване на външните библиотеки SDL2 и OpenEXR, понеже те си идват с готови cmake скриптове, които съдържат особеностите на библиотеката и как тя да бъде включена в проекта

Освен това, в последни години, CMake се наложи като дефакто стандарт в open-source световете за C++ програми и особено библиотеки. Това е стандартният пакетиращ формат, съдържащ информация на кои други библиотеки зависи тази библиотека или програма, и кои headers са вътрешни, кои външни.

Toolchain: MinGW-w64

Под toolchain разбираме всички програми, свързани с компилирането: компилатор, линкер, дебъгер, асемблер и дизасемблер, ресурсен компилатор, ...

Ако за развойна среда ползвате Visual Studio Community, препоръката ни е да си генерирате .sln/.vcxproj от CMake, и след което да си компилирате, ползвайки IDE-то. Това беше и препоръката в предходни издания на курса, т.к. тогава алтернатива на MSVC нямаше истински за Windows (MinGW не се поддържаше нативно от Visual Studio, а и не беше достатъчно стабилен и надежден toolchain)

От това издание на курса, и особено ако ползвате Visual Studio Code, за компилатор най-добре ползвайте MinGW-w64. MinGW включва популярният компилатор GCC, който генерира добре оптимизиран код (често по-добър от MSVC), а качеството на toolchain-а е достатъчно, че самите Microsoft да го препоръчват. Ако се чудите между MSVC и GCC (MinGW-w64), изберете второто, защото:

• По време на презентациите ще се пише на Visual Studio Code с компилатор GCC под Linux; ползвайки Visual Studio Code и GCC под Windows ще ви доближи максимално до пробната среда от лекциите, без да минавате на Linux;
• Ако тестваме ефекта от някоя gcc-specific компилаторна опция на лекциите, MinGW ви дава възможност да я тествате абсолютно същата. Не всички GCC възможности имат еквивалент в MSVC;
• Visual Studio Community е предназначено за любители и студенти, със забрана за професионална разработка (билдване на програми, които да продавате). MinGW няма такова изискване. Макар, че учебният рейтрейсър напълно попада в разрешената употреба на Visual Studio Community, наложеното ограничение все пак ви лишава от някаква свобода, а няма защо да се лишаваме, ако има алтернатива, която не ни лишава от нищо.