Заметки на полях: 002, текстуры и stb
Кратенько, что бы не забыть.
В рамках ковыряния всё того же опенГл воткнулся в занятную проблему с загрузкой текстур, ну и записываю её на будущее, что б не забыть, как она решается-то.
(под катом неинтересно и путано, я вас предупредил)
Долго ли коротко, для загрузки текстур их нужно как-то прочитать из файла, ну и превратить в массив последовательных байтиков. Можно написать обработчик самому, но зачем, если всё уже придумано за нас, разобраны все особенности форматов, набиты шишки и всё это собрано в удобные библиотеки в паблик домейне.
В моём случае это хедер_онли(ю донт вона ноу) библиотека stb_image, и, как выяснилось, у её взаимодействия с опенДжиЭль есть НЬЮАНСЫ. Ну по крайней мере один, который мне стоил пары вечеров.
лонг стори шорт: библиотека неверно определяет количество каналов для неквадратных картинок(точнее со стороной кратной степени двойки; то есть в теории может быть и 1024х512, важно что б делилось на 4), и для произвольного размера картинки возращает всё равно 4 канала(Красный, Зелёный, Синий и Прозрачность), даже если у исходной картинки никакой прозрачности не было. И, в результате, мы получаем вот такую красивую картину:
Как можно видеть, картинка с полупрозрачностью, на переднем плане, показывается как надо, тогда как фон явно «сдвинут».
в виде схемы это выглядит вот так:
Оно, очевидно, сдвинуто, как раз потому что опенГл ожидает четыре значения и повтор, ну а получает три и повтор.
В общем решения два:
- делаем все загружаемые текстуры кратные степени двойке, тогда выравнивание по 4 работает и для трёх каналов без проблем; Используем в таком случае GL_RGB
- загружаем все картинки в четыре канала, даже если никакой прозрачности у них нет; в таком случае можно загружать картинки любого соотношения сторон и размера без головной боли про выравнивание байтов. Минусы очевидны, 25% прибавка футпринта в памяти на «пустой» канал. Ну и в этом случае это GL_RGBA, очевидно.
Продолжаю наблюдение.