Path: chuka.playstation.co.uk!news
From: Majik <majik@127.0.0.1>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Rotation, ApplyMatrix Query (fairly long)
Date: Wed, 25 Feb 1998 10:17:06 +0000
Organization: Sinclair MicroComputer Museum
Lines: 99
Message-ID: <34F3EFA2.4CD2@127.0.0.1>
Reply-To: majik@127.0.0.1
NNTP-Posting-Host: 194.202.250.27
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (WinNT; I)

Hi,
	While working on the Drone Tank routine for Combat3D I've noticed a
quirk, which may well be my sloppy code, but it looks like
a strangeness in RotMatrix, anyway take a butchers:

some variables:
	long dx, dz, tx, tz, mx, mz, td, td2, td3;
	short angle;
	MATRIX ltw;
	GsCOORDINATE2 dir;
	SVECTOR rot, hpl;
	VECTOR hpw;

where is the opponents tank?
	tx = BTanks[op].coord2->coord.t[0];
	tz = BTanks[op].coord2->coord.t[2];

make a local copy of our tanks GsCOORDINATE2 struct
	dir = *(BTanks[me].coord2);

this bit seems to be needed to set which direction the tank is facing
I would have thought it would get it from the copy just done.
	setVector(&rot, 0, tank->angle, 0);
	RotMatrix(&rot, &(dir.coord));

Get the local to world transform matrix
	GsGetLw(&dir, &ltw);
we consider an imaginary point in front of the tank
	setVector(&hpl, 0, 0, TANK_BOUNDC << 4);
	ApplyMatrix(&ltw, &hpl, &hpw);
					// consider a point at the
					// front of the tank
	mx = dir.coord.t[0] + hpw.vx;
	mz = dir.coord.t[2] + hpw.vz;
this is the postition of the point, after rotation.

get a rough estimate of the distance
	dx = tx - mx;
	dz = tz - mz;
	td = abs(dx) + abs(dz);		// find the right angled distance

decide whether we should turn clockwise, or anti-clockwise
	angle = (tx < mx) ? -32 : 32;	// which way to turn (if facing northish)

if we're facing south, then we need to turn the opposite way
	if(tank->angle > 1024 && tank->angle < 3072)
		angle = tank->angle - angle;
	else
		angle += tank->angle;

	angle &= 4095;

try out this new angle
	setVector(&rot, 0, angle, 0);
	RotMatrix(&rot, &(dir.coord));

	GsGetLw(&dir, &ltw);
	ApplyMatrix(&ltw, &hpl, &hpw);

	mx = dir.coord.t[0] + hpw.vx;
	mz = dir.coord.t[2] + hpw.vz;	// same point in
					// front of the tank
get a rough estimate of the distance using this new rotated point
	dx = tx - mx;
	dz = tz - mz;
	td2 = abs(dx) + abs(dz);	// find the distance

Now the algorythm works by seeing if this new rotation makes the drone
closer
to the opponent, so you're wondering whats the problem...

If the angle is close to a right angle, 0, 1024, 2048, 3072... then the
results from
the ApplyMatrix seem inconsistent, take for example 3072, this gives an
x/z vector
of -75,0 say, the program decides to move -32, 3040, it tries this and
gets an x/z vector
of -75,0 the same. it then takes this turn (I have it hard coded to
always turn atm) and next
time round we get 3040 as the input angle, which this time gives it an
x/z vector of -75,-8
different!, it then tries to turn +32, back to 3072, and this time it
gives it an x/z vector
of -75,-8... guess what happens next time round the loop*

Now I know that the maths may still be a little screwy behind this
method
(it may be complete rubbish !) but it's still an interesting quirk?

Or have I missed something?

Majik.

*answers on a postcard, sent to the waste paper bin :)
--
-- Majik - Owner/Curator of the Sinclair Microcomputer Museum
-- 	Spod in a suitcase - ' Have Compiler, will travel '
-- 		http://mudhole.spodnet.uk.com/~majik/
--