FreeGameDev

Hello again!

It's been a tough week at my job and I didn't have much time for testing OD and finding bugs. I think I've found a way to bypass the memory eating problem I had. As suggested by paul424 here (thanks pal!) the issue was caused by the CullingQuad class defined in QuadTree.h. I looked in the the code for every line in which this class was used and in the end I figured out that if you comment this line:

{l Code}: {l Select All Code}

tracingCullingQuad->moveEntryDelta(this,get2dPosition());

in method Creature::setPosition() the game becomes playable. I've played for some time and it looks fine (there are some issues of course, I'll try to gather information about them and post in the bugs forum) but you can play normally up to some point.

So I was wondering what is the CullingQuad class used for. I have no idea about graphics but I researched it a little and I understand its purpose is to track the position of the creatures in the map so they are not rendered in screen if the camera don't see them or if they are behind another object, like a wall. Then I found that Ogre seems to do this already without any modification. It has a pyramid that represents the field of view of the camera. Every object in that pyramid gets rendered, while those that are outside are not, thus saving rendering time. They call this a "frustum" (a pyramid that has had its top cut apparently? Sorry, English is not my mother language). I found some info here and here.

I haven't found any performance issues running the game this way. In fact my laptop has this nVidia Optimus technology (now pretty well supported in GNU/Linux thanks to the bumblebee project and primus, yeah Transformers, you know ) that switches between an Intel integrated card (mostly useless for games) and a more powerful nVidia chip. For OD I feel no difference between them as it runs perfectly smooth with the Intel chip.

Regards

Then I found that Ogre seems to do this already without any modification

It does , yet I found with this structure I won a few dozen FPS, no idea about current Ogre3d [1.8.1] as it constantly evolves ...
With one of the Ogre version , with only ogre3d Octree Culling and large playboard ( like 400 x 400 ) the game was limping at 2-7 fps.
So Ogre3d does culling , but you must check if he has done his task correctly ( that's just lazy, stupid Ogre, after all !).
It could be used for creature collision as well in near future .


Culling is the process of removing breeding animals from a group based on specific criteria. This is done either to reinforce certain desirable characteristics or to remove certain undesirable characteristics from the group. For livestock and wildlife alike, culling usually implies the killing of the removed animals.
http://en.wikipedia.org/wiki/Culling

If ogre does this already, which is what I thought, then it's probably best to remove the culling code alltogether.
I think just changing to use the octreeSceneManager plugin rather than the default one achieved a similar performance boost, so I don't see any reason to do the culling manually. And if not it should probably be done in an ogre plugin rather than game code anyhow.

IT SPEEDS UP THE OCTREEMANAGERPLUGIN.
It wouldt be even faster when fixing leaks and adding custom allocators .

I think I'll try to run OD on an older computer to see the difference between using the QuadTree or not. I understand OD is already using the OctreeSceneManager right? I found this in the plugins.cfg file:

{l Code}: {l Select All Code}

#Scene manager
Plugin=Plugin_OctreeSceneManager

And this in the constructor of ODFrameListener:

{l Code}: {l Select All Code}

Ogre::SceneManager* sceneManager =  ODApplication::getSingletonPtr()->getRoot()->createSceneManager("OctreeSceneManager", "SceneManager");

Different Ogre SceneManagers are descripted here and here. Maybe you guys can decide which one to use.

Paul, can you give us a clue on where do you think are the leaks on the code?

bool CullingQuad::moveEntryDelta( Creature* cc , const Ogre::Vector2& newPosition ) and bool CullingQuad::reinsert( Entry* ee ) both don't free nodes they should, I must look of they use case and decide which should do that ....
Besides is this somethign criticaily blocking a work for you ? I think not , and you could even fork from mine Quadtree and work without it , if it's such a big problem ....

The heatwaves are terrible in Poland == 36 degrees of C .
Regards....

Hi!

No, it's not blocking me for testing the rest of the code and finding bugs, working overtime is . Deleting the call to moveEntryDelta temporarily seems enough to make the game playable... almost. I'm finding some very ugly segmentation fault errors, I'll debug the code to find where the issue is.

We have a heatwave all over Europe. Here in Madrid it's 39-40 C, too hot even for Spain!