Construct Game Freezes

Hi,

I ran into a strange bug in version .98.9. So I found a cool example .cap of a space game on the forums that had walls around the playing area that was 4000 x 4000. I removed the walls on the left side and increased the playing area to 50000 x 50000. Now when I fly at an angle south east I lose all movement control around 20000, but the game doesn't lock up because I can still fire. Any ideas why this would happen?? I'm not sure if this is a Construct bug, or just doing something stupid with the .cap so I didn't want to post a bug report yet.

http://www.mediafire.com/file/1z2d52mzx0k/large_arena_space.cap

btw... Would you recommend learning on version .98.9 or using the latest dev build?

It's a limitation of the physics behavior. If I remember correctly, the size of the layout is limited to a certain amount. Anything beyond that and physics stops working. I'm not exactly sure what the range is, though. David would be the one to ask, he's the fellow that implemented the physics behavior.

And I suppose that's something that should be added to the wiki

Anyway, if you're making a space game, there are better ways to make large areas like that. You can fake it with manually scrolling backgrounds, for instance. You don't actually have to make ginormous levels like that, it's kind of a waste. With a little pre-planning you can set up a system where it seems like the universe goes on forever but in actuality it's just a small area.

Looks like the limitation is 20000 x 20000. I updated the wiki to state that.

I figured there was a better way to give the appearance of a large world without making it ridiculously large. I'll have to experiment some with scrolling backgrounds then. I still want the world to seem large as in: the x and y coordinates still increment to a large number, and I can place objects at large x or y position. Once I figure it out I'll post an example. Cheers!

Hmm in our code we used:

b2AABB worldAABB;

worldAABB.lowerBound.Set(-100, -100);

worldAABB.upperBound.Set(400.0f, 400.0f);

The default scale for physics is 2% = 0.02

So 400 / 0.02 = 20000

So yeah, 20,000 pixels is the max size.

I need to do a review of the physics code because the speed values dont conform with pixels per second like everything else does.

We originally wrote the physics using newton...and then we changed to chipmunk...and then we changed to box2d...so the codebase got a bit confusing trying to make it backwards compatable with older versions (so that force values all remained the same)

However so many of the games use physics, if I suddenly changed the unit measurement it would make lots of games behave wrong...I'll probably add a checkbox to use 'old unit scale' which will be ticked if your project is old

Even if it broke old physics games, the time to do that is now - the sooner the better.

I'll probably add a checkbox to use 'old unit scale' which will be ticked if your project is old

Good idea.

Even if it broke old physics games, the time to do that is now - the sooner the better.

Agreed. It's ultimately for the best.

And even if there is a conversion checkbox, it wouldn't really be suitable to have it remain in the 1.0 version. People are going to have to bite the bullet some time, and either convert their physics settings and math to the new way, or finish their game with a beta version.

Of course, that's just my opinion

bite the bullet...my opinion

Mine too. Yay for pixels/second, that'll make messing around with physics much easier.

it wouldn't really be suitable to have it remain in the 1.0 version.

and why not? it's just one checkbox..