All I want to do is after clicking on an object, look in the direction of a target and send it on it's way. The only problem is the angle isn't always quite right (limitations of 32 dir movement). I've tried two MMF object extensions, 'angle calculator' and 'advanced direction object' but there were no examples on how to do this. Apparently 'angle calculator' has a 360 degree look up table.
Search the clickteam upload forum, loads of 360 degree example files there. If you do it right, you can have as many angles as are provided by the precision of decimals in MMF, e.g. 125 degrees, 125.1 degrees, 125.01 degrees, 125.001 degrees etc. would all be (slightly) different directions.
I seem to recall having a long discussion about this some time ago HagarTech. Even though monitors only display whole pixels you can still use decimals to allow greater accuracy. You can essentially have an infinite number of directions, if you need them.
The key to doing what you want is to know the coordinates of the object and its target, and then use trig to work out the direction angle required. You can either use the Advanced Math object to do this (use the "angle from fixed object to x,y" function), or you can just work it out manually ( something like ATan((y1 - y2)/(x1 - x2))*180/3.141592654 ). Once you've got the angle then a simple engine like Tigerworks' 360 movement tutorial should allow you to move the object with sufficient accuracy.
I know that Arf, but there is no use going to say somehing like 9 dp when the resolution is so relatively low on a monitor anyway.
I severely doubt you would be able to tell the diffrence between 125 and 125.001 or 125.01 degrees for that example (especially at something like 300 pixels or less away) so why waste comuputational power by doing so?.
What im trying to say there is: a infinite amount of directions that can not be displayed on a monitor, so why not have a finite amount, as there is only so many pixels you can move by at a certain distance.
You need to work to the accuracy needed for the distance you are working at eg. A calculation that is 3000 pixels away from the objects position it is relative too needs more accuracy than somehting thats 200 pixels away (you could easily use integers at this range and not tell the slightest difference ).
Ah, well in TGF it's probably not worth the bother. But seeing as it's relatively simple in MMF, I don't see why you would not want to be accurate. Besides, being pixel-perfect like that makes me feel all warm and fuzzy inside in a geeky kind of way.
Decimal accuracy does make a difference. Say you were moving at a rate of 1.1 pixels on the X axis per tick. It would go 1.1, 2.2, 3.3 ... 8.8, 9.9, 11!
So the 10th tick it actually jumped two pixels, not one, making it move at 11pix per 10 ticks. If it was rounded to 1 it would mean 10pix per 10 ticks. Less accurate. Blah.
This object does virtually anything you could want for angles and distances. Get the angle/distance between two points, convert angles into directions, rotate one angle towards another, get the closest/farthest objects, and more.
But then it's bad to move at 22.5 degrees unless you go fast, because the X position will increase by 1 pixel every few frames. Every few frames is not every single frame, so it's unsmooth and by definition a BAD THING. In fact, let's not have 360 movements because they are so unsmooth. Limit yourself to up, down, left and right. Never mind that you will go faster on diagonals, if you made it slower it would be unsmooth, and that's bad.
Hagartech, I kind of implied that in my description by saying "on the 10th tick it would actually jump two pixels", but I guess I didn't make it clear.
MMF actually rounds all decimals down when converting to coordinates, doing the standard int-truncation. That means 3.3 rounds to 3, 5.5 rounds to 5 and 9.9 rounds to 9 - jumping one pixel at a time. Only on the 10th tick will it jump two pixels.
MMF uses decimals like this for the built in movement, if you choose a low speed it will not jump a regular number of pixels every frame - at very slow speeds it might even not move at all on some frames, going 0, 0, 1, 0, 0, 1, for example. It still looks OK.
If you only use integer speeds (1pix/sec, 2pix/sec, 3pix/sec) you'll actually find that quite a limited range of speeds, especially for slow moving things. Most people would agree irregular pixel intervals still look OK, because they follow a pattern, like 2, 1, 2, 1 and are therefore predictable.
Both Tigs And Mr branch have a look at exhibit a, especially the last two columns. This would be the results of creating an aiming reticule with the angle to the precision of 3dp and at a distance of 300 pixels. The x and y positions have been rounded using 'standard int-truncation' just as tigs says mmf will.
Hey Hey What A surprise! is there infinite directions?
Nope, this proves your infinite directions to be a load of manure That's what I'm trying to get across .
Oh and Mr. branch, before you take the piss, at least know what I'm capable of :
Electronics, Digital Electronics, Physics, Engineering (i can lathe, mill etc) C Programming (ANSI C), Maths (not pretend maths, I/J Notation anyone?) the list goes on. I'm also developing an Intel 8088 based micro-controller at an hardware level, try having a go at that. On an IQ test i did very well as well (surprising even to myself )
I have to admit i cant program in C++ you dudes seriously beat me on that front . I don't know, klikkers of today. Next thing your going to tell me is that it is not 1987 and Hawaiian shirts, jeans and addidas trainers are out of fashion .
Manure? What are you talking about? angles can be expressed as -pi to +pi (radians), and since pi has an infinite number of decimal places (so we think), that means there are an infinite number of angles too.
"Say you're hanging from a huge cliff at the top of mt. everest and a guy comes along and says he'll save you, and proceeds to throw religious pamphlets at you while simultaniously giving a sermon." - Dustin G