[SOLVED for now] Good or bad practice?

[LJS]

To tie things together I create an object as a FrameListener and call it cGameObject. So within the frameRenderingQueued it can update the position from btTransform - later on (g)ui, audio and other stuff.

Would that be good or bad practice to have an enormouse amount of FrameListeners?

R,

[tod]

I tried to keep the frame listeners to a minimum, but in the end it's pretty much the same. In the frame listener I just call functions from other objects.

One aspect that comes to mind, when having only one frame listener, is the ability to skip processing some data each frame, in a more centralized matter. For example I could update NPC vision only 1 time every 10 frames. I can group this and other stuff in some "update less frequently" group. If all those objects would have been frame listeners each one of them would have to skip frames themselves.

[LJS]

Thanks for the valuable insight.

So it would be usefull for updating [s]physics[/s] transforms which bullet has calculated, which are needed every frame. On the other hand that could be done in several ways. However, creating a new void cGameObject::updatephysics( float deltatime ); would be just the same. So my conclusion is, think it over how you do what and where .

R,

[amartin]

Ok Updating parts of your graphics from multiple Framelisteners is one thing. Updating your physics engine using multple listeners is another thing. The first is only sort of bad since it's graphics code mixed with graphics code. More stuff to change if you want to flip things around. Depending on how you did it in the first place you may have to update those classes anyway. I would however not mix libraries more than necissary. It makes it much harder to change your mind on any single part. For something like physics I'd bring it all in through one place that way if later on you decide that you need to run the physics independant of the frame rate. You can do this without having to do too much digging.

I would recommend that in all cases when you use a library wrap the bits that you are using in your own code. This gives you a buffer between different libraries and makes updating be it to a new version or a different library easier.

I could go into more detail but I'll let a much better speaker than I explain that. http://vimeo.com/97530863

[LJS]

As long as you are a better speaker than me, you would be fine. See my previous post for an example, hehe.

Am not updating the physics, just the transforms. It is only reading from the physics engine. Have eddited my previous post.

Thanks for the link, will watch it in a minute.

R,

[LJS]

@amartin or anyone

Did you mean something like this?
Re: extending ogre with custom game classes

[amartin]

More or less what Kojack is saying don't make one object and put it into all the managers but also don't make the managers call other managers.

At some point you will probably have to update visual positions from the physics. You could have the visual manager you retrieve all the physics objects each frame and update the visual positions. Don't do that, use a bridging class in between. It's a subtle difference but having a class that uses the physics manager and the visual manager and goes through all the objects and updates the positions is better than having the physics manager or the visual manager call each other. If you suddenly want to have an object that has no physics it's easier this way you change the user of the manager not the manager so you know that part will keep working as it did before.

I hope that makes sense.

[LJS]

Think I get what you say; If so that would mean a massive change but on the other side - after fooling around to get back into ogre again - I just started so now is the time to change

Pseudo code:

Code: Select all

class InBetweenClass                // or encapsulating everything class
{
  OgreEasy::SimpleOgreInit* ogre;   // e.g. Mad Marx's
  BulletEngine*             bullet;
  GUI*                      gui
  vector< int / guid >      entity;
  function run
  {
    while( !ogre->RenderWindow->isClosed() )
    {
      bullet->stepworld
      iterate entity
      {
        gameObject = ogre->getByID( entity )
        bulletObj  = bullet->getByID( entity )
        if( bulletObj )
        {
          gameObject->setPos( bulletObj )
            panel  = gui->getPositionPanelByID( entity )
            panel->updateText( gameObject->getPos )
        }
      }
        gui->update
        Ogre::WindowEventUtilities::messagePump();
    }
  }
}

R,

[amartin]

Getting there but technically your InBetweenClass is a manager as this point because it is managing the connections. It's also mixing the responsibilities it should not be running the render loop and updating the objects. Something more along the lines of this I guess I'm kind of in a rush so this isn't valid code just a general idea of how I'd break that same block down.

Pseudo code:

Code: Select all

class InBetweenClass                // or encapsulating everything class
{
  this moves into GUI OgreEasy::SimpleOgreInit* ogre;   // e.g. Mad Marx's
  BulletEngine*             bullet;
  GUI*                      gui
  //vector< int / guid >      entity; Technically this list is a manager for the connections just make it proper manager.
  EntityManager* entity;
  function run
  {
    //start any extra threads like for example if you had network or physics threads here
    bullet->start();

    //put your frame listener in thats fine 
    ogre->FrameEnded(&this.Update)
    ogre->Run();
    // at this level we don't want to know how anything runs we just tell them to go.
   }

 function Update(double time)
{
      bullet->stepworld
      entity->Update
      gui->update
}

Class EntityManager
{
vector<pair< gameObject , bulletObj  >

  function Update
  {
    iterate entity
      {
        gameObject = pair.first
        bulletObj  = pair.second

        MyClass::Vector3 position =  MyClass::Vector3(bulletObj.position) // this is another of those in between classes it handles all the fun of physics to graphics vector conversions

         gameObject->setPos( position.ToOgreVector3)
      }
  }
}

[LJS]

Thank you, especially because you had to run. Nevermind real code, am aiming at the principle anyway. Digging into it, so this thread is done for now.

Moving Ogre into GUI makes sense as ogre is G)raphical and used by the U)ser and is so an I)nterface. Actually it is exactly that - ogre is a rendering engine, not game engine.

R,