oosyrag's Forum Posts

  • Use an instance variable to keep track of the state of the character, and set animations based on that variable.

  • Construct 3 has some improved handling of css and html layers that is different from construct 2.

    I don't know if this will help your issue in particular, but are you utilizing the following?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • JavaScript allows for conditional expressions. If you can't save a boolean as an expression, save it as a 0 or 1 value instead.

  • The developers are generally quite attentive regarding backwards compatibility - tutorials and concepts from years ago are still relevant. If anything, newer features might have made some things easier to do though.

    I do recommend utilizing the manual - it is kept up to date, well written, and is an excellent reference for whatever you're trying to do. You should also read through (up to before the references at least) it before getting started, it actually isn't very long and will save you a lot of pain in the long run.

    Try not to rely on tutorials too much - there are usually many ways to achieve the same result, and it's often better to try to do it in the way that makes sense to yourself rather than copying another person's logic that you don't understand. If you're constantly frustrated by things not working out how you expect them to or how everyone seems to do it differently than you want to, it's possible the engine is not the right fit for your style.

    As for specific tutorials, there are two official ones that should be more than enough to get you started.

    construct.net/en/tutorials/beginners-guide-to-construct-3-1

    construct.net/en/tutorials/platformer-game-2329

  • True = 1, false = 0

  • Try different browsers? This kind of reproducible issue will get handled more expediently if you file a bug report following the guidelines.

  • Funny how you need to think about design implications and do work to implement cool features.

    Thanks Ashley!

    The stepped function is cool too! I really appreciate it. I think small things like this that can replace a extra conditional event (getting rid of the exception to set 0 as mute) goes a long way to making things simpler for the user.

    One more minor suggestion while we're on the topic - recommend updating the tooltip when choosing the volume parameter for Audio: Play (and other places?). It currently states "Volume: The attenuation in decibels (dB). 0 is original volume, -10dB is about half as loud, etc." I think that tooltip by itself was another source of confusion as well - I know it led me to think ok, if -10db is half as loud (it wasn't), 50% should be -10, and if I want half of that half (because of my limited knowledge of dB), I'd need -20 at 25%... (also wrong) ect.

    I think it would be enough to say that it is the attenuation in decibels from 0 to negative infinity, possibly implying or explicitly stating the user needs to determine the lower bound (this might be TMI for a tooltip?), and note that the normalizedVolume expression is a thing that exists for it.

    Recommending the dynamic range lower bound to be -40 (instead of -50 or -60) due to the stepped function) in the manual manual entry for normalizedVolume() might be good too. I'm not familiar with how standard ranges are across systems though so explicitly recommending a value may or may not cause problems for some people? Although I can't imagine that literally every piece of software in existence that dealt with audio would have (or should, at the least) to deal with something like that.

    And why not make it so you can have it louder instead of just quieter...

    This is the dream for us laypeople isn't it? This really is a key point that can be hard to wrap your head around without prior knowledge. Unfortunately, that's simply just not how computers/operating systems work when outputting sound, as far as I've learned about.

  • Just make it two pieces, pin a slanted end sprite onto it.

    9patch would be suitable for this as well.

  • Use the lastkeycode expression on any key pressed to see exactly what key code construct sees, if any, when those buttons are pressed.

    Construct to map 0-1 to dB for you

    I think this would indeed go a long way to reducing confusion (as an expression would be a great step and backwards compatible as well). And I suggested earlier, perhaps actually allow the user to input a value outside the 0-1 range to address the new limitation of not being able to set the range and cutoff. Anything greater than 1 wouldn't have an effect and anything less than 0 probably wouldn't have a perceivable effect anyway.

    The more common problem I can foresee is users complaining about is they can't hear a difference between -50 and -40 db (0 to 0.2) because of too low volume overall especially if their system volume isn't maxed, but that would simply be a matter of starting adjusting the lowest volume to 0.2 before muting instead.

    Whether or not that's a good idea, it is still up to the user to choose. The user will still have control over the range in the end.

    In effect, this would basically assist a user define what 0 volume is (or rather what they should set as the lowest volume), which currently causes confusion.

    (Ed: I totally missed the part of the expression that allows for lower bound to be set. I hope there can be a default value if not specified, or at least suggested in the manual.)

    Unfortunately I'm sure there will also be those that will complain that 0 isn't actually silence either, as this doesn't address muting at the lowest setting so there might still be some misunderstanding. That's no different than how it is currently though, even theoretically at -100 db.

    Ed2: Also may I suggest "normalizedVolume()" as the expression if this is going to be a thing? "linearVolume()" might cause... confusion ;)

    Ok so I spent all night experimenting and reading about this topic. Ashley was right in the end, although I think it could still be made easier for the end user by using a 0-1 scale.

    From the Dr. Lex article, once again -

    I sometimes get mails from people who want to know how they should configure a hardware or software volume control that already uses dB values by design. Some seem to believe they still need to apply a non-linear transformation to the dB values. No! The only things you need to determine there, are the range you want to use and the step size if applicable. For instance if the volume control offers a range of 120 dB, most likely you will want to limit it to the upper 60 dB range. Some controls offer attenuation (negative dB values) as well as amplification (positive dB values), you need to determine if your application needs either or both.

    The key is to identify the lower bound - -50db in my case is more or less silent. This should be confirmed at the highest system volume available. If your lower bound is too low, then the lower parts of your volume settings will be imperceptible. My earlier (volumepercent*50)-50 is what I'll be going with moving forward.

    Here's another article from Microsoft. When the online articles talk about linear controls, they are generally referring to linearly controlling the voltage or power - which results in the undesirable perceived volume, or loudness, curve as seen in the first diagram. It illustrates the problem of minimal effect on loudness at the upper volume levels, and disproportionally large effect at the lower volume levels. Where we're at, since we're working with decibels directly in Construct, is the second diagram already, where the loudness in db is linearly proportional to the volume control slider position. This is the desired behavior. Again, the key is identifying the minimum loudness, otherwise a portion of your lower volume settings will be useless.

    So what happens if we apply a logarithmic function again to our decibel level in Construct? (the formula I've commonly consistantly found was 20(log10(v)). This would result in skewing the perceived loudness to volume position the OTHER way. That is, upper volume level adjustments would have a larger impact on loudness, but lower volume adjustments have a lower impact. While this is indeed skewed, it's not nearly as uncomfortable as the other way around since at louder levels we are able to hear more and discern more of a difference than when the loudness is very low. That's why some people have found using the logarithmic formula on the decibel setting acceptable or even preferable.

    tldr:

    1. Identifying the lower bound of attenuation is critical. I've found -50 to be a good result for my system at max volume, although lower system volumes result in differences in the lower end of the volume slider being hard to perceive, which is understandable.

    2. Using linear decibal attenuation values results in linear perceived volume, which is "correct". Using logarithmic decibal attenuation values results in skewed perceived volume, which might be preferable, but "wrong" - this can be considered overcorrecting.

    I've got an example project illustrating various approaches coming soon after I make it a bit more comprehensive and labelled.

    TLDRTLDR:

    Set your volume to -50*volumecontrol, where volumecontrol is a value from 0-1 and -50 is the point you don't hear anything anymore at max system volume. Mute when volumecontrol is 0.

    PS: After all this I still think it would be nice for Construct to apply this for the user as a 0-1 value. Although the ability for each user to determine the lower bound themselves would be lost, a whole ton of confusion is resulting from users not understanding where that lower bound is to begin with, or how or why they should identify it themselves. Users who want to apply a further logarithmic adjustment can still do so on this 0-1 value. If the ability to apply more attenuation than -50 is desired to be preserved, then allow negative values. Values greater than 1 would be capped at 1 anyway, since we can't have less attenuation than no attenuation.

    (Apologies in advance - I'm even getting annoyed at myself at this point for being confrontational like this)

    If I don't know the answer and you don't know the answer then is Construct really making it easy?

    After playing around [mute, -90, -80, -70, -60, -50, -40, -30, -20, -10, 0] results in the sound being inaudible after the 5th (down). Would it be like that for everyone on every system? So seems like the answer would be to set volume to (volumepercent*50)-50?

    Edit: (volumepercent*30)-30 seems to be better...

    Ok I guess I still don't understand...

    Let me ask a more straightforward question then since I still don't know the answer -

    If I'm making a volume slider in Construct with 10 (or n) steps, what should I set volume to at each step to have the lowest step be silent and the last step to be maximum or system volume?

    As a user, I sure wish I'd be able to just "Set volume" to "n" as a value between 0 and 1 and end up with a nice volume curve.