Directional sound

[Norbert]

Dunno how easy/useful it would be to add, but...
https://www.youtube.com/watch?v=5CxgnWaZ8zk&t=341
(about an opening gate) "[...] there's no stereo sound in Prince of Persia, so I can't tell. That'll be interesting to add."

[Edit:]
https://www.youtube.com/watch?v=W7gg_DTLqlM&t=589
"It would be nice if SDLPoP could add stereo sound. [...] So that you could tell where the portcullises [gates] are opening. If they're to your left or right. [...] But perhaps that would take something out of the game."

[Falcury]

Dunno how easy/useful it would be to add, but...
https://www.youtube.com/watch?v=5CxgnWaZ8zk&t=341
(about an opening gate) "[...] there's no stereo sound in Prince of Persia, so I can't tell. That'll be interesting to add."

[Edit:]
https://www.youtube.com/watch?v=W7gg_DTLqlM&t=589
"It would be nice if SDLPoP could add stereo sound. [...] So that you could tell where the portcullises [gates] are opening. If they're to your left or right. [...] But perhaps that would take something out of the game."

I’ve started to implement this. I have the directional sound working so far (interaural time and level differences, on the horizontal axis), now I still need to figure out how best to decide/determine the direction sounds should appear to be coming from in game. I am guessing it’s probably best to do it based on rooms: sounds in the current room are neutral, sounds from adjacent rooms are still close to center, and sounds from more than 1 room away would sound further to the left/right.

[Norbert]

I’ve started to implement this.

Interesting.

[Edit: Multiple things may be triggered at once...]

[Falcury]

[Edit: Multiple things may be triggered at once...]

Maybe multiple sound sources should be allowed to be mixed together.
Broken room links are also a problem.

[Falcury]

I’ve started to implement this.

Here is my first attempt:
https://github.com/Falcury/SDLPoP/commi ... f76f800ea3

It also seemed to make sense to make distant sounds softer, so I did that as well. This also works with loose tiles crashing in rooms below you.
Multiple things being triggered at once is still a problem. But apart from that it seems to work mostly OK.

To deal with broken room links, after googling the problem I ended up using Dijkstra's algorithm. The strategy is to check for the locations of and distances to other rooms (starting from one particular room). The distances are recalculated every time the room changes. The only case I can think of in which this breaks down, is if some rooms cannot be reached at all because they are cut off from the rest.

By the way, is 'directional sound' even the correct term? Wikipedia seems to have another idea about what this means:
https://en.wikipedia.org/wiki/Directional_sound

[Norbert]

Here is my first attempt: [...]
[...]
By the way, is 'directional sound' even the correct term?

