Asynchronous Simulation: Difference between revisions
| Line 13: | Line 13: | ||
(Preliminary information, not released yet) | (Preliminary information, not released yet) | ||
Rendering in a gadget can negatively affect the performance, although the performance penalty is | Rendering in a gadget can negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget, using SendToUnsynced(), whenever needed. | ||
Revision as of 18:40, 20 July 2011
Spring Multithreaded Lua Compatibility
In order to make your Lua code compatible with the multithreaded engine, you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in.
All versions
Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between any rendering call-ins. This means it is not recommended to store lists of e.g. units in global variables, and if you still want to do that, each one must be re-checked for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.
0.82.X
Unfortunately, Spring MT has very limited Lua rendering support in this engine version. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.
There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.
0.83.X
(Preliminary information, not released yet)
Rendering in a gadget can negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget, using SendToUnsynced(), whenever needed.