Перед нами в Kuflex стоит задача построения универсального набора модулей, которые бы позволяли, как из конструктора, собирать интерактивные приложения, работающие с камерами глубины, OSC, и при необходимости, OpenGL.
Здесь я опишу соображения о том, что для этого будет удобно использовать динамические библиотеки (DLL).

Необходимость создания подобного набора модулей связана с тем, что многие наши проекты, фактически, построены на одних и тех же технологиях (камера-обработка-сеть-экран), но код не расчленен на независимые модули, которые можно было бы использовать снова и снова. Мы уже предприняли ряд шагов, и вынесли основные модули в виде аддонов openFrameworks на github (ofxKuTextGui, ofxKuNetwork, ofxKu, ofxKuBox2d).

В то же время, мой опыт использования аддонов показал, что это не всегда удобно:
* аддоны, написанные для одной версии oF, не всегда работают в другой
* аддоны, использующие внешние библиотеки, могут требовать достаточно долгого подключения в новый или уже существующий проект (для версий oF менее 0.9.3)
* аддоны предназначены для разработки oF-приложений, хотя бывают ситуации, когда требуется использовать аддон для консольного приложения (анализ данных с вебкамеры) или для написания плагина к Unreal Engine.

Другой альтернативой является программирование модулей с помощью нодов (Max/MSP, PureData, TouchDesigner). Я понял, что идеология нодов, на данном этапе, имеет следующие недостатки для нашего случая:
* нас интересуют достаточно крупные программные модули, такие, как работа с камерой глубины или отправка данных по сети. Такие модули, чаще всего, работают с комплексными данными (растры, облака точек), и множеством параметров. В то же время идеология нодовых систем предполагает, что связи между нодами атомарны – то есть одна связь передает скаляр, вектор или матрицу (либо звуковой сигнал). Из-за этого сложные ноды обрастают связями, даже если требуется связь всего лишь двух нодов.
* нодовая система, сама по себе, не позволяет использовать модули без хостинга нодов. А нам бы это хотелось.

Поэтому, было решено сделать модульную систему, основанную не на аддонах, а на DLL (Windows). У меня уже был опыт создания плагинов на основе DLL, а также, опыт создания DLL из oF-приложения, в котором подключены нужные аддоны.

В данном проекте, я предлагаю следующий подход создания модулей:
* создается DLL или EXE файл с опубликованными функциями (EXE предпочтительнее, так как его можно использовать для тестового запуска модуля)
* создается один H-файл, содержащий необходимые функции для работы с DLL и необходимые объявления структур.
* таким образом, для использования модуля нужно скопировать его исполняемый файл (DLL или EXE) в корневой каталог проекта, и подключить в проект H-файл, и вызывать его функции.

Преимущества подхода с DLL:
* очень простое подключение в C++-проект.
* гибкость использования – их можно использовать как в oF, так и любых других средах. В будущем, можно создать нодовый хостинг для них.

Недостатки подхода DLL
* возможно, затрудненный процесс контроля ошибок на уровне пользователя
* пока не реализована кросс-платформенность
* требуется отдельная сборка 32 и 64 версий
* более сложный процесс разработки и отладки

В то же время, этот подход “развяжет руки” для разработки и адаптации самых разнообразных модулей, сделанных как на основе oF, так и прямо из сторонних библиотек. Данные модули могут использоваться/создаваться широкими кругами программистов, в том числе студентов.

Advertisements