Are behaviors bad?
by baylor wetzel · in iTorque 2D · 07/19/2009 (8:21 pm) · 9 replies
One of my screens had two dozenish buttons, all using the button behavior. When i do a trace(true) in the console, the console is instantly flooded with ButtonBehavior::onUpdate() calls. My assumption (based on zero proof) is that onUpdate calls are expensive, even if the callback method is empty (since my buttons should only respond to mouseOver and mouseClick). i love behaviors but i can certainly go back to doing normal Button::onMouseDown() callbacks. It would make traces a lot easier to read but would that approach be faster?
About the author
#2
But usage of onUpdate is bad, as well as adding a mass of behaviors like you would do it in regular TGB.
I would restrict myself to 1 behavior per object that handles all the stuff.
07/20/2009 (2:53 am)
behaviors themself aren't bad.But usage of onUpdate is bad, as well as adding a mass of behaviors like you would do it in regular TGB.
I would restrict myself to 1 behavior per object that handles all the stuff.
#3
I thought I'd done this pretty well, but still ended up with a <5fps performance. Is there any place where there's a more in-depth overview of what the expensive parts of the behaviors are? Obviously onUpdate() is a killer, but none of my behaviors do that. My basic gameplay scene looks like this:
1 background 480x320
7 animated sprites (64x64 or 128x128) - each share a single behavior
6 static sprites (64x64) - each share a single behavior
I've been surprised that the performance hasn't been better. Any "gotchas" here that might be causing a massive slowdown? My background is in C++, so I've been toying with the idea of going to components, but I haven't really found a nice, definitive reference for that yet either. Is that going to be a better route in the end?
</hijack>
08/01/2009 (10:02 pm)
<hijack>I thought I'd done this pretty well, but still ended up with a <5fps performance. Is there any place where there's a more in-depth overview of what the expensive parts of the behaviors are? Obviously onUpdate() is a killer, but none of my behaviors do that. My basic gameplay scene looks like this:
1 background 480x320
7 animated sprites (64x64 or 128x128) - each share a single behavior
6 static sprites (64x64) - each share a single behavior
I've been surprised that the performance hasn't been better. Any "gotchas" here that might be causing a massive slowdown? My background is in C++, so I've been toying with the idea of going to components, but I haven't really found a nice, definitive reference for that yet either. Is that going to be a better route in the end?
</hijack>
#4
The behavior shooter and behavior shooter component projects should give you a good idea how to approach it.
08/01/2009 (10:04 pm)
Highly recommend to go to components, assuming that your component uses heavy math or lot of data to work with.The behavior shooter and behavior shooter component projects should give you a good idea how to approach it.
#5
08/02/2009 (4:04 am)
Best use here is the same as always: If your behavior does something on every update, make a component for it. Otherwise, doing the action in a behavior is fine. The 'best' scenario is a combination of behaviors and components, as that gives you maximum flexibility and best performance.
#6
Mark and Dave, by components do you mean behaviors?
The point was made (maybe) that you should use behaviors if there's a lot of math, but i don't think there's a relationship between math and components. If you have math, you use C++ rather than script, not components vs. events
The original post had to do with the fact that behaviors *ALWAYS* make a call to onUpdate, even when you don't want them to. It makes the call even when you don't have *have* an onUpdate method to call (maybe it's calling a base one?). That strikes me as expensive and wasteful, although i haven't fully thought it out (the alternative for the button behavior is polling the mouse location to see if it's location is over the button)
08/02/2009 (3:18 pm)
To all the people saying components are better - what is that based on? At first glance, with no testing, it appears that components are much, much worseMark and Dave, by components do you mean behaviors?
The point was made (maybe) that you should use behaviors if there's a lot of math, but i don't think there's a relationship between math and components. If you have math, you use C++ rather than script, not components vs. events
The original post had to do with the fact that behaviors *ALWAYS* make a call to onUpdate, even when you don't want them to. It makes the call even when you don't have *have* an onUpdate method to call (maybe it's calling a base one?). That strikes me as expensive and wasteful, although i haven't fully thought it out (the alternative for the button behavior is polling the mouse location to see if it's location is over the button)
#7
Components are the C++ counterpart to Behaviors and allow you to implement the math and data heavy parts on the C++ end while using it painlessly on your script behavior.
08/02/2009 (3:49 pm)
By Components we mean Components.Components are the C++ counterpart to Behaviors and allow you to implement the math and data heavy parts on the C++ end while using it painlessly on your script behavior.
#8
Are Torque components described anywhere in the docs? i don't remember seeing them and it sounds like something i should learn
Components, i take it, are a Torque thing, not the generic OO meaning (in design by composition/aggregation) or software meaning. Are they used like behaviors? Are they just behaviors implemented in C++?
08/02/2009 (3:58 pm)
Must be the thread hijack then because my original post was on behaviors :)Are Torque components described anywhere in the docs? i don't remember seeing them and it sounds like something i should learn
Components, i take it, are a Torque thing, not the generic OO meaning (in design by composition/aggregation) or software meaning. Are they used like behaviors? Are they just behaviors implemented in C++?
#9
And yes they are like a C++ backend for behaviors
And no its no hijack, because if you are using Behaviors and want to have running code, you commonly also will need to use Components.
08/02/2009 (4:04 pm)
I think they are described, but easiest way to learn more about them is checking out the BehaviorShooter Components project and the related folder within the sources and comparing the project to the regular behaviorshooter projectAnd yes they are like a C++ backend for behaviors
And no its no hijack, because if you are using Behaviors and want to have running code, you commonly also will need to use Components.
Associate Kyle Carter