Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411491 Posts in 69371 Topics- by 58428 Members - Latest Member: shelton786

April 25, 2024, 03:30:20 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Object Pooling in Box2D
Pages: [1]
Print
Author Topic: Object Pooling in Box2D  (Read 2484 times)
st33d
Guest
« on: March 08, 2010, 03:05:03 AM »

I've got a platform game engine with a lot of roaming to do. I can't just pack the whole level into the world without causing a lot of chug.

I've reduced the number of static surfaces by doing a marching cubes walk around the entire level.

My issue is with the interactive objects. I'll need to remove them when they get off screen, but then put new ones in.

I've tried doing a lot of creation and destruction with Box2D before, and it lead to a clusterfuck of chugging. Another in-house project we did was also guilty of this. I was lucky at the time that I was working on a puzzle game, so the chug didn't matter. Now though, it really does.

So I'm wondering if there's any way I can generate a load of objects, and figuratively put them on the bench as opposed to destroying them and recreating them.

Take the spikes for example - I'm guessing that I could generate so many spikes, but then when they went off screen, I could bench them instead of destroying them. And then when new spikes came on, just set the xform of those old spikes to the new positions.

What are my options? Is there a better way of going about this?
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #1 on: March 08, 2010, 12:37:46 PM »

This C++ or AS3 (or other?)

C++ has some elaborate memory management behind it. You can tinker with this. But i think it unlikely you are actually running into add/remove speed issues in C++.

AS3 doesn't have object pooling for the CreateDestroy methods, but it's really easy to put in. There are examples of pools all over the place. Heck, I could even code it up for you, if you like. You might also run into broadphase slowing you down for adds and removes if you are using 2.1a, in which case you should use the HEAD revision, which has some tree rebalancing. You can also change shapes to work by reference than by value, which would save a great deal on copy calls.

In either case, recent versions of Box2D support an "active" flag. Inactive objects are fully registered in the world, but don't participate in anything. Convenient for what you want, though you probably would still want to truly remove for very large worlds.
Logged
st33d
Guest
« Reply #2 on: March 09, 2010, 01:53:05 AM »

We're in AS3 here.

I'm using a 6 month old build of Box2D that I went through, made all variables public and replaced all the methods that bridged access to those private variables with direct access. I went through a min/maxing phase on one project that was running slow. That's besides the point though, I'm sure I could spend a day to update.

For another project, my simple rectangle physics system in that uses a kind of display list. Objects get pushed in and out of the display list but sit around in memory in case they're needed.

I assumed though that Box2D wouldn't have a straight forward version of a linear display list. Either that or there's too many interdependant lists. Am I right, or was it just a matter of TLDR?

I assume this active business like an advanced version of the sleep tag? Since sleeping objects just turn static for a while an ease off the cpu, so they would be more so if bypassed altogether. A good reason to get the latest version.

Examples of pools would help most of all. I'd be happy with some code off the shelf, but it'd be good for me to get my head around this.
Logged
bateleur
Level 10
*****



View Profile
« Reply #3 on: March 09, 2010, 03:39:04 AM »

This may sounds like a silly question, but how sure are you that it's really object creation/destruction that's slowing you down?

The reason I ask is that garbage collection overheads don't actually vary as much as people tend to assume with the amount of creation/destruction going on. As such, my initial reaction is to assume the bulk of your delays must be from something other than the memory management.

(This isn't to say garbage collection doesn't slow things down, but the slowdown is typically more to do with the volume of data you're working with.)
Logged

st33d
Guest
« Reply #4 on: March 09, 2010, 04:24:52 AM »

I'm sure. I am making no assumptions. I have studied the problem thoroughly with a game that blasted Box2D shapes into smithereens. Lots and lots of little smithereens.

When Box2D creates and destroys objects, there's a lot going on. I spent a while studying the problem and how to reduce it.

One tactic I had to adopt was to create a separate world to do shape tests for an explosion. The explosion sensor I obviously wanted to be in and out of the world quickly.

When you have 20 explosions in one frame, and those sensors are being affected by gravity, and you want them out of there soon before the contact listener sends repeat collisions, it's not pretty. So I ran collision tests with objects in another world, by testing their shapes (I had simply a circle and a rect that I would pop into relative positions before running each test). This bought me loads of cpu.

There's a lot of calculations that go on in bringing a new shape into the world. It means that a shape that suddenly pops into existence collides and squeezes stuff out of the way. This is good. But I need a way to push shapes into reserve, so that the engine doesn't do a load of chunky grinding when a lot is going on.

This is a platform game where you are basically a very bouncy pogo stick. Lots and lots of movement over big distances required.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #5 on: March 09, 2010, 12:25:41 PM »

As I implicitly stated, there's only two (significant) calculations when you add something - creating objects, and inserting in broadphase. You need to determine which is causing you problem, exactly as bateleur says.

If it's the broadphase, none of these tricks will work, it's just as expensive to move something a long distance in the broadphase as it is add it. In that case you could try QueryShape (which may require some reverse porting). It has none of the start up costs, but it's slower if you are going to be calling it every frame.

If it's object creation, then do pooling, then worry about the other details. This makes a decent difference, so I've been slowing cutting down on allocations inside Box2DFlash.

Quote
There's a lot of calculations that go on in bringing a new shape into the world. It means that a shape that suddenly pops into existence collides and squeezes stuff out of the way.
I don't consider position correction to be part of creating a shape, it's part of the general engine. But if you are creating lots of shapes near on top of each other, it is going to hammer the engine. If this is your bottle neck, you are pretty much stuck. Turn down the engine accuracy, or give it less work to do.
Logged
st33d
Guest
« Reply #6 on: March 19, 2010, 09:39:09 AM »

Okay, my bad. I figured out where all the overhead was coming from on my previous project.

MovieClips.

Lots of particles - lots of MovieClips. And to make matters worse, I slapped the graphic inside another Sprite for the body's userdata. There's my chug. If object creation was the issue, then it should have frozen the game, not slowed it down.

*st33d dons fucking idiot hat and sits in the corner

I seem to be doing okay ignoring the issue of object creation/destruction by rendering as much as possible using bitmaps.

I do have a question concerning the "active" setting though:

I have some appearing and disappearing blocks. Would it be better to toggle the active setting or dick around with the collision filter, or is there a third option?
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #7 on: March 19, 2010, 05:03:21 PM »

Sure, toggle active. Filtering is there for finer control.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic