profiling freeorions sources?

[ssalamass]

well... first of all: greating to the community, since this is my first post . As probably most of the poeple here I am a great fan of Imperium galactica series etc.. so I really love this project. and I may contribute to it sometime by providing some patches... .
But one thing spoils the playing experience for me and that is the running speed of the program ( i have a pretty up-to-date-system dualcore2Ghz, decent ati-graphics, 1GB memory etc... so that's definitly not the problem.)
Is the most recent freeorion binary-version for windows (0.3. a debug version of the game? Is the speed rather a problem of the underlying graphics-engine? The two parts of the game that need speed improvements imho are

1. the calculation time for the AI's at the end of every Round.
2. the graphical interface

I mean... I am asking this question in the programmers forum, since I would be honored to help the project with this issue and try to provide a patch with some speed-improvements in speed-critical parts of the source code.

[m_k]

The newest version is 3.9 (incidentally released today, also see here)
but apart from that you can also try and compile the game from the newest source code in the svn (read the compile page for this), which is what you'll need to do to contribute to programming.

On the speed, the first thing you mentioned, the calculations at the end of the turn, for what I know this wasn't the AI calculation but the resolvement of the AI orders, because it simply submitted too many of them. You can produce the same effect by adding several dozens of items to the production queue, but this has been fixed with the first attempts of a real AI, so it shouldn't appear in new versions.
The other thing, the graphical interface, there the time isn't lost in the interface but mostly in some calculations like the remaining time in the production queue, these could be improved but I believe the general consensus is that they probably will be changed again several times anyway. So the main focus now is still on integrating new features, as long as the game is playable for tests, speed improvement, hunting bugs and memory leaks and all those things still have low priority and will probably mostly be done somewhere in 0.9. (At least this is my oppinion, if geoff or tzlaine tell you something otherwise they are the ones who are right)

[tzlaine]

m_K is correct. The priority for optimizations is very low. It has been my experience that premature optimization is the root of all evil. Do you like that? I just made it up. Just now. By myself.

Having said that, if I find that something that is running too slow is actually reducing playability enough to need optimization, I'll optimize. The MapWnd rendering code recently suffered a near-rewrite for optimization. If you would like to optimize something, feel free to do so and submit a patch.

BTW, what about the UI seems to need optimizing?

[The Silent One]

The tech screen.

[Geoff the Medio]

One TechTreeWnd optimization would be to avoid redoing the layout after every zoom. The relative positions of the techs and the lines connecting them won't have changed, so it shouldn't be necessary to recompute everything when a scaling would suffice. The layout is laso redone about five times when toggling the "All" button, leading to a half-second delay.

It would probably also help the general frame rate and tech screen lagginess even when not zooming or changing the filters if the galaxy map wasn't rendered while the research screen is open. (Just making the research screen non-transparent doesn't help.)

Another particularly noticable bit of lag is populating the buildable items list; when populating with the full set of unavailable and available buildings, it takes several seconds.

It would also be nice if opening the sidepanel didn't take several seconds when a new planet type is first seen, or in particular, when asteroids are first seen. Loading all the art hangs the program, and initially seems like a crash has happened. If this could be done in a background thread, either before or after the panel itself opens, (with the loaded art popping in over a few seconds while the UI still works), that'd be ideal.

[eleazar]

It would also be nice if opening the sidepanel didn't take several seconds when a new planet type is first seen, or in particular, when asteroids are first seen. Loading all the art hangs the program, and initially seems like a crash has happened. If this could be done in a background thread, either before or after the panel itself opens, (with the loaded art popping in over a few seconds while the UI still works), that'd be ideal.

In my experience this one is far and away the most noticeable and annoying lag in FO.

This could be optimized in part, by using asteroid animations that didn't weigh 3 megs each, i.e. had fewer frames, and/or saving the asteroid animation as some sort of compressed movie file.

[tzlaine]

It would also be nice if opening the sidepanel didn't take several seconds when a new planet type is first seen, or in particular, when asteroids are first seen. Loading all the art hangs the program, and initially seems like a crash has happened. If this could be done in a background thread, either before or after the panel itself opens, (with the loaded art popping in over a few seconds while the UI still works), that'd be ideal.

In my experience this one is far and away the most noticeable and annoying lag in FO.

This could be optimized in part, by using asteroid animations that didn't weigh 3 megs each, i.e. had fewer frames, and/or saving the asteroid animation as some sort of compressed movie file.

I agree this is annoying. We should just pre-load these. The 12 megs to store all 4 sets at 3 megs each is chump change on most modern systems. As for reducing the number of frames, we did, and it looked terrible. We're doing about as few now as we can get away with. And making them into a movie file means adding yet another library dependency, and writing code to integrate it with GG. In other words, "Patches welcome, because I won't be doing that."

[eleazar]

This could be optimized in part, by using asteroid animations that didn't weigh 3 megs each, i.e. had fewer frames, and/or saving the asteroid animation as some sort of compressed movie file.

I agree this is annoying. We should just pre-load these. The 12 megs to store all 4 sets at 3 megs each is chump change on most modern systems. As for reducing the number of frames, we did, and it looked terrible. We're doing about as few now as we can get away with. And making them into a movie file means adding yet another library dependency, and writing code to integrate it with GG. In other words, "Patches welcome, because I won't be doing that."

By "reducing the number of frames" i didn't mean "reducing the frame rate, which would indeed probably look bad, but decreasing the length of the sequence. By my rough calculations we have ~10 seconds of asteroids before the little sequence loops and starts over. Few people are going to watch the asteroids for 10 seconds to try and catch the loop point. If, for instance we only had 4 seconds worth of asteroids before it looped, i don't think anyone would notice.

Did pd make these? It would be a massive pain to try and edit the graphics as i'm suggesting without the 3D source files.

The whole folder takes up 21 megs on my system, due to the minimum file size of my HD, there's only 9 MB of data. I don't know graphics memory has "minimum file size issues"— either way it's still not a horribly huge amount of memory -- but it's still enough to be annoying to wait for.

[pd]

Yes, I did those. It was one of my first contributions I think. I'd welcome if the sequences could be pre-loaded by code.
Reducing the total frame amount(to 64 for example) would either mean, we have to speed up the animation and play it twice as fast which would kill the effect or I'd have to remove the big rocks, since they are the most obvious indicator of speed. I still have the source files, but I hope I'll never have to touch them again. They include 3-5 messy layered particle systems.

[Geoff the Medio]

I've always wondered why the asteroids can't be rendered 3D objects, like the planets are... Once Ogre is up and running in particular, I assume a model for asteroids could be used fairly easily...

[shrinkshooter]

I've always wondered why the asteroids can't be rendered 3D objects, like the planets are... Once Ogre is up and running in particular, I assume a model for asteroids could be used fairly easily...

They include 3-5 messy layered particle systems.

In short, they can be. It's probably more labor instensive though. It's much easier in programs to create a particle field and assign it properties than it is to make an asteroid in 3D, then resize it, copy it a gajillion times, and alter some of them so it looks like you have random, unique asteroids in a belt. Particle fields are, from what i can tell, probably much easier to control in animation of random entities than actual 3D objects.

However, you can make it so that the particles in a field actually ARE 3D objects. At least, you can in blender, so I assume everything else can too. I'm guessing this is what pd did for the belt, so unless I'm misunderstanding your...well, misunderstanding, I think the asteroids already are rendered 3D objects.

[pd]

Yes, particle systems with instanced geometry have been used. I don't think we can do this in ogre, as the polygon counts are quite high. That said, we will have to find a way to show asteroid belts in combat. Maybe a combination of geometry and sprites could work for this.

For the sidepanel I think the current way of doing it, provides the best results. Alternatively we could maybe show a single or very few roids with 3D meshes, which was perhaps what Geoff was suggesting.

[MareviQ]

As for asteroids I wonder if something like Paged Geometry plugin for Ogre would be applicable ( http://www.ogre3d.org/phpBB2/viewtopic.php?t=36655 ) - I mean, rendering huge forests and asteroid belts is a bit similar (lots of similar geometry, most likely static), or at least use Compiled Vertex Arrays (CVA, applicable OpenGL extension is EXT_compiled_vertex_array)

[pd]

Thanks for the link. Stuff like this is greatly appreciated as tzlaine and myself are rather inexperienced with Ogre.

The PagedGeometry engine is an add-on to the OGRE Graphics Engine, which provides highly optimized methods for rendering massive amounts of small meshes covering a possibly infinite area.

From this description at least, it sounds like it is worth a try. I'll browse through the documentation and have a look at the examples.

[tzlaine]

A couple of things to note. First, Ogre may turn out to be no help when doing the SidePanel graphics. This is not set in stone, but typically the fewer interactions between Ogre and GG, the better. Currently, all GUI (GG) stuff is done after all 3D (Ogre) stuff. Adding another pass where Ogre renders some stuff on top of the GUI may prove to be too complicated for my patchwork of hacks that allows GG and Ogre to coexist. For this reason, I'd like a very simple solution (i.e. like what we have now) for the asteroids. Does anyone object to merely preloading the asteroid graphics, as I've mentioned?

Second, the display of asteroids in the combat window is a totally separate issue. I don't know if the PagedGeometry scene manager is the right fit, because most of the time the asteroids will be large and visible, but distant. The planets, star, and ships are not to scale, or at least that is not the current plan. This means you will not usually have a view in which the asteroids make up most of the view. Then again, reading the description of PagedGeometry, it may in fact help, regardless of the presence of asteroids. I'll keep it in mind. In either case, we can try just use a handful of repeated bump-mapped asteroid meshes. If that proves too slow, we can try something else.