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 did have a have a look in the forums and also found a few articles on 360 directional movement but it was mainly to do with firing bullets etc.
Is anyone familiar with the 'angle calculator' and 'advanced direction object' extensions? BTW, 360 degrees is fine, in fact I have now worked out the exact angles I will be using (all integers).
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
In a game being displayed on a monitor there is no such thing as true infinite angles, have a look at the table, i have proved this to be correct, see how often it moves a by pixel on either axis.
ahh, on a computer, sorry I thought you meant in every-day advanced maths :3
"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
So you're trying to disprove it by throwing a trig table at us? Anyone can tell you that the more you multiply by, the greater the integer precision. If you multiplied by 300000, you're going to get visible changes in the coordinates.
Apart from the fact that it's wrong (the theoretical X should be 300 when the angle is 0 and no more) you're missing the point in that stuff still moves over a period of time and needs the precision if it is to be accurate. If you convert a velocity vector to cartesian coordinates and then round the i/j values to integers, you will not end up with the same direction or magnitude you started off with. If you multiply the original vector and the rounded vector by an arbitrary high number, they are NOT going to be the same. This difference is accentuated when you use a small magnitude, for obvious reasons.
I mean, just look at games that use 32 directions for shooting and compare them to those that use trig, and you'll find that the latter hits the target wherever you place the target. There's no point denying it, it's there as clear as day.
Like you Hagar, I'm capable of exactly the same Maybe not to the same extent, but I'm in AS year after all, and come from an engineering background...
The table is correct as i do not start at 0 for some reason .
Yes it does need accuracy, but what that i think that table proves is that putting angles into a engine greater than 3dp is pointless (in that aiming reticule example), as the monitor simply cannot display to that accuracy level and all the possible directions.
Sure if you write 3d engines which are vector based and terefore can run on any resolution then sure use that accuracy (heh in 3d 32 bit numbers give rise to gaps in the wall joins as the precision is'nt high enough - playstation 1).
And im fully aware of the old 8 direction movement custom movement, of course you need to 'slow' the one axis down, or your player will move at double speed on diagnols (been there done that ), but his displacement or velocity in a certain direction will remain the same.
You are capable of far more on the software front so i'm gonna stop arguing .
Edited by the Author.
n/a
Pete Nattress Cheesy Bits img src/uploads/sccheesegif
Registered 23/09/2002
Points 4811
26th November, 2004 at 09:50:23 -
can't you guys argue about something more interesting? like kittens or something.
Ok, well I think I've sussed out the 'advanced direction object' extension for MMF but I'm not sure how to stop it when it completely overlaps another object (detector). At the moment the object looks in the direction of the detector and then travels toward it. When the object has more of less the same co-ordinates of the detector it will then shimmer over the top of it as it doesn't land exactly. It repeatedly tries to look in the direction of the detector object.
I just wish to add that I am in favour of kittens.
Anyway, if you only want to aim at a distance of 300 pixels then obviously decimal accuracy won't make much noticeable distance. The point is that, in general, it is much better to allow decimal accuracy. This is especially true in movement engines. Try and make any engine that requires low speeds and you'll see how useful it is to use decimals. Once you start adding them together 50 times a second they quickly add up to whole pixels that can make an important difference.
EDIT: If you have sufficient accuracy, you should only need to point it in the right direction once (i.e., when you tell it to move), rather than telling it to always point towards the detector. Then just test if it's within a certain area around the detector object to tell when it has arrived (X > X("Detector")-10, X < X("Detector")+10 etc.), or just use the "Overlapping another object" condition.
you can have as many angles as are provided by the precision of decimals in MMF -Me, earlier.
Stop nit picking at the details and just get the gist of it!
Decimal angles is the same code as 360 directions, so you may as well throw in the extra precision!
Advertisement
Post Reply
.
.
Edited by the Author.
.
.
