- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
void TexQ::Move()
{
mx = quad.v[0].x;
my = quad.v[0].y;
if(hge->Input_GetKeyState(HGEK_RBUTTON) || hge->Input_KeyDown(HGEK_LBUTTON))
{
hge->Input_GetMousePos(&nx, &ny);
move = true;
sx = GetPositionX();
sy = GetPositionY();
subx = nx - sx;
suby = ny - sy;
if ( abs(subx) > abs(suby) )
{
iter = abs(subx);
ms = subx;
subx = (subx < 0) ? -1.0f : 1.0f;
suby = (suby < 0 ) ? suby/abs(ms) : abs(suby/ms);
}
else
{
iter = abs(suby);
ms = suby;
suby = (suby < 0) ? -1.0f : 1.0f;
subx = (subx < 0 ) ? subx/abs(ms) : abs(subx/ms);
}
}
if (move)
{
if (iter >= shift)
{
iter-=shift;
this->SetPosition(
GetPositionX() + subx * shift,
GetPositionY() + suby * shift);
}
else
{
this->SetPosition(nx , ny);
move = false;
}
}
}
Хреновый из меня математик. Этот метод втыкается в функцию фрейминга. И текстура едет по прямой туда, куда мышью тыкнешь.
Позже узнал, как можно тригонометрией в 5 строк написать такую же )
Follow us!
Насколько я понял, задача состала в том, чтобы сдивнуть текстуру в направлении мыши на расстояние 'shift'. То что вы сделали - шаг в правильном направлении, но очень криво реализованный.
Говнокодом тут попахивает из-за того, что не видно не одного объявления переменной. У вас что, все эти переменные являются членами класса что-ли?
Во-первых, тут нет никакого вычисления скорости (в явном виде). Вся идея тут заключается именно в том, чтобы избежать выделения "скорости", как отдельной сущности. В выражении вида 'dy * shift / adx' первым выполняется именно умножение, что избегает явного вычисления скорости и позволяет нам решить задачу не притягивая сюда за уши плавающие вычисления.
Во-вторых, кто вам сказал, что скорость постоянна? А именно, кто сказал, что значение 'shift' не меняется от тика к тику? Даже если оно и не меняется в данной конкретной задаче , все равно в ситцуации, когда нет ущерба эффективности, более общее решение всегда неизмеримо лучше более частного. (Как я уже говорил выше, вычислительной код должен быть отделен от GUI-шного и ничего не должен знать о GUI-специфичной конкретике).
Даже если скорость постоянна, попытки вычислить ее заранее в виде явной сущности будет ярко выраженной тупейшей говнооптимизацией.
Вы не гейм разработчик:-)
>вычислительная геометрия жопа
>Отсюда и ноги растут...
Разумеется, во избежание говногокдовости надо бы отделить GUI-шные вызовы от чистой математики, т.е. вынести вычисления новых координат в отдельную функцию.
И не знаю как у вас а у нас для этого либы есть...
Задача, решаемая вы кординатах пространства отображения (например, в координатах курсора мыши, как у вас) - это всегда задача уровня GUI.
вот решение с тригонометрией
оно намного короче моего говна, от чего я и начал этот пост )
У автора жопа вместо головы.
есть текстура, ее координаты и положение определяются 4мя парами координат (углы четырехугольника)
0 ------------- 1
|(пробелы)|
3 ------------- 2
Допустим я тыкаю мышью в произвольное место в экране и текстура смотрит в эту точку. ее лицо - это сторона 1-2.
PS. По сути Гуя поддерживает поворот, но не текстур а спрайтов и тем более на определенное количество радиан, которое тоже надо считать ( решение на том же сайте). в данном случае мне спрайт не нужен.