[copperpen]

Using the same scenario, FBL afternoon commuter, at the start of the activity my render process is 88% with 0% waiting, my updater process is 40% with 0% waiting. This is at the start of the activity in view 2 which is default. Once I start the train moving and change views, my render process drops slightly to 84%, updater process goes up slightly to 48%, but FPS also increase in this activity in view 2 they have reached 220.

My CPU is an E7200 at 2.93 Ghz with 8Gb of DDR2 memory and an Nvidia 650 card.

[markus_GE]

It seems to me, I should really invest in a better suited systeem for running OR on... if it only wasn´t about Money :ko2:

[disc]

I didn't notice performance drop in constant fps (maybe the game stutters more at tile loadings) since v1251, but i have quad core cpu. Those who have fewer cpu cores may notice big performance impact in the last two month releases, as the sound thread is using significantly more cpu resources(14% cpu usage of that thread on v1251, 56% now in latest build), due to the short blast horn, and such fixes. As i heard it's a temporary workaround, so it will be lowered.

[gpz]

Actually I thought it as final solution for horn sounds, not a workaround. However I am planning to utilize the AL_LOOP_POINTS_SOFT extension for the rest 90% of sounds to handle looping of files with only two cue points. This can lower the CPU load. (Though I have never seen it above 20% for sound thread, but I might look at wrong routes.)

[copperpen]

If we are referring to the Sound Process here, back in X1492 at the start of any activity anywhere, it was 0%. Using x1614 through 1618 it starts at 1% and may rise to 3% sometimes.

[Lindsayts]

gpz, on 30 May 2013 - 08:45 AM, said:

Actually I thought it as final solution for horn sounds, not a workaround. However I am planning to utilize the AL_LOOP_POINTS_SOFT extension for the rest 90% of sounds to handle looping of files with only two cue points. This can lower the CPU load. (Though I have never seen it above 20% for sound thread, but I might look at wrong routes.)

Have a crack at the Bernina Bahn, I have found the sound thread is generaly up around the 30% mark. As to frame rates taking a dive its difficult to tell, specialy with the increased viewing distance avaible. One thing I have noticed though on Windows XP if one has the OS running for a while OR frame rates will eventually (sooner or latter) take a major dive, I have had at least a 33% drop. Can only be fixed with a reboot. It appears to occur when resuming a saved drive. I would not bet my life though on it only happening at that point.

Lindsay

[markus_GE]

@ Lindsay: You´re of course right, viewing distence and so on all take an Impact on Performance, neverthelss if everybody tuned their Settings to give them the ultimate Maximum of Performance, aat least some relative comparisons can be done. And in addition, we get info on what systmes OR works how well / badly :).

And as for the OS lowering OR fps after some time running: It seems, OR is sometimes closer to mSTS than we want it to, as this seems to me imported from MSTS - although it takes way longer in OR to have the OS depress fps...




To all: having my Settings tuned to give me "ultimate" performace (I think, I posted the way there somewhere farther above in this thread - if not, prove me wrong :) ) in an Explore at Abra on Bob wirth´s ATSF "Peavine" Phoenix Sub (my Standard testing Location, as there´s quite Little scenery there) I get this for the outside view:

FPS araound the lmid 40´s to upper 30´s (depending on the angle), render at 99 to mostly 100% (after one Minute, when OR seems to have found a "compromise" for all those Performance numbers), updater at some 30%, Sound (only one D9er, the Default one in there) too... - everything at idle, not moving.

[disc]

gpz, on 30 May 2013 - 08:45 AM, said:

Actually I thought it as final solution for horn sounds, not a workaround. However I am planning to utilize the AL_LOOP_POINTS_SOFT extension for the rest 90% of sounds to handle looping of files with only two cue points. This can lower the CPU load. (Though I have never seen it above 20% for sound thread, but I might look at wrong routes.)

See the attached screenshot. However it barely reached 10% before the short blast horn update, i think it's too much for a little effect. Can't be such effects triggered by a key event based method instead of lowering the sleep time of sound thread?

Attached thumbnail(s)

• 

[copperpen]

OK. So I am sitting in the cab on the PRB. Sound process is running at 7%. I give a short horn blast and it drops to 6%, then goes back up to 7%.

The Bernina is definitely more hungry in the sound department. I am getting 43 to 44% on that one.

Far as overall FPS goes, mine go down and up. I am going for a three hour run on the Surfliner 2 tomorrow. Will let you know how that goes.

[gpz]

Sleep time was decreased for the purpose of being able to release a sound with jump and to increase the accuracy of sounds with frequency curve. The other type of sound sources are still playing with the old sleep time. These tasks have to be handled by OR code, because the low level sound library cannot do that. Generally there is no other way, as I know. It is simple math: frequent queuing or pitch adjustment means frequent update.

Disc, what do you mean of "it is too much"? In your previous post you wrote you didn't notice performance drop.