amue wrote in Tue Jul 06, 2021 9:54 am:(Position) MP packets are already time stamped and old/late packets are filtered albeit late in the pipeline in FGAIMultiplayer::update() after the whole packet has been processed in FGMultiplayMgr::ProcessPosMsg() .
Maybe an earlier filtering can be done in FGMultiplayMgr::ProcessPosMsg() when the timestamp is decoded.
And that was the point, the time stamp present is not readily accessible, which makes the early packet pass/discard decision difficult, and doing it late costs processing for a packet which, as you said, will be later filtered anyway.
Also, the time stamp you mentioned is 'sim time' which, if I understand the idea correctly, is perfect to re-create behaviour of a local representation of a remote player, but it is not the same as network 'time' (packet sequence order) although they are related (but also during replay? i don't know for sure..).
While I have your attention I would like to ask a question which relates to the same source file, but not to the topic. Yet I do not want to spam the board with another topic for a possibly trivial question. So, here goes. We have this original code in ProcessPosMsg:
- Code: Select all
for (unsigned i = 0; i < 3; ++i)
motionInfo.position(i) = XDR_decode_double(PosMsg->position[i]);
SGVec3f angleAxis;
for (unsigned i = 0; i < 3; ++i)
angleAxis(i) = XDR_decode_float(PosMsg->orientation[i]);
motionInfo.orientation = SGQuatf::fromAngleAxis(angleAxis);
for (unsigned i = 0; i < 3; ++i)
motionInfo.linearVel(i) = XDR_decode_float(PosMsg->linearVel[i]);
for (unsigned i = 0; i < 3; ++i)
motionInfo.angularVel(i) = XDR_decode_float(PosMsg->angularVel[i]);
for (unsigned i = 0; i < 3; ++i)
motionInfo.linearAccel(i) = XDR_decode_float(PosMsg->linearAccel[i]);
for (unsigned i = 0; i < 3; ++i)
motionInfo.angularAccel(i) = XDR_decode_float(PosMsg->angularAccel[i]);
If we rearrange the code like that:
- Code: Select all
SGVec3f angleAxis;
#pragma omp parallel for
for (unsigned i = 0; i < 3; ++i) {
motionInfo.position(i) = XDR_decode_double(PosMsg->position[i]);
angleAxis(i) = XDR_decode_float(PosMsg->orientation[i]);
}
motionInfo.orientation = SGQuatf::fromAngleAxis(angleAxis);
#pragma omp parallel for
for (unsigned i = 0; i < 3; ++i) {
motionInfo.linearVel(i) = XDR_decode_float(PosMsg->linearVel[i]);
motionInfo.angularVel(i) = XDR_decode_float(PosMsg->angularVel[i]);
motionInfo.linearAccel(i) = XDR_decode_float(PosMsg->linearAccel[i]);
motionInfo.angularAccel(i) = XDR_decode_float(PosMsg->angularAccel[i]);
}
1. would there be any ill effects, assuming the #pragma omp.. is ignored?
2. would there be any side effects related to thread safety if handling of the 'for' loops was indeed passed to a pool of OMP threads as pragmas direct?