Asking this query as a result of I wish to implement performant sound dealing with on weaker methods. Whereas specializing in such methods are a deadend since everybody has quick gadgets, I nonetheless wish to do that as a programming train
When enjoying video games such because the Want For Pace collection on the PS1 and PS2 (and all their contemporaries), I seen the sound high quality of the engines will not be as dangerous as one would count on. Working example being NFS Underground 2 which was a large improve over its predecessors
I’m taking these methods for instance since they don’t use FMOD to the very best of my data and since nearly any pc in use immediately ought to be stronger than the PS1 or PS2 on the very least
With my expertise with racing video games on the SNES, understanding how engine sounds labored had been straightforward. The DSP on the SNES’s audio chip might change the pitch of samples performed in {hardware}. All you wanted had been just a few samples (extraordinarily quick ones by the best way), and the DSP would deal with pitching it up and down extraordinarily quick
When getting into the fifth and sixth era, we by no means actually had the potential to depend on {hardware} quirks like this, particularly as video games had been being developed for Sony, Microsoft, Sega, Nintendo and PC all on the similar time
From what I perceive, the present strategy on present era methods is both to report engine sounds at varied rpm ranges and have FMOD or another comparable device to deal with enjoying and pitching these sounds in actual time, or utilizing granular synthesis (one thing I do not notably perceive properly)
Doing equally on fifth and sixth gen methods by altering the pitch of 24-48khz samples in real-time would’ve been extraordinarily taxing on fifth and sixth era methods from what I assume. On that matter, to forestall aliasing because of low pattern charges, you’d have needed to report your samples at 48khz and as much as forestall any nasty aliasing from pitching up your sounds, so the methods needed to crunch via extra samples inside a specific timeframe, to not point out doing ALL of this on CPU
So very clearly, these methods had been NOT utilizing these strategies merely due to how sluggish they’d be for such methods. In order that possibility is ticked off too
So what strategy am I left with then? I am unable to use FMOD, nor can I depend on {hardware} pitch shifting, assuming I’m working solely on PCs, the place I am unable to use a useful DSP
