Quote:
Originally Posted by neznein9
Learn tweens first.
Printable View
Quote:
Originally Posted by neznein9
Learn tweens first.
huh? composition is not very complicated, is it?
edit: tweens: i read something about them, but honestly, is it a good idea to use them? they seem very short term problem solvers, or am i wrong? i don't think i will be able to use them very flexibly.
this is getting oftopic: compositions do not really have to do much with performance, neither really have tweens impact. Either you use them or you dont,- its fare more a design decission. This discussion feels abit like elementary school of flash.
On a sidenote but back onTopic: scripted tweens however can differ a hell lot performance wise if you dont stick to the bloated default classes but instead eiter code your own using getTimer or pick one of dozen available tween classes.
In most projects I usually code all tweens myself as it reduces the code and increases the performance for what I need it for.
ok
back on topic: how much ram does an object use? does the amount of methods increase this? or only the amound of fields?
An object uses exactly a megabyte of ram, plus 472k for each field.
seriously though.
what i meant was really: what detirmines the amount a of memory an object takes?
it really doesnt matter ,- what matters however is the amount of video or image ram that is used- so better watch out for them and like mentioned earlier ditch components as they can eat up to be loaded memory as well.
In as3 you can diplay the used ram
but again it does not have much to do with performance but rather stuff like garbage collection, preloading and dymainc asset loading.PHP Code:var mem:String = Number( System.totalMemory / 1024 / 1024 ).toFixed( 2 ) + 'Mb';
trace( mem ); // eg traces "24.94Mb"
And as for classes or functions,- just code smart and you wont have to worry that much for performance or bloated bytes. Only very complex projects really require thoughts on that matter.
when you have an if else statement, and in a particular case the else statement is executed, how much will the code placed after the if statement affect performance? because the processor has to go through it until it finds the else statement, right?
PHP Code:if (true)
{
//1000 lines of code
//how much will these lines of code slow down the execution?
}
else
{
doWhatever();
}
The length / contents of the first if don't make any difference, as in byte-code it'll just branch to the else check ( Like it would in any language ).
Your only speed lose is if the first conditional is false more often than it's true, that's why you should order conditionals in the order in which they're more likely to be called, although in the grand scheme of things it's not even worth worrying about.
Squize.
but branching to the next else statment takes a little bit of time, doesnt it? because he has to move thourgh the bytecode checking if he's reached else yet, right?
ps.
is there a big perfrmance difference between:
andQuote:
if (myObject is myClass){}
and then define varClassname in MyClass as " MyClass"Quote:
if (myObject.varClassname = "MyClass")
Im pretty sure the compiled code stores that info in tables, so it's not "searching" for the next 'else'. It just jumps to the next else in the if code table
"because he has to move thourgh the bytecode checking if he's reached else yet, right?"
No, the byte-code adds a branch when it's created, eg
conditional check
branch if it's not equal label_a
//...
label_a
//....
As to the new question about classes, I don't know off the top of my head, or care to be honest.
It's such a moot point that adds so little at all to the run time of a game that even at my most anal when we were doing all this with F5/6 did anyone care about that even then.
Sorry, but it's a question of priorities. If you've got a for example a brute force collision system in place then that alone will negate any short hand speed ups to the actual code, as I'm sure has already been said in this thread before.
Squize.
well the point is i have to do those if statements about 2500 times every 25 millisecs or so, and then alot more. so i'd figure it would probably have it's effect.
but ok i'll just focus on other stuff.
Could I ask why ? That seems really intensive, like a path finder or a 3D engine type intensive.
Squize.
AI every object has to check other objects. but i'll make it more effective, so that they only check nearby objects for danger etc, but right now it has to check allot.
Oh I see.
Like I said a couple of posts ago, avoid brute force methods as they take so much cpu time, and you seem to be aware of it so all good.
You should find that once you've nailed the main routines and got them running quickly that it won't even be worth your while to worry about the smaller things.
Squize.
yeah.
i just got another problem.
i have a function that is called when you press a key:
andPHP Code:private function keyPressed(e:KeyboardEvent):void
{
if (Boolean(keysDown[e.keyCode]))
{return;}
keysDown[e.keyCode] = true;
switch (e.keyCode)
{
case (LEFT)://arrow-left
///trace("left key pressed");
kine.setHSpeed(-SPEED);
//leftDown = true;
break;
case (UP)://arrow-up
//trace("up key pressed");
kine.setVSpeed(-SPEED);
//upDown = true;
break;
case (RIGHT)://arrow-right
//trace("right key pressed");
kine.setHSpeed(SPEED);
//rightDown = true;
break;
case (DOWN)://arrow-down
//trace("down key pressed");
kine.setVSpeed(SPEED);
//downDown = true;
break;
case (SHIFT)://Shift
trace("shot!");
weapon.shoot();
break;
}
but when i press them alot , the fps goes down. and you can see the spaceship shake even if u hold only one button. it doesnt go fluently, even though the fps remains about 50-55fps when only pressing one button.PHP Code:stage.addEventListener(KeyboardEvent.KEY_DOWN,keyPressed,false,-2);
how is that possible?
am i correct, that memory allocation (and deallocation???) is relatively a veery slow proces?
Memory allocation and deallocation will always be slow processes, however in flash it won't be as much of an issue because it is both slow to begin with and has garbage collection.
what do you mean? you can use object pools to solve the problem. and that significantly increases performance, if you have to make new objects and delete them all the time.
Well, it isn't like memory allocation or deallocation will be significantly slower in Actionscript than C++ since it is a single operation. So because Actionscript is so much slower than C++, percentage wise, memory allocations are not going to be as much of a problem. On top of that, Actionscript is garbage collected which means its allocations and deallocations are more efficient in general.
Testing has shown that object pools rarely increase performance (and generally decrease it) unless you are dealing with very large objects (Generally the kind you dont need many of).
Either way though, if you are creating hundreds of large objects a frame only to discard them, I would say you have a far larger problem on your hands, and one that object pools aren't going to fix (Starting over might though).
i have to create 10 bullets a second. i used object pooling, increased the fps with about 7.
I find it highly unlikely that the speed gain was due to object pooling. On my computer the following code executes in 60ms:Quote:
Originally Posted by omniscient232
Creating a hundred thousand objects a frame will still give you 16fps (Ignoring the garbage collector).Code:var p:Point;
for (var i:Number = 0; i < 100000; i++) {
p = new Point();
}
If I had to take a guess, you were not discarding the bullets properly and they were building up over time.
I'm sure we've had this discussion before mate, but pooling gives more of an advantage then your simplistic example, as lots of one time properties can be set up in the constructor, which in real life usage saves a lot.
If you're doing really intensive loops at a high frame rate then little changes can make a real difference, although I'd only use something like that [ An intense loop / boosted framerate ] for an eye-candy effect and not in a game, because it doesn't allow much "give", which you need for something which is interactive ( As opposed to passive ).
Squize.
But when we are talking about 10 bullets a second there is no way pooling is going to make any difference. The only possible way that could hurt the framerate by any measurable amount is if you let a few thousand of them pile up somewhere.
Usually bullets tend to exist a while before they hit something and are removed, so it can pile up pretty quickly. I'm not that knowledgable when it comes to garbage collection, but doesn't it tend to lag a bit, so it can actually contain quite a few iterations?Quote:
Originally Posted by 691175002
Either way sprite pooling works. It has proved itself to me in actual games and apperantly it has for Squize and omniscient. I don't find it very usefull to go into theory when empiricism suggests otherwise.
This has nothing to do with pooling VS creating. No matter which approach you take the same number of bullets will be in existence at any point in time. Pooling 10 bullets a second will only save one "new" call every 3 frames (And don't kid yourself, a single new call isn't going to drop your FPS by 7 frames).Quote:
Originally Posted by TOdorus
In this case for sure, I can say that the speed issue is that old bullets are not being garbage collected (Due to references being left around, probbably event listeners?). Pooling will solve this problem (Since you no longer need to properly dispose of your objects), but that doesn't change the fact that something was done wrong in the first place.
By definition, an object pool is essentially replacing the new operator with push/pop to a list (Time the operations and you can see what kind of gain you are getting).
As squize has said, we have had this discussion before and in a program that is allocating in the region of dozens to hundreds of objects a frame you might be looking at 10-20% gains but seriously, how much time does your program spend creating new objects compared to say, doing math and running onEnterFrames?
If you are finding incredible performance gains from object pooling, I would be much quicker to attribute it to user error than your program wasting half its execution time creating two or three objects a frame.
I think I only did half a post last time, it was almost a knee jerk "No, pooling is good" reply
"If you are finding incredible performance gains from object pooling, I would be much quicker to attribute it to user error than your program wasting half its execution time creating two or three objects a frame."
Totally agree.
To let me try and clarify so it doesn't look like I'm just agreeing with whoever posted last, pooling is a useful process and does improve things a lot more than that Point pooling example, which I understand was simplistic, I was just trying to re-dress the balance.
As to it saving 7 fps, I can only imagine it making that sort of saving if the game is running at a overly high ( 120 ) frame rate and the mainloop is very intensive ( Most of the experiments in my sig. have gone through various iterations during their development, and all of those have seen large frame increases due to relatively tiny tiny changes, because they're pushing the Flash player much harder than I'd have a game running ).
So I can see it being possible to have such a high saving, although I'd be concerned if any one thing I did to my game made such a saving.
Squize.
I might be generalizing the definition to much, but I consider using one bitmapdata and copypixels for multiple projectiles/characters/tiles a form of pooling. You reuse the same iteration again and again.
Copypixels has proven itself to give a gain only when you use A LOT of sprites at the sime time. Still it is accepted as a solid solution to reduce the performance lost to rendering a lot sprites. The basic idea: it's a little faster, but with big numbers it's much faster.
Pooling objects has the same basic idea. It's not that much faster but it helps. And I think the game I'm currently working on can easily top the 10 projectiles a second at times.
I find my code as easy to read as before (calling to a pooling function or a constructer function? they both look the same) and it gets me the exact same behavior. On top off that it costs less. I can't quite say the same for all the alternative math functions people have come up with (they only cost less). So I can't really get around the idea of advocating against it, really. If it were a ***** to implement, then yeah, but it only takes a very simple class to set multiple pools up.
I am mainly against object pooling as a matter of principle because it has become a net performance loss in almost all other languages and instantiation is rarely even a minor bottleneck.
Even if pooling objects was infinitely faster than creating them using new (As in, pooling was essentially no operation and executed in 0ms) I would still avoid pooling in 90% of cases simply because in a typical game you are probbably spending 30% of your time doing collision detection or logic, 50% of your time drawing, 15-19% a bunch of other stuff and perhaps 1-5% instantiating objects. At that point it is more a matter of preference regardless of the speed differences.
You also run possible risks depending on how you return objects to the pool. It would be bad if you returned an object to the pool but somewhere else code is trying to do stuff with the old object.
I always thought constantly creating of new objects and deleting old ones is the cause why many AS3 games hang at random times. Thats when garbage collector is finally kicking in and cleaning up the mess of millions unneeded objects. By reusing same objects you avoid it.
Sometimes it's a good idea to reuse old objects but most of the time it's simpler and just as effective to make new ones.Quote:
Originally Posted by tonypa
Unless you've made lousy timeline code, the GC shouldn't be any kind of a problem.
there was heavy discussion about this a while ago http://board.flashkit.com/board/show...object+pooling
I've never used pooling and my results are fine. Of course I don't make many games which require 5000 moving objects.