Probably a memory leak somewhere that's got to do with GUI and filters. In Orbiter, what with Orbiter itself and all the add-ons running in parallel, such things can ruin your day much faster than when you run it alone.
I guess I finally need to find me a sensible method to check for memory leaks...
Also, I just re-read large parts of this whole thread... It's amazing how most people have stuck around here, giving input and advice, and just waited, waited... until now finally we have a playable release. It's kind of touching. Thanks guys!
---------- Post added at 06:34 PM ---------- Previous post was at 04:48 PM ----------
"Captain, iceberg... errr... I mean memory leak ahead!"
Turns out that, when switching location by the search function or by clicking on the galaxy map, the stars never got the call to delete their systems, letting them rot away in memory for all eternity... most probably the cause of the frequent crashes when using the search funtion and the galaxy map, but we'll see. While looking through those old pieces of code, I also noticed that there is much room for performance improvement. In a lot of cases I'm copying whole elements instead of just passing their pointers on (Hey, I was learning...), so I'll have a look if I can streamline the speed of the whole thing a bit before putting another patch up (no, that won't affect texture generation speed, don't get your hopes up! it might be possible to make the loading of new cubes a tiny bit faster, but that's about it).
One more thing came to mind, in every system the stars should look different ....
It took me a while to understand what you're saying there. Yes, I agree, that would be a great feature, and I even have some ideas to pull it off, but... there's always a but.
Exporting the catalogue into a bin file that orbiter can open isn't really a problem. However, that's only so much of the galaxy. For exporting an "alien sky" for a star at the other end of the galaxy, I'd have to generate the WHOLE surroundings (a thousand lightyears or so), check for apearant magnitude relative to the centralized star, do a few tens of thousands of euler rotations, and then write the whole afair into a .bin file.
Now, the last two points are not really an issue here. Even a low end graphics card can do those rotations quicker than I can google "Lokomotivheizerpausenbrotbeleger", and calculating the aparent magnitudes is a breeze, but generatting the whole surroundings to know what stars there are isn't. Ever notice that short loading time when you click on a place in the galaxy map? that's the whole time it takes to generate the 27 cubes you see on the screen afterwards. Now multiply that by a few thousand, and I will have a serious rival for the texture export!
It's a problem of the architecture I chose... I decided for an easy solution that fits my abilities rather than a multi-thread LOD that would have alowed me to generate the galaxy more dynamically. Improving oversight was also an issue, but it all comes at the price that the program never has an idea of its actual surroundings.
The visual c++ express debugger allows checking for memory leaks and can tell you the file name at the least, where the problem is. You have to start orbiter from inside visual c++ of course, in debug mode.
I'm running the add-on in the debugger the whole time of course, how would I find my bugs otherwise? But until now I have failed to understand how the debugger actually helps me detecting memory leaks...
Also with no orbiter running, my cores are at about 50% max, so the export process appears to be running faster at least in terms of the files appearing every few minutes in the textures folder. I guess I cannot start Orbiter now and target this system as after targeting the MFD will start generating textures too.
Nope, if you click "save to cache" in the standalone, first action of the day is writing the system to the cache, then exporting cfgs, then textures. So you can target the system inside orbiter while export is running in the standalone. It will look up the cache, see that the system's listed, and not give a damn about wheather or not all the textures are already exported (if the cfg export isn't finished, that will result in a crash, but you'd be a hero in my book if you can target the system and hit the jump button before those are exported).
.....yeah GPU is the graphics processing unit which is on the graphics card if you have one. Its better at parallel algorithms, texturing quads etc. than the CPU.
!!
