Dalal's Forum Posts

  • fisholith,

    Thanks! I think your suggestion to move them to the Sounds folder works best for me. I tried it out and it does do what I want, but I'm just a bit concerned.

    Aside from the difference in streaming, are there any other playback differences with sounds and music? I'm assuming it's just a psychological effect (i.e paranoia), but the music sounds a bit different when played as a sound. Please quell my worries and tell me I'm hearing things

  • When I lower the "playback rate" of a sound, it slows it down, affecting both pitch and speed.

    When I do the same for music, however, it only affects the speed, which is unwanted in my case.

    How can I make it so that music is affected the same way as sounds are?

  • Does this mean anything for CocoonJS (which uses V8)? How about Crosswalk?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ah cool, thanks for this perspective. You're right that what we have is astounding already, quite a feat. As a C2 fan, I merely seek to help improve the engine, though obviously I have very little knowledge of its inner workings. That's where discussion helps me.

    First is that what you are looking for is a change on how the sound is rendered, by the system, not a change in the C2 engine, or better described as a hack.

    I think I get where you're going, but I don't see it as a change in how the sound is rendered. In a C2 game, if you were to fade an object out before destroying it, is that a change in how objects are destroyed? You are merely using the system how it's supposed to be used to achieve a result more useable within the scope of your product. Put another way, just because there is a System.StopAudio() doesn't mean that MyGameEngine.StopAudio() is restricted to solely calling System.StopAudio(). There are specific needs the game engine has, among which are aesthetically pleasing audio playback. I am suggesting a change in C2's Audio > Stop, not the system's core implementation of audio rendering.

    [quote:2u1jdq9c]Second, the kind of timing precision you want isn't there, especially on mobile. You'll be lucky to get 0.1 ms.

    Yeah, I didn't think of this too much. "0.1 ms" precision? That doesn't sound too bad for a fade-out that must occur in less than a frame of 16ms. Honestly, anything to reduce the harshness of the click is beneficial I feel.

    [quote:2u1jdq9c]Thirdly, this is why we have polyphony.

    Haha, yeah but there is still a definite need in games to stop certain sound samples from overlapping, just as there is a need to prevent certain images from overlapping. You wouldn't say "that's why we have layers". There is obviously such a thing as aesthetics, and it can apply to audio just as much as it can to visuals.

    [quote:2u1jdq9c]Also theres nothing wrong with using an even shorter sound for that type of situation.

    The sound in the demo was exaggerated to demonstrate the effect. Consider a real game like Super Mario World when he's flying through a bunch of coins. Look at how neatly the sound effect repeats for each coin, how it cuts off the previous one. Even if they had the full polyphonic capabilities of today they wouldn't have let them play together. Letting those sounds play together creates this muddy kind of reverb-y, sloppy sound, characteristic of amateur fan-made platformers. It's very disgusting. A shorter sound is not the solution, or the coin wouldn't have the rewarding effect it does when you get one. I mean, come on, unless you're just a programmer, you know that game design and development is art! And artists are picky people. Lots of subtleties to think about. The engine shouldn't require us to make compromises on something that can be fixed.

    Anyway, I'm up way past my bedtime. Perhaps the -100db solution is fine. But hopefully this is something to think about, because there is basically no reason I see for someone wanting the risk of that click when they call Audio > Stop.

  • Try using the "Make Seamless" filter in GIMP.

    http://cgcookie.com/blender/2014/04/15/ ... ures-gimp/

  • I'm looking for the pirate princess on this website. I found the second clue and opened the page which I suspect contains the third. Now I'm stuck.

    Before I rack my brain, could someone give me a definitive answer on whether or not she's still here? Or is she missing?

    Thanks!

  • TiAm, holy shiz! I wasn't a believer, but you've converted me. I definitely see the difference in Chrome (60 FPS event-based recyling, 20-50 FPS without it). And this is on my development PC which is quite a beast (at least per my standards). After reading the articles about garbage collection I figured it'd be a waste of time to recycle objects beyond what C2 already does behind the scenes, but this has me convinced otherwise. Looking forward to seeing where this discussion leads!

  • newt That workaround works fine for this demo, but not in more practical applications (see below). While workarounds may work in certain cases, my intent with this post is to explore whether 'Audio > Stop' should do it on its own. Why so adamant on finding an event-based solution when this is something that should work right out of the box? Between a stop that clicks, and one that doesn't, which one falls more in line with the expectations of the game developer? Which one is more useable? It's obvious that the 'click' noise is unwanted and unexpected. Shouldn't we consider this suggestion as a way to improve Construct 2 functionality?

    In the case of the demo, the workaround you posted is simple and manageable. But now consider a more practical use of Audio > Stop: preventing the overlap of similar/clashing sounds, like collectibles. Imagine Mario running through a bunch of closely spaced coins. "Ding ding...d..d.d..d..d...ding" is what it should sound like, rather than "Ding ding...d *pop* d *click* d *pop* etc." That sounds unpolished, glitchy and unprofessional. Granted, for many sounds the popping is subtle and big pops only happen once in a while. But that inconsistency alone is troubling.

    Check the event sheet in the attached .capx. The solution that would ideally work is to simply stop the previous sound, then play a new one. The workaround you posted almost works, but it plays the sound 0.02 seconds late because of the Wait, which is not the desired game experience.

    The workaround that actually works requires a variable that toggles between two values. Now we can stop the previous sound in a neat way but immediately start the next sound. Kinda ugly, but it works. But now let's say I have different kinds of collectibles. It complicates things a bit more, and ends up obfuscating the events more too. And really, all we want is to stop a sound without that unwanted click.

    So now consider my main points:

    • Audio > Stop doesn't imply anything about audio 'clicking'. It is most certaintly unexpected behavior. The click is usually an unwanted addition to the sound.
    • It is hard to imagine a case where someone would desire the 'click', especially because its very inconsistent, and shouldn't be there in the first place.
    • Workarounds using events are not straightforward. The cleanest approach is to modify the Audio object with a micro-fade.

    Does the above not seem to you a compelling enough case to at least consider changing the 'Audio > Stop' action? I would like to at least discuss the feasibility and implications of changing it. I understand that sometimes people post suggestions when they want something very specific to work in their game. This is not the case with my suggestion. This is a somewhat common issue in multimedia work. In music production, for example, when a sample is chopped out of a wave, a slight attack and decay will be added to get rid of the clicks. No one wants the clicks! I don't think game development is any different.

  • In case the example is hard to get to, I've attached it to this post.

    newt Events update per frame, whereas the "micro-fading" I'm talking about has to happen in 2ms. Let me clarify that the point is to prevent the high-frequency click that occurs when a sound is stopped midway through, not to modify the original sound in a perceptible way. It's not a "fade" so much as it is a better algorithm for stopping the sound. The current algorithm basically adds a click to the sound. The one I'm suggesting leaves it as it is, not to mention that it indeed stops well before the next frame. Which one behaves more as expected?

    Naturally, I feel the native Stop action should have this 'smoothening' behavior by default, because I can't imagine a scenario where this inconsistent click would be desired in a game, can you? As it stands, it feels more like a bug. It's only if there are reasons to leave the method as it is that I would suggest a "Fade Stop" action as an alternative to allow people to avoid those pesky clicks.

    I read a post from 2010 from someone encountering this issue in Unity (I wonder if it is fixed now). The solution suggested was to write a routine that fades it out in 1/10 of a frame. That's exactly what I think Construct 2 should do natively, because it's the only way people want to use 'Stop'. To do that in Construct 2 right now, I would have to modify the Audio object (and I would do a sloppy job of it), and this will put me out of sync with future updates.

    If this is as common an issue as the person in the post suggested, and if people everywhere end up writing their own micro-fade routines to fix it, why not just make it native functionality in Construct 2? To me I think the Audio: Stop method is less useful if it doesn't behave the way most people would like it to. How many people expect there to be a click when they stop their audio? That's not what 'Stop' is supposed to do in games!

  • I feel that the Stop action of the Audio object isn't quite fit for games because it abruptly cuts off the waveform, causing an undesirable click or pop [example], at least when using the .m4a format. Most audio players and editors use inperceptible micro-fades to prevent/reduce this artifact. If possible, I think Construct 2 should do the same.

    Unless you work with audio a lot, the 'click' hardly feels like the natural result of stopping a sound. It's not what is expected of a Stop action. The click is literally CREATED when you cut off the audio, because the waveform does a straight line back to 0. Why should something be added to the audio that wasn't there originally? And what is the use of this inconsistent sound in games? That's why I think micro-fading the audio is like a higher quality 'stop algorithm' with more natural, useable results. The final thing you hear is the original sound itself, rather than a sharp click. That seems much closer to the behavior we expect.

    In any case, if the current method cannot be changed, may I suggest creating a 'Fade Stop' action as an alternative? This would fade the audio down to 0 through a specified number of milliseconds before actually stopping the sample. This I feel would have more uses in games over the current stop method and I believe it would be a worthwhile addition to the official Audio object. What say?

  • I don't know how to enlarge the cursor. When using a custom cursor, however, I don't think you'd need to write any color changing code. Just put the "Difference" effect on it.

  • I haven't used the behavior before, but I do fades like this normally:

    If Object is Overlapping     |  Set Opacity of Object to Object.Opacity - 1000*dt
