Anyone got any tips on how you are supposed to get a small soundtrack (.ogg or whatever) to loop cleanly?
Having: @soundtrack.play unless @soundtrack.playing? just isn't cutting it inside update function. It sounds awful when you've built a nice tiny soundtrack loop that isn't supposed to skip a beat. Well, I understand that you can't predict when the update loop will be around again I guess but have any of you out there solved this one yet?
All I could think of was to attempt to start again on the 'beat' by calculating the BPM of the soundtrack and syncing up its starting and (hopefully) replaying to the internal pulse of gosu.
Byjlnr (dev)
Date 2009-01-12 10:14
Edited 2009-01-12 10:16
It's on the To Do, ... and I've moved it up again ;) The next release was supposed to help with real-life problems anyway.
What you could probably do is turn it into a tracked music file (.it or so, using e.g. ModPlug) and set it to loop. Gosu should respect that, but it's a rather clumsy workaround :)
Hey.. that's a great idea for a temp fix, thanks! What I did for the Monorail game was since it was supposed to be a short level per the compo requirements, I just made my loop file larger then the level length... ;) Used up more disk and transfer space of course, but fine for a quick deadline fix.
I'll have to check out that mod plugin you've mentioned.
P.S. good chatting to you in the #ludumdare channel this past weekend about Gosu, thanks for you help!
Byjlnr (dev)
Date 2009-02-06 15:52
Edited 2009-02-06 15:54
I'll just recycle this thread to because the Monorail game also had this timing glitch that we were talking about on IRC. Due to Gosu only using a millisecond timer, the loop always waited 17ms between ticks and that seems to have added an extra frame every now and then. Your fix is use a value of 16 (that will be rounded to the desired 16.6667 by the vsync) seems to be a great workaround even after I've taken looks at some alternatives. And when vsync is broken, the game will still run at about 60fps, which should be less of a problem than the ugly tearing ;)
I don't know if I'll ever support games that run at more than 60Hz (which currently is only possible on systems with broken vsync). For now, I'll just truncate the update_interval argument on Windows and try to get vsync to work on more drivers, which seems a much more pragmatic solution.
Just thought I'd let you know, so if you release another version/game after 0.7.12 is out, you can just use the default value again :)