64 replies to this topic

[Miloch]

I think it might be remotely possible that this stutter happens when two or more ambients (particularly the same ambient perhaps) overlap in their radius of effect, which in this case is 500 (pixels I'm guessing). So does am1900e2.wav work fine but not am1900e1? There are several of each in that area.

[Miloch]

I don't know if it's so much the "when" the sounds play, but rather the "where." This seems to corroborate what I was thinking:

This leads me to believe that water sounds are not responsible, even though the stutter usually happens in areas with lots of water running.

In Candlekeep where GeN1e first noticed this, you have several fountain ambients (amb_e28) with large radii of effect (700). Doubtless many of these overlap since some are practically right next to each other. I could imagine this could cause stutter when the engine is trying to fire the same .wav off, possibly at slightly staggered times. Certainly it wouldn't sound pretty at the very least. Maybe some sort of math-heavy code could go through and adjust all the conflicting ambients, but in the meantime, maybe we could test by reducing the radii to areas where they won't overlap and test it again. I haven't been able to reproduce the stutter, so it's a bit hard for me to test.

[Sam.]

I don't have any of the games installed on this computer, but if you can post the full area graphic as a JPEG (The druid grove AR1900?) along with a list of the different ambients, where they are centered, and their radii, I would like to try something .

[Sam.]

A visual of the overlapping:



 AR1900-Visual.rar   4.91MB   142 downloads

[Miloch]

Very cool... did you use some sort of script to do that? It should be incorporated into DLTCEP.

Can you also colour-code the ambients that are the same reference?

It looks like there are about 4 stacked on each other in the northwest corner - what's with that?

Now someone just needs to write a WeiDU superfunction to go through and adjust/delete conflicting ambient radii...

[Wisp]

Yeah, it might be wise to confirm this problem and proposed solution on a small scale first.

Personally, I have my doubts. Overlapping ambients are by no means rare, so it that was it I would think this problem would be a lot more prevalent.

[Sam.]

Very cool... did you use some sort of script to do that? It should be incorporated into DLTCEP.

I wrote a quick program to generate an ImageMagick script.

Can you also colour-code the ambients that are the same reference?

Sure

It looks like there are about 4 stacked on each other in the northwest corner - what's with that?

for one thing the slowdown was apparent upon entering the area (southeast corner) when none of those sounds should have been triggered yet

Several of the ambients in the area (including at least a couple in the top left corner) have the "Ignore radius(2)" flag set. This would mean that regardless of the specified radius, you would be in the area effect of multiple ambients as soon as you enter the area. As you pointed out, however, this is a fairly common occurance. Miloch, how do you want to handle the rendering of these (ones with ignore radius flag) on the area background?

Now someone just needs to write a WeiDU superfunction to go through and adjust/delete conflicting ambient radii...

Could you start by writing a WeiDU script to extract the full area graphic as a BMP (leaving out the extra tiles at the bottom of the tileset), and a tab-delimited list of: ambient name, associated WAV (although some have many... Haven't decided how to handle those yet...), Origin X, Origin Y, and Radius?

[Sam.]

Color-coded including ambients with "Ignore radius(2)" flag:


Color-coded excluding ambients with "Ignore radius(2)" flag:

Edited by Sam., 27 August 2012 - 01:11 PM.

[Miloch]

Sam. - thought I'd commented on the last post but very cool anyway. Shows more clearly that there are relatively few of the same ambient that overlap. Still might not be the issue, but you may not have to step into the actual overlapping sections... maybe the fact that it occurs in an area is enough to trigger the stutter. Maybe not, but I still think people who get the issue should test it with and without modding the ambient radii to something smaller.

Shin - that could be the case but is hard to tell unless folks who have the issue post their sound cards and the exact areas where they get the stutter. So far, no one's really done this. Also it is unlikely for BGEE to fix the issue if it occurs in the ToB engine and no one knows exactly *what* the issue is (so far it seems inconclusive without further details and testing).

[Sam.]

getting exactly the same issues in certain areas both in BG and BG2,

If everyone starts posting what they are, it may reveal some commonality. Plus I'll generate and post a visual of each one.

Miloch, would it be necessary/interesting/worth my time to calculate the overlapping area of the ambients with the same sound file(s)?

Edited by Sam., 24 September 2012 - 09:26 PM.

[Sam.]

AR0700 (Waukeen's Promenade) - the stutter kicks in only at night when the AM-FirePot 1-14 ambients kick in. The wav is AM0700O.WAV

Visual for AR0700

For some reason, it kept returning an error when I tired to attach the .jpg to the post...

Edited by Sam., 29 September 2012 - 02:41 PM.

[Miloch]

Miloch, would it be necessary/interesting/worth my time to calculate the overlapping area of the ambients with the same sound file(s)?

Well it might be worth analysing some of the areas in which no overlap is claimed, such as ar0300 above? Obviously, there is quite a bit in ar0700 at least in one area of it but I don't know if that's conclusive. I think we can get to the bottom of this with enough data and analysis.

[Sam.]

Analysis of Stutter vs File Size & Type for ToB:
 Stutter vs File Size & Type for ToB.xls   846K   155 downloads

I only had the files from BG2, not BG1. I may have to do a BGT install to get them all... I thought some of the ambients might not have been compressed to WAVC, but they all were. Considering the two ambients reported to cause stutter that were on this list were way down the list as far as filesize, I'm not so sure that has anything to do with it ether. Those two things were really easy to test, so I figured it couldn't hurt .