Re: going about developing a rythem game
@12
I have a sighted friend who plays rhythm games and is also a programmer (though admittedly not a game programmer) and she says whatever she plays is accurate to around a frame (which is around 16MS). Things that are full body movement style stuff will have to be looser if only because legs and whatever don't respond that fast. Human response time is much worse than keeping in sync with rhythm, and I think that actually we're better at audio rhythm than visual rhythm (but sighted people only get the visual aspect). I don't know of any research being done on the topic.
Things like AMD True Audio don't (to my knowledge) use shaders, as shaders aren't flexible enough for audio in general. Also I have yet to be impressed with one of the demos of that tech: it's great if your problem is "Hi, I am a lazy sighted game developer and I want you to autocompute this by raycasting" but doesn't do much beyond that. Really it's just a trick for computing very long impulse responses off level geometry and applying them in parallel. I've done research on this topic--indeed for a brief time I was considering making synthizer use the GPU, and I believve I have a GPU-ized parallel FFT somewhere--but for the actual synthesis part you're better off not dealing with with it.
I think that the audio on the GPU stuff is mostly hype: the people doing the GPU stuff already knew how because 99% of the math for modern graphics and the math for advanced audio effects are the same (literally, not exaggerating in the slightest). So you've got an easy to maintain thing that takes some of the "and now you have to configure your reverb probes" out of the level design, and when you convince game devs to use it their players will buy better laptops with your GPU in them.
But you can actually prototype such things in Python with Numba and Cuda, if you want. They won't help you with your rhythm game, and indeed they won't help you with almost anything that's not do a bunch of raycasting off level geometry. But you can do it, and I've done it myself as part of determining what might work for Synthizer. The irony is that Python is actually almost better than C/C++ for GPU compute because of the ecosystem and the science people needing it--it's not going to be low latency because of the data transfer, but you're going to be hard pressed to beat what Numba or Tensorflow or etc spits out with a hand-written Cuda kernel, and if you wanted to prototype something audio before porting the algorithm to C/C++ for the final version you absolutely could.
However for anyone here, frankly just setting reverb parameters gets you a reverb of around the same quality of insert-GPU-audio-solution here, a really basic algorithm that figures it out by estimating how many open tiles are around the tile in question can get you something good without requiring a beast of a machine or you tweaking every tile, and none of that will help solve a rhythm game problem anyway. Rhythm games aren't performance, they're timer precision, in an environment where everything that isn't the rhythm game is competing with you for system resources, and the OS hates you because high precision timers suck battery like a vampire.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
