The RoM Slowdown Culprit

I didn't know that. I tought the exe contains just the graphic engine...
So the XML indexed and loaded into memory by the exe? Do you know how the DLL acces to the data? (Sorry for the asking, but I'm curious and it seems you know the answers. ;))

The DLL loads the data initially, I know you can mess with that, I had to for a few things. However, once it's loaded...

The exe also controls music, and some of the UI, like the diplomacy screen.
 
The DLL loads the data initially, I know you can mess with that, I had to for a few things. However, once it's loaded...

The exe also controls music, and some of the UI, like the diplomacy screen.

Hm. Looks like at least worth to check it later...

Thanks!
 
I thought I'd share this...

I found in the SDK for Civilization, many many times the SDK used the results of python to find out whether to continue. Many times, this is useful, for example, the screens need to calculate some stuff, show it to the player, and then send the calculations back the game engine. But sometimes, it was used despite no one running any calculations on the other side, wasting the interpreter, and the player's time. One example was that when the game checked if any buildings melted down in your cities, it called python too, and this could not be turned off. Well, I found 13 examples like this all over the SDK, and I turned them into Python Callbacks, so I could then turn them off. I ran a speed comparison for the engine on a huge map with AND 1.54 vs my AND 1.60beta with the new and disabled python callbacks. After measuring the engine calculation times in the profiler, I had found that I had gotten another 10-15% (+/- 10%) speed increase, over AND 1.54.

1.60beta will be the first release to have these new speed improvements.

I hope to one day make AND/RoM run faster than BTS alone. We are one step closer to this...
 
I thought I'd share this...

I found in the SDK for Civilization, many many times the SDK used the results of python to find out whether to continue. Many times, this is useful, for example, the screens need to calculate some stuff, show it to the player, and then send the calculations back the game engine. But sometimes, it was used despite no one running any calculations on the other side, wasting the interpreter, and the player's time. One example was that when the game checked if any buildings melted down in your cities, it called python too, and this could not be turned off. Well, I found 13 examples like this all over the SDK, and I turned them into Python Callbacks, so I could then turn them off. I ran a speed comparison for the engine on a huge map with AND 1.54 vs my AND 1.60beta with the new and disabled python callbacks. After measuring the engine calculation times in the profiler, I had found that I had gotten another 10-15% (+/- 10%) speed increase, over AND 1.54.

1.60beta will be the first release to have these new speed improvements.

I hope to one day make AND/RoM run faster than BTS alone. We are one step closer to this...
Have you shared your speed improvement findings with Better BtS AI team or CAR mod team? I'm sure they'd like to hear about all the speed improvements. :)
 
Does this make the city screen faster? Great find by the way!:goodjob::D

City screen is way too slow, I agree! My last game I was amazed at the turn speed of a new dawn, but the slow city screen response made me quit the game anyway...
 
Does this make the city screen faster? Great find by the way!:goodjob::D

Sadly, it doesn't. There is little anyone can do to speed up the city screens. It's painfully slow in vanilla BTS as well...

Have you shared your speed improvement findings with Better BtS AI team or CAR mod team? I'm sure they'd like to hear about all the speed improvements. :)
Perhaps....
 
City screen is way too slow, I agree! My last game I was amazed at the turn speed of a new dawn, but the slow city screen response made me quit the game anyway...

Learn to make good queue of your planned buildings/units at correct time. That should reduce your time in city screen to necessary ones. The time taken to deal with city screen is significantly small compared to the game in totality. So my recommendation is to concentrate on what you need to do in city screen at that time and don't think about time. After you escape the city screen, you can sit back and enjoy Afforess' brilliant speed optimizations in the turn times :D. I had never went over 30 seconds in my games if my map is Huge or less. With Gigantic, it never went over 1 min (granted I quit because it was a bit too long so I never experienced late game in Gigantic map).

So long story short: Deal with city screens at one time and you will be fine because the time taken to deal with the city screen is comparatively minor.

Patience is a virtue, after all! :D :goodjob: to Afforess for his continued efforts!!!
 
How odd, I've never noticed any slowness in my city screens and my computer is distinctly average. Maybe I'm just slow. :)
 
Back
Top Bottom