20,741
edits
Property Tree/Native Protocol Slaving: Difference between revisions
Jump to navigation
Jump to search
Property Tree/Native Protocol Slaving (view source)
Revision as of 21:10, 26 March 2013
, 26 March 2013→Syncing multiple instances
No edit summary |
|||
| Line 61: | Line 61: | ||
Windows doesn't have a real concept of "pipes" in it's underlying kernel, especially "real time" pipes which can't be faked with a temporary file, so shared memory is another solution for getting two applications to talk to each other. I'm sure that's where the "sharemem.dll" comes into play. | Windows doesn't have a real concept of "pipes" in it's underlying kernel, especially "real time" pipes which can't be faked with a temporary file, so shared memory is another solution for getting two applications to talk to each other. I'm sure that's where the "sharemem.dll" comes into play. | ||
Also it should be noted that if you can run your monitors/projectors at 60hz refresh rate, and then sync FG to the vertical refresh signal, and if your hardware is fast enough to sustain at least 60hz, then you can have extremely smooth displays. If you are able to send the NetFDM packets at exactly 60hz to all your display channels, you can have remarkably good syncronization between channels, and very smooth animation over all. But the key is to have *everything* running at a solid consistant frame rate. If you can't do 60hz, we have a mechanism to artificially throttle the frame rate to something lower, like 30hz or 20hz. Sometimes a slower consistant frame rate produces much smoother results than a faster, but varying frame rate. | |||
if you're really seeking for a 'clean' solution there are more topics to add. For instance you have to synchronize the yoke positions because you are likely to have a setup where the co-pilot's yoke is visible in the right-window view. Neither protocol will handle this. You might see AI aircraft taking off at the local airfield, an aircraft carrier or whatever else which lack synchronization as well, no matter which protocol you use. | |||
Distributing the AI stuff over the general/official MultiPlayer server might not be such a nice thing to do, so it might make more sense so | |||
synchronize the slave views locally. This still lacks synchronization of AI objects but at least you don't annoy other people which are using | |||
the MP server. | |||
Having the MP protocol extended to handle the needs of local synchronization might be the solution of choice, because apparently it puts less load onto the master machine than the 'native' protocol and it is platform independent - and while everybody is waiting for a chance to implement new features inside the MP protocol, 'they' might add a viewer-only mode as well | |||
In my application with one cockpit computer and 3 out-the-window computers, I already am using the FGNetFDM and FGNetCtrls structures to pass data between these 4 machines. Flight dynamics, cockpit controls, control surface animations, etc. are already synced. That is taken care of. | |||
Now I want to fly this system of computers in the multiplayer world. An invisible player option (view only) for each of my visual channels would | |||
be a quick and dirty solution to my problem. I realize it wouldn't be perfect and there could be synchronization issues with the MP aircraft | |||
locations when passing between displays, but I can live with that for now. | |||
AI aircraft is an entirely different issue. I just turn all that off on this system because precisely as you point out, the AI stuff operates | |||
independently in each display and that is not helpful. There are a lot of things we could discuss with AI aircraft, but I don't want to | |||
distract everyone from my main request, a viewer only mode for the Multiplayer system. | |||
<pre> | <pre> | ||