Ashley's Forum Posts

  • The compositing mode option caused several other bugs. We don't want to support it because of all the other problems it caused. The problem here appears to be a bug in AMD's software, so they'll need to fix that - it's out of our hands, and working around bugs in other company's software by reintroducing a mode that causes a bunch of other bugs is not something that it's tenable for us to do. As ever the best approach is to go to the root cause and get it fixed there.

  • You do not have permission to view this post

  • newline is a Construct expression. Those cannot be directly accessed from JavaScript.

    In JavaScript, if you want a string with a newline in it, use "\n".

    • Post link icon

    I think based on what oosyrag wrote, and what I was also explaining, using dB for volume is the easy intuitive way to do it.

    If Construct has a 0-1 linear volume, then either your volume control works wrong (nonlinear perceived volume), or you have to do some complicated logarithmic math to get a linear perceived volume (e.g. doing the dB conversion yourself, or some other exponential formula). As oosyrag pointed out there is a simple linear calculation you can use when the units are dB.

    So if you think linear 0-1 is actually the simple intuitive option, are you saying you want a nonlinear perceived volume - which AFAIK no other software does - or that you want to do the logarithmic math yourself - which I wouldn't describe as the simple or intuitive thing to do?

    Or if you want Construct to map 0-1 to dB for you, then surely someone will want to control the dB range and cutoff, so it actually makes it a more limited option.

    Perhaps all we need is an expression to map 0-1 to dB for you - e.g. linearVolume(-50, x) will map x as 0-1 with a -50 dB range/cutoff.

    • Post link icon

    I'm not sure what the standard approach is, because I don't know what every software developer in the world has done with their volume slider, but I would say an easy solution is that each step is a lower amount of dB, with a special case for the bottom one being -Infinity dB (or just enable mute). Maybe -10dB per step will do it, I don't know, I'd just play around and come up with something that seems right.

  • It looks like you were exploiting the lack of proper encapsulation in JavaScript to use undocumented and unsupported APIs. The addon is already at risk of breaking at any time. We had a big red warning in the documentation saying not to do that.

    This is the very problem we're trying to solve with the Addon SDK v2 - you should not have done that, we said we wouldn't support anyone doing that, and that support for such features could be removed at any time.

    You'll need to find a new way to do this in the Addon SDK v2, or submit a feature request.

    • Post link icon

    I'm not sure you've understood the point. By working in dB, Construct makes it easy to have a volume slider that works properly. If it worked in 0-1 scale, then you'd need to look up all the logarithmic math to make a volume slider that works properly, because volume sliders that work properly use a dB scale - even if they label that as 0-100 for the user.

  • So your first port of call should be: report the issue to Google and ask them to fix it. Only use a workaround in the interim until Google fix the problem, and then remove the workaround.

    Even if Google remove the app, you should object, and tell them their ANR measurements are incorrect and that they are not cause to remove the app.

  • textInstance refers to ITextInstance, which has a text property. So you want to write textInstance.text = "score";. If you're not sure about how to access object properties, I'd suggest going through the Learn JavaScript in Construct tutorial series which covers this.

    • Post link icon

    Construct and Audacity are the only pieces of software I’ve used that has decibels. I’ve certainly never played a game where volume was anything but a percent.

    I think that, just to confuse things, most software actually uses a dB scale for their volume sliders, but label it as 0-100. Most normal users don't know what dB means so presenting a dB scale slider as 0-100 is easier to understand and still works in terms of perceived volume.

  • Construct expects global variables to be strings, numbers or booleans. Don't assign objects to global variables or it will probably crash Construct.

    Construct's 'Play audio in background' just means 'don't deliberately pause all audio when going in to the background'. If you play audio with JavaScript then you are working with the browser directly, and Construct is not involved in when audio playback starts and stops.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Why can't you add this to the construct panel?

    Because your workaround might be worse. If it is taking several seconds to load the app before Construct is ready to display anything at all, and you disable the splash screen, then the user will open the app and see a blank screen with nothing happening for several seconds. They might think the app is broken, close it, and then uninstall it. The splash screen is vital feedback to say "this app is open and working, wait a moment for it to load".

    So long as the loader style is not "none", Construct should be able to hide the splash screen very quickly anyway. All it has to do is load the core HTML and JavaScript file and then it will hide the splash screen and switch to its own loader. I have no idea how that could take more than 1-2 seconds, even on a weak device. So part of the problem here is it's not clear what's actually going on that causes such a long delay on the splash screen.

    If you just hack around stuff without dealing with the root cause problem, it often makes things worse, or allows the situation to deteriorate further until it can no longer be worked around, and then you're really stuck. The problem appears to be at least in part that Google are incorrectly measuring splash screen time as the app not responding. This ought to be reported to Google as a bug that they need to fix. The more people who report it the more likely they are to fix it. If they fix it then the situation will be improved and you won't need to do hacks to work around it that might cause users to think your app is not working and uninstall it.

    FWIW enabling AutoHideSplashScreen just means "hide the splash screen on a timer". The time delay is SplashScreenDelay, which defaults to 3 seconds on iOS, or when onPageFinished is triggered on Android, according to the documentation. If Construct finishes loading and hides the splash screen before this time, it will have no effect. If you configure this and it hides the splash screen before Construct finishes loading, the user sees the splash screen, then it disappears and they're looking at a blank screen doing nothing again; once again they may think your app is broken, close it and uninstall it.

    So I guess you can do that if you want but it doesn't seem like it actually makes the situation better for actual users. Basically you're showing the user a non-responding blank screen to try to work around a measurement bug that affects numbers shown on your dashboard that customers never see. Are you sure you want to do that?

  • Construct already automatically hides the splash screen as soon as it is ready to show anything. If you want to hide the splash screen ASAP, the important thing is not to use loader style "none", which shows the splash screen until the entire project is loaded (hiding any loading progress). FWIW the root cause problem here appears to be Google measuring stats incorrectly, so for a real fix, ask Google to fix that.

    • Post link icon

    I think it would be misleading to call that option "percent". If there's another mode, it should just be the 0-1 value that goes directly to the Web Audio API, and then you can use your own formula if you want.

    I'm not sure what every software developer who has ever made a volume slider has done, but I would guess there is either a special case for volume slider 0 = -Infinity dB (i.e. at the very bottom it becomes a mute), or a very short linear ramp at the very bottom of the scale, or perhaps some other exponential formula that ends on 0. I think just special casing 0 = -Infinity is a reasonable way to handle it.

    • Post link icon

    I think dB is a better unit for volume because it better matches how human hearing works, as the human perception of volume is not linear.

    For example -10 dB sounds about half as loud (note that perceived volume is different to the actual sound power), -20 dB sounds about the same amount less loud, -30 dB sounds about the same amount less loud, and so on.

    If you work in percentages then that goes 31.6%, 10%, 3.1%. I don't think that's very intuitive - the percentage changes are wildly different but the perceived change is about the same.

    If you make a volume slider that works in percentages then you'll find the top half of the slider seems to do very little, and the very bottom end of the slider does very quick changes, which makes it harder to control low volumes. If the volume slider is in dB, then it works more like people expect it to. If you ever see volume controls in software, they are very likely working in dB - usually the linear scale with all the control really happening at the low end is seen as a mistake. Similarly if you want to fade in audio, it's better to fade it linearly in a dB scale for a natural increase in volume. Otherwise you get a similar problem to the linear volume slider: the volume very quickly increases to nearly full volume, and then the rest of the fade time it only gets very slightly louder.

    So really you should generally be working with volumes as dB all the time anyway. Can you give an example of when you'd prefer to do something with a percentage volume?