collinhover / impactplusplus

Impact++ is a collection of additions to ImpactJS with full featured physics, dynamic lighting, UI, abilities, and more.
http://collinhover.github.com/impactplusplus
MIT License
276 stars 59 forks source link

Random back and forth jumping of entities in chrome #149

Closed Pattentrick closed 10 years ago

Pattentrick commented 10 years ago

Hi there,

I discovered a really strange behaviour of entities in the current chrome version (33.0.1750.154). At first I was thinking that I just messed something up, but after almost 2 days of debugging I have still no clue what exactly is going on. On top of that, the problem does not occur on any other browser.

As soon as I spawn new entities with the spawner abstract, near by (but not all) entities will start to move a pixel forth and then back again for the rest of the game, as if they were jumping back and forth over and over again. Which one of the entities are affected depends on the spawn order (most of the time), and sometimes it seems rather random. Sometimes the player will be affected, sometimes not.

Although these entities are moving back and forth the accel and vel properties doesn't change at all. So my idea was that the pos of those entities gets messed up somehow. However, until now experimenting with the pos has failed to produce any solutions. As far as I can tell this has nothing to with the draw either, because the draw position and the entity position is the same.

I provided a demo here, because the behaviour is somehow hard to explain:

https://github.com/Pattentrick/chrome-bug

The demo shows an almost empty level. The ship of the player flies to the right and collides after a few seconds with a trigger. That trigger will activate a spawner, which will spawn some enemies. Shortly after that the bug described above will occur.

There are also some invisible entities (responsible for preventing the player ship from leaving the screen). So you better activate the debug panel and click on the “show collison box” check box. The bug also occurs, if those movement borders are not present. Even when there is no player at all. You can use the EntityBee for example instead of the player, and the same behaviour will occur.

I'm at my wits' end. Any help on this will be highly appreciated. This is a big blocker for me. I hope that I just miss used some class and everything is fine, and this is not one of those hard to track and insanely annoying bugs …

collinhover commented 10 years ago

Hi @Pattentrick, I'm here and will be looking into the bug. Let me know if you have any updates, otherwise I'll try to fix this asap!

collinhover commented 10 years ago

@Pattentrick the issue is happening on my end also, but sometimes it does not occur at all. Trying to track down the cause!

edit: seems like the issue usually does not happen the first time I open the game in a tab, but then it does every time after when I refresh the tab.

collinhover commented 10 years ago

@Pattentrick can confirm that it only appears to happen when the spawner is triggered. Other triggers seem to be fine.

collinhover commented 10 years ago

@Pattentrick stepped through the spawner code, and it looks like the issue starts only after an entity is spawned in the spawnNext method. Commenting out the code that spawns entities fixes the issue entirely, but no entities are spawned. However, allowing the entity to be spawned and commenting out the code just a bit later in the spawnNext method that calls this.spawned(entity) seems to reduce the random back and forth movement quite a bit. This is a very strange bug, I'm going to try it out on a new project and see if I get the same results.

Pattentrick commented 10 years ago

@collinhover I am very glad to hear that you are working on the problem. You are truly awesome man! I have no updates on this one either. I hope that you will find a solution. This is a really strange bug, especially because I think it's just chrome related.

There is one thing that I didn't wrote about before, because I thought that would make this crazy bug even more confusing. But right now this may could be helpful for you.

A few weeks ago I wrote the shoot mechanic (I used the shoot ability + projectile class at that part). I noticed that whenever I shoot, the bug with the random back and forth jumping also occurs. However, after finishing the work on that part (defining offsets, velocity, animation sheets) this strange behaviour was gone.

However, I am not sure if something I did fixed it. Maybe it was related to the spawn of the projectile, similar to how this bug occurs now after spawning entities with the spawner. But that's just a wild guess :-/

collinhover commented 10 years ago

So, I've tested this about 15 different ways, and for who knows what reason I decided to turn off the jet engine in the demo. This fixed the issue entirely .__.

I'm digging into the jet engine now.

Pattentrick commented 10 years ago

Whoa - that's surprising. The only thing that comes to my mind regarding to the jet engine is that I didn't use the moveTo method there, because the jet engine was following the player with a slight delay. So i updated the pos property in every udpate manually.

