Insimnax Framework - A game framework for OGRE

[MrD]

The Insimnax Framework is the game framework I use when creating applications using OGRE. I've decided to release it in the hope that it will be useful to someone other than me.

It it licensed under the MIT license, and has been tested to build and run against OGRE 1.6 and 1.7 on Windows. I have tested that it builds on Linux, but was unable to test if it runs due to my lack of experience it getting CMake to do anything useful. I have no idea if it builds on OS X, and even if it does there are sections in the code that just say "//TODO: Figure out how to do this on OS X" since I don't own or have access to a Mac.

• Information
• Download
• API
• Wiki
• Forum

Have fun

Also, if anyone wants to help out with the Linux/OS X testing or CMake file writing it would be very much appreciated.

[nightmare]

Wow, excellent work, similar to the design approach I have been taking, but already implemented so may instead bring my threadable GameObject infrastructure over to this framework

[MrD]

Version 1.1.0 Released
Version 1.1.0 of ICL (Hapi) and the Insimnax Framework (Mihos) have now been released. They are available for download at the website and the release notes are listed below.

ICL:
Fixed:

• Loading strings with CDataReader not resetting the string before appending data to it in binary mode.

Added:

• CGUID to create version 4 UUIDs/GUIDs.

Framework:
Breaking:

• CWorld::create and CWorld::destroy have been renamed to CWorld::_create and CWorld::_destroy. Any classes deriving from CWorld which override these member functions will need to be updated. If you tagged your overridden member functions with INSIMNAX_OVERRIDE and use MSVC the compiler will point out these cases.
• Added an extra parameter to INodeBehaviour::_create to allow you to pass creation parameters. Any classes deriving from INodeBehaviour which override that member function will need to be updated. If you tagged your overridden member functions with INSIMNAX_OVERRIDE and use MSVC the compiler will point out these cases.

Fixed:

• Not being able to pass NULL to CWorld::reparentWorldNode to automatically attach to the root node.
• Some const issues with the reverse iterators used in CWorldStack.

Added:

• IWorldSystem; this is essentially a world level INodeBehaviour and lets you create re-usable logic blocks for use with worlds. (See CWorld::addWorldSystem and CWorld::removeWorldSystem).
• CWorld::detachWorldNode to allow you to detach a world node from the scene.

[buckED]

Hey MrD.

I had a look on your framework. Quite some code to read and understand there.
Anyway. Since I am currently in the process of designing the input end of my framework I was especially interested in what you did in this area.
I think that I understand most of whats going on there. The InputMaps are what catches my interest, since I am looking for a generic way of mapping
input to actions.

This may sound incredibly dumb, or maybe I just missed it, but in your examples I didn't even see the InputMap used.

So here's my question. Do you use the InputMaps in your examples in some way that I just missed completely? If that's not the case and you just designed the examples
to work without InputMaps, is there any chance you could provide a simple sample on how these would be used in an actual application?

[MrD]

No, the InputMap isn't used in any of the example code. TBH, although I liked the initial design of the InputMap by having it use delegates to provide callbacks, in practice I've found it more fiddly to use than I expected it to and have though about changing it to something you can query by action ID which will return true or false if an action should run (as well as a context value, such as a stick offset for some inputs).

I've just moved into a new flat and don't have the internet yet, but hopefully I should do by the weekend and can post you an example then.

[buckED]

That'd be great.

But don't rush it. I will be waiting patiently.

[MrD]

Ok, this is how it currently works. Honestly, the more I look at this solution, the less I like it (I like the general principal of generic action mapping, I just dislike my implementation; one thing I would like to add is a generic concept of controllers for both physical controllers like a keyboard, and logic controllers like an AI agent, or network stream so that they can utilise the same code path).

Code: Select all

//! Enum of your action IDs, these can be anything as long as they are unique within the key map
enum MyActionID
{
   MYACTIONID_SOMETHING,
};

//! Just an example class, could be anything really
class MyClass
{
   public:
      MyClass()
      {
         // Register the S key on the keyboard to do the something action
         m_inputMap.addKeyboardKey(OIS::KC_S, MYACTIONID_SOMETHING);

         // Register the A button on the 0th 360 controller to do the something action
         m_inputMap.addJoyStickButton(0, EXBOX360BUTTON_A, MYACTIONID_SOMETHING);

         // Bound the something action to the something callback
         m_inputMap.assignActionCallback(MYACTIONID_SOMETHING, TInputMapCallback(this, &CCorridorTestGame::somethingCallback));
      }

      void update(const float deltaTime)
      {
         // Each update you would call processInputMap to check the current input state and perform any callbacks
         m_inputMap.processInputMap(deltaTime);
      }

   private:
      CInputMap m_inputMap;

      void somethingCallback(
         const SInputMapCallbackInfo &info   //!< Input info
         )
      {
         // You would handle your input here
      }
};

Now the main thing I dislike about this is that to handle any info more complex than a button press, you have to actually know what produced the input (from the callback info) which defeats the point of the abstraction. I have used another library which got around this by using a context float value that would be set to something relevant for the input; for instance, if you bound your movement to a keyboard button and a joystick, when input was received from the button the context value would be 1.0f, but when it was received from a joystick it would be the offset of the joystick normalised between 0.0f and 1.0f. This meant to handle movement you just had to multiply your desired speed by the context float in order to get the speed the player wanted.

[buckED]

Thanks a lot for that sample MrD.

I think this will be really useful to me.