Game Development Community

Negating a Behaviors impact.

by rennie moffat · in Torque Game Builder · 07/25/2010 (2:04 pm) · 6 replies

hi, I am trying to optimize my games performance. As a newb, I did not realize that the computer, apparently runs all scripts, at least all behaviors at all times, so if a behavior is not in use, it still runs it, thus causing drag. If this is true, I thought of two things that could eliminate a behavior being used unnecessarily and would like some input as to if this is possible (and or even necessary as I am not 100% sure if this theory is true).




a. obviously use scripts, but I am very comfortable with behaviors and would like to keep them.

b. is there a way to create a game script, something that is called right away that says, essentially, unless a behavior is being used in a currently open level, that is can not be called?

c. does using onLevelLoaded in a behavior over onBehaviorAdd() have any effect?

d. I have changed many of my onUpdate calls to schedules, so instead of demanding a call every 33ms, I have set the calls to vary between 300 and 1000ms. I thought this would have a greater impact than it has.


Cheers.








About the author

My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.


#1
07/25/2010 (4:48 pm)
The TGB engine doesn't run all behaviors at all times. It only runs behaviors that are attached to objects in your scene. If you have a behavior that isn't attached, the code just sits there doing nothing.

Also, just for your information, the onUpdate calls are called every 32ms.

Finally, from your point of view, there is no difference between onLevelLoaded and onBehaviorAdd. They both get called at the beginning before your scene starts playing.

P.S. I don't know if you can call yourself a newb anymore. Newbs are people who are new to the engine, not people who have used it for over a year. You should upgrade to novice.
#2
07/25/2010 (5:24 pm)
Sweet, William, I appreciate that vote of confidence I think. In the term newb I was more referring to programming and how all scripts are compiled, learning the intricacies of how the engine works. Its one thing to know how to drive, it is another to know how to fix the engine.

Anyhow, my problem exists with in iTGB, I posted here as I thought more knowledgeable hands would be available.. like yourself. Anyhow, is it safe to assume iTGB is the same, in that it will only run a behavior that is in use, in scene?



#3
07/26/2010 (3:32 am)
While I've never used iTGB, I feel that I can say with 99.9% confidence that behaviors will only run if they are attached to an object in the scene.

Think of it this way: your behaviors get assigned the "owner" variable after they are attached to an object. If the behavior was running when it wasn't used in the scene, who would the "owner" be?
#4
07/26/2010 (3:35 am)
Cool, thanks William.






#5
07/26/2010 (1:32 pm)
Rennie's back for some more science!

How about a sneak preview Ren? It's usually a good idea to get it out there before release day to generate some buzz. I'd be lying if I said I wasn't curious about what you've been working on!
#6
07/26/2010 (3:10 pm)
Thanks Patrick.

Well I have developed the game, and have loaded it onto the iPhone. However, it is sooooo freaking slow. I had a bunch of onupdates that were perhaps hindering it's performance, so I eliminated them for schedules, thinking that would help quite a bit. It has helped but not enough. It is driving me craazzzy.



Anyhow, I have been receiving help from quite a few people at the iTGB. One has even worked with my code to streamline and had suggested a few ideas, tho he was the one that mentioned behaviors are always running, even if not loaded on a level. so... anyhow I am currently trying to think of ways to enhance my performance.



What I have done.
a. $timeAdvance
b. removed 98% of all onUpdates replacing them with 200-1000ms schedule calls
c. lowered image memory from 5MB to 300kb
d. changed all images to POT, but no sourceRect.


That is pretty much it. I don't get it, I have seen games on the iDevices do wayy more stuff then what I am doing. My game is fairly simple, tho right now, not running smoothly. Currently frustrated, but optimistic.