Editor rendering errors with 9-patch and effects

Neither your approach or mine seem to have helped anything... Funny is that we just got a new dev laptop, and it has the same issue. Afterall, nvidia is a small company and has only one driver for all its products, must be normal...

I know it might not be helpfull to state how much they don't care. But Ashley way to address this concern is just as not as helpfull. They only answer we got is: "I tried on my computer, it's not happening", end of the discussion. We al lknow that every single dev reacts like that, we all do, because we created the software on our own machines, we didn't notice anything and all the sudden someone comes out of the wild and tells you it's broken, where you exactly know it isn't. Then, you have to make the effort to go deeper, and not just say: "No, not my problem, we, small company are not in fault, but the big fishes (nvidia, and it seems like intel too) are in fault".

It is not the work of nvidia/intel to adapt to Construct 2, but Construct 2 's work to adapt to what they lay on top of, the graph drivers. For as long as they aren't in a leading position of producing graphic drivers/components. But afterall, they are way too busy porting Construct 2 on Chrome to fix these issues maybe.....

I have another bug, but I'm not even considering posting it here, because the only answer I gonna get is to change my computer where this one is about 4 month old with almost top notch hardware. Instead of that, we just move away from C2.

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.

I tried to do some more digging into this, and found something I thought was interesting. Construct 2 appears to have some utility used on it to provide anti-debugging features. This begs the question: When Ashley tested wertandrew 's capx, did he use the same executable that is distributed on the website, or did he use a version of it before the anti-debugging utility was applied? I ask because a bug that only shows up in the 64bit version could easily be the result of this anti-debugging utility doing something wrong.

Ashley, could you at the very least respond to let me know that you have read anything in this thread beyond the first page? I'm getting the feeling that you haven't checked back on this thread since last year.

It's almost impossible to do anything about bugs that I can't reproduce. Step 1 is to reproduce the problem, so I'm still stuck on step 1.

I'm not sure what the OpenGL traces prove if anything; C2 ought to be making the same rendering calls across all systems. If they're different, that just adds to the mystery, because they should be the same.

Messed around with thous examples. It seems to be caused by 9-patch and sprintfront original huge size+webGL+your window current view. When WebGL effects added, then WebGL will be triggered on that ~1500x1000 size which somehow breaks objects rendering, if i downscale it 150x100 everything start to work fine. Same if i got layout 5000x5000 filled with sprites, if my current window view is on spot where there is no 9-patch/sprintfront everything works fine, but when i move in one of them, objects just disappear.

But when i change some random 9-patch/spritefront setting everything start to work fine. It is like your project files loads, 9-patch/spritefront WebGL effect is forced to overflow your current box size(like it want to apply itself on whole (original size) area around your current 9-patch box but there isent anything so it gets buggy). As if you change some setting everything start work fine, as some values get refreshed.

But! when i open thous examples, change 9-patch/spritefront settings and get them work, then without saving close project and open it again, everything works fine. But when i close project + construct 2 and open project, the bugged effect starts again, as some values somewhere get deleted when construct 2 is closed.

My laptop is quit old and has - https://www.notebookcheck.net/ATI-Mobil ... 698.0.html.

It's almost impossible to do anything about bugs that I can't reproduce. Step 1 is to reproduce the problem, so I'm still stuck on step 1.

I'm with you on that, but the usual methods of achieving that step don't seem to be working. Perhaps we need to think outside the box.

I'll try to keep this little story brief. Back in the days of Windows XP, there was a crash bug that afflicted

many users in every game, and for a significant period of time, no developer knew why. EA would just tell you that "you didn't meet the minimum requirements", even though their own utility said the opposite. Then, Valve stepped up and said, "ok, someone send us a computer that can reproduce the crash". Someone did, and then Valve found the cause. Users were running out of paged pool memory, as windows wasn't allocating enough for some arbitrary reason. The problem was worked around with a registry tweak that forced windows to allocate more, and the problem was fixed for good in Windows Vista.

That being said, I don't think the cause of this Construct 2 bug is so obscure as to require shipping a computer to you. So, lets try some other options first.

I am able to reproduce the bug in a virtual machine, so perhaps I can let you remote in to it, and you can do as you will with it?

I could probably reproduce it on a virtual machine provided by you. I have yet to find a computer that I can't reproduce this on.

Perhaps I could send you a virtual machine with a save state?

If you have better suggestions, I'm all ears.

Since last time I posted, I got a new PC. It still happens on new PC as mentioned before and it also happened on a new project too. The temporary fixes are to turn preview effects off and if that doesn't work to turn force texture ON in layers. It is the only issue that is very obvious to every project I work in C2.

It's almost impossible to do anything about bugs that I can't reproduce. Step 1 is to reproduce the problem, so I'm still stuck on step 1.

My current hypothesis on the matter is that you haven't been testing this bug with the same executable as the rest of us, but instead a version of it before anti-debugging "features" have been added. This is understandable, but I really think you should attempt to reproduce it with the same executable that is distributed on the website.

But regardless of whether this is the case or not, we can (probably) sort it out with virtual machines. What sort of virtual machine shenanigans would you be okay with? I'm up for whatever.