Move along...

[vexed]

Upon reading a post.... I decided to do some tests. (Let's see who will count up all the units there...)

lots1.jpg (81.71 KiB) Viewed 9894 times

Yeah, as I thought.
Slide show time!
Ack, this is too slow....
Come on, move! move!
I said MOVE!
I can't take it anymore...

notsomuch.jpg (90.33 KiB) Viewed 9894 times

All is well again!

[vexed]

Anyway, this is still basically the same Warzone engine as Pumpkin released it.
Sure, some things have changed since then, but, the bottom line is, the engine, as it stands now, can't handle anymore units than it could back then, ever since it was released.

Yes, we have 10p games ability, but, unless the host and most everyone else playing have a very good machine with a fast CPU, it becomes a lag-a-thon, with people seeing the "Zzz" trying to sync up to the slowest player. It isn't uncommon to have games run under 10 fps. That isn't fun.

The engine itself just isn't capable of displaying tons of units.
There are little to no optimizations done, and it shows.

While things are slowly changing, people should always keep in mind this is a very old engine!

[Terminator]

Is it possible that all this slows causing only path-finding ? and all load only on CPU, GPU usually idle or 10-15% max. I remember some guy a half a year back wanted to improve path-finding ...may be hire some freelancers from donation fond if there anything left at all, if only I'm right out path-finding.

[NoQ]

clustAddDroid() is at 25% in perf-top with ~400 droids (which means that ~25% of CPU instructions are executed directly inside this function, neither in its backtrace nor in sub-functions), above everything else (second place NEXTOBJ::operator DROID*<DROID>() const with 6%).

On 3.1, pie_Draw3DShape2() eats twice as much as clustAddDroid(), which indicates that graphics engine updates in master were actually quite effective.

P.S. This O(n) loop through all droids inside clustAddDroid() looks suspicious ... hmm, aint it recursive as well? No, i guess not too much recursive, just O(n). Probably resulting in O(n^2) time per frame.

P.P.S. Not sure, but the way NullBot does cluster analysis (re-clustering all objects on timer ticks) might actually be more effective

P.P.P.S. What does cluster.cpp do, anyway, apart from calling WZScript Seen and Attacked events and JavaScript Seen events? If nothing, then maybe just remove the whole system? We would soon hopefully scrap WZScript, and JavaScript's eventObjectSeen is not useful anyway (too throttled, and throttling can be done equally well without clustering).

P.P.P.P.S. Removing the inner loop in clustAddDroid() allows me to run smoothly at ~20fps at 400 own droids on screen (on master). Normally, the loop causes periodic lags (~2 seconds smooth, then lag for a little while, then again smooth).

[Goth Zagog-Thou]

What got changed, exactly? I'm a little confused. The color of the units?

Never mind, I see it now. Heh.

[vexed]

For the path finding, we don't compute the path for every unit you have in a frame.
We only do X units, then next frame X more, and so on.

For the other stuff... unsure, would have to re-read the code.

[Ezio]

For the path finding, we don't compute the path for every unit you have in a frame.
We only do X units, then next frame X more, and so on.

For the other stuff... unsure, would have to re-read the code.

we currently use A* right?, i personally think FlowField was best.
i tried to make one but implementation requires high amount of system resource and it requires a "battle formation" which wz does not have.

[vexed]

Yes, A*.
The main problem isn't the search per se, that is fairly standard.
It is the other stuff.

While flowfield is an option, that won't solve everything wrong with the 'pathing' routines.

[Iluvalar]

We use A* over map passabilty. (accounting walls but not units). A little tweak could account for terrain movement speed without too much cost. I already tried that.

Also mentionned previously that adding a function that increase the resistance of the tile which are encumbered on the left side. Would most likely dramaticaly reduce the traffic jams in chokepoint. But nobody listen to me anyway...

[vexed]

Hmm, nobody listens to whiners ? Imagine that.
You also got a knack for stating the obvious.

Anyway, NoQ, looking at an analysis, I get:

Code: Select all

clustAddDroid
PointTree::queryMaybeFilter<0>(class PointTree::Filter &,int,int,int,int)
avUpdateTiles(void)
drawTerrain(void)
pie_RotateProject(struct Vector3i const *,struct Vector2i *)
pie_ActivateShader(int,struct iIMDShape *,union PIELIGHT,union PIELIGHT)
_alldiv
pie_Draw3DShape2
SyncDebugIntList::set(unsigned int &,char const *,char const *,int const *,unsigned int)
gridStartIterateFiltered<ConditionTrue>
pie_RemainingPasses(void)
_allmul
glm::rotate<float>(struct glm::detail::tmat4x4<float> const &,float const &,struct glm::detail::tvec3<float> const &)
pie_TRANSLATE(int,int,int)

Looking at clustAddDroid() seems to me that this whole system needs to be rewritten.
Right now, thinking of something along the lines of using AABB to fix this mess.
That will get us out of the WZ brute force approach. (Could also use the same to fix the rendering pipeline... )

[NoQ]

...
pie_Draw3DShape2
...

That's on 3.1, right? I'm not having this anywhere near the top on -master.

Looking at clustAddDroid() seems to me that this whole system needs to be rewritten.
Right now, thinking of something along the lines of using AABB to fix this mess.

The system is only useful for wzscript, right? I'm still not sure it's worth fixing rather than removing.

[vexed]

No, this was master.
Why, what does your findings show ?

As for the cluster system itself, I didn't look at what exactly uses it, I just looked at the brute force approach that pumpkin did.

[vexed]

The system is only useful for wzscript, right? I'm still not sure it's worth fixing rather than removing.

No, if you look a bit closer, you would see that both systems use (need) it.
eventFireCallbackTrigger(...); is indeed for wzscript
triggerEvent____(...); is for qjscript

So, for example, eventFireCallbackTrigger((TRIGGER_TYPE)CALL_DROID_SEEN);
we have triggerEventSeen(psViewer, psObj);

[NoQ]

JavaScript's eventObjectSeen is not useful anyway (too throttled, and throttling can be done equally well without clustering).

I believe that cluster-based eventObjectSeen is not useful anyway. In fact, i cannot comprehend what's good about clusters for eventObjectSeen; there are easier and lighter ways of making it worse.

p.s.: whoops, forgot to post my perf-top, maybe tomorrow.

[Per]

So how would we like eventObjectSeen() to work?

Let's say we have two hundred unseen enemy units, and suddenly the map is revealed. Should the scripting engine fire off 200x eventObjectSeen() at once?

One solution is simply to queue them up, and rate limit how many we fire each script frame. (We always have 10 script frames each second.) Say we only fire off max 20 eventObjectSeen() each script frame. That means you could be handling the reveal of some of them a second after the fact. But that should be okay, I think.

I suppose another option is to queue up all revealed units until the end of the frame, and then fire off a single eventObjectSeen() with a list of revealed units.