Bassman's terminology may not be 100% correct and there may be some confusion in the wording of his message, but there is nothing wrong with the foundation of his statement.
A locked VSync renderer has less CPU work to do than a non locked VSync renderer, this could potentially lead to less cycles available for AI, (depending on the engine), even if it is multi-threaded and/or multi-core. The logic is simple, if you are traversing a scene graph, culling, clipping and presenting draw calls, (this is all basic CPU rendering work), at 60FPS; it's obviously less CPU work for a given time interval, compared to doing the same thing at 100FPS.
With all that said, I would be terribly surprised if ED's AI thread was coupled to it's rendering thread; typically AI and physics are run on separate threads at semi-deterministic intervals, (e.g. 100Hz), whilst the rendering thread runs at a completely different frequency, (depending on factors such as VSync, GPU speed, game's chosen graphic settings, etc).
This is an interesting thread and nothing is black and white in complex multi-threaded and multi-core games, as I said I would be surprised if the AI and physics of ED was coupled in anyway to it's rendering, but I would also not rule out complex interactions due to issues such as:
- Not 100% decoupling of AI and rendering.
- A bug in the AI that makes it seem it is VSync dependent.
- The almost infinite variability in user's hardware and software configurations.
It's extremely difficult to test situations like this, unless the behaviour discrepancies become obvious, (such as the AI not firing, or coming to a dead stop, etc), and is subject to personal interpretation; with that said I would still ticket it so that someone at FD at least knows there is a potential issue.
