Post 2.0: Pygame needs better resource loading

[charlesej]

Creating a separate issue for this item originally from issue #417.

discuss making a pygame.sound.load or something like that which is similar to pygame.image.load. It makes sense to have a similar name for loading images and sounds.

Related Docs: https://www.pygame.org/docs/ref/mixer.html#pygame.mixer.Sound https://www.pygame.org/docs/ref/image.html#pygame.image.load

[nthykier]

AFAICT, pygame.mixer.Sound appears to have a similar interface to what is needed here. So the pygame.sound.load could simply be an alias of that (and be written in pure python).

This makes me wonder if we should make this a good first issue?

[illume]

It's potentially a really good idea... and a good PR from @MyreMylar at #1888 At first glance, I like the symmetry to pygame.image.load, and I also like avoiding typing the capital letter in pygame.Sound('blah.wav') (but don't really like having to type the extra '.load' part).

However, I'd prefer not to add new APIs (in general) at the moment, and not resource loading ones in particular. After pygame 2 would be the time to add new resource loading APIs IMHO. Even though we've broken this rule before, and recently. On reflection we should just try not to add new APIs at the moment.

Mainly because they tend to take quite a while to get right. They should really be discussed and tested widely, and proven in real game code. We have to support them for a long time, and without a lot of thought mistakes can creep in. But also because we have a lot of other features which can in from pygame 2.1. We have some new features which several months later are still untested with problems. With some other recent feature additions taking quite a while to 'get right'.

The sound namespace being otherwise is a bit weird. Some alternatives to this might be:

pygame.sound('blah.wav')

Except we already have pygame.Sound('blah.wav'). So now we have two ways to do it?

The term 'load' is used in the image module now, but is that a good name even? Why should people have to know what the word 'load' does? Newbies especially might have never heard the term load before.

from pygame import * will now import a sound? But isn't that a widely used variable?

There are a dozen libraries which work to bring a nicer higher level interface to pygame resource loading. These solve in various ways different problems the pygame resource loading APIs have. From snäke to pygame zero to pgreloaded, and other ones going back as far as from the year 2001. There's a lot to learn from them.

Some other issues with pygame resource loading that should be considered for an overall solution to cleaner more elegant sound loading...

• handling case sensitivity. Most who release games on other platforms get tripped up by Cat.jpg not being 'cat.jpg'.
• loading from zip files is perhaps harder than it should be
• recursively searching folders, and searching multiple paths at once.
• Loading from multiple threads/processes for performance isn't supported well.
• loading from separate processes for untrusted images isn't supported that well.
• async and stream based loading aren't supported well out of the box
• loading into existing memory buffers is required for some applications, and constantly allocating Surface memory all the time is really not possible.
• unloading resources in the main thread can cause giant pauses. Being able to remove stuff in background threads would be very useful for many games. De-allocating giant Sounds and Surfaces can take significant time.
• there's no high level API. Why do I have to do a whole dance for loading, rather than just using things?
• why isn't image loading into sprites, or things like pygame.video.Image/Texture? Do we want to keep people loading into surfaces, when some might just want to use high level stuff, and others might want to stream directly into textures?
• hardware loading isn't supported (most systems include hardware jpeg loading for example)

There are other needs and issues with pygame resource loading, but this gives you some idea of the topics that need consideration in new resource loading APIs. If we add new APIs now, then such things are not considered even though there's a clear need (because dozens of libraries and games implement their own solutions to these problems).

For this topic, I'd prefer to hold off till pygame 2.1, and have any new API be proven and address various needs that we've offloaded to higher level libraries.

[MyreMylar]

I have no real interest in whether this gets added or not, just trying to tick off as many issues as I can to smooth the path of pygame into the future - and this one looked relatively easy.

I'll close the PR.