how to make games faster?

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.

Quote:

---

Originally Posted by omniscient232

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:

Code:

---

var p:Point;
for (var i:Number = 0; i < 100000; i++) {
        p = new Point();
}

---

Creating a hundred thousand objects a frame will still give you 16fps (Ignoring the garbage collector).

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.

Quote:

---

Originally Posted by 691175002

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?

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.

Quote:

---

Originally Posted by TOdorus

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?

---

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).

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.

Quote:

---

Originally Posted by tonypa

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.
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.