Hi
I am getting very skow performance an occasional random crashes.
I want to check the performance (4 - 5 fps with stalls) is normal before I invstigate he crashes.
This occurs across both my core 2 based xp pro machines.
Latests Stable and Pak 64
Ta
Known bug for v100.0 - try a nighly version instead.
And that double post - pushing with just a "." 10 minutes after was simply unnecessary!
nightly builds are here :
=> http://www.wernieman.de/simutrans/index.en.html
The double posting was an accident and there is no delete post button. The . is as there is no way to post an empty post after editing out contents.
Still not geting brilliant performance, but better with nightly build. The process as a whole seems to only use a minute % of available processor power though (3-5% if left alone).
I've just removed your post. Please, upon posting, take care next time. :)
Regular members are not able to remove their own posts for security reasons and for avoiding abuses.
What is your System (Windows, Linux, SDL, .....)
Do you play with Musik?
The performance depends very much on the size of the map, the number of schedule entries and moving objects, the screen resolution... In case of an on-board graphics adapter with shared memory, it may have rather limited performance, so reducing the screen dimensions may help. The 16-bit colour depth display modes (that ST uses) may be less optimized than the 32-bit ones.
One real performance killer (on some PCs) is the water animation. Set parameter water_animation_ms to 0 in the config file (simuconf.tab) to disable that.
From my experience (not from recent versions though), setting the refresh interval (parameter frames_per_second) to a lower value (e.g. 15) helps much for overloaded CPUs.
In display options and the config file, you can change some more settings to reduce CPU usage a little (e.g. disable display of pedestrians). The autosaving function can cause delays (only at switching to the next month).
I've seen that happen, too. One possible explanation is that the peak CPU usage is very high, but also very short, so any monitoring program won't catch that properly, unless configured for fine time resolution.
(EDIT: topic title adjusted)