OpenTTD optimizations

[peter1138]

Seems that animation slows the game a lot.

Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...

[kaan]

I have though of another optimization. During some tests with callgrind and one of my savegames I discovered that GetTileSlope in tile.cpp, some "complicated" function is eating 6.95% of cpu time, which is relatively lot.

I though of possible fix: cache slope data (1 byte/tile) in some array, this will mean max. 4MB of memory "wasted" on largest map (2048x2048), but those 7% of CPU cycles will be reduced to neglibigle lookups.

Do you think it is a good idea?

Actually, root cause of this was GetSlopeZ_Track in rail_cmd.cpp, eating 7.96 % of cpu time, so if this function can be rewritten to do more effectively without GetTileSlope (I have no idea what for this function is), things may be beter too and without any extra memory usage

I think madman is working on including slope info in the map.

[Bilbo]

Seems that animation slows the game a lot.

Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...

But rest of the desktop will be in 8bpp also which is .... not good

[athanasios]

Seems that animation slows the game a lot.

Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...

And how did you come into the conclusion that I didn't?

Actually it makes almost no difference if you use 8bpp-optimized or 32bpp-anim. The slowdown from animation applies to both modes. OK, when game progresses and AI players join the game 32bpp is affected more. But in the beginning of the game there is no difference. I may have to repeat what I said: Use Fast Forward in any mode with/without animation and you can tell the difference. Turn off animation when we press the FF button?

NOTE:
This behavior I tested in Windows versions.

[peter1138]

And how did you come into the conclusion that I didn't?

Because I guessed you'd confuse "blitter" with "video mode"...

Under Windows, OpenTTD is only in an 8bpp mode when you run full screen and have fullscreen_bpp set to 8, or if your whole desktop is set to 256 colours.

[Korenn]

true old-fashioned 8bpp palette-shifting through interrupts is very costly... I can imagine that in real 256 color mode the speed gain is only minimal.

[athanasios]

peter1138: OK, you are right regarding running in 8bpp, I forgot to change my .cfg.

Yet you are wrong in suggesting this would improve speed with animation. There is a slight improvement but it is negligent, minimal as Korenn said.

So what I previously asked/suggested remains.

I was thinking about SimuTrans: Their approach to animation in sea is not ideal. Any other way for animation like gifs or multiple sprites?

OK, I am not a programmer, but I hope my reference to this, will triger a fruitfull discussion.