Load Times. Ah yes.
Vex is built around an "auto cache" system. Planets, ships, what have you, are all generated using fairly sophisticated algorithms which take some time to run. Once they are generated, they are saved to an optimized file, which although much larger than that data used to generate them, is faster because then we can just load them rather than having to go through the generation.
Some months ago, I came to the grim realizing that a fully-cached-out Vex universe is going to be not just a few hundred megabytes, but at least a few gigabytes. Most of that will be city, monster, and other models. A much smaller amount will be in planetary terrain data, mainly due to the excellent scheme used to render the planets which results in the cached data being naturally quite small.
So we have two separate load time issues (actually three but nm that for a moment). We have the issue of loading precached data, and the issue of generating that data. The first I am in the process of solving using threaded load routines. Basically, we have a thread which loads stuff so the game can continue. When you near a city, rather than a 2 second pause, there will be a slight dip in FPS (or maybe not, actually) and the city will then pop up. But gameplay will continue for that two seconds, you may not even notice that it's loading because most of the time will be spent in IO blocking, not CPU. The details of getting this to work properly are slightly interesting (I made a really spectacular template class to manage threaded loading, let's see how useful it really is...)
The second problem is harder, because it's almost all-CPU. I am taking a two pronged attack. First I will optimize some of the generating routines. For this I will mainly use the profiler, and actually from previous optimization sessions (where I was focused on gameplay time, not load time) I did notice a few areas which I can hopefully fix without too much work. Then, I am going to need to decide on one of two options. Either I show the player a spinner and say "GENERATING..." or we suffer some really slow FPS for awhile. Or maybe, a combination. The FPS goes slowly and "GENERATING..." appears flashing in the corner, sort of an apology to the player. The third option is we pregenerate as much as we can at "umake time", which was my original plan until I realized how much HDD it would take. However, most of the generation time is when you first enter a system, and yet that is least of the HDD usage. So maybe I can pregenerate the planets/moons/etc., and generate the cities using the hybrid bgloader/apology approach. Hmn... something to think on.
The last place where loading times are occuring is due to info parsing. Yuck. I didn't really reckon on ANTLR being so slow, and I don't really want to complain on other peoples design approaches but I have found a few things rather frustrating with ANTLR. I love the usage design of it, i.e., the way you lay out the parser is so nice, but I hate a few things about it, mainly it requires exceptions to work properly (and I use gcc 2.95, yikes I know) but also, it is rather slow when compared to flex/bison. Anyhow, I may actually rewrite the parser using flex/bison, but the other thing I can do quite easily is put the info parsing stuff in a thread (assuming ANTLR is thread safe, which it may not be because it uses exceptions and I have an old compiler). I think I had probably better do both. The info language is simple enough that it won't be a /huge/ task but, frankly, this is kind of disappointing.
Well actually, my rant probably isnt' totally justified. Vex also caches info files you see. When it parses one, it writes a .db2 file which it then loads instead. Those .db2 files are kind of inefficient, though, and so if I can optimize them (I'll call the new format .db3 =) I can probably save a lot on load times. We'll just have to see. I'm not 100% sure yet how I'm going to get the drones to load faster. It actually might be possible to just load them totally in the BG though I'm not sure how this would affect gameplay yet.