requests regarding aircraft LOS, attack

[mecha]

Even if it wasn't "too hard" to do, then the bottom line is that we are simply making one of the most time-consuming tasks around even more time-consuming. Horrendously counter-intuitive.

as far as the processor goes, calculating an spherical LOS has only thrown in one more multiplication (if it is done in the way outlined by one of the previous posts). If a cylindrical (finite height) LOS is used then the existing LOS algorithm regarding obstacles that aircraft use could still be used.

this process may be timeconsuming but I can still run a game smoothly with well over a 100 aircraft on patrol in normal spring (on a computer 4 yrs old at 1024x768) so I don't think that this process is that time intensive.

The whole idea behind this is to do it simply.

ie in pseudocode
if (object within LOS radius) //ie is in the cylinder of LOS that is currently used
{
if(abs(object.height - aircraft.height)<heightofLOS)
{
object is seen
}
else
{
object is not seen
}
}

I have no clue how this is actually done in the source since I am unfamiliar with C++ but come end of exams I'll look into it

[Gnomre]

The point is, though, that the formula for a cylinder is much more complex than a sphere, so it takes more computational time and power. This wouldn't matter on a small scale, but with planes (which already lag the game in large amounts), it would be really bad.

The ellipse example in the previous page might work well, since ellipses don't really take *that* much more power to calculate than spheres (as far as I know). I can't really say that 100% certainly. One definite advantage spheres have over anything else is that the radius of a sphere is exactly the same anywhere in it, so it's very easy to use that in a stored variable, instead of needing to calculate distances constantly.

[Dragon45]

Once again, what you say may be true for one unit or a few units, but the system must be scaled to hundreds, possibly even thousands, of units.
Take the following scenario: lets say that we were adding a single addition operation or worse yet, a multiplication operation, or possibly the worst of all, a division operation.

Take that single operation, and multiply it by two hundred units. Multiply that by ten players, and multiply that by *each tick*. If you really do want to go through with that, go for it, but be sure to do a before-after and note the slowdown.

I'm not saying that doing this would make the game unplayable, but I personally don't think that it would be the wisest thing to do at this point.

[mecha]

Sorry to catch you on that one dragon. The worst operation of all is the square root which is generally computed on computer using a taylors approximation. even a simple 2nd order approximation involves 2 divides, an addition and a multiplication. This estimate can be improved by iterating this a couple of times

Heres a simple algorithm:
http://www.dontletgo.com/planets/math.html

I know this since I recently had the rare pleasure of having to do this on an 8bit microcontroller that didn't support floating point ops.

Reiterating: I don't think that an extra multiplication (for an elliptic LOS) will make that much difference even across a thousand units. especially if a square root is being computed for every radar 'tick' already

You also have to remember that the LOS radius does not have to be accurate to n decimal places. so the multiplication may be as small as say 30*30, I know that 32 bit processors may require 32 shift and add numbers however most computer ALUs these days have 'speed up' blocks which check if the rest of the register is clear. greatly speeding up the operation (this is courtesy of a pipelining lecture last year).

I think that even the current LOS algorithm would have problems if we ramped up the scale of games to thousands of units.

[SJ]

The los system isnt working at anything near the premises you think it do so that sort of stuff wouldnt work ...

[mecha]

All theory and academic debate aside, I think it would be a pretty cool feature if it could be implemented though

[IMSabbel]

Mecha, that may be true for embeded stuff, but modern CPUs have fully, totally pipeplined execution units.

Multiplies are 1 clock instructions with an effective latency of 1-4 cycles only. Given the fact that the OO instruction resheduling window is >40 instructions on all modern CPUs, it even allows hiding the additional multiply in the last squareroot (which takes about 40 clocks, iirc, on a k8).

The contents of the target values of an instruction _only_ matters if you are using stuff that is determined by series (i.e. fsin/fcos, ect), even there the difference between worst and best case is only 50-75% (although a double precission Fsin can take >150 clocks...)

Also, all this talk about counting muls to determine the runtime doesnt sit well with reality: code and data locality is so much more important. A single l2 cache miss when checking los would cause a loss of 80-100 cycles even on a k8 (>150 cycles on a p4 even with a good memory subsystem).

So i think that maybe spring would need some serious profiling to check where the time is really spend. I once found _surprising_ stuff when messing aronud with amd code analyzer (stuff like finding out that an check in a look that was supposed to improve runtime by bypassing a calculation when a criteria was not met slower it by a factor of 2 because of cache trashing, for example...)

[mecha]

He he,.. caught out myself, lol, I'll go back to my embedded stuff