This is certainly interesting. It changes the playing experience. I like it, and it's nice that you applied it to loose floors as well. Making distant sounds softer makes sense too. It's a bit strange that gates that are visible in the room but are outside the room (on the left) make noise as if they are in the room. Similarly, gates on the far right - their columns - are visible in the room, but make sounds as if being outside the room. For example in the starting room of level 1. This makes me wonder how your code works (I didn't look into it). One thing I also realized while playing is that only closing gates in room 2 of level 3 can be heard from all rooms. Perhaps with sound localization (to answer your question ) enabled, the prince should simply hear all sounds? I don't know how easy this change would be though; maybe the code used for the level 3 exception can help. To end with a random thought: perhaps the effect could also be applied to tiles in columns 1-3 and 7-10, regardless of where the prince is? Or even depending on where the prince is, e.g. with sword fighting. If I'm making things too complicated or it doesn't help the playing experience, just ignore my ramblings.

[Edit:]

columns 1-3 and 7-10

In fact, only that would help with this.

[David]

Here is my first attempt:
https://github.com/Falcury/SDLPoP/commi ... f76f800ea3

I tried it; it seems to work correctly.
It made me realize (again) that my headphones swap left and right for some reason.

Possible bugs I found:
* When a piece of the room's ceiling shakes, it sounds as being in the room above (i.e. softer).
* The sounds of the gates in the rightmost column of the current room don't sound as coming from right (only softer).

By the way, is 'directional sound' even the correct term? Wikipedia seems to have another idea about what this means:
https://en.wikipedia.org/wiki/Directional_sound

The VRML standard calls it spatialization.
The SDL_mixer documentation calls it positional audio.

Perhaps with sound localization (to answer your question )

I think the linked page is more about the listener's ability to determine where is a sound coming from, than about making sounds sound like they are coming from a certain direction.

It's a bit strange that gates that are visible in the room but are outside the room (on the left) make noise as if they are in the room.
Similarly, gates on the far right - their columns - are visible in the room, but make sounds as if being outside the room.

This is the same logic as what the original game uses for closing gate sounds.
If (the moving part of) the gate is visible on the screen, then it's considered to be in the current room. Otherwise it's not.

[David]

Moved posts to a new topic.

[Falcury]

Some more progress:
https://github.com/Falcury/SDLPoP/commi ... 978161d26b

perhaps the effect could also be applied to tiles in columns 1-3 and 7-10, regardless of where the prince is? Or even depending on where the prince is, e.g. with sword fighting.

* When a piece of the room's ceiling shakes, it sounds as being in the room above (i.e. softer).
* The sounds of the gates in the rightmost column of the current room don't sound as coming from right (only softer).

OK, I changed it a bit. Now the desired effect is achieved (hopefully):
* The sounds are now originating from specific tile positions, instead of from specific rooms.
* I put the 'listener' at some distance along the Z-axis (i.e. some distance away from the screen). The idea is that sounds coming from near the center of the play area should still sound close together, including floorpieces shaking in the room above which are not very far away after all.

I also enabled it for all digi sounds, including footsteps, chompers, etc.

The SDL_mixer documentation calls it positional audio.

I think this sounds good. I changed it to this in the new commit.

One thing I also realized while playing is that only closing gates in room 2 of level 3 can be heard from all rooms. Perhaps with sound localization (to answer your question ) enabled, the prince should simply hear all sounds? I don't know how easy this change would be though; maybe the code used for the level 3 exception can help.

The relevant code is in seg007.c, play_door_sound_if_visible(). You can change it so has_sound is always true, or you can add more specific exceptions, for example:

Code: Select all

	// Special event: sound of closing gates
	if ((current_level == 3 && gate_room == 2) || GATE_SOUND_CONDITION) {
		has_sound = 1;
	}
	// Example: more exceptions:
	if (current_level == 2 && gate_room == 16) has_sound = 1;
	if (current_level == 3 && gate_room == 1) has_sound = 1;
	if (current_level == 4 && gate_room == 3) has_sound = 1;
	if (current_level == 5 && gate_room == 16) has_sound = 1;
	// ...

[Norbert]

Cool.
Perhaps it's possible for the functionality to get 'Scaling method' like options, with Off, On, and Excessive (or something).
Where the latter doubles the directional shifts and volume changes?

[Norbert]

Tried this again
https://github.com/Falcury/SDLPoP/tree/directionalsound

But now run into (and am too lazy to figure out what's the issue):

gcc main.o data.o seg000.o seg001.o seg002.o seg003.o seg004.o seg005.o seg006.o seg007.o seg008.o seg009.o seqtbl.o replay.o options.o lighting.o screenshot.o menu.o midi.o opl3.o stb_vorbis.o -o ../prince -lSDL2_image -lSDL2 -lm
/usr/bin/ld: data.o:(.bss+0x40e0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg000.o:(.bss+0x100): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg001.o:(.bss+0xae): multiple definition of `hof_count'; data.o:(.bss+0xe4c): first defined here
/usr/bin/ld: seg001.o:(.bss+0xc0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg002.o:(.bss+0x0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg003.o:(.bss+0x20): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg004.o:(.bss+0x20): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg005.o:(.bss+0x0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg006.o:(.bss+0x20): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg007.o:(.bss+0x20): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg008.o:(.bss+0x320): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg009.o:(.bss+0x348): multiple definition of `sound_names'; data.o:(.bss+0x4c0): first defined here
/usr/bin/ld: seg009.o:(.bss+0x3e0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seqtbl.o:(.bss+0x0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: replay.o:(.bss+0x54880): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: options.o:(.bss+0x0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: lighting.o:(.bss+0x20): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: screenshot.o:(.bss+0x240): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: menu.o:(.bss+0x30): multiple definition of `menu_control_scroll_y'; data.o:(.bss+0x4): first defined here
/usr/bin/ld: menu.o:(.bss+0xa0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: midi.o:(.bss+0x0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here

[Norbert]

Also, this and/or the audio changes made by Dmitry (mentioned here) might be useful to have as a toggle in the main branch, particularly given this.

[David]

/usr/bin/ld: data.o:(.bss+0x40e0): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here
/usr/bin/ld: seg000.o:(.bss+0x100): multiple definition of `room_offsets'; main.o:(.bss+0x0): first defined here

I think an extern should be added to the line which declares room_offsets: https://github.com/Falcury/SDLPoP/blob/ ... ata.h#L685

/usr/bin/ld: seg009.o:(.bss+0x348): multiple definition of `sound_names'; data.o:(.bss+0x4c0): first defined here

sound_names is defined at two places:
https://github.com/Falcury/SDLPoP/blob/ ... ata.h#L636
https://github.com/Falcury/SDLPoP/blob/ ... 09.c#L2007
You could remove the one in data.h, because this variable is not used outside seg009.c .
In the main SDLPoP repo, it was removed from seg009.c, though.

/usr/bin/ld: seg001.o:(.bss+0xae): multiple definition of `hof_count'; data.o:(.bss+0xe4c): first defined here

hof_count is defined at two places:
https://github.com/Falcury/SDLPoP/blob/ ... ata.h#L305
https://github.com/Falcury/SDLPoP/blob/ ... g001.c#L51
You should remove it from seg009.c .

/usr/bin/ld: menu.o:(.bss+0x30): multiple definition of `menu_control_scroll_y'; data.o:(.bss+0x4): first defined here

menu_control_scroll_y is defined at two places:
https://github.com/Falcury/SDLPoP/blob/ ... ata.h#L848
https://github.com/Falcury/SDLPoP/blob/ ... enu.c#L120
You should remove it from menu.c .

[David]

I merged Falcury's changes into a new branch:
https://github.com/NagyD/SDLPoP/commits ... ionalsound

Unfortunately I can't hear any directionality, although distant sounds are softer.
That's odd considering that it used to work for me.

I even checked out the exact commit which worked for me, but nothing changed.

[Norbert]

Unfortunately I can't hear any directionality, although distant sounds are softer.

My guess is that you will hear it when using a headphone.
But even then it's probably (too) subtle.
Likely this is why I commented:

Perhaps it's possible for the functionality to get 'Scaling method' like options, with Off, On, and Excessive (or something).
Where the latter doubles the directional shifts and volume changes?