Large map performance bottleneck

[shihonage]

Yar, we had a similar problem with Shelter. The solution was to only draw what will actually be displayed on the screen, making renderer's performance viewarea-dependent instead of mapsize-dependent.

[mvBarracuda]

Coolio shihonage :-)

It looks like the main problem is the rather messy FIFE view code so it's a bit hard to see where we actually should implement such an optimization and which consequences it will cause.

FIFE developer prock created a ticket for it and they'll try to look into it for their 0.3.2 release:
http://fife.trac.cvsdude.com/engine/ticket/419

[amo-ej1]

shihonage, I think that FIFE already renders what is supposed to be on the screen. The bottleneck however is figuring out _what_ should be rendered. Figuring out what should be rendered is iterating over a vector which is basicly O(n) and our n is getting very large. So there would be a more efficient implementation of that vector (e.g. early abort, sorting on spatial data, ...)

edit: the UH people came to the same conclusion as we did: http://logs.unknown-horizons.org/%23fife/%23fife.2009-Wed-22.log

[shihonage]

Our map data is a 2D array with a struct for each cell. The renderer merely goes through the "viewable area", checking each cell for graphics or index of Actor standing on it. When our actors move, they erase the index from the old cell and put it in the new cell on which they stepped.

It's not perfect, and we have our glitches, but this approach minimizes CPU load.

[mvBarracuda]

FIFE dev phoku is currently working on improving the view performance in a branch. See:
http://fife.trac.cvsdude.com/engine/changeset/3098
http://fife.trac.cvsdude.com/engine/browser/branches/active/view_performance

[mvBarracuda]

Alrighty, there's news from this front!

Phoku recently continued to work on his view_performance branch and it's basically ready for a larger scale test at this point. There are still bugs here and there to iron out, so it won't be merged to trunk right away. As four eyes see more than two, the FIFE devs would appreciate if devs of FIFE-based games could test the branch in combination with their game to see if they can find any bugs.

That's how you can test it yourself: Follow the instructions outlined here:
http://wiki.parpg.net/Download

However don't check out the FIFE code from:

http://fife.svn.cvsdude.com/engine/trunk/

But from:

http://fife.svn.cvsdude.com/engine/branches/active/view_performance/

Obviously you have to build the view performance branch of FIFE as you would build the trunk (win32 users will need to move the win32 devkit files into the right folder). Furtermore you'll also need to check out the PARPG files into <view_performance>/clients/parpg/ so that PARPG actually runs with this branch of FIFE and not trunk.

I had the chance to test the branch last night and results vary quite a lot from system to system.

On my win32 desktop system, I had 20-40fps with the techdemo1_ground_level.xml profiling map with FIFE's trunk. The same map runs much smoother with the view_performance branch, somewhere between 80-160fps.

On my win32 notebook, performance has "only" slightly improved though. The view_performance branch runs about 10-25% faster than FIFE's trunk.

So the purpose of this post is twofold: to encourage you to test the view_performance branch to see if you can find any bugs and to hear about your performance reports. In case there are quite a number of devs who can test the branch and provide feedback if there are any obvious bugs left, the code could find its way into the FIFE trunk before we release techdemo 1 of PARPG.

[amo-ej1]

When I run the large map on fife trunk I get 20-30 fps, with the changes in trunk I get about 200 fps (but then again we might wish to add the possibility to render the fps string inside the hud somewhere for  more easy reference. (This is in 1024x768, not fullscreen)

The only remark I have is that now I see some artifacts (apar from the PC and NPC's starting to dans at the same locatio), these artifacts are not obviously reproducible and not screenshotable so you may either believe me or think that i was drunk while seeing them.

What I see is the following ,when the PC is moving, i think mainly when starting or ending a movement i sometimes see black lines which oultine a horizontal/vertical/diagonal cut through the scene but still following the tile outlines. This occurs about once a minute, but i haven't found a real way to trigger this ... i don't believe I ever saw this on the trunk (not in the past, not on trunk (of parpg and fife)).