Next topic

[sorlok_reaves]

Good evening,

I've got a development-based question about the "None" audio backend. Would it make sense to add empty initializations of "sound_add", "sound_play", etc. to this backend? In other words, "sound_add()" would check for the file and return an id, sound_play would take that id and do nothing (no sound). Basically, this would allow developers to compile games that use audio functions without actually linking to an audio backend, which is useful for debugging, performance testing, and other things.

If this doesn't really belong in "None", what about a "Mute" backend that does what I described? I'm comfortable implementing such a system, but I thought I'd check first.

[Josh @ Dreamland]

I think I'd go "Mute," between the two. The point of "None" was to remove all audio functions from the compilation process except the ones the system itself fundamentally depends on. It'd be better if we could find a way to remove all such dependencies, but that's usually a difficult problem.

[Goombert]

I am in favor of adding a "Mute" audio system. For every system actually. Also would be nice to automate it somehow as Josh said. Perhaps we could make an "emulate" system option or something where JDI nulls all the function pointers.

[Josh @ Dreamland]

If this is going to be an "every system" thing, we might just call it "Debug." It seems like a good idea to do this sort of logging globally.

[Darkstar2]

What about doing it at the API level, you know where you select OpenAL, DirectSound and None, you could add a null option or whatever, which will work like the other APIs but not actually process sound and output it to your audio device, so you can easily switch back and forth APIs as you are testing your game.

[sorlok_reaves]

What about doing it at the API level, you know where you select OpenAL, DirectSound and None, you could add a null option or whatever, which will work like the other APIs but not actually process sound and output it to your audio device, so you can easily switch back and forth APIs as you are testing your game.

This makes the most sense to me. Since there seems to be some interest, I'll prepare a pull request so it can be properly evaluated.

[Goombert]

But then this becomes an every system or every extension thing too. I think it would be much better to automate this.

[Josh @ Dreamland]

Every system type, yes. It'd be hard to mock the collision and networking systems in a useful manner, and you'll find the same is true of most extensions. There are plenty of systems out there to automate mocking—Google maintains Mockito, as an example with which I've become very experienced. But this isn't what we need, here. Your instinct is correct, though; we can create a template function or macro whose only job is to take the place of a function that is supposed to load a file or stream and record that it was done.