Asynchronous Simulation - Revision history

Abma at 21:09, 25 October 2013

2013-10-25T21:09:26Z

← Older revision		Revision as of 22:09, 25 October 2013
Line 55:		Line 55:
	:'''3. Batching glitches''', applies to threading models 2 - 4		:'''3. Batching glitches''', applies to threading models 2 - 4
	::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue.		::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue.

	~~[[Category:Lua]]~~

Abma: Protected "Asynchronous Simulation" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

2013-10-25T21:09:10Z

Protected "Asynchronous Simulation" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

← Older revision	Revision as of 22:09, 25 October 2013
(No difference)

Abma at 21:08, 25 October 2013

2013-10-25T21:08:58Z

← Older revision		Revision as of 22:08, 25 October 2013
Line 1:		Line 1:
			{{deprecated}}

	== Asynchronous Simulation ==		== Asynchronous Simulation ==
	Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.		Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Zerver: /* Common side effects */

2013-03-22T23:18:08Z

Common side effects

← Older revision		Revision as of 00:18, 23 March 2013
Line 52:		Line 52:

	:'''3. Batching glitches''', applies to threading models 2 - 4		:'''3. Batching glitches''', applies to threading models 2 - 4
	::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue~~. Batch management is expensive, making it very difficult to solve this problem engine side~~.		::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue.

	[[Category:Lua]]		[[Category:Lua]]

Zerver: /* Lua Threading Models */

2013-03-22T23:15:49Z

Lua Threading Models

← Older revision		Revision as of 00:15, 23 March 2013
Line 10:		Line 10:

	== Lua Threading Models==		== Lua Threading Models==
	These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ASIM compatible, and will have ~~the~~ <code>~~simulation thread~~ enabled by default.</code>		These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ASIM compatible, and will have <code>ASIM enabled by default.</code>

	:'''<code>0</code>. No MT, single threaded'''		:'''<code>0</code>. No MT, single threaded'''

Zerver: /* Lua Threading Models */

2013-03-22T23:14:35Z

Lua Threading Models

← Older revision		Revision as of 00:14, 23 March 2013
Line 10:		Line 10:

	== Lua Threading Models==		== Lua Threading Models==
	These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ~~asynchronous simulation (~~ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>		These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ASIM compatible, and will have the <code>simulation thread enabled by default.</code>

	:'''<code>0</code>. No MT, single threaded'''		:'''<code>0</code>. No MT, single threaded'''

Zerver: /* Steps required to support ASIM in your game */

2013-03-22T23:08:54Z

Steps required to support ASIM in your game

← Older revision		Revision as of 00:08, 23 March 2013
Line 4:		Line 4:
	Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.		Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

	== Steps required to support ASIM ~~in your game~~ ==		== Steps required to support ASIM ==
	:'''1.''' Choose a Lua Threading Model > 2 below		:'''1.''' Choose a Lua Threading Model > 2 below
	:'''2.''' Rewrite ~~your lua~~ code to conform with the rules imposed by that threading model		:'''2.''' Rewrite the Lua code to conform with the rules imposed by that threading model
	:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it		:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

Zerver: /* Lua Threading Models */

2013-03-22T23:06:49Z

Lua Threading Models

← Older revision		Revision as of 00:06, 23 March 2013
Line 23:		Line 23:
	::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.		::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
	::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.		::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
	::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what ~~features (~~call-ins) the game ~~implements,~~ and ~~what~~ widgets ~~the user has activated~~. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.		::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what call-ins the game and any user-enabled widgets implement. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

	:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''		:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''

Zerver: /* Lua Threading Models */

2013-03-22T23:03:22Z

Lua Threading Models

← Older revision		Revision as of 00:03, 23 March 2013
Line 10:		Line 10:

	== Lua Threading Models==		== Lua Threading Models==
	These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>		These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system\|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

	:'''<code>0</code>. No MT, single threaded'''		:'''<code>0</code>. No MT, single threaded'''

Zerver: /* Asynchronous Simulation */

2013-03-22T23:02:02Z

Asynchronous Simulation

← Older revision		Revision as of 00:02, 23 March 2013
Line 2:		Line 2:
	Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.		Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

	Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to ~~numerous~~ Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.		Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

	== Steps required to support ASIM in your game ==		== Steps required to support ASIM in your game ==