GM:S 1.4 audio_sound_gain's Timing

Discussion in 'Programming' started by Ragster, Aug 1, 2019.

  1. Ragster

    Ragster Member

    Joined:
    Jun 21, 2016
    Posts:
    16
    I was under the impression that functions that utilize milliseconds as timing are not synced to the game's speed. However, ever since I've started using delta_time to determine my game's speed, the timing of my audio is way off. audio_sound_gain takes way longer now. 8000 milliseconds seems to take a whole minute. I tried multiplying the milliseconds by my game's speed (which I shouldn't have to do anyway), but the timing was still incorrect (better, but still off). I noticed the timing also changes depending on if I have v-sync on or not.

    I don't think there's anything I can do to fix this problem per-se, as it seems like something wrong with GameMaker itself, however I was wondering if anyone else has had this problem and how they overcame it.
     
  2. spoonsinbunnies

    spoonsinbunnies Member

    Joined:
    Aug 24, 2018
    Posts:
    63
    my geuss is your trying to run room_speed at like 100000000 fps? the game will register that as the room speed as that ridiculous number even if the frame/step rate isn't actually running anywhere near that is your issue, yeah game maker isn't super delta time friendly or not in a way I know how to do well because of this, maybe one of the developers can tell of a true variable for the current estimated frame rate but that I do not know. If its nessecary I'd look into maybe having a counter that goes up based on the computers current seconds, that would at least give you the fps of the last second?
     
  3. Ragster

    Ragster Member

    Joined:
    Jun 21, 2016
    Posts:
    16
    Yes, my room's speed is set to 1000 by default. With V-sync disabled, I did notice that delta_time wasn't returning the correct time between steps... but if I'm not mistaken, the game's speed cannot exceed the monitor's refresh rate, right? My 144mhz monitor is usually limited to around 6900 delta_time, while with V-sync disabled it returned faster values like in the 2000's. So I figured keeping V-sync enabled would be the way to go, but as I said audio_sound_gain doesn't work correctly either way.

    I thought about making my own audio fading counter, yes, but I'm afraid it wouldn't sound smooth if it's just lowering the volume every step.
     
  4. TsukaYuriko

    TsukaYuriko Q&A Spawn Camper Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    1,536
    You don't do delta timing by increasing the FPS beyond any sane limits.

    You do delta timing by keeping the FPS at 60 (or whatever your game is designed to run at, or providing options to the player to set the FPS) and timing things relative to delta_time.
     
  5. spoonsinbunnies

    spoonsinbunnies Member

    Joined:
    Aug 24, 2018
    Posts:
    63
    people seem to have grown up with the idea that no game should have a fixed frame rate anymore, which considering triple A shooter titles on pc do this I understand, but in 90% of games going above 60 isn't nessecary.
     
  6. Ragster

    Ragster Member

    Joined:
    Jun 21, 2016
    Posts:
    16
    Delta_time is new to me, so I set up my game based on posts by other people that were using delta_time (most of them used delta_time with an abnormally fast room speed).

    So with a room_speed of 60, how can a game render smoothely at 144mhz? It doesn't matter if the player's sprite draws 144 times per second if it's position is only updated 60 times per second.

    This is kinda getting off topic but I'm curious on how delta_time really works.
     
  7. TsukaYuriko

    TsukaYuriko Q&A Spawn Camper Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    1,536
    I see. While it may produce results that technically qualify as "working" for this purpose, this method tortures the hardware of an unsuspecting player for no good reason. You're literally asking the game to absolutely, under any circumstance, max out the player's hardware's capabilities, until one of them creates a bottleneck.

    It does fulfill its intended purpose of keeping the refresh rate of the game at its absolute maximum, but it does so using an extremely unconventional and unhealthy wet bandaid of a workaround rather than a proper solution.

    It's a bit like like flooring it in the middle of traffic - it might speed up things (slightly, depending on how fast it's moving by default?), but you run the risk of ending up with a trail of wreckage left behind in your path... or with police and firefighters on your tail. (The firefighters part was only partially a joke... maxing out a PC's hardware over an extended period of time can easily lead to it overheating. Not that it'll catch fire or anything... unless it's extremely old or broken... maybe.)

    Oh, it does matter. It renders exactly the same way a game that runs at 30 FPS renders on a 60Hz monitor - at 30 FPS, with roughly every second frame displayed twice, at least without lag spikes.

    With that said, a higher refresh rate is not only relevant for the amount of different frames it can display per second. Merely drawing the same frame multiple times can help reduce some visual artifacts such as blurs and trials that are often (more) apparent in monitors with lower refresh rates. I'd even call this a more important aspect than the capability to draw more different frames per second, as you get to experience the benefits of blur and trail reduction regardless of the game's frame rate.

    That aside, this is why I mentioned to give players a choice regarding frame rates - if you wish to support higher frame rates, running the game at the respective room speed and adapting timing with delta timing should be the optimal way.

    To quote the manual, delta_time "measures the time that has passed between one step and the next in microseconds". It is therefore used to adapt any calculations or values that are otherwise relative to game time (movement in pixels per frame, amount of frames an alarm ticks down) to real time.



    With that said, does keeping the room speed at 60 resolve the audio issues by any chance? It shouldn't - as in, it should neither make it work nor break it either way - but just to make sure.

    When you say "ever since I've started using delta_time", you don't mean that you're factoring delta time into the 8000 milliseconds of the audio fade calculation, correct? The audio functions are by default based on real time, so applying a second layer of this would surely throw the timing off.
     
    Last edited: Aug 3, 2019
  8. Ragster

    Ragster Member

    Joined:
    Jun 21, 2016
    Posts:
    16
    Thanks for the details. I did not factor in delta_time for audio timing at first because, like you said, I shouldn't have to. I only factored it in when I noticed it wasn't timing correctly to try and fix it.

    I ran some tests using current_time while changing only a select few variables each build, and here are the results:
    Using current_time and audio_sound_get_gain, I found the times it takes for audio_sound_gain to reach zero:

    #1: [room_speed: 60; v-sync: off; v-sync alternate: off] results: 8333 milliseconds.
    #2: [room_speed: 60; v-sync: on; v-sync alternate: off] results: 8333 milliseconds.
    #3: [room_speed: 60; v-sync: on; v-sync alternate: on] results: 8334 milliseconds.
    #4: [room_speed: 144; v-sync: off; v-sync alternate: off] results: 9282 milliseconds.
    #5: [room_speed: 144; v-sync: on; v-sync alternate: off] results: 9281 milliseconds.
    #6: [room_speed: 144; v-sync: on; v-sync alternate: on] results: 9260 milliseconds.
    #7: [room_speed: 1000] results: audio_sound_get_gain failed to detect the audio reaching zero. Using a stopwatch, the fade time took roughly 56.26 seconds, or 56260 milliseconds.

    So, with a room_speed of 144 (my monitor's refresh rate) the timing is off by one second, and setting the room_speed to an abnormally high number seems to break the audio system, even though it uses milliseconds to determine timing. I don't really understand why.
     
  9. TsukaYuriko

    TsukaYuriko Q&A Spawn Camper Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    1,536
    That seems clearly unintentional... anything that's timed in real time should stay timed in real time, no matter the frame rate. There may be a slight delay in between the sound becoming inaudible and it being detected as silent in code, but that delay is certainly not supposed to be multiples of the original target time.

    I can't see any sort of linear progression based on your test results, so it's definitely not just accidentally stretching it out. If this is reproducible in an otherwise empty project, you may have to file a bug report, as this looks like it may be either a bug or an undocumented quirk of this function.

    Just about the only other thing I can think of is that the insane frame rate is killing your hardware. This may not give the underlying engine the time it needs to actually apply the fading effect (as this requires processing time slices). Make sure you have ample headroom with your CPU and GPU at your target frame rate, and if neither is maxed out or near 100% usage (single core - if you have 4 cores, 25% is maxed), consider it a bug.
     
    Last edited: Aug 4, 2019
  10. Ragster

    Ragster Member

    Joined:
    Jun 21, 2016
    Posts:
    16
    Sorry for the late reply.

    I'm looking into your suggestion about the CPU and GPU (I did recently get a new computer). I made a quick test project for anyone to try (GMS 1.4.9999):
    http://www.mediafire.com/file/7hc04hl3y8q27ye/Test.gmx.zip/file

    I noticed that if the room_speed is set to 1, the resulting fade time is exactly 8000, while other room_speeds increase the fade time.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice