2019-02-23 06:28:44

So like I said, I'm working on a sound module that is easy and comfortable to use, at least for me. Here's a problem: BGT's sound pool is only useful for BGT. What I mean is this:
If you didn't know, BGT's sound_pool is basically a glorified array, or list if you're familiar with python. The methods loop through the list, updating the sounds based on the values given. That's not my issue. My issue is implementation.
In python, every time I'd want to use BGT version of the sound pool I'd have to import it. Can you imagine? Can you imagine how many update methods I'd call just for, say, 50 pits? As far as I know, I can't import a module in one file and force python to realize that yes, I'll be using the same damn thing in all my files without re-importing it, like I can with bgt. That'll mean something like this:
Say we have a player file, an enemy file, and a pit file. Every time I'd want to use sound pool I'd do
import sound_pool
into each file. The problem is that the sound pool will have 100 objects, and now I'd have to call the update_listener method 3 times in 3 different places, which would also probably break things. I have sound positioning functions written, that was simple enough, but I'm stuck on how not to make python loop through many different lists and not having the same code over and over and over.
So tips? Suggestions? I'm truly lost here. I don't know how to progress, and more importantly I don't even know where to start looking.

2019-02-23 11:41:47

You simply didn't get the object-related programming scheme here. BGT itself does it exactly that way, you need to include the soundpool but you also need to create an object of the soundpool class. Thats what you'll need to do in python as well, writing a soundpool class which knows the methods to modify it. that way each of your different objects (player, pit, map, whatever) will probably have its own soundpool, although that doesn't sound very useful to me, it'd probably best to only give the map a soundpool and put all the sounds relevant for the map into that one and update it as needed.
best regards.
hijacker

2019-02-23 12:53:47

Yeah, I'm really confused as to what you're confused about. #include and import are effectively the same. Python has stricter scope control, the module concept instead of just combining scripts, but from the perspective of porting the sound_pool, the only things that change are syntax, keywords, and the underlying sound engine. Half of that can probably be managed programmatically, since the only weirdness in the sound_pool file, iirc, is how member variables are declared (BGT didn't allow declaration and initialization in single statements when it was created). Porting the sound_pool should be more tedious than difficult. It's the sound object and its features that will be a pain. And if you use a sound engine with a built in listener / viewpoint / camera concept, you can probably ditch the sound_positioning functions, too.

(Yeah, yeah, I know there are technical distinctions between #include and import. Those aren't really relevant here. Instead of #include "sound_pool.bgt", you say "from sound_pool import *". Or just "import sound_pool", if you want to type more later.)

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2019-02-23 16:22:59 (edited by amerikranian 2019-02-23 16:26:34)

My problem is the following:
When I include a sound pool in bgt, I only do so once. Let's say we have a game.bgt, which contains the following code:

#include sound_pool.bgt
sound_pool p;
Now we have another file, but we don't need to include sound_pool in that file, what we can do is p.do this or that, and it will still work.
Of course, our game will need to do this,
#include file.bgt
But my point still remains the same. It will work, without me having to write the include sound_pool statement in file.bgt.

In python, every time I'd want to use the sound pool class I'd have to create a new object, destroying the point of a central sound manager class. I'll have multiple sound pools, each with their own list and sounds, and I'll need to call the update_listener methods god knows how many times. So that's what I'm looking for. A way to have an object be created once and be available to all the files without creating a different instance of that object. Is my issue clear? Am I just being stupid as usual?

2019-02-23 18:23:19

pick a module in which to create an instance of the sound_pool, be sure that the other modules have access to that one in one way or another. If you don't make it private to that module, you should be able to use it anywhere. Unless something changed recently that broke the things I've done that do this.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2019-02-23 19:12:37

I have noticed something and wanted to clarify. If you import a module 500 times that doesn't create 500 instances of said module. Modules get imported once and are further referenced later. You generally import a module in another file to preserve the namespace as clear as possible and use only modules you really will need in the file you are working on. About sound pool, I have no idea about how it is done in BGT, but you can try to do something like this in Python, that's generally how I tend to handle this:

# import all stuff to handle audio

soundpool = None

def setup():
    global soundpool
    if soundpool == None:
        soundpool = soundManager()
        # Initialize, load sounds, etc.

class soundManager(object):
        """ This would be the class responsible for everything related to sound decrypting, loading, playing and so on"""

Then, in the main file in the game, you just will need something like:

import sound

sound.setup()

And for calling your sound functions in the sounddpool it'd be something like:

import sound

sound.soundpool.play("somefile.ogg")

Of course you'll have to implement everything in the soundManager class.

2019-02-23 20:11:51

So I just wanted to clarify. If I import a module in 2 different files, will that create 2 instances of that module? Let's go back to our sound pool:
file 1: player.py
import sound_pool
file 2: pit.py
import sound_pool
Let's say, for simplisity's sake that I import my player file first. Would the pit file access my player sound pool when I import it, or would it create a new instance of the module.

2019-02-23 20:27:28

An imported module only  ever has a single instance. When another file imports a module, it's just given the reference to the already existing module instance.

Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic.

2019-02-23 20:46:24

OK, something else. Module instances are something different to object instances, that's something interesting about object oriented programming. Module instances are not important for your needs, what you are talking about is class instances. If you use the setup I posted earlier, you just need to call sound.setup somewhere in your program, and any other part of your code that imports sound, will use the same class instance, thus you will not create duplicated objects and all stuff.

2019-02-24 02:46:19

From what I recall, OpenAL has no limit on the number of sounds you can load, but has a hard limit on the number of sounds you can actually play simultaneously, which would be roughly 32, but more likely 31 in practice. So first you load your sound samples, then your 31 or so sound players, in this instance the available players not playing anything would be your "sound pool". So, you load a sample into a free player as needed and move it into an active list and then update those, when its finished you eject the sample and return the player to the idle sound pool to load another sample thats been queued. If you like I can put together an example of this kind of management engine.

-BrushTone v1.3.3: Accessible Paint Tool
-AudiMesh3D v1.0.0: Accessible 3D Model Viewer