So I've about hundred of map tiles and each title has some object which does some stuff. And one of things it should do is to update text (a time after which you need to do something) in text field. How should i do it better - with enter frame开发者_C百科 event and on each enter frame update it or set up a timer object which on each second would update the text in text field? I wonder more from performance view which would be better.
You should use frame events any time you want to do processing that ultimately affects what shows up on the screen. If you're moving images around, or resizing visual contents, or doing programmatic animations, or anything of that nature, you should use frame events. The reasoning why can get fairly involved, but at the simplest level it boils down to this: if you do that kind of processing more than once between screen updates, you're wasting performance for no reason, and if you do it less often you get choppy visuals. Using a Timer to do things at the same speed as the frame rate might seem like an alternative, but you'll spend a certain amount of time out of sync. That is, even if your content is 25FPS and you run a timer with a delay of 40ms, because of small fluctuations in timing, sometimes that timer event will fire twice between redraws, and sometimes it will get skipped. That might be worth it if there was some huge inherent advantage to using Timer, but there isn't.
On the other hand, any time you want to do something that happens a lot less often than screen updates, Timer is a good option. It's clearer to make a timer event that fires in 5 seconds than it is to make a frame listener that counts up to 200. (But be wary of mixing frame events and timers together - see here.)
Finally a word about performance: it doesn't make any difference which you use. Or rather, whatever difference there is will be tiny compared to rendering, and what you do inside the frame or timer events. What can make a slight difference is minimizing the overhead - if you do a lot of different things every frame, use a single event listener, and have it call all the functions that need to fire, rather than using lots of listeners. And the same thing goes for Timers. But even this, realistically is unlikely to dent your performance unless you're running many hundreds of listeners. You should always start out whatever way is simplest, and worry about performance later if testing shows you have a bottleneck.
A Timer object would probably listen to the ENTER_FRAME event anyway for basing its calculations. Since it is a new object it would also use up a bit of memory and possibly more depending on the inner workings. This would only really be a problem if you were creating a lot of instances of the Timer class.
Assuming this is some dynamic world you are creating, you most likely already have a main game loop that is called on an ENTER_FRAME event. It is in here you would loop through all your tiles and update the text accordingly. You might need to store some timestamps or something if you need to record how long a tile has done something.. hard to say really without more of a description of what is happening :)
I disagree with fenomas. There are a lot of reason why you could want to update your code more often than fps. However there are a lot of different methods to do this. The easiest one is to use the ENTER_FRAME event as the main function for your updates and inside that function evaluate the time that has passed. You can then either run your updates several times or use the time as a value you pass to your objects for them to update accordingly. That way your gameplay stays smooth even if fps drop and you won't have troubles later on.
Also, while i agree you should avoid premature optimization, a good code right from the start is better than having to rework half your game engine while the game was near completion.
精彩评论