> Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

>

Yikes. That is no good. Load order shouldn't affect behaviors like that.

Ashley, have you had a chance to look at this yet?

The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

Well, it's hard to tell what is going on without a capx, but I would suggest making sure that the project ID (the com.mycompany.myapp thing) is different between the two applications. Also, open up the .caproj file in each and make sure they have different <unique-id> elements.

Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

I decided to poke at this bug again today. As we know, scrolling around in the affected projects changes how they render significantly. So, I decided to put GLIntercept to the task, and find out what happens differently between good renders and bad renders.

In both my example and in wertandrew 's example, the objects that disappear are being rendered to framebuffer 1 instead of framebuffer 0 like everything else. It even sets up new projection and modelview matrices for this framebuffer. Framebuffer 1 is also never cleared, which leads me to believe that the usage of this framebuffer was completely unintentional in these cases. I imagine that this extra framebuffer is meant to be used to render layers that "force own texture", but is being erroneously triggered in these examples, and only on the 64-bit version of the editor.

Ashley, I've uploaded these captures so that you can review them. Open the IEViewLog.hta file in each folder to view the capture.

https://drive.google.com/open?id=0B40Xy ... EY4aHJwSVk

Each capture shows the full framebuffer before and after each render call, as well as a diff image.

Well, you can get the image data from the blob URL by using the AJAX plugin, but restoring that back into a sprite isn't something I have a solution for off the top of my head.

Johncw87

Thanks for your tip John. I don't want to make you work but could you do a quick little example of 139 vs 239 and show improved performance? That would be a huge help and shed light on this for all of us! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">))

Thank you man. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Ok, but only because I was planning on re-installing Construct 2 to test something else anyway.

I took the project you posted, and made the modifications I mentioned. Window size is 500x500, and the layout scale is set to 0.05. I also modified the project XML so that Construct 2 rev 139 would open it. Visually, it's exactly the same.

https://dl.dropboxusercontent.com/u/207 ... 20fps.capx

In version 139, I get 22 - 27 fps, with an occasional dip

In version 242, I get above 50 fps, with an occasional dip.

These tests were run in Firefox 50 32-bit

I put 3 text boxes into a layout, previewed with NW.js, and saw nothing odd. You should provide a *.capx and some additional information.

• graphics card model
• graphics driver version
• graphics driver release date
• webgl enabled or disabled

When you pick a file, the browser loads it, and assigns a temporary URL to it. When the browser decides that the data isn't needed anymore (or when you close the browser) it unloads it, and the URL becomes invalid. The URL isn't a shortened version of the filepath, nor a shortened version of the image itself. It's a temporary name assigned to a temporary blob of data. There's no Construct 2 bug here.

What you need to do, is save the actual image, instead of a temporary name for the image.

Collision cells are a performance tool. Used correctly, they can increase performance. Used incorrectly, they can decrease it. IIRC, the size of each 'cell' is determined by the window size defined in the project properties. But, since you made that ridiculously huge, you rendered the collision cells completely ineffective at boosting performance. If you take that exact same project, lower the window size to something sane (like 640x480), and set the layout scale to compensate (like 0.05), you will get a very similar result, and it will be much faster. This is not a problem with the tool, this is a problem with how it's being used.

The fact that he doesn't care is enough. They are hiding behind an easy excuse of the drivers being the problem because they can't repro. This bug has been reported since looong and always been denied. It is not my job to look around and bring informations in that sense. I can give infos if I have them and/or I'm being asked, but as you can see, no officials ever asked anything. Bug reporting here is terrificly bad. I can act nice you know, when I'm taken serious. This is by far not the case here as you can see based on the answers you got after all the huge work you made for them trying to rule out cases and demonstrate with A+B that it is not a driver bug.

Think about it from his perspective. Lets say that you are tasked with fixing this bug, and you can't replicate it. How do you even begin trying to find the cause if the issue never manifests on your machine? How would you know if you have fixed it or not? Instead of complaining about how much he "doesn't care" (which is NOT helpful), try to help Ashley reproduce it. That's how this will get fixed.

Also, consider the small size of Scirra's dev team, and that Construct 3 is in development. Ashley probably doesn't have a bunch of time to dedicate to hunting down minor bugs like this, especially when you consider how many non-bugs get reported. The more you can do to narrow down the cause, the easier it will be for Ashley to identify the bug and fix it.

I was thinking about this bug again today, and decided to try replicating it on a software OpenGL implementation, to rule out driver bugs completely. I downloaded Mesa 3D 12.0.6 for this test, cross-compiled it from Ubuntu for windows 64-bit, and placed the resulting opengl32.dll into my Construct 2 folder. As an added precaution, I removed all 3rd-party plugins that could render something. As I expected, I was still able to reproduce the bug. I know for a fact that Construct 2 was using Mesa 3D, as process explorer showed that opengl32.dll was loaded from the Construct 2 folder, instead of System32 (also the editor ran pretty slowly, which was expected). If anyone else wants to try this without having to compile Mesa 3D, I've put it on google drive.

Psychokiller1888 I don't think your 'persistence' in this matter is helping. If you have no new information to offer for this bug report, could you maybe chill? I know the bug is annoying, but you have a few usable workarounds. You don't need to hound Ashley about it.

*quote snip*

I 100% agree with you, I also would have liked to have a third tilemap for jump-throughs, which would complicate issues even further, which leads me to suggest that tilemaps need the ability to set behaviors per tile/groups of tiles.

Well, that wouldn't really work, since adding behaviors to individual tiles would inevitably lead to people trying to add movement behaviors to them, and that wouldn't work for obvious reasons.

The best workaround I can suggest is to have 3 separate Tilemap objects, instead of 3 instances of the same Tilemap object. That way, you can filter the traces however you want.