Ashley's Forum Posts

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

    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.

  • 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.

    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.

    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?

  • It's much easier to help if you share your project file. But from just looking at that code, it looks like textInstance refers to an ITextInstance. That's a whole class - you can't just assign a string to it. You probably meant to assign the text property instead.

  • Whenever I try it, offline support works. I just tried it again and it works for me. Usually whenever people complain about this, it turns out they're making some mistake, such as not waiting for the "ready to use offline" notification, or using browser privacy settings that prevent Construct saving itself for use offline.

    If you run in to a problem with offline support please file an issue - but note the steps to reproduce need to include clearing your browser cache, loading Construct, waiting for the "ready to use offline" notification, and then proceeding to reproduce the problem.

  • Again, the manual entry describes that:

    colorRgb ... An array with 3 elements specifying the red, green and blue color filter of the instance, with color values as floats in the 0-1 range.

    Using floats in the range 0-1 is how GPUs actually process the data. It makes many color calculations work more easily, and works regardless of the actual color data being processed. For example when using colors in the 0-1 range, the multiply effect is literally just "a x b". If you use colors in the 0-255 range, that is very much specific to 8-bit unsigned storage - e.g. 10-bit storage would use a 0-1024 range instead - and doing "a x b" will process an entirely different type of effect that isn't really useful - to get a multiply effect with the result also in the 0-255 you'd actually have to do "round(((a / 255) x (b / 255)) x 255)".

    So basically everything in computer graphics uses colors as floats in the 0-1 range as it works a lot better, and so does Construct.

  • Remember to think about the inherited classes. The ISpriteInstance manual entry states it derives from IWorldInstance, which in turn states it derives from IInstance. So all the properties and methods covered in all three manual entries are available for Sprite instances. (This is the standard way object-oriented programming works in a range of languages.)

  • Don't guess -look in the manual to see what methods and properties you can actually use. In this case you want the IWorldInstance property colorRgb, e.g. to set a red filter: 

    inst.colorRgb = [1, 0, 0];

    You might also want to take a look at using TypeScript which provides precise autocomplete and error checking to help catch mistakes like the one you made.

  • You can diff the JSON files for the event sheets. I realize it might not be too easy to read but it will show things like where additions, changes and removals have been made.