Использование библиотек и компонентов
В проектах C++ часто требуется вызывать функции или обращаться к данным в двоичных файлах, таких как статические библиотеки (LIB-файлы), библиотеки DLL, компоненты среды выполнения Windows, компоненты COM или сборки .NET. В этих случаях необходимо настроить проект таким образом, чтобы он мог находить нужные двоичные файлы во время сборки. Конкретный способ сделать это зависит от типа вашего проекта, типа двоичного файла, а также от того, был ли этот двоичный файл собран в том же решении, что и ваш проект.
Использование скачанных библиотек с помощью vcpkg
Если вы хотите использовать скачанную библиотеку с помощью диспетчера пакетов vcpkg, то приведенные ниже инструкции можно пропустить. Дополнительные сведения см. в разделе:
- vcpkg в проектах CMake
- Установка и использование пакетов с CMake в Visual Studio
- vcpkg в проектах MSBuild
- Руководство. Установка и использование пакетов с MSBuild в Visual Studio
Использование статических библиотек
Если проект статической библиотеки был создан в том же решении:
- #include файл заголовка для статической библиотеки с помощью кавычки. В типовом решении путь начинается с ../ . При поиске вы можете использовать предложения технологии IntelliSense.
- Добавьте ссылку на проект статической библиотеки. Щелкните правой кнопкой мыши элемент Ссылки в узле проекта приложения в обозревателе решений и выберите Добавить ссылку.
Если статическая библиотека не входит в состав решения:
- Щелкните правой кнопкой мыши узел проекта приложения в обозревателе решений и выберите Свойства.
- На странице свойств Каталоги VC++ добавьте в раздел Пути библиотек путь к каталогу, который содержит LIB-файл. Затем добавьте в раздел Включаемые каталоги путь к файлам заголовков библиотеки.
- На странице свойств компоновщика > добавьте имя LIB-файла в дополнительные зависимости.
Библиотеки динамической компоновки
Если библиотека DLL была собрана в рамках того же решения, что и приложение, выполните те же действия, что и для статической библиотеки.
Если библиотека DLL не входит в состав решения приложения, вам потребуются DLL-файл, заголовки с прототипами для экспортируемых функций и классов, а также LIB-файл, содержащий необходимую для компоновки информацию.
- Скопируйте DLL-файл в папку выходных данных проекта или другую папку, которая задана в качестве стандартной для поиска библиотек DLL в Windows. Дополнительные сведения см. в разделе «Порядок поиска библиотеки динамических ссылок».
- Выполните шаги с 1 по 3 для статических библиотек, чтобы задать пути к заголовкам и LIB-файлу.
COM-объекты
Если в собственном приложении C++ требуется использовать COM-объект и этот объект зарегистрирован, вам достаточно вызвать функцию CoCreateInstance и передать в нее CLSID объекта. Система выполнит поиск объекта в реестре Windows и загрузит его. В проекте C++/CLI COM-объект можно использовать таким же образом. Кроме того, он может использовать его, добавив ссылку на нее из списка добавления ссылок > COM и используя ее через вызываемую оболочку среды выполнения.
Сборки .NET с компонентами среды выполнения Windows
В проектах универсальной платформы Windows (UWP) или C++/CLI для использования сборок .NET или компонентов среды выполнения Windows можно добавить ссылку на сборку или компонент. В узле Ссылки проекта универсальной платформы Windows (UWP) или C++/CLI представлены ссылки на часто используемые компоненты. Щелкните правой кнопкой мыши узел Ссылки в Обозревателе решений, чтобы открыть диспетчер ссылок и просмотреть доступные в системе компоненты. Нажмите кнопку Обзор, чтобы перейти к папке, в которой находится нужный вам пользовательский компонент. Поскольку сборки .NET и компоненты среды выполнения Windows содержат встроенные сведения о типах, для просмотра их методов и классов можно щелкнуть правой кнопкой мыши и выбрать команду Просмотреть в обозревателе объектов.
Свойства ссылки
Каждый тип ссылки имеет свойства. Свойства можно просмотреть, выбрав ссылку в обозревателе решений и нажав клавиши Alt + ВВОД. Также можно щелкнуть ссылку правой кнопкой мыши и выбрать пункт Свойства. Одни свойства доступны только для чтения, другие можно изменять. Тем не менее обычно эти свойства не требуется изменять вручную.
Свойства ссылки ActiveX
Свойства ссылки ActiveX доступны только для компонентов COM. Данные свойства отображаются только тогда, когда в панели Ссылки выбран компонент COM. Эти свойства нельзя изменить.
- Управление полным путем Отображает путь к каталогу элемента управления, на который указывает ссылка.
- GUID элемента управления Отображает GUID для элемента управления ActiveX.
- Версия элемента управления Отображает версию элемента управления ActiveX, на который указывает ссылка.
- Имя библиотеки типов Отображает имя библиотеки типов, на которую указывает ссылка.
- Средство программы-оболочки Отображает средство, которое используется для создания сборки взаимодействия из указанной библиотеки COM или элемента управления ActiveX.
Свойства ссылки на сборку (C++/CLI)
Свойства ссылки на сборку доступны только для ссылок на сборки .NET Framework в проектах C++/CLI. Данные свойства отображаются только тогда, когда в панели Ссылки выбрана сборка .NET Framework. Эти свойства нельзя изменить.
- Относительный путь Отображает относительный путь от каталога проекта к сборке, на которую указывает ссылка.
Свойства сборки
Следующие свойства доступны для различных типов ссылок. Они позволяют задавать способ построения со ссылками.
- Копировать локальные Указывает, следует ли автоматически копировать сборку, на которую указывает ссылка, в целевое расположение во время сборки.
- Копировать локальные вспомогательные сборки (C++/CLI) Указывает, следует ли автоматически копировать вспомогательные сборки ссылочной сборки в целевое расположение во время сборки. Используется, только если для параметра Копировать локальные задано значение true .
- Выходные данные ссылочной сборки Указывает, что эта сборка используется в процессе сборки. true означает, что эта сборка используется в командной строке компилятора во время выполнения сборки.
Свойства ссылок проектов на проекты
Следующие свойства определяют ссылку проекта на проект из проекта, выбранного в панели Ссылки, на другой проект в том же решении. Дополнительные сведения см. в статье Управление ссылками в проекте.
- Компоновать зависимости библиотек Если это свойство имеет значение True, система проектов установит в зависимом проекте связь с LIB-файлами, создаваемыми независимым проектом. Обычно устанавливается значение True.
- Идентификатор проекта Уникальный идентификатор независимого проекта. Значение свойства — это GUID внутренней системы, который невозможно изменить.
- Использовать входные данные зависимостей библиотек Если это свойство имеет значение False, система проектов не установит в зависимом проекте связь с OBJ-файлами для библиотеки, созданной независимым проектом. Таким образом, это значение отключает инкрементную компоновку. Обычно указывается значение False, так как при наличии множества независимых проектов сборка приложения может занять длительное время.
Ссылочные свойства только для чтения (COM & .NET)
Следующие свойства существуют в ссылках на компоненты COM и сборки .NET, и их нельзя изменить.
- Имя сборки Отображает имя сборки для сборки, на которую указывает ссылка.
- Язык и региональные параметры Отображает язык и региональные параметры выбранной ссылки.
- Description Отображает описание выбранной ссылки.
- Полный путь Отображает путь к каталогу сборки, на которую указывает ссылка.
- Identity Для сборок .NET Framework отображает полный путь. Для компонентов COM отображает GUID.
- Подпись Отображает метку ссылки.
- Имя Отображает имя ссылки.
- Токен открытого ключа Отображает токен открытого ключа для идентификации сборки, на которую указывает ссылка.
- Строгое имяtrue , если сборка, на которую указывает ссылка, имеет строгое имя. Сборка со строгим именем имеет уникальную версию.
- Версия Отображает версию сборки, на которую указывает ссылка.
FAQ: Как подключить библиотеку на C/C++? Зачем файлы .h, .lib, .dll?
Этот вопрос довольно часто возникает у начинающих, а также у программистов, которые привыкли работать с языками, имеющими встроенную поддержку импорта из модулей (например, Delphi/Pascal).
В языке C исторически сложилось иначе. Чтобы подключить библиотеку к программе на языке C или C++, нужно выполнить два действия:
- Включить в исходный текст заголовочные файлы библиотеки (.h или .hpp) директивой #include
- Обеспечить, чтобы при сборке программы использовались соответствующие объектные файлы библиотеки (в зависимости от системы они могут иметь расширения .lib, .a, .o, .obj и т.д.) В зависимости от используемого компилятора это делается разными способами, например:
– добавить файл(ы) в проект как объектные;
– в MS Visual Studio: добавить имя файла в Linker->Input->Additional Dependencies (если файл в другом каталоге, путь добавить в Linker->General->Additional Library Directories);
– при использовании make прописать файл в список файлов для линкера (обычно это LIBS= или т.п.).
А если библиотека представлена в исходных текстах, надо просто добавить все нужные .c (.cpp) файлы в проект программы.
Файлы .lib должны быть совместимы с используемым компилятором и ОС. Поэтому к библиотеке может прилагаться несколько наборов файлов для разных сред.
Файлы .dll (динамическая библиотека Windows) не нужно указывать при компиляции, они используются при выполнении программы (о динамических библиотеках см. ниже).
В чём смысл этих действий, зачем нужны все эти разные файлы?
Файл заголовков (.h) нужен для того, чтобы компилятор мог распознать идентификаторы (имена макросов, типов, переменных, функций), которые определены в библиотеке. Специального средства для импорта имён в стандартном C нет, и для этого используется директива препроцессора #include, которая вставляет включаемый файл как исходный текст, как если бы он был написан вместо директивы #include.
В файлах .h идентификаторы объявляются, но не определяются (decalared but not defined), т.е. под переменные не выделяется пространство, а функции не имеют кода. Это достигается использованием ключевого слова extern для переменных, а для функций даются прототипы, например:
/* mylib.h */
extern int mylib_global_variable;
int mylib_function(int x, int y);
Если эти объявления включить через #include, то компилятор сможет скомпилировать .c файл, в котором упоминаются mylib_global_variable и mylib_function, например:
/* myprog.c */
#include «mylib.h»
int main(void)
mylib_global_variable = 1;
return mylib_function(mylib_global_variable, 2);
>
После компиляции получится объектный файл (например, myprog.o), причем в нём эти идентификаторы будут описаны как внешние. Но линкер не сможет собрать такую программу в готовый исполнимый файл, потому что для этих идентификаторов нет определений, т.е. есть имена, но нет «тела».
При попытке собрать программу будет выдано сообщение об ошибке «undefined external».
Теперь нужно, чтобы при сборке программы нашёлся объектный файл, в котором реализованы все эти переменные и функции. Допустим, у нас есть исходный текст библиотеки – например, такой:
/* mylib.c */
int mylib_global_variable = 0;
int mylib_function(int x, int y)
return x + y;
>
Тогда при его компиляции получится объектный файл, который можно соединить с нашей основной программой (включить оба .c файла в проект или makefile), и всё готово.
Если же библиотека уже скомпилирована отдельно, то нужно взять готовые объектные файлы (.lib или .a – это по сути контейнеры объектных файлов) и передать их линкеру.
Это в общих чертах всё, что касается статических библиотек, т.е. таких, код которых попадает в исполнимый файл основной программы.
О динамических библиотеках следует сказать отдельно. Динамическая библиотека отличается тем, что её код хранится в отдельном файле (Windows – .dll, в системах типа GNU/Linux и FreeBSD – .so) и загружается операционной системой при запуске программы, либо самой программой по мере надобности.
Рассмотрим оба способа на примере Windows.
Чтобы подключить динамическую библиотеку с загрузкой при запуске, используются файлы .h и .lib – точно так же, как в случае статической библиотеки. Просто в данном случае .lib файл содержит не сам код, а ссылки на импортируемые функции из DLL, так что после компиляции получается .exe файл, в котором есть ссылки на нужную DLL. Файл .dll при компиляции не нужен, зато нужен при запуске (в каталоге с .exe файлом, в системных каталогах Windows, в каталогах, перечисленных в переменной окружения PATH и т.д.).
Также можно загружать динамическую библиотеку «вручную» функциями LoadLibrary и GetProcAddress. Тогда .lib файл не нужен вообще, а .h включить обычно нужно (чтобы иметь описания типов и констант-макросов), но к функциям обращаться нужно будет не по именам из .h, а через указатели соответствующих типов, например:
/* . */
typedef int (*my_funct_ptr_t)(int, int); /* тип указателя на функцию */
HINSTANCE h_dll;
my_func_ptr_t func;
int x = 1, y = 2, z;
h_dll = LoadLibrary(«mylib.dll»);
if (NULL == h_dll) return MY_ERROR_CANNOT_LOAD_DLL;
func = (my_func_ptr_t)GetProcAddress(h_dll, «mylib_function»);
if (NULL == func) return MY_ERROR_FUNCTION_NOT_FOUND;
z = func(x, y);
/* . */
| Перейти к другим статьям FAQ | Cтатья создана: | 14.08.2014 |
| Последняя редакция: | 04.08.2016 |
Графическая библиотека
Инициализация и закрытие графики
Библиотека для C++, использовать только в файлах c расширением «.cpp». Подключение:
#include «graphics.h»
Внимание! Нужно ставить самым последним в списке подключаемых файлов.
int initwindow(int width, int height, const char* title=»Windows BGI», int left=0, int top=0, bool dbuf=false, bool closeall=true);
Инициализирует графическую систему (новая).
Создается окно указанного размера. Возвращается номер окна. Можно также задать заголовок окна, координаты, режим буферизации (по умолчанию не включена), поведение при нажатии кнопки X для закрытия окна (по умолчанию закрывается программа).
int getmaxx(void);
Возвращает максимальную координату экрана по x.
int getmaxy(void);
Возвращает максимальную координату экрана по y.
void closegraph();
void closegraph(int window);
Завершает работу с графической системой.
Графическое окно закрывается. По умолчанию закрываются все окна, можно указать номер окна или CURRENT_WINDOW для закрытия текущего окна.
void cleardevice(void);
Очищает графический экран. Все установки сбрасываются в начальное состояние.
int getcurrentwindow(void);
void setcurrentwindow( int window );
Позволяют выбрать текущее окно и узнать номер текущего графического окна.
void restorecrtmode(void);
Восстанавливает текстовое консольное окно и делает его текущим.
Устаревшие функции, для совместимости со старыми программами
void initgraph(int *graphdriver, int *graphmode, char *pathtodriver);
Инициализирует графическую систему.
Для graphdriver можно указать значения DETECT, CGA, EGA, VGA и др. Для graphmode — CGAC0, CGAHI, EGALO, EGAHI, VGALO, VGAMED, VGAHI, VGAMAX и т.д. Отличия только в размерах создаваемого окна, они устанавливаются в соответствии с возможностям старых видеокарт (VGA/VGAHI — 640×480, VGA/VGALO — 640×200, VGA/VGAMAX — максимально возможный размер). В режиме DETECT — используется VGA/VGAHI. Последний параметр не используется.
Вызов:
int gd=VGA, gm=VGAMAX; initgraph(&gd,&gm,"");
Графические библиотеки для C (3D, 2D)
В общем, что на сегодняшний день релевантно в области графических библиотек (3D, 2D) для C? На данный момент щупаю OpenGL. Может стоит сначала разобраться в OpenGL, а потом переходить на какой-нибудь SDL2 (для 2D, а для 3D оставить OpenGL)
snake266 ★★
10.12.19 20:01:37 MSK
← 1 2 →
Я думаю, писать подобное на С на сегодняшний день совершенно нерелеванто. Хотя бы потому, что в случае с SDL2 придётся переизобретать на C то, что люди давно написали на плюсах в SFML (графическое API которого — плюсовая обёртка над OpenGL, те же шейдеры использовать очень удобно).
Meyer ★★★★★
( 10.12.19 20:04:05 MSK )
Последнее исправление: Meyer 10.12.19 20:05:29 MSK (всего исправлений: 1)
Зачем тебе opengl если собираешься переходить на sdl? А еще есть вулкан. Че делать то собрался? Если для изучения комп графики, забудь про sdl и прочие врапперы.
BOSS-NIGGER ☆
( 10.12.19 20:08:06 MSK )
Может стоит сначала разобраться в OpenGL, а потом переходить на какой-нибудь SDL2
SDL2 можно освоить за вечер, а OpenGL это любовь на всю жизнь 🙂
cvv ★★★★★
( 10.12.19 20:09:05 MSK )
Ответ на: комментарий от cvv 10.12.19 20:09:05 MSK
Любовь с первого взгляда?
snake266 ★★
( 10.12.19 20:09:47 MSK ) автор топика
Ответ на: комментарий от BOSS-NIGGER 10.12.19 20:08:06 MSK
Ну интерес у меня больше академический, чем практический
snake266 ★★
( 10.12.19 20:10:31 MSK ) автор топика
Ответ на: комментарий от Meyer 10.12.19 20:04:05 MSK
У меня скорее академический интерес, поэтому что то переизобретать я не боюсь
snake266 ★★
( 10.12.19 20:12:05 MSK ) автор топика
Ответ на: комментарий от snake266 10.12.19 20:09:47 MSK
Ну это дело вкуса
cvv ★★★★★
( 10.12.19 20:12:28 MSK )
SDL2 изучай, тебе все равно окно для OpenGL создавать чем то надо. Хотя я хз зачем тебе такие низкоуровневые либы.
insw
( 10.12.19 20:13:28 MSK )
Последнее исправление: insw 10.12.19 20:14:39 MSK (всего исправлений: 1)
Ответ на: комментарий от snake266 10.12.19 20:12:05 MSK
Ну в таком случае, с помощью OpenGL можно и всякие двухмерные вещи рисовать без каких-либо проблем. А на SDL2 переложить создание окна, OpenGL контекста, обработку ввода, кроссплатформенный I/O и т.д.
Meyer ★★★★★
( 10.12.19 20:15:25 MSK )
Ответ на: комментарий от snake266 10.12.19 20:10:31 MSK
Значит смотри на 10-15 лет вперед. Я серьезно. Ray tracing, алгоритмы, развитие железа, там много направлений. Дохрена чего. Убить кучу времени на опенжеле ты всегда успеешь. Получишь незабываемых впечатлений, это да. Конечно, может и стоит немного времени на это потратить, но не зацикливайся.
А sdl это спрайты двигать, утилитарщина одним словом.
BOSS-NIGGER ☆
( 10.12.19 20:18:50 MSK )
Ответ на: комментарий от insw 10.12.19 20:13:28 MSK
SDL2 изучай, тебе все равно окно для OpenGL создавать чем то надо.
Я пока использовал GLUT для создания окон.
Хотя я хз зачем тебе такие низкоуровневые либы.
Узнать как все это работает под капотом. Чтобы понимать, как устроен sdl
snake266 ★★
( 10.12.19 20:19:02 MSK ) автор топика
Взгляни на Corange. Ничто не мешает использовать SDL как просто инициализатор контекста, а всё остальное делать без призязок к нему.
Изучай OpenGL спокойно, а SDL используй просто как упрощение своей жизни. Открыть окно, получать эвенты, всё то что к OpenGL отношения не имеет, но также всё то что делает изучение удобнее. Ты же хочешь вывести квадратик на экран и двигать его мышкой? Ну так выводит через OpenGL, а двигай через SDL. Это два API которые дополняют друг друга, а не заменяют. И да можешь смело просто не использовать функции типа SDL_GLblablabla это всё опционально и не обязывает ни к чему.
LINUX-ORG-RU ★★★★★
( 10.12.19 20:22:48 MSK )
Ответ на: комментарий от BOSS-NIGGER 10.12.19 20:18:50 MSK
Хм, да, надо будет почитать про это на досуге.
snake266 ★★
( 10.12.19 20:25:28 MSK ) автор топика
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 20:22:48 MSK
Спасибо за такой развернутый ответ. А что можете сказать про Vulkan? Стоит его трогать?
P.S. Если честно, ждал вашего ответа, так как иногда видел ваши работы и удивлялся им. Можно ли где-то найти ссылку на ваш гитхаб? Было бы очень интересно посмотреть на ваш код.
snake266 ★★
( 10.12.19 20:34:02 MSK ) автор топика
Ответ на: комментарий от snake266 10.12.19 20:25:28 MSK
Если задача не только движки для игрушек делать, то ещё взгляни на физически корректный рендеринг.
Вот известный материал по этому. (pdf).
Весьма интересно, но помимо этого нужно оптику осилить, если профессионально заниматься решишь.
Artamudo ★★★★
( 10.12.19 20:34:57 MSK )
Ответ на: комментарий от Artamudo 10.12.19 20:34:57 MSK
Выглядит очень интересно. За пдфку спасибо, будет что почитать скучными вечерами.
snake266 ★★
( 10.12.19 20:38:49 MSK ) автор топика
Ответ на: комментарий от BOSS-NIGGER 10.12.19 20:18:50 MSK
Не надо недооценивать SDL. Про спрайтодвигатель это вообще лол. Он просто даёт тебе аппаратно ускоренное API для 2D графики, а что ты будешь там рисовать дело десятое хоть спрайты хоть всю десткопную графику выводить.
Ида это фундаментальная «утилитарщина» именно благодаря которой можно удобно и практично изучать алгоритмы, развитие железа и рейтрейсинг (тебя маркетологи покусали? ахах, это вещи которым 100 лет уже)
На OpenGL вообще зацикливатся не надо. Текстуры, буферы, шейдеры в удобных обёртках под себя и вуаля рисуй что хочешь и как хочешь. Весь OpenGL знать не надо. Надо только то чем ты будешь пользоваться, а это чаще всего лишь десяток функций и десяток констант и всё.
Ты как то завуалировано предлагаешь ему использовать готовые движки.
LINUX-ORG-RU ★★★★★
( 10.12.19 20:39:23 MSK )
Ответ на: комментарий от snake266 10.12.19 20:38:49 MSK
За вечер такое вряд ли осилишь (или кто-то осилит вообще), но я видел примеры самописных движков у которых получалось.
UPD: Ещё интересно выглядит Lisp в компьютерной графике, за счёт того что можно писать красивые анимации в красивом коде IMHO. Вот примеры 1, 2.
И ещё потому что программа изменяется прямо на ходу без перезапуска.
Поскольку у тебя Haskell и Emacs в подписанных тегах, то тебе это будет весьма занимательно.
Artamudo ★★★★
( 10.12.19 20:42:12 MSK )
Последнее исправление: Artamudo 10.12.19 20:54:04 MSK (всего исправлений: 2)
Ответ на: комментарий от snake266 10.12.19 20:34:02 MSK
Нубские туториалы по графике есть только для опенжоеля/d3d. Но для «Узнать как все это работает под капотом» очевидно курят и вулкан, да и после вкуривания опенжоеля 3+ особого труда не составит.
anonymous
( 10.12.19 20:44:28 MSK )
Ничего адекватного для 3D нет. Для 2D хоть отбавляй.
anonymous
( 10.12.19 20:51:21 MSK )
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 20:39:23 MSK
ро спрайтодвигатель это вообще лол.
man образное выражение
Ты как то завуалировано предлагаешь ему использовать готовые движки.
Я ему завуалировано предлагаю забить на opengl и sdl (что рано или поздно произойдет и так, если он не собирается быть граф программистом), и вместо этого просто посмотреть на перспективы. Скорее всего он просто не знает что делать (исходя из ОП). Втыкание в экран на котором плавает треугольник эту проблему не решит. А интерес, как он написал у него академический. Но т.к. он скорее всего школьник или первокурсник, то я даже ванговать не буду что он сделает в конце концов.
удобно и практично изучать алгоритмы, развитие железа и рейтрейсинг
да, особенно развитие железа : ) но скажем так, пользы их я и нигде не отрицал
BOSS-NIGGER ☆
( 10.12.19 20:59:46 MSK )
Ответ на: комментарий от snake266 10.12.19 20:34:02 MSK
Если первое — твоё железо и дрова его могут и второе — если ты готов смирится что твой код не будет работать на железе 5ти летней давности и свободных дровах. Ну то есть у меня Radeon HD 6850 я катаю в csgo (OpenGL версию нативную) но не смогу даже с проприетарными дровами запустить ничего на Vulkan ибо там сделанно всё что бы сделать железо прошлых поколений просто нерабочим причём намеренно. Но Vulkan позволит тебе то что OpenGL делает за тебя делать руками. Ну например в OpenGL ты говоришь вот тебе массив вершин вот тебе шейдер и вот тебе текстуры -> рисуй. В вулкане ты говоришь вот тебе массив вершин вот блок текстур вот индекс вот устройство вот последовательность рисвоваания вот тебе банк памяти (ещё пяток всего при полном контроле) -> рисуй. Короче то что в OpenGL делает драйвер в вулкане это делается руками. Если у тебя супералгоритм какой то да ты более свободен. Если тебе нужно как и всегда было нужно рисовать по правилам которые ты установил в шейдере и всё и тебя не заботит как будет видеокарта с памятью разруливать траблы то OpenGL.
Это на ютубчике чтоль? =)
Ну на гитхабе у меня пусто считай я по сути сам учился на коде Corange https://github.com/orangeduck/Corange можешь там issue и пул-реквесты глянуть (fedor-elizarov это я там) закрытые я туда пару демок пропихнул в том числе некоторое которое есть на ютубчике. Возьми к примеру демку с чайником, там по сути всё в одном. Даже основной рендер не используется. А в демке parallax типа продвинутые шейдеры и ты можешь с ними играться как угодно (например вот тебе задачка взять эффект из shadertoy и запустить его на corange =))
Клонируй Corange запускай демки и смотри как они работают. Потрать время и разберёшься. А потом либо чисто своё начнёшь либо просто за основу коранж можно взять.
Что бы просто не терятся в терминах и не грузится лишним можно глянуть сюда https://learnopengl.com/ на хабре есть переводы
сюда http://steps3d.narod.ru/articles.html на gamedev.ru статьи посмотреть. Не что бы зазубривать ТООООННЫ иныф нененене. Просто ради интереса и фана поглазеть (даже если нихрена не поймёшь оно уже будет на слуху и не будет пугать)
Не старайся заучивать всё прям изучааать там. Практика и только она и лучший способ это взять готовое и глянуть как оно работает чтобы избежать всяких непоняток.
Лично я OpenGL знаю нуууу 1% где то. Но лично мне этого хватит чтобы отрисовать что угодно как угодно и на чём угодно с расчётами хоть на CPU хоть на GPU. Да и программистом я не являюсь. Чисто любитель.
И да, ещё раз читай всякие статьи. Обычно их пишут в весёлой манере. Но это лично из своего опыта что бы подогревать интерес и не пугаться непонятных слов которые в сути своей являются как оказывается вполне обычными вещами.
Ну, а так. Бури и кодируй. Создал окно. Узнал как получить тектуру, узнал как загрузить буфер вершин, узнал как написать шейдер и потом как запустить всё это вместе и это 99% фундаментального кода которое ты опишешь 1 раз а потом только разве что коректировать будешь.
Короче дерзай. Главное практируй что-бы видеть результаты и радваца что квадратик рисуется, пусть маленький пусть кривой, пусть непонятно чё с ним делать но он твой бляха муха цикатуха! и всё тут. Короче играйся больше с кодом.
LINUX-ORG-RU ★★★★★
( 10.12.19 21:13:54 MSK )
Ответ на: комментарий от Artamudo 10.12.19 20:34:57 MSK
PBR не стоит упоминать на ранних этапах обучения графике. Он реализуется при должных знаниях за 1 день в 1 шейдере. Да и если честно PBR это эмммм. Это тупо хайп. Внезапно появившаяся философия того что надо рисовать как в жизни. Типа тренд. А в сообществе игровых движков сразу типа — «Нет пайплайна для PBR ты лох и твой ивиг тоже лох, фуууу днищеее» и всё такое.
Настоящий PBR в том виде который он должен быть никто включая юнриал, юнити,крайтеки не используют ибо это красивое в теории да на словах. А на деле памяти под это всё надо до жопы поэтопу все делают так что результат как в PBR а на деле подходы разные.
И ваще это больше к созданию контента, всё дело в текстурах, если раньше дифуз + нормаль ну и ещё моожет быть спекуляр и всё то сейчас минимум 6 текстурных карт на объект. Да их упаковывают но всё же.
Хотя просто почитать про это всё интересно. Это да.
LINUX-ORG-RU ★★★★★
( 10.12.19 21:24:04 MSK )
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 21:24:04 MSK
Так для игр его и не стоит применять, это для фильмов, и для 3d анимации. Если ты смотрел Короля Льва 2019 года, то там эта технология реализована. Лучше графики чем в нём, ещё не видел.
Artamudo ★★★★
( 10.12.19 21:28:35 MSK )
Ответ на: комментарий от Artamudo 10.12.19 21:28:35 MSK
Не стоит применять? Это наибольший реальный буст к графонию в игорях, по сравнению ним все остальные графические фичи говно полное, чисто греющее видеокарту впустую.
anonymous
( 10.12.19 21:35:21 MSK )
Ответ на: комментарий от anonymous 10.12.19 21:35:21 MSK
Вот когда твоя видеокарта будет тянуть его в Real-Time, то ради Б-га. А так на современных видеокартах только недавно Ray Tracing начали внедрять.
Artamudo ★★★★
( 10.12.19 21:38:49 MSK )
Ответ на: комментарий от BOSS-NIGGER 10.12.19 20:59:46 MSK
Ну, одну две недельки поковыряется и решит. Да я остаюсь на C+SDL2+OpenGL2/3/4 или Нет мне надо что-то повыше уровнем.
В любом случае зайди на любой форум где люди делают игры и прочее с графикой, очень часто даже используя движки они вынуждены спускаться на уровень чистого OPENGL или узнавать что-то о SDL который как подсистема встроен почти во все AAA даже движки как прослойка. Работает жрать не просит. Вон Gamedev_ru тему начинают как префаб в юнити использовать, а заканчивают какой уровень мипмапа устанавливать для новой текстуры и какую разрядность установить для Depth текструры Gбуфера 😀 Что по итогу к юнити никакого прямого отношения не имеет в плане интерфейсов, но даёт понимание почему жрётся память и то или иное возможно или невозможо. Короче вреда он точно не получит.
LINUX-ORG-RU ★★★★★
( 10.12.19 21:38:50 MSK )
Ответ на: комментарий от Artamudo 10.12.19 21:28:35 MSK
А ну да. Тогда ок.
LINUX-ORG-RU ★★★★★
( 10.12.19 21:40:13 MSK )
Ответ на: комментарий от anonymous 10.12.19 21:35:21 MSK
Я тебе открою тайну PBR использовали ещё до появления термина как такового. Сразу же как только позволила видеопамять. Ещё во времена первых крузисов =) Просто тогда это не выделяли в нечто отдельное и применялось только к оружке и подобному что в глаза тыкается =)
LINUX-ORG-RU ★★★★★
( 10.12.19 21:43:11 MSK )
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 21:38:50 MSK
Нашёл твой канал но YouTube и весьма заинтересовался EGNAROC. На гите у тебя репозитория не нашёл.
Artamudo ★★★★
( 10.12.19 22:17:07 MSK )
Ответ на: комментарий от Meyer 10.12.19 20:04:05 MSK
Ууууу, да нифига подобного. Посмотри любой доклад по геймдеву начинают за блюпринты и мышевозие заканчивают про ручной заход солнца с побитовыми манипуляциями памяти и бенчмарками фандаментальных вызовов графических API с сотней нюансов и хаков =) шобы пропихнуть графон в лимит филрейта видюхи. И по итогу для общих случаев да выбирают готовые обёртки, а для 90% всего остального выбор либо топать в библиотеку ассетов где всё додумали заместо тебя и выложить доллары денег либо опускаться в фундаментальщину и писать всё самим что чаще всего и делают. И тут внезапно надо уметь знать как оно там работает в реальности. Потому что в ряде случаев надо под свои потребности сам SDL править =) Да и часто если выбирают для графона C++ то пишут по итогу всё равно на С потому что плюшки плюшками, а кадр 16 мс и выкручивайся как хочешь. А сейчас ваще по хорошему над на кадр 7мс надо ибо у людей герцовка и они требуют, я уж молчу про экшоны где на кадр в идеале хотят ~3-5мс а в игре 10 подсистем и на каждую бюджет уже наносекунд по итогу. И сидишь такой. Смотришь на все эти менстрим технологии десктопо строения и плакаешь от зависти — как же они счастливы можно целую секунду думать после нажатия кнопки в интерфейсе! 😀
LINUX-ORG-RU ★★★★★
( 10.12.19 22:32:11 MSK )
Ответ на: комментарий от Artamudo 10.12.19 22:17:07 MSK
EGRAROC это форк CORANGE 😀
Исходников нет, я делаю игру и затачиваю форк специально под игру. Некоторые приколюхи изредка возвращаю обратно в Corange правлю там баги и добавляю демки.
Но у меня подход к движку другой Сorange идеальный для старта затачивания под себя. Будет время предложу динамические отражения, более продвинутые частицы, анимированные текстуры, воспроизведение видео через собвственный примитивный но быстрый видеокодек, реализацию gui контейнеров для мышевозного создания ui элементов и так далее включая компиляцию в 1 файл вместе со всеми зависимостями и ресурсами игровыми. Всё это и ещё некоторое есть но находится в ужасном состоянии. Выкладывать такое стыдно. Доработаю. Доделаю игру. Выпущу в Steam. Отшлифуется предложу Даниэлю свои фичи, может примет что-то. А так у меня нет желания выкладывать EGNAROC в опенсорс во первых кроме меня он нахрен не нужен никому, он по сути полигон где я каждый день ломаю обратную совместимость с самим собой и Corange уж подавно. Я так и оставлю его чисто для себя и своей игры. А 100% рабочие вещи буду портировать обратно в Corange по возможности. Да и вообще я заболел концепцией ECS и тотальной оптимизации всего и вся и тут некоторая архитекрура уже мне не нравки, если решусь то буду делать с нуля микродвиг на тотальном ECS. Тогда просто выкину все наработки EGRAROC и забуду про него. Но пока здравый смысл меня останавливает.
Короче, всё что ты видел на ютубчике можно сделать на Corange, параллакс я уже добавил, работу с физикой тоже, работу с gui тоже,для всего этого есть демки там, в issue есть код для реализации SSLR. Ну, а остальное lua скриптинг к примеру у меня есть но на зачаточном уровне. Всё это валом на одного меня откровенного быдлокодера тяжело. Да и делается всё не по приколу а чисто для игры. Хотя… почему не по приколу, по приколу конечно =) Но сутьв том что я всеми силами стараюсь делать именно игру, а не бесконечно пилить ещё один двиг
Ахаха. Ты даже подписался =) Мама я ютуер ТЫШЬ табуреткой по голове мааааааам не бей меня мааааааам ))))))))
Через месяц пресс релиз моей игры…. Будешь ржать если увидишь ахаха. И я настолько наглый что выйду с ней в ситим Габеееен пасиба за билетики в библиотетики =)
LINUX-ORG-RU ★★★★★
( 10.12.19 22:51:04 MSK )
Последнее исправление: LINUX-ORG-RU 10.12.19 22:59:58 MSK (всего исправлений: 2)
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 22:51:04 MSK
Ахаха. Ты даже подписался =) Мама я ютуер ТЫШЬ табуреткой по голове мааааааам не бей меня мааааааам ))))))))
Через месяц пресс релиз моей игры…. Будешь ржать если увидишь ахаха. И я настолько наглый что выйду с ней в ситим Габеееен пасиба за билетики в библиотетики =)
Разве кроме демок ещё что-то есть?
Artamudo ★★★★
( 10.12.19 23:07:10 MSK )
Ответ на: комментарий от Artamudo 10.12.19 23:07:10 MSK
Пока нету. Да я так полушутя в целом. Есть куча наработок, которые начал, но не доделал. Короче ладно фиг со всем этим.
Основная суть в том что Corange топ если хочется С/SDL/OGL то рекомендую. Благо он устроен так что можно удобно выкидывать ненужное и добавлять своё.
А видосы это просто помойка когда надо скинуть что-то разок показать не более.
LINUX-ORG-RU ★★★★★
( 10.12.19 23:15:49 MSK )
Ответ на: комментарий от snake266 10.12.19 20:34:02 MSK
К слову на этом форуме касательно этой темы лучше не на меня внимание обращать, а на EXL eagleivg i-rinat и подобных и не стесняться их кастовать по вопросам 😀 Они в отличии от меня реальные вещи делали, а не полувымышленые
LINUX-ORG-RU ★★★★★
( 10.12.19 23:38:06 MSK )
Последнее исправление: LINUX-ORG-RU 10.12.19 23:38:58 MSK (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU 10.12.19 23:38:06 MSK
Ну, не знаю почему, но ваши сообщения, в интересных для меня тредах, я видел чаще, поэтому я точно знал, что вы знаете что к чему. Ну и как-то неловко людей кастовать для такого нубского треда.