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
Maybe not to the same extent, but I'm in AS year after all, and come from an engineering background...
.
Edited by the Author.