If Object is Not Overlapping |  Set Opacity of Object to Object.Opacity + 1000*dt
[/code:1m3t3yey]
The first line says that if the object overlaps, keep subtracting from its opacity (fade out). The second line does the opposite. It keeps adding to its opacity (fade in). Replace 1000 with the speed of your fade.

  • Glad you were able to figure that out!

    I think a reasonable approach would be to have an instance variable for each action. Assuming a two-button game where you can move left and right, you might add the instance variables "leftButton" and "rightButton" to your "Player" family's instance variables. These variables will store the key codes for each action.

    Continuing this example, you could set P1's leftButton to 37 (which is the left arrow key) and the rightButton to 39 (the right arrow key). You could set P2's leftButton to 65 (which is 'A') and the rightButton to 68 (which is 'D'). Once each player on screen has a different set of controls, the following event logic will work to control the players:

    For each "Player"
   Key Code Player.leftButton is down   | Move "Player" Left
   Key Code Player.rightButton is down  | Move "Player" right[/code:2xcz1gqh]

Basically it's asking each player what their button for a particular action is, then checking to see if that button is pressed. if it is, then do what needs to be done to that Player to execute that action e.g setting animations, moving the player, etc. In this manner, you can assign all of your controls.

That's the basic approach. There could be a better one, but this might give you some ideas.

  • Look into Families. Create a Family called "Player", and then set the animation of "Player" to Idle, Run, Jump etc. You might need a "playerNumber" variable on the family so you can assign different controls to each player.

  • Could you give an example (pic or video) of the menu you want to make?