Editor rendering errors with 9-patch and effects

Report Construct 2 bugs here.

Post » Wed Jan 04, 2017 12:47 pm

@Ashley Any news?
B
32
S
11
G
3
Posts: 214
Reputation: 4,267

Post » Thu Feb 02, 2017 8:53 pm

@Ashley is that fixed in Construct 3???
B
32
S
11
G
3
Posts: 214
Reputation: 4,267

Post » Sun Feb 05, 2017 8:27 am

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.
Last edited by Johncw87 on Wed Mar 22, 2017 1:41 am, edited 1 time in total.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Sun Feb 05, 2017 8:54 am

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.
B
32
S
11
G
3
Posts: 214
Reputation: 4,267

Post » Sun Feb 05, 2017 6:33 pm

Psychokiller1888 wrote: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.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Wed Mar 15, 2017 9:21 am

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.
B
32
S
11
G
3
Posts: 214
Reputation: 4,267

Post » Thu May 04, 2017 10:07 am

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.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Mon May 08, 2017 1:01 am

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.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Mon May 08, 2017 10:15 am

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.
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,694

Post » Mon May 08, 2017 2:17 pm

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.
B
30
S
20
G
14
Posts: 17
Reputation: 9,874

PreviousNext

Return to Bugs

Who is online

Users browsing this forum: No registered users and 0 guests