How Do I: Stop Sprites Using Bullet Behaviour Sticking & Sli

Yes. It is bouncing behaviour related thread no #89218301 on the forums.

I've been cruising along with C2 and I've learned a lot of things, I feel as though I have a firm grasp of things but there is just one little bug I can't shake and it appears to be a bug with the bullet behaviour.

I have done extensive trial and error with the bullet behaviour, I've also extensively searched the forums, looked through example CAPX files and still have yet to solve this issue.

The problem:

I have a simple ball sprite with bullet behaviour. The speed is set to 850 and I have 4 walls surrounding my canvas (all belonging to the same family). The walls are set to solid and the sprite ball is set to bounce off solids. The speed remains consistent and never changes. Acceleration is set to 0, as is gravity.

Now it doesn't happen right away, but when the ball sometimes hits a side wall usually on the X axis (left and right walls), the ball will get stuck and end up sticking to the wall and sliding around the canvas. Eventually it unsticks itself, but this isn't the kind of behaviour I want in my game.

I've tried toying with the gravity value and every other parameter to no avail. Is there a definitive fix for this problem?

I've read of others with the same problem and solutions range from custom movement to using physics. For performance reasons, I want to keep using bullet behaviour and I couldn't find any solution for bullet behaviour.

I tried setting up a scenario like the one you mentioned and couldn't get anything like you mentioned to happen. Could you please post a capx?

From the top of my head, a bullet with 850 speed could very well have some problems on a low framerate. Why ? Because 850px/sec is a lot, and if the game just has 1 big tick when the ball is near a wall, it can very well go through, or in your case get stuck in the wall.

There is no good solution to this problem (to my knowledge) but there are some fix you can add :

• reduce the speed of the ball, if it's possible in your game
• add a check every now and then to test if the ball is overlapping with the wall. If so, check what wall, the current exact position (is it bouncing or is it stuck ?) and move it just a little so it isn't in the wall anymore.

I know this doesn't seem like what you want, and the problem may be different... Hard to tell without a capx

copy.com/browse/copy/Test%20Bounce.capx

Thanks for the help everyone. I've posted up a CAPX online here:

It won't happen every single time, just sometimes, but enough for it to be considered a final release stopping bug. The thoughts around pixel speed and framerate are interesting. It doesn't seem to happen on desktop as much as it does when I test on my Samsung Galaxy S4 and it's a little more prevalent when viewing on an iPhone 5 as well. The framerate being at fault here would make some logical sense.

View the above CAPX on your mobile phone and you'll see the issue I am talking about. This is going to be a mobile game, and so, this can't happen.

In regards to preventing the ball overshooting and or getting stuck on a wall, is there some pre-existing code elsewhere (perhaps another project) that I can implement and test with? I am getting better at Construct 2, but by no means a ninja when it comes to resolving issues using events and messing with positioning coordinates.

Sorry but your link doesn't seem to work (you linked the private version of your file, not the public URI)

I'll try to build something to show how I would do it. Only solution I can see is replacing the whole bounce of solid from the bullet behavior with home cooked events. If anybody sees another method for this, don't hesitate.

For more precision I would suggest to use a loop like.

Repeat Sprite.speed

X overlapping wall

=>

move 1px to Sprite.angle or more for less precision but faster execution.

And for the bouncing maybe this would help

R0J0hound lazer example

http://dl.dropbox.com/u/5426011/examples%208/lazer.capx

Here is an example. I tried it until it eventually broke, once the ball was moving over 4k pixel per second. Can't blame it.

After a lot of tries, using the collision detection like this and bouncing manually, with big ass walls, had the best results.

Only true solution would be to detect if the ball is now out of its box, interpolate the theorical boucing point and calculate the correct position.

I looked into the example you linked Katala, and didn't understand everything, but saw so many loops I got scared :p still, the FPS was 60, with hundreds of loops being done every tick, I was amazed ^^

Oops sorry, I still have link restrictions on the forums and pasted the correct one initially only to have it removed and then I accidentally pasted the private URL. Here's the public link: copy.com/SD2LKtm2qbO2

I'll have a look at your example Guizmus, 4k sounds reasonable for buggy behavior. I am only keeping the ball at 850px/s, so with your example it should theoretically be fine! Your example works well until as you say, it gets so fast it just disappears from the screen. I don't think I'll ever run into that problem on this project, thank you for all of your help everyone.