Posted: 11 Jul 2007 06:30
Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...athanasios wrote:Seems that animation slows the game a lot.
Transport Tycoon Forums
The place to talk about Transport Tycoon
https://www.tt-forums.net/
OpenTTD optimizations
Page 5 of 5
Posted: 11 Jul 2007 09:50
I think madman is working on including slope info in the map.Bilbo wrote: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
Posted: 11 Jul 2007 13:12
But rest of the desktop will be in 8bpp also which is .... not goodpeter1138 wrote:Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...athanasios wrote:Seems that animation slows the game a lot.
Posted: 11 Jul 2007 22:53
And how did you come into the conclusion that I didn't?peter1138 wrote:Switch to an 8bpp graphics mode and it'll cost almost no extra CPU time at all...athanasios wrote:Seems that animation slows the game a lot.
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.
Posted: 12 Jul 2007 05:56
Because I guessed you'd confuse "blitter" with "video mode"...athanasios wrote:And how did you come into the conclusion that I didn't?
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.
Posted: 12 Jul 2007 16:51
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.
Posted: 13 Jul 2007 03:03
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.
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.