Согласно комментарию Кристофера:
У меня нет опыта работы с Ogre3D, но может быть так, что он на самом деле дает вам данные изображения в виде RGBA (или BGRA, или ARGB) вместо просто RGB. Таким образом, вы пропускаете дополнительные pDest++
(или, может быть, *pDest++ = 255
), и, следовательно, в первом взаимодействии цикла вы получаете синий, зеленый, красный, а затем синий, ..., который как-то совпадет с вашим изображением.
РЕДАКТИРОВАТЬ: В своем комментарии вы говорите (если я правильно понял), что вы получаете совершенно красное изображение, когда добавляете в цикл дополнительные ++pDest
. По крайней мере, это говорит нам о том, что вы действительно получаете 4-компонентное изображение от Ogre3D, поскольку мы больше не синхронизированы с цветами и имеем только один цвет. Но так как этот цвет красный, кажется, Ogre3D предоставляет вам данные изображения в виде BGRA. Так что просто установите первый компонент на 255 вместо третьего (и, конечно, оставьте там этот дополнительный ++pDest
).
Возможно, вы указали текстуру как PF_R8G8B8
, но, похоже, у Ogre3D есть некоторая свобода в отношении размещения данных изображения в буфере, и на самом деле графический драйвер также имеет некоторую свободу относительно расположения в памяти текстур и часто 32-битное изображение RGBA или BGRA имеет некоторые преимущества по сравнению с 24-битным RGB.
Это также может зависеть от того, какой базовый графический API (D3D или GL) используется Ogre3D и какой там стандарт. Например, в GL вы не можете напрямую отображать текстурную память и для этого нужно использовать PBO, чья компоновка памяти, в свою очередь, может быть выбрана отличной от текстуры. Я не знаю о D3D, но я думаю, что D3D особенно нравится макет BGRA.
РЕДАКТИРОВАТЬ: Вы также можете проверить pixelBox.format
, чтобы увидеть, какой формат имеют данные.