None of the necessary bits are exposed to Python, so you'd have to fork
Pygame probably. It might be possible to open a PR to add the feature
though.
On Wed, Jul 14, 2021, 18:41 Andrew Baker wrote:
> I'd assume that deep under the hood, one should be able to advance
> whatever read pointer to th
Sure, though I'm not clear on where that would be in the Python vs SDL
boundary. I'm not prepared to go spelunking for it either, at least until
I know I need optimization.
Ideally pygame's Channel api would be extended to expose this directly! I
don't have enough of a feel for pygame's release p
I'd assume that deep under the hood, one should be able to advance whatever
read pointer to the soundbuffer is used by the channel.
Is that correct?
On Wed, Jul 14, 2021, 15:51 Jasper Phillips wrote:
> Thanks Daniel, that works! Plus using soundarray should be faster than
> first converting to
Thanks Daniel, that works! Plus using soundarray should be faster than
first converting to raw.
So far I don't need to cache, but rollback netcode demands lots of CPU so I
suspect I probably will end up optimizing this to improve robustness vs lag.
A pity mixer won't let you start Channels partwa
Instead of using the raw sound binary data and winging the slice, I'd
recommend throwing things into a sndarray.
def clip_sound(sound, start_time):
freq = pygame.mixer.get_init()[0]
offset = round(freq * start_time)
arr = pygame.sndarray.array(sound)
clipped = arr[offset:]
ret
Alas, that is precisely what I did:
def clipEffect( effect, startTime ):
raw = effect.get_raw()
rawStart = int( len(raw) * startTime / effect.get_length() )
return mixer.Sound( raw[rawStart:] )
Depending on what sound effect I play the code either:
- Works fine!
- Horribly dis
