Move along...

[vexed]

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.

Yeah... this is what I was thinking by doing AABB.

[Per]

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.

Yeah... this is what I was thinking by doing AABB.

It is certainly an interesting idea. It occurs to me though that it might only addresses the less interesting half of the problem. The example I gave of a map reveal making 200 units being seen at once is incredibly rare. What is not rare, though, are attacks of huge groups of units, where only some of them are revealed in each logical frame. Let's say you attack with 40 units, and 2 are revealed each frame. Just a bounding box for those two units in the seen callback not going to give you a lot of useful information about that attack. What we might need in addition is a list of already seen units in that bounding box, I suppose.

[NoQ]

I'm keeping thinking about it, but the only thing i figured out so far is that we're right now discussing a premature optimization.

I am not yet using eventObjectSeen in the AIs. Instead, all versions of NullBot are deity-cheating (always looping through all objects rather than visible objects, equivalent to always seeing everything). I'm not yet having a specific algorithm in mind to make it non-deity-cheating, even though it's a good thing to do. Once i come up with something, we would have a rough idea on how to improve performance. But right now we don't have a single use case for eventObjectSeen in AIs.

In fact, eventObjectSeen is less frequent than eventAttacked (until you build a satlink, and it might be the last time you trigger the event). I believe that probably having it completely unthrottled would not hurt perfromance. A list-based approach would be a good optimization for satlink case, if it is found to be a problem (needs testing).

Now, for campaign. In fact, for campaign, a completely different approach seems useful: the script subscribes to seeing a certain pre-defined set of objects (a label or a group, that is, ids of these objects are already known), and then receives a one-shot event when at least one of these objects is seen. This is rather close to how eventAreaLABEL works. We may think of eventSeenLABEL, where LABEL may be object, group, or maybe even terrain position or area. Or, alternatively, subscribe dynamically:

Code: Select all

function callback() { console("Enemy base detected!"); }
//...
subscribeForEventSeen(label, "callback");
subscribeForEventSeen(group, "callback");

[Per]

How about something like this? See attached patch (it only compiles, haven't actually tested it).

It checks for 'triggered' as a key in labels other than positions. If it is non-zero, then it is deactivated. If it is zero, then it is active. A positive number records which unit did trigger it, but this is not exposed to scripts yet, and I'm not sure if it is useful for anything.

If an active group or object is seen, and viewer is owned by script 'me' or isReceivingAllEvents, then fire off either an eventObjectSeen(viewer, seen) or an eventGroupSeen(viewer, groupid). Then the triggered key is deactivated.

Not sure if the "viewer is owned by script 'me'" part makes any sense.

It would be trivial to add a way for scripts to (re)activate such labels or create new ones.

[MaNGusT]

I don't really want to offtop, but you should exclude lags of graphics engine 1st ,imho. I-NoD's branch is improved by bucket renderer that allows you to render as many tris as your gpu could(in theory),afair. Then you could know the real impact on performance by path-finding and test your fixes. Sorry, if i'm wrong.

[vexed]

I don't really want to offtop, but you should exclude lags of graphics engine 1st ,imho. I-NoD's branch is improved by bucket renderer that allows you to render as many tris as your gpu could(in theory),afair. Then you could know the real impact on performance by path-finding and test your fixes. Sorry, if i'm wrong.

If you are talking about the original pic I posted, that has nothing to do with path finding. That is all a CPU bottleneck.

Which I-Nod branch are you talking about, I don't see anything in the WZ repo ?

[Per]

Are you sure it is a GPU bottleneck? In master?

From what I remember from my own testing, we are currently CPU-bound. Especially if you use shadows.

[MaNGusT]

Which I-Nod branch are you talking about, I don't see anything in the WZ repo ?

Here, some discossions were started here. It was made for the updated WZM format that wasn't introduced into wz for reasons I don't know, but I think you could still use its bucket renderer for some performance tests.

edit:nvm, I've missed that a good job on optimizations was done, with the latest master the gpu-side is no longer a bottleneck of wz's performance.
Per, could precalculated MINMAX_TSCEN values stored in wzm models increase the performance even more? afair, it could, but only for a huge amount of tris on the screen, so it's not that important, we don't have very detailed models anyway.

[vexed]

Are you sure it is a GPU bottleneck? In master?

From what I remember from my own testing, we are currently CPU-bound. Especially if you use shadows.

D'oh, typo. CPU.