elapsed field on enterFrame event tables

Solar2D Daily Builds and Public Releases
#1

I am very much more concerned in my projects with the passage of time than with the current clock. Presently, this obliges me to track the last time my listeners were triggered externally, and calculate the difference to subtract it from another persistent value that indicates how much more time I have to wait. (Storing next-fire times instead of remaining waits is awkward as well.)

It would save me a lot of time to receive the time elapsed since the last enterFrame dispatch as an additional field on the event table. Alternatively, an API to get the current frame rate might suffice. I can also implement this function myself given two things I am not currently certain of; that listeners are fired in the order they were added, and that the table passed to listeners as the event argument is reused. In that case I could save [lua]local tPrime = system.getTimer()
Runtime:addEventListener(‘enterFrame’,
function(event)
event.elapsed, tPrime = event.time - tPrime, event.time
end
)[/lua] to something like “enterFrame.elapsed.lua” and preface my main.lua file with “require ‘enterFrame.elapsed’”.

If those conditions are guaranteed (calling order of listeners and reuse of event tables), then this request drops in priority significantly. [import]uid: 12678 topic_id: 5024 reply_id: 305024[/import]

#2

Well the second question is easy to answer. Yes, it’s the same table each time, not like a new copy of the table is initialized each time. Try running this code:

local table = {}  
table.count = 0  
function table:enterFrame(event)  
 self.count = self.count + 1  
 print(self.count)  
end  
Runtime:addEventListener("enterFrame", table)

Notice how the count is an attribute of the table? Thus for the count to increase it must be the same table each time.

–

As for your first question, I’m not sure what order listeners fire in and this may have mattered recently for me. What I ended up doing is removing the enterFrame listener from all but one object and having that one object call the update() method in the other objects in order to control what order they were updating. This fix works fine but now that you bring it up I wonder if changing the order of addEventListener calls would have made a difference. oh well *shrug* [import]uid: 12108 topic_id: 5024 reply_id: 16442[/import]

#3

I have, as you point out, confirmed the second point. The first point did work for my initial test, but I don’t know if this is a reliable behavior or not. [import]uid: 12678 topic_id: 5024 reply_id: 16444[/import]