Вращение текстуры.

[impersonalis]

Неоптимизированный (сами ставьте сдвиг вместо умножения, используйте свою подсистему перевода и проч.: конкретика ваша, да и оптимизация может затруднить понимание сути) аналог функции RotateTexture2 для Blitz3D (см.)
Т.к. Xors3D имеет другую ориентацию осей текстурных координат (нежели блитц), то преобразования будут иными (другие знаки при sin/cos).

void RotateTexture2(int Texture, double Angle){
    const double RA2GR=180/M_PI;
    double PosX=0.5-0.5*cos(Angle)+0.5*sin(Angle);
    double PosY=0.5-0.5*sin(Angle)-0.5*cos(Angle);

    xRotateTexture(Texture, Angle*RA2GR);
    xPositionTexture(Texture, PosX,PosY );
}

Значение аргумента Angle задаётся в радианах.
Функция позволяет вращать текстуру не за "вершину", а вокруг "центра".

Формулы выведены с нуля, хотя, не трудно было бы заметить, что разница сводится к смене знака координат
xPositionTexture(Texture, PosX,PosY );//стало
и
PositionTexture Tex,-u,-v;//было

Поучить аналог RotateTexture3 из данного кода можно очевидным образом.

[dsd]

А так не адекватней?

void RotateTexture2(int Texture, double Angle){

    const double GR2RA=Angle*M_PI*0,0055555555555556;
    double PosX=0.5-0.5*cos(GR2RA)+0.5*sin(GR2RA);
    double PosY=0.5-0.5*sin(GR2RA)-0.5*cos(GR2RA);

    xRotateTexture(Texture, Angle);
    xPositionTexture(Texture, PosX,PosY );
}

А то просто все функции хорса воспринимают угол в градусах, а тут надо в радианах задавать.

[impersonalis]

Я уже написал причины:
у меня, например, сложная система вычислений, оперирующая радианами (что вполне логично), "человеческая" визуализация - лишь небольшая часть программы (и, вообще говоря, подстраиваться надо под общепонятный стандарт [например, СИ], конвертируя значения по необходимости - об этом я упомянул в первом посте). Таким образом, это (вариант dsd), безусловно, может быть целесообразно для каких-то случаев (в частности, если эта функция многократно используется, "становясь дополнением" Xors3D - здесь единый интерфейс [градусы] просто необходим).
0,0055555555555556 совсем не очевидно 1/180, тем паче, что это оптимизирует (посчитает значения констант) любой компилятор (*транслятор), важнее тогда заменить *0.5, на битовый сдвиг и считать 0.5*cos, 0.5*sin отдельно, но читабельность понизится: а я хотел именно показать алгоритм (да - вероятно стоило писать псевдокодом).

P.S.: А по мне 0.25 всё равно удобней, чем 25%.

Спасибо за отзыв!