Should I use workarounds for a bug in C3?

0 favourites
  • 14 posts
From the Asset Store
Bug Match
$2 USD
60% off
Match same tiles with each other as fast as you can and earn more score during a limited time!
  • Ayy, currently not subbed to C3, I was subbed before, but stopped due to some concerns, but I wanted to sub again knowing C2 will not be supported and knowing bugs will be fixed and such in C3.

    So I saw "Drawing Canvas" finally can rotate in a recent update, which made me think Drawing Canvas is now better than Paster from C2 since it has everything needed!

    However, I quickly tested pasting a 9-patch object with an effect, and it is glitched. I made a bug report but it was closed and has been reported similarly before. No sign of the bug ever being fixed.

    Bug report here: github.com/Scirra/Construct-3-bugs/issues/4202

    So, Paster in C2 works perfectly and doesn't have this bug with pasting 9-patch objects, yet this bug with drawing canvas sounds like it may not be fixed due to the "complexity of the effects compositor".

    I respect that it's a complicated engine, but Scirra are the programmers, Scirra created the "effects compositor" for their product, and therefore only Scirra can fix this bug... This confuses me, so what do I do now? Wait and hope? It is a very clear reproducible bug but I wasn't told "it will be considered in future" or "this will never be fixed"...

    I reported the bug because its exactly what I needed for my project, I need 9patch objects to have effects and be pasted, and C3 is not able to do this and C2 CAN do this and I can't port my project over a bit more easily due to this (or even starting from scratch isn't easy).

    So, my main question, if I start making a project that has a workaround with this bug, is that safe/recommended to do? The bug makes the "paste" result offset a bit weird so I could use adapt to this and get the desired effect I need, but I'm concerned that in the future, the drawing canvas will suddenly get updated, or effects compositor will be suddenly fixed and then my workarounds might become glitched and broken.

  • I just tried the file from your bug report and the bug is quite clearly pasting the object from the viewport's origin rather than the drawing canvas' origin.

    I believe Ashley when he says the code there is extremely complicated, but knowing exactly what to look for should help...

    as a work around all you have to do is make sure the top left corner of the canvas is at ViewportLeft(0), ViewportTop(0) and it will paste where you want it. It doesn't matter how wide or tall the canvas is. I tried with unbounded scrolling just to make sure it wasn't assuming the top corner is 0,0. And it is pasting based on the viewport left and top. Making the canvas origin top left (instead of center as in your sample) makes it easier to position.

    Is that a limitation you can live with? Is there a reason you need to paste with canvas somewhere else? As long as you aren't destroying objects in the same tick as pasting them you can move the canvas and objects as needed, paste, and move them back. Future updates and fixes won't break that.

  • Ah I see, thanks for the info about the bug!

    I have a few ideas for workarounds to test, maybe even using 2 drawing canvases to get what I need (keep one at 0,0 like you said, then use a second drawing canvas to position and paste on the first drawing canvas), but I was mostly worried about a sudden fix in future messing up whatever workaround I produced.

  • I admit I didn't thoroughly read that bug report. But did you see the release notes for new beta r215?

    You can now make a snapshot of a portion of the screen. For example, the area with your 9-patch object, and then load this image into a sprite.

  • Ah yes that's almost a better alternative, but I do need to retain the alpha channel on the 9patch, which I think the snapshot doesn't do. Thanks for the idea!

    It's cool, I'll try my workarounds out later, if any work then I'll probably subscribe again to make this project. Its mostly menus and 9patches in my project so I would have hoped it worked like paster did in c2.

    I was mostly worried about logging in one day to see the compositor was fixed but breaks my entire project that relies on whatever workaround I used.

  • I decided not to bother trying to workaround the bug - I mean it works in C2 with paster and I have a licence already, rather than paying monthly/yearly for C3 to have to make my own workaround when it should just work as advertised (why not hide 9-patch objects from the "Paste Object" list? This will surely come up again with other people).

    I purely wanted to subscribe to C3 for ease-of-use and not messing about with bugs or issues as often, and right away I've encountered a bug and I wasn't told whether it will be fixed or not, all I know is that "it's complicated"... yet it works in C2 perfectly.

    My use-case for this was purely for performance gains - Being able to set an effect, paste it, then disable the effect, would give a performance boost in exchange for RAM usage (which is very minimal), especially when multiple 9-patches/sprites with different effect values are needed.

    I hope Scirra reconsiders fixing the bug, or even making an internal "workaround" for bugged "Paste Object" instances, instead of leaving it up to the subscribers to fix.

  • why not hide 9-patch objects from the "Paste Object" list?

    Sorry but I have to disagree with this. Your use case is very specific. The issue only applies to 9-patch objects and effects applied and with a canvas offset from the viewport. And you are only doing it because you don't want to apply the effects each frame to eek out extra performance in a project where most game objects are 9-patch. You would want to disable 9-patch object pasting entirely because of that, when it still works for the other 99% of use cases that other people have?

    I haven't seen your project or any screenshots, so I can only guess that it is a GUI heavy project? Have you benchmarked the difference with just applying the effects? Because the effects you mention in your issue, black and white, HSL - they are the lightest effects for a GPU to run - the performance impact should be minimal.

    Otherwise take the old school approach we used before shaders (effects) - pre-render the black and white, faded versions etc., and swap the object or just switch their visibility on/off.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • simstratic

    I meant specifically hiding 9-patch from the "Paste with Effect" option where the bug is present, although thinking more about it, locking down options would be a worse idea as it wouldn't allow any workaround to exist all, so I take that back!

    Yes in my case, my project is GUI heavy and player-customisation heavy, I made the strong assumption that pasting onto a canvas would be much better for CPU/GPU rather than having many concurrent effects. I did not want to choose the baked-in approach, as this limits customisation, and limits colour choice to whatever I picked.

    I am unsure how to measure this (Is it better to have a low-end device to test on?), I tried measuring on my PC but I get no difference at all in draw calls and such with the two approaches. I may be wrong about the performance gain, but as of now, I don't know, I still feel more inclined to move the load onto RAM in my mind, there's plenty more RAM compared to GPU power, especially on lower-end mobile devices.

    Regardless, the bug exists and is reproducable, and it's unknown whether it will be fixed due to the complexity of the effects compositor.

  • it isn't just 9patch... sprites also are affected, and probably other types as well.

  • Drawing canvas would be great, especially for gui except the whole redraw on resolution change thing.

    It's a deal breaker. There any many circumstances where you simply can't redo everything on the canvas.

    And transfering to other objects is problematic.

  • So you got me curious and I did some testing today - and yeh - effects (HSL, B&W, probably others) seem to have a huge overhead on 9-Patches compared to sprites. Sprites I hit the CPU limit with lots of juice left in the GPU, but 9-Patches maxed out my GPU much sooner. I'm not sure why - every time I thought I had a theory, my testing didn't back it, so I'm afraid I'm no closer to unravelling the mysteries of the effects compositor for you.

    I should mention this is Construct 3. I don't know if you see the same in Construct 2, so it might be worth checking? If you create a layout with 20 sprites with an effect, and another layout with 20 9-Patches with same effect, do you see a big difference in GPU% when running the layouts? (BTW you have to force a screen redraw - so give the sprites and 9-Patches sine behavior or something to make them move)

    To answer your other question, when you can't test on a phone, a computer with integrated graphics will perform more similarly to a phone, they tend to have the same problems with fill rate, overdraw etc. Testing GPU% is tricky too, it can look really high when you first add a lot of objects/effects/etc., but leave it running for 5 minutes and it can drop significantly. I think when the GPU gets lots of new work it 'panics' and draws a lot of power to make sure the framerate doesn't drop, then it gradually winds down it's power until it is just maintaining the desired framerate.

    Finally a word of caution about the RAM, yes there's more of it, but there's probably more background applications fighting over it, whereas the GPU should be almost fully dedicated to the game. Test on a phone while developing if you can - I tend to do a build when I'm heading to bed and test it in the morning - because performance can be very different.

  • simstratic , Ooh interesting!

    I tried what you suggested in C2 - Checking the GPU% usage in Windows 10 Task Manager, I see no difference in percentage (though I'm not using a low-end device and don't have one available), however, with having 20 sprites and 20 9-patches on different layouts all with sine, I got these results from looking at "Draw Calls" in the preview debugger (after waiting about a minute for it to settle down and give a consistent percentage):

    Draw Calls

    9-patch no effects : 0.9%

    9-patch WITH effects : 2.4%

    Sprite no effects : 0.6%

    Sprite WITH effects : 0.8%

    Considering these results are not from a low-end device, I'm not sure if they mean too much, but interesting nonetheless.

    Yeah true with RAM, I hope that doesn't come back to bite me, though I quickly measured this in my C2 project at the moment, it's appears to be an extremely small cost in my case assuming the "Est Image Memory" is a fair thing to observe:

    I see Est Image Memory goes up by 0.1MB or 0.2MB for each 149x149 "Paster" created and pasted onto, 149x149 in resolution.

    So this means you could give the player more than 10 uniquely-chosen effect parameters for 9-patch/sprites (assuming they're just a square icon in a HUD, not necessarily for backgrounds for HUDS that have higher resolutions that cover the screen), for 1MB of RAM and no extra GPU usage to render the effect (presuming it's a static effect like AdjustHSL/Black&White/Tint). That's pretty alright, assuming I've measured this correctly!

    I will take your advice on building more often, I've always only previewed in Chrome on a phone! But I recently saw on that other thread that there's unexpected differences between Chrome and a built APK.

  • So I realized today, I can test this in Construct 3 by with running the Construct 2 runtime, and with the C2 runtime I am definitely still seeing an increase in GPU% (both in the debug preview window and the Windows task manager). And this isn't a really low end GPU either (Radeon RX 570). In Construct 3, there's an option with the C2 runtime for WebGL, if I turn that off, then I don't get any GPU usage (but I get higher CPU usage as it's software rendering). This makes me think you're not using WebGL in your project?

    I know which thread you're talking about (Chrome vs APK), and there was some fear mongering going on there. In the vast majority of cases, the performance should be very similar - there are these rare cases where it seems like WebGL is being disabled in the APK on a specific phone or GPU driver - the Chromium team is continuing to investigate. Honestly I wouldn't worry about it, but it's still good practice to test with an APK export occasionally.

  • The C3 runtime requires WebGL. The game won't run at all without it. You can still get software-rendered WebGL though, which can cause poor performance.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)