So if i post a 1000 messages in one update all of them will be dispatch?
Ok so when i post a new message in on_message, it start message chain. But if i post 2 new messages in on_message. Is that 2 messages one dispatch or two dispatches?
Example:
step1:i have a queue with 4 messages.
step2: engine empty queue ( 1 dispatch pass)
step3:last message(number 4) generate to new messages
step4:engine empty queue or engine send one message? (1 dispatch pass)
Interesting question.
I believe it is more about how much time has been spent on dispatching (pre and post update) but not sure.
In the game we’re working on now nr of dispatch rounds has been crucial to us as we want to do some actions in the end of post update when ALL messages has been sent. (We are creating a state, serverside that we want to send to clients and that state must be sent last when all updates and transformations are done)
This can be done in several ways of course but what we’ve found is that even if our design is heavily based on messaging (instead of direct lua function calls) it’s extremely rare that you will wind up with more than 4-5 dispatch rounds post update.
This is of course a subject of your code. Why don’t you create a few tests where two scripts are bouncing a single message back and forth (with some counter).
Also do that test with several messages and see the different results?
The limits we’ve set are such that it should be a very rare thing if not all messages are dispatched during the frame in which they were posted. If you find that messages get delayed then I’d argue that you need to rethink your design.
Made me curious so I whipped up a test to see how many dispatch rounds are allowed. I’m not sure if it’s hardware/platform dependent but on OSX the cap seems to be 180 rounds for a full update loop.
It isn’t impacted by the amount of messages within one dispatch round. (so if you post 3 messages back and forth between 2 scripts you will be able to send 560 messages with a render update).
Still this is not the full truth because it seems like its capped due to where in the update loop.
You will be able to handle 10 rounds post update function ( messages posted on_input ), 160 at update() and 10 rounds at system.
This is just observations when monkeypatching the msg.post and checking counters at update(), on_input() and render.update() that could be totally wrong and it would be cool to hear anyone from the engine team verify this?
It should be noted that message passing is not intended to be used as a straight replacement for member function calls. A message is much more expensive than a function call (msg data is serialized) so if you post thousands of messages each frame you will kill performance. So use messages for high level communication between objects. If you run into problems with the number of messages the engine can handle you definitely need to rethink your design.
Hmm. But there’s not an alternative to message passing for communicating between objects is there? So are things like go.get(), go.set(), or go.set_position() less expensive then?
Well actually there is. You can use a Lua module that acts like a typical listener interface or publish-subscribe pattern and let two or more game objects share information/notify each other via function calls. This approach can sometimes be useful, but usually message passing works equally well.
I was thinking something like this. First the listener module:
--- listener.lua
local M = {}
local listeners = {}
function M.register(event, fn)
listeners[event] = listeners[event] or {}
listeners[event][fn] = true
end
function M.unregister(event, fn)
listeners[event][fn] = nil
end
function M.trigger(event, ...)
for fn,_ in pairs(listeners[event] or {}) do
fn(...)
end
end
return M
Then someone listening:
-- robot.script
local listener = require "listener"
local function on_move_to(x, y)
-- start moving towards x,y
end
function init(self)
listener.register("move_to", on_move_to)
end
function final(self)
listener.unregister(on_move_to)
end
And finally something triggering the listener:
-- game.script
local listener = require "listener"
function on_input(self, action_id, action)
if action_id == hash("touch") and action.released then
listener.trigger("move_to", action.x, action.y)
end
end
Awesome, thanks! I pretty much got there myself after Sicher’s hint. I’m not sure how relevant of a test it is, but I put some different things in for loops and checked socket.gettime() between each and this is what I got:
The empty message (no data table, just url and message id) is mostly faster because it’s not initializing a table. It didn’t make any time difference if the function called through the module (which is in a different script) was sent arguments or not.