The jet engine itself is an extension of the explosion entity from the SUPERCOLLIDER demo, and is a spawner as you know. I may recognize a pattern here. I stated that problem once occured with a enemy spawner, so this may be related to the spawner class somehow (as you guessed before).

However, you said that this problem is complety gone once you remove the jet engine ... strange :-/

collinhover commented 10 years ago

Okay, it appears to have to do with your jetengine particle. When each particle is added to the game world, you're forcing an immediate sort of all entities. I'm not sure if this is during the update loop exactly, but I'd be very careful about immediate sorts. Maybe I shouldn't have it even as an option... but I don't want to take too much control away from the dev, you know? I'd suggest always using deferred sort and let the game handle it, as the game will do so only when it is safe to sort. This also makes sure you do no more than 1 sort per frame, because any more would be wasteful =)

Just switched the ig.game.sortEntities call in your jetengine particle to ig.game.sortEntitiesDeferred and everything seems to be working fine! Please double check and let me know if this works.

collinhover commented 10 years ago

Actually, I'd like to get your opinion on this sorting issue also. I'm strongly considering only exposing the game's sortEntitiesDeferred and rerouting sortEntities to just be an alias for the deferred method. This would avoid future issues of devs sorting when it is not safe. What do you think?

Pattentrick commented 10 years ago

I will double check your solution as soon as possible! I think it's a good idea to reroute the method, because this will prevent this issue completely in the future. Good catch! You are amazing :D

collinhover commented 10 years ago

Cool, please give the latest commit a run also if you can. It seems to work for me, but always good to have extra tests =)

Pattentrick commented 10 years ago

Double check is finished, works like a charm! Yeay :D

I will now test the latest commit!

Pattentrick commented 10 years ago

Extra test is finished. Everything seems to work like expected. Great job :-)

collinhover commented 10 years ago

Woot! Can't wait to see the full game you're working on!

Pattentrick commented 10 years ago

I hope i will finish the game in the near future. I will keep you updated. Since i have your attention right now, i want to seize the moment. Shame on me! What do you think about this pathfinding behavior?

www.shuchu.de/ssr/

I just call this.moveTo( player ). But for whatever reason the enemy is constantly moving up and down and is switching nodes on the y axis for reasons i don't understand.

That's not critical in any means for me right now, because I will add another attack pattern for this enemy. They are too easy to defeat when they approach the player in a straight line. However, that may be a problem some day in another game. If you have an idea on the fly let me know, if not that's also not a problem, since i won't use pathfinding on this fella anyway.

collinhover commented 10 years ago

Hmm, have you tried using top-down mode instead of side-scrolling? This looks like side-scrolling pathfinding, based on where the entity's source node is. I think there is some special behavior setup for top-down that helps with this sort of pathfinding, and since your game has no gravity it is a good fit for both. That said, it should not be too difficult to add the behavior to side-scrolling entities that have a gravity factor of 0.

collinhover commented 10 years ago

Also I love how the explosions feel in the game =) super heavy, you can really FEEL the hit.

Pattentrick commented 10 years ago

Awwww ~ thanks! Glad you liked it. There are also some random critical explosions if an enemy dies. And I am not even finished with the explosions. I want some more things like debris and some magic stuff. Although i have to be careful and don't add to much. This video was a great inspiration:

https://www.youtube.com/watch?v=AJdEqssNZ-U

It's about "game feel" regarding to action themed games. A really entertaining presentation.

The game right know is TOP_DOWN: true, or is there another setting for pathfinding where you can switch the behavior? I guess not, or am I wrong? I will experiment a little bit with it. It's not very crucial at the moment. Thanks for your opinion on this issue :D

collinhover commented 10 years ago

Hmm, try changing this method: https://github.com/collinhover/impactplusplus/blob/dev/lib/plusplus/helpers/pathfinding.js#L2364

Have it just return the center points of the entityPathing and entityTarget. Does that fix the strange movement?

Pattentrick commented 10 years ago

When i change the code like that:

javascript return { from: { x: pCenterX, y: pCenterY }, target: { x: tCenterX, y: tCenterY } }



The problem still occurs, but is a little bit better (although i could just surmise this part. it seems that it's a difference of maybe 3-4 pixel).