Game appears to hang
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Game appears to hang
Ok, this is technically not a bug... but... to people who don't know better, the game may feel like it has hung when they start a new game as the time taken to generate the dynamic universe can be significant. Some feedback to the user to indicate the game is loading (or even a message saying, "Loading dynamic universe, this may take few minutes so please be patient!") will make people feel reassured.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
I committed a simple fix for now that adds a message in generate_dyn_universe.py
VS.showSplashMessage("Generating a Universe... This may take a while.")
I noticed that the splash screen sometimes changes to black or white in the middle of the campaign loading (sometimes when reloading from the basecomputer). I have seen it inconsistently a few times, but maybe because I was also debugging it at the same time.)
VS.showSplashMessage("Generating a Universe... This may take a while.")
I noticed that the splash screen sometimes changes to black or white in the middle of the campaign loading (sometimes when reloading from the basecomputer). I have seen it inconsistently a few times, but maybe because I was also debugging it at the same time.)
-
- The Shepherd
- Posts: 5841
- Joined: Fri May 13, 2005 8:37 pm
- Location: Ottawa
- Contact:
An other thing i have never seen the Shaper screen in the rotation the fraternal war one seems to be the one that goes white on my system while the shaper seems to be black.
Enjoy the Choice
Enjoy the Choice
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
That might explain the white/black thing.
Anyway I found out why in Linux at least, loading a saved game takes so long.
Most of the loading time is spent beacuse of hashtable collsisions. The hashtable used for mission string data is simply way too small.
Now that is quite a few buckets, but every time I break it is stuck in string::compare, and when I try next'ing through this I can't get to the end, so each bucket has on average hundreds of elements... maybe off by an order of magnitude or two.
Not sure why this is suddenly a problem... maybe decreasing the number of ships overall will fix this, but half a minute of loading time is wasted in adding ships to the saved game, and most of that is spent searching through buckets of a hashtable, or so it seems.
Any ideas on how to solve this loading issue?
Is there a way to reserve buckets in STL, say as a function of the number of bytes in the savegame file (which is easy to find).
Anyway I found out why in Linux at least, loading a saved game takes so long.
Most of the loading time is spent beacuse of hashtable collsisions. The hashtable used for mission string data is simply way too small.
Code: Select all
(gdb) list 753
748 hashtable<_Val, _Key, _HF, _Ex, _Eq, _All>::
749 insert_unique_noresize(const value_type& __obj)
750 {
751 const size_type __n = _M_bkt_num(__obj);
752 _Node* __first = _M_buckets[__n];
753
754 for (_Node* __cur = __first; __cur; __cur = __cur->_M_next)
755 if (_M_equals(_M_get_key(__cur->_M_val), _M_get_key(__obj)))
756 return pair<iterator, bool>(iterator(__cur, this), false);
757
(gdb) print __n
$11 = 34336
(gdb) print _M_buckets.size()
$12 = 49157
Not sure why this is suddenly a problem... maybe decreasing the number of ships overall will fix this, but half a minute of loading time is wasted in adding ships to the saved game, and most of that is spent searching through buckets of a hashtable, or so it seems.
Any ideas on how to solve this loading issue?
Is there a way to reserve buckets in STL, say as a function of the number of bytes in the savegame file (which is easy to find).
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
That's normal, it's the only time-expensive operation on a hashtable, it's 99% chance you'll break there no matter how efficiently the table is used, mostly if you're dumping/inserting things.
And no, if there's a way to reserve space, it's nonstandard. But a very very common extension (SGI's STL for instance has it, and whatever the SGI STL has almost all others have) is hash_map::resize(), which does exactly that. But you don't know the number of strings beforehand, so you're better off letting the STL handle resizes.
The scripts I talked about were thought as a way to release a bit of that burden, by restructuring the data saved. I have more strings, but shorter - should help a bit, make the hash more efficient. Should. Also, that should also speed up operations with the unit list on saves, since now they don't have to process that much data. However, I haven't benchmarked it in full, but one good thing is that it introduced hookpoints where to add progress reports - and that's what I did.
I'm not sure if I should commit, will bork people's savegames a bit (though not to the point of having to delete them I think, only the dynamic universe gets reset).
And no, if there's a way to reserve space, it's nonstandard. But a very very common extension (SGI's STL for instance has it, and whatever the SGI STL has almost all others have) is hash_map::resize(), which does exactly that. But you don't know the number of strings beforehand, so you're better off letting the STL handle resizes.
The scripts I talked about were thought as a way to release a bit of that burden, by restructuring the data saved. I have more strings, but shorter - should help a bit, make the hash more efficient. Should. Also, that should also speed up operations with the unit list on saves, since now they don't have to process that much data. However, I haven't benchmarked it in full, but one good thing is that it introduced hookpoints where to add progress reports - and that's what I did.
I'm not sure if I should commit, will bork people's savegames a bit (though not to the point of having to delete them I think, only the dynamic universe gets reset).
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
I actually had to change two things. The bottlenecks were from both hash_map's that had an incredible number of elements.
In savegame.cpp, I changed it from:
typedef stdext::hash_map<string,vector <StringPool::Reference> >MSD;
to:
typedef std::map<string,vector <std::string> >MSD;
Unfortunately, this change couldn't be hidden from code that uses it since you can't easily cast vectors with two different string types.
A proper hashtable should be able to go faster than a red-black tree, however the STL hashtables
But it does decrease loading time significantly for me.
Anyway, I committed the change.
In savegame.cpp, I changed it from:
typedef stdext::hash_map<string,vector <StringPool::Reference> >MSD;
to:
typedef std::map<string,vector <std::string> >MSD;
Unfortunately, this change couldn't be hidden from code that uses it since you can't easily cast vectors with two different string types.
A proper hashtable should be able to go faster than a red-black tree, however the STL hashtables
But it does decrease loading time significantly for me.
Anyway, I committed the change.
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
If you are going to commit it, now's the time, so that post-release you're not in the situation of possibly borking saves.klauss wrote:I'm not sure if I should commit, will bork people's savegames a bit (though not to the point of having to delete them I think, only the dynamic universe gets reset).
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community
-
- ISO Party Member
- Posts: 410
- Joined: Tue Jun 26, 2007 7:15 pm
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
If you click "Campaign" then you are starting a new game, and it will generate a new universe.
If that isn't clear, maybe we should give it a different name.
Were you clicking Campaign or Load Game?
Also, maybe we should ship VS with a pre-generated universe so as to avoid the long wait on the first game.
If that isn't clear, maybe we should give it a different name.
Were you clicking Campaign or Load Game?
Also, maybe we should ship VS with a pre-generated universe so as to avoid the long wait on the first game.