Ashley's Recent Forum Activity

    • Post link icon

    — - it takes 1 second to open every time, consistently. It has to fill a dropdown list with 1000 items every time so this is likely why. Rebooting won't affect this (it still has to fill 1000 items), and I doubt it's anything to do with icons. It would only turn to 4-5 seconds if you correspondingly had 4000-5000 global variables, which even the biggest projects ever won't get close to (a huge project would have that many events, not just variables).

    So I don't see how this is a sign of anything more serious. Like I say, this seems like a very specific case, and if that's it, I don't think it's worth optimising (who has 1000 variables in one project, let alone 5000?). I think there are probably other cases that actually need optimising, but like I say, I'll need projects and repro steps for them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
    • Post link icon

    Please be patient. This issue is only about a week old and was filed over the holidays when everyone was out of office.

    I took a look at Slow.capx. It seemed OK to me. I have a high-end machine, but I ran a debug build with optimisations disabled which usually more than cancels out the fact it's a high-end machine; despite that it still opened quickly enough (I'd say ~1 second). After a few quick checks I realised the project has around 1000 global variables and most of the work opening the dialog seems to be filling the dropdown list with 1000 entries.

    So all this report proves so far is "editing actions using event variables is slow if you have 1000+ variables", which is a really specific situation. It sounds like there's some confusion in this thread over what the problem really is. It seems there may be different cases which are also slow, but unless there is a separate report for those, complete with example projects and reproduction steps such as in this case, I don't have anything to work with. So please try to narrow down each individual case; it seems unlikely that everyone here has a project with 1000 global variables and are repeatedly editing actions with variable parameters.

    FYI C2 lazy-creates icons, so the first time you open a dialog it goes and creates thumbnails of the objects in the project. Lazy-creating is important to avoid reaching the 10000 graphics object limit in Windows - it avoids creating icons for things that aren't used or looked at. This would be difficult to change, since if we create icons in advance, it will in some cases unnecessarily use more of the Windows limit. (In C3 we spritesheet icons so, fingers crossed, this should never be a problem ever again in C3.) Anyway, it explains why the first open is sometimes slower, but in a long session only the subsequent opens really matter, so that's what I'd prefer to focus on.

  • The normal function for arrow keys is to move the caret in the text selection, and it would be inconvenient to override that.

  • Apologies for any outage, the meltdown/spectre security issues are causing emergency patching and reboots of servers. We're looking in to it now and checking everything's working OK.

  • The project uses the following third-party addons:

    Audio helper

    Layout transition V2

    LiteTween

    Also given the size of the .capx it looks unlikely to be a minimal repro as per the bug report requirements. Closing, please file again following the guidelines if you still want us to investigate.

  • HessamoddinS - I'd rather not add languages before we know when we'll be able to use them, since it might upset contributors. For example if someone spends 2 weeks doing a complete translation, then we don't use it for 6+ months, I'd understand if they were angry and felt like their time was wasted!

  • Your screenshots don't match the effect or .capx provided. Based on what you have provided, it's not a bug. vTex is the position in texture co-ordinates of the current fragment on the source surface. By design, this can be pretty much anywhere. With spritesheeting, this means the sprite image is no longer 1:1 with the source texture, and will instead be a subset of the texture. Also it changes in some other circumstances, such as you've found when you change opacity: in this case the effect compositor pre-renders the sprite to a viewport-sized surface with the opacity applied, and then processes the effect from a sprite-sized subset of the viewport-sized surface. This is necessary to ensure the shader processes pixels with the opacity already applied. This pre-draw step changes the co-ordinates of vTex. Normally this doesn't matter - if you use texture2D(samplerFront, vTex), you always get the right pixel. The shader you provided simply displays vTex as a gradient and you've pointed out the cases where it varies; these cases are by design, so this in itself won't be fixed.

    What you probably need instead are uniforms that specify the source rectangle subset being processed. Then you can use vTex's position within this rectangle to determine the normalised texture co-ordinates ([0-1] range) within the subset actually being drawn, rather than relative to the entire source surface. Construct 3 provides the necessary uniforms with the srcStart/srcEnd uniforms, and even provides an unclamped srcOriginStart/srcOriginEnd rectangle as well to avoid effects changing as they clip against the viewport edge. Then in a C3 shader you can use a calculation like this:

    mediump vec2 tex = (vTex - srcStart) / (srcEnd - srcStart);[/code:1j3hmbyw]
which calculates 'tex' as normalised co-ordinates within the rectangle being drawn. Using the srcOrigin variants gives you normalised co-ordinates which don't change as it clips against the viewport, which is usually more useful for anything other than sampling the background. E.g. if your shader drew a circle from vTex normalised to srcStart/srcEnd, it would squish up as it moves off the viewport, but using the srcOrigin variants ensures it looks consistent. (The manual covers this, and some other useful patterns, in the manual entry I linked to previously.)

Unfortunately, C2 doesn't provide the necessary uniforms. We did a ton of work on the effect compositor for C3, and it took a great deal of time and effort, it's some of the most complicated code I've ever written. C2 has around 80 built-in effects and we managed to get by without these uniforms. At this stage it's unlikely we could add these uniforms back in to C2, it's incredibly complicated and time consuming, and we did it along the way while upgrading the codebase for C3. These uniforms are essentially a new feature of the effects engine in C3 allowing for more consistent and better quality effects. Still it should mean you can write these effects and have them work as you need them to in C3.

  • Well, that basically proves its an Intel graphics driver bug. You can try reporting it to Intel, but good luck with that, I've struggled to get any graphics vendors to pay attention in the past...

    I'm afraid we can't do anything about driver bugs ourselves, so closing.

  • Can't reproduce here, it's working fine, and I've not seen any other reports of this. Maybe try updating your graphics drivers, driver bugs often cause issues in C2.

  • The .capx link is invalid. Please provide a working link otherwise we can't investigate.

  • I've no idea. The best way to get help is to share a project. Removing third-party plugins is helpful too. And perhaps try waiting longer than 50 minutes for a reply

  • Well, as I said we plan to introduce a whole new feature anyway, so yes we will improve it and it should become a moot point in future.

    Fork-and-modify inherently causes compatibility problems, so if possible we should try to think of a way to extend existing addons from a different addon. Perhaps there could be a way to tag ACEs to appear on a different plugin instead, which receives the instance to operate on as an extra parameter, or something like that.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,831,030 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs