Месяц назад решил переписать код с использования библиотеки SDL2 на SFML. Меня не устроило отсутствие в SDL2 нативной поддержки текста, а только через сторонний, слабо развиваемый, плагин. Да и сама библиотека SDL2 “ванильная”, а SFML “плюсовая”. Конечно, я придирался, но решение было принято. Поддержка вывода 2D текстовых сообщений в SFML оказаласть действительно гораздо удобнее. Еще в ней очень удобная работа со звуком (хотя и не без шероховатостей).

Но в процессе работы выяснил что, во-первых, SFML очень хорошо заточена под работу в режиме 2D, а трехмерный OpenGL представлен только возможностью создать окно с контентом. В принципе, большего и не надо (говорил я себе), но позже обнаружились еще некоторые особенности. После обновления ядра Arch Linux на рабочей машине обе ветки програмы (разработка и стабильная) стали падать при создании контента в SFML, не помогал даже откат не несколько коммитов назад. В версии для Windows SFML вела себя стабильно до момента обновления библиотеки. Не исключено, что ошибка была в логике моей программы, но нервирует то что баг появился не при разработке кода, когда было понятно что именно изменилось, а после обновления библиотеки - когда проблему уже надо искать по всему коду программы. В общем по моему непросвещенному мнению библиотека ведет себя нестабильно.

Еще один момент хочется отметить - мой модуль управления перемещением камеры в пространстве, который абсолютно одинаково вел себя на разных платформах при использовании библиотеки SDL2, после перехода на SFML стал демонстрировать разницу в чувствительности к настройкам скорости перемещения, между реализациями на Linux и Windows, примерно в двадцать раз. Это свидетельствует о том, что реализация кода для разных платформ недостаточно идентична. Хотя, справедливости ради, надо отметить что причиной такого результата могла стать и разница в производительности видеокарт, так как FPS не учитывался. В общем, после более детального ознакомления с SFML, искать новые “грабли” уже нет хочется. Для меня такая плата за наличие удобной встроенной поддержки текста и звука оказалась неприемлемой.

В целом, выводы следующие - нельзя все “затачивать” под работу с одной большой универсальной библиотекой. Все равно в процессе развития проекта рано или поздно возникнет ситуация, когда какие-то возможности используемой библиотеки начнут ставить барьеры в реализации отдельных компонентов или идей и диктовать свои условия. В этом плане идеальным решением представляется “Философия Linux” - когда каждая задача решается независимым сравнительно маленьким модулем, который делает небольшую работу, но исполняет ее с исключительным качеством. Создание окна с OpenGL контентом и обработки событий - GLFW. Обработка графических файлов - Libpng. Звук - своя подсистема, сеть - аналогично. Тогда в случае необходимости не придется переписывать весь код, как мне пришлось делать, а обойтись только улучшением отдельного модуля. Впрочем, это “прописные истины”.