Audio Virtual Time and Rhythm Game Development in Love2D?

[Pyuu]

I've been curious about this for a long while, but is it possible to have Audio virtual time (where you can get an accurate estimate of what time the audio is currently at while playing), and is it possible to make a rhythm game with input that is accurate to the millisecond with Love2D's standard libraries?

Now, if not, then what libraries would help with the creation of a rhythm game? Have there been any in the past?
it's been on my mind for ages.

[zorg]

There were some threads about rhythm games in the projects subforum, both commercially released and otherwise (i think).

Technically, [wiki]Source[/wiki] objects have a :tell() function that, if called with 'seconds' as the parameter, return the current time of a playing Source in seconds, though it will usually return a non-integer, meaning it has sub-second precision. (which depends on at least the sampling rate of either the file, or the openal device used by love, which uses the system default sampling rate, iirc.)

As for how accurate this may be, that kinda depends on a few other factors, mainly on how fast your love.update callback executes; if you have vsync on, it will undoubtedly trigger fewer times, meaning the playback positions will be queried less frequently, hence lowering the accuracy.

No vsync means probable graphical tearing, but a rate of 1000/s means that Source:tell will be able to give you back much accurate positions; do note that most humans don't have timings (lol robots) reaction times better/faster than 100-250 milliseconds.

There are ways to achieve a middleground, like implementing your own love.run that can run updates and draws separately, or you could thread the audio stuff, which i believe is possible.

In short, yes, it's possible, with löve2D's included features.

[Pyuu]

Thanks for the information
I might make a rhythm game test project later on the see if I can get it accurate and stable enough to play.
Does love.draw block love.update from being called? (if so, lag in the draw function could mean inaccuracies when getting input, which means I'll just have to be more efficient.)

[zorg]

Thanks for the information
I might make a rhythm game test project later on the see if I can get it accurate and stable enough to play.
Does love.draw block love.update from being called? (if so, lag in the draw function could mean inaccuracies when getting input, which means I'll just have to be more efficient.)

Tehnically yes; they're called sequentially, one after the another.

[Tanner]

Let's not kid ourselves here, if you want your game logic (and input polling) to run at 1000FPS then you're definitely going to need to put it in a separate thread at the very least.

Here's my advice, though: you should put together a quick prototype to figure out if you really need the kind of timescales you're talking about here. If you do, I'm not totally sure that Love is the right framework for you. You probably want something that isn't garbage collected where you have finer grained control. This is not to say that it can't be done in Love but it might be easier if you use the right tool for the job.

[Pyuu]

Well of course, Tanner. It's just a thought really. I have OpenGL and DirectX if I absolutely need to make one, :p it's just fun to think of what can and can't be done with something such as love2d.

[zorg]

You could take advantage of LuaJIT and use c-like vars/pointers/structures/arrays in a thread; there'd be nothing to garbage collect automatically that way, but i agree with Tanner about prototyping first.

[Pyuu]

I could probably have a proof of concept in the next week. Busy schedule though. If you take a look at osu!'s timing, you'll find that the strictest timing clocks in at 13ms, so a good 200-240 FPS would be a good aim for a "prototype." (which is very doable on modern machines afaik)

How does garbage collection affect this type of project? Is it lag or...?

[Sulunia]

I could probably have a proof of concept in the next week. Busy schedule though. If you take a look at osu!'s timing, you'll find that the strictest timing clocks in at 13ms, so a good 200-240 FPS would be a good aim for a "prototype." (which is very doable on modern machines afaik)

How does garbage collection affect this type of project? Is it lag or...?

Eh, as someone who messed a bit with rhythm games and love2d, i can say it's a pretty good platform, good enough for a nice prototype.

The last rhythm game i made on love2d ran @ 300FPS on a low end machine, so you'll get these framerates assuming you know what you're doing.

Lua's garbage collection is quite fast, and if you have troubles with it, you can disable it ingame and enable it back on menus and such.

Also, to pretty much kill any timing issues, use interpolated timing.

Fair warning though, if you're trying to implement controls as tight as osu! does, then you'll probably have troubles on love2d. It can only go so far without separating threads for input/video (exactly what Tanner mentioned above), so, consider this if you become unhappy with prototyping results.

[Pyuu]

Thanks Sulunia. Interesting that you've made a rhythm game on Love2D, can I see what it looks like?
A problem I'm going to run into is that I'm not very good with optimization (as I haven't learned it yet.) I usually just use canvas' to minimize draw calls.