Patch: simplified realistic acceleration

[Zojj]

I've rewritten the realistic acceleration patch.

Latest patch here.

Differences:
-Much cleaner (faster) code.
-Resistance is friction, drag, and gravity.
-Maglevs dont have 150,000hp anymore. =)
-Trains enter/exit depots and stations faster, depending on rail type.

[hertogjan]

May I point your attention to this topic ("smoother realistic acceleration") and this topic ("physics patches")? These topics have gone somewhat into obscurity, as they are not regularly updated, and there seems to be more interest in other things. However, it might be good to look at it, to make sure that you will not waste your time on things that have already been done.

I can make some remarks on one of those topics ("physics patches"), which is my own work. As this patch is quite large, let me summarise what features it includes:
- A totally rewritten function for realistic acceleration, and is customisable by numbers in the config file. You also have the option to use the existing realistic acceleration function (of which I have only cleaned up the code somewhat).
- A realistic acceleration function for road vehicles. This also allows road vehicles to go faster than 127 km/h (79 mph).
- Most of the relevant newgrf variables are supported.
It is, without doubt, more CPU intensive than the current realistic acceleration function in trunk, or your patched version of it. However, I have -so far- not been able to spot any decrease in performance by the use of any realistic acceleration function.
The last update of the physics patch on the forum is a little while ago, so the most recent version will (most likely) not merge properly against the current trunk code. However, I have a slightly updated version on my pc. If you like, I will place an updated version of it next week in the forum topic (earlier is not possible).

[Zojj]

Your patch is great, are there plans to include it in the trunk? I had seen those threads, but thought they were dead topics. Good that they are not.

I made this patch with the idea of it being a drop-in replacement that could be easily added in the trunk. Also for practice and fun. =) I'll spend a couple more hours to finish what I started; thanks for advice not to waste too much time.

[hertogjan]

Your patch is great, are there plans to include it in the trunk? I had seen those threads, but thought they were dead topics. Good that they are not.
(...)

An older version has previously been included in MiniIN, which is now abandoned. I have not been pushing the lead developers too much into inclusion of my patch. Maybe I should increase the pressure on them a little bit.

[Zojj]

Here is a completed version of my realistic acceleration patch, current to r9804. Patch is a drop-in replacement for the current realistic acceleration. It doesn't add or remove any features.

Differences from trunk:
-Much cleaner code
-Reduced 'physics' from 5 elements to friction, drag, and gravity.
-Physics use real-life numbers. Air drag is a big factor. Maglevs don't have 150,000hp anymore.
-Trains enter/exit depots and stations faster, depending on rail type.

Anyone else want this in the trunk? =)

[Zojj]

Updated. (Finished!?!)

r9891 Diff at top of thread.

[kaan]

I don't know a thing about physics but I think this patch looks nice.
Maybe it could use a few more comments in the code.

[Zojj]

And I thought I put in too many comments =) I'll see what I can do.

[kaan]

And I thought I put in too many comments =)

There is no such thing

Don't sweat it, its not me who is going to judge your code

[Zojj]

There isn't anything without comments that I can see. =) Is there something specific you think should be explained bettter?

[kaan]

There isn't anything without comments that I can see. =) Is there something specific you think should be explained bettter?

huh? maybe I got confused, ill look at it again in the morning

[Zojj]

While reading B. N. SmatZ!' OpenTTD optimizations post, I noticed this:

Code: Select all

Function                        %Incl.  %Excl.
-----------------------------------------------
...
GetTrainAcceleration             9.688  9.618 
...

The current realistic acceleration uses more CPU time than any other function! My patch should reduce it by a lot. Can someone test? I dont have VC pro.


Some of the obfuscated code that the current GetTrainAcceleration() uses:

Code: Select all

for (i = 0; i < 2; i++) {
	if ( _curve_neighbours45[dir][i] == ndir) {
		curvecount[i]++;
		if (lastpos != -1) {
			numcurve++;
			sum += pos - lastpos;
			if (pos - lastpos == 1) {
				max_speed = 88;
			}
		}
		lastpos = pos;
	}
}

[hertogjan]

Some of the obfuscated code that the current GetTrainAcceleration() uses:

Code: Select all

for (i = 0; i < 2; i++) {
	if ( _curve_neighbours45[dir][i] == ndir) {
		curvecount[i]++;
		if (lastpos != -1) {
			numcurve++;
			sum += pos - lastpos;
			if (pos - lastpos == 1) {
				max_speed = 88;
			}
		}
		lastpos = pos;
	}
}

I don't understand why that piece of code is still there. Long ago there has been a change in how directions and changes in directions are handled, and nearly all instances of where it was needed had their code changed. Except this piece in GetTrainAcceleration. If someone had been willing to take a look at it, it was probably changed to this:

Code: Select all

for (const Vehicle *u = v; u->next != NULL; u = u->next, pos++) {
	DirDiff dirdiff = DirDifference(u->direction, u->next->direction);

	if (dirdiff == DIRDIFF_45LEFT || dirdiff == DIRDIFF_45RIGHT) {
		curvecount[(dirdiff == DIRDIFF_45LEFT ? 0 : 1)]++;
		if (lastpos != -1) {
			numcurve++;
			sum += pos - lastpos;
			if (pos - lastpos == 1) {
				max_speed = 88;
			}
		}
		lastpos = pos;
	}
(...)
}

I don't think that this change of code will have a major effect on performance. However, it is way easier to read that the old piece of code - which is exactly what all developers want.

In order to increase performance, one might think of calling GetTrainAcceleration not every tick, but only once in every few ticks (and use a cached value of acceleration for the other ticks). Maybe one should include a patch option to let the user choose how often he wants GetTrainAcceleration te be called. For a slower machine, one would choose a setting for increased performance, while on a faster machine, one would choose GetTrainAcceleration to be called every tick for the highest detail.
(Note: For network games, all users must use the same setting to keep things synchronised.)

[Zojj]

Ok I built my own performance meter for OpenTTD. My acceleration patch speeds up the game ~1 - 3%.

I got these numbers by playing #openttdcoop's savegame #9 (1300 trains), playing at 1024x768 middle-zoom, testing for 120 seconds.

ticks per second:

Code: Select all

          cur accel  new accel  diff
no cache  43.4       44.9       +3.4%
cache     71.4       72.2       +0.8%
diff      +64.5%     +60.8%     

I need to test this some more, as my accel changes train speeds a little. Slower trains = faster game.

Press the FF button to activate the performance meter.

[Nickman]

The performance meter is cool .
I'll give it a test run .

[skidd13]

Ok I built my own performance meter for OpenTTD. My acceleration patch speeds up the game ~1 - 3%.

Press the FF button to activate the performance meter.

The problem is that your code (of the performance meter) is Microsoft based and does not work at my linux. Could you fix that please.

[Zojj]

I don't have linux. =(

Code: Select all

SYSTEMTIME st;
GetSystemTime(&st);
int	cur_time = st.wHour * 3600000 + st.wMinute * 60000 + st.wSecond * 1000 + st.wMilliseconds;

Can someone convert that to compile on linux?

[skidd13]

Why don't you use time.h instead?

[Zojj]

Time.h in windows doesn't do milliseconds. Can someone convert it? Or tell me how to use TIC() TOC()?

[Rubidium]

TIC/TOC is not usefull for this purpose, unless you want to show the number of frames per cpu tick.