cg_api: implement trap_R_BatchInPVS to test if a bunch of entities are in PVS in one call

[illwieckz]

Implement trap_R_inPVSArray to test array of entities in PVS in one call.

Engine sidecar of:

• cg_players: implement trap_R_BatchInPVS to test if a bunch of entities are in PVS in one call Unvanquished/Unvanquished#2679

[illwieckz]

I rewrote this using lessons learned while implementing:

• cg_api: implement trap_CM_BatchMarkFragments to process all impact marks in one call #1114

The code now sends and receives the shortest vector possible for valid and active entities only.

Commits are meant to be squashed so one would probably better want to review this as a whole.

[slipher]

We should ultimately avoid the IPC entirely by implementing inPVS in the cgame, but this is fine for now.

LGTM to the engine side.

[illwieckz]

Does it makes sense to also do a inPVS.reserve(MAX_LOCATIONS); here as inPVS is an argument?

I tried it, the code builds and run, but I don't know if that changes something.

[slipher]

It doesn't make sense to have both reserve and resize. You can do either reserve+push_back, or resize+a[b]=c.

[illwieckz]

I rewrote that part, in fact I could iterate the source array directly by using push_back for the destination, which looks cleaner.

[illwieckz]

We should ultimately avoid the IPC entirely by implementing inPVS in the cgame, but this is fine for now.

That's exactly my opinion. I would like to see this in cgame to avoid IPC entirely in the future, but this is something I can reach today and the benefit is there, so we can start with that.

[slipher]

LGTM

[illwieckz]

LGTM

Any comment on the game counterpart?

• cg_players: implement trap_R_BatchInPVS to test if a bunch of entities are in PVS in one call Unvanquished/Unvanquished#2679