Direction of next version of MOGRE

I'm considering what feature I should work next and I'm interested in the opinion that others may have. The options are:

1. Being able to extend Ogre classes - This won't require too much work (faster to get), most of the mechanism is implemented (there's limited support for this already for interfaces like Renderable, Node.Listener etc.). The downside is that for Mono support there's a good chance I may need to rewrite the mechanism later on.[/*:m]
   
2. Mono support - This will require the most work (longer time to get). I'm considering implementing a "framework" to help out with "portable C++/CLI code". It's only on theory at the moment, I've only did a bit of reading and little "experiments". (If it is possible, it won't depend on MOGRE and will likely end up on a separate sourceforge project.)[/*:m][/list:u]
   Anyway, the point is: which feature do you think is more important ? If you make a post stating your opinion I'll appreciate it.

What to you mean by extending Ogre classes ?
Rewriting some P/Invoked C++ Ogre classes in full .NET code ?
The most interesting thing for my work is to have the "best compatibilty" between the original C++ code and the wrapped .NET code.
I mean, when a new useful function is introduced in Ogre C++, I would like to have it in the .NET wrapper "as soon as possible".

Could you explain me the main principles your use to wrap in .NET a new Ogre C++ function. Is it a long and hard work ?

I have finished to port in Mogre a Xadeck Ogre C++ tutorial #4 concerning the construction of manual objects with texture mapping.
It works in C# windowed mode and I will try soon to use Windows Forms events for interaction.
If your are interested, I could send it to you in order to add it to Mogre tutorials section.

Thks for your great work.

What to you mean by extending Ogre classes ?
I mean being able to subclass a Mogre class and override its behaviour, thus "overriding" the Ogre class too. So stuff like this can be implemented.

I mean, when a new useful function is introduced in Ogre C++, I would like to have it in the .NET wrapper "as soon as possible".

Could you explain me the main principles your use to wrap in .NET a new Ogre C++ function. Is it a long and hard work ?
Nope, I made a utility to cover this. It parses the classes/methods and spits out the wrapping code automatically.

I have finished to port in Mogre a Xadeck Ogre C++ tutorial #4 concerning the construction of manual objects with texture mapping.
It works in C# windowed mode and I will try soon to use Windows Forms events for interaction.
If your are interested, I could send it to you in order to add it to Mogre tutorials section.
Thanks, that would be great

Option 3...

We need a unified approach to input. I've stopped with the tutorials (in part because of school), but also because I dont know the "Best Way" to handle input.

The winforms approach works well...aside from the fact that the program doesn't completely "capture" the mouse. Using windows mouse hooks as madmark suggested works, but it's complex and hard to fit into a tutorial.

If the user isn't using winforms (but instead opts to have ogre create the window for you), there's currently no way to get the mouse/key data out of Ogre. (A good decision, since the input system in ogre is poor.) Are you planning on wrapping OIS when eihort is finally released?

I'm at a bit of an impass in terms of what to do with the tutorials and input. I considered writing a wrapper around SDL as an example of how to do this (because it's what I use in my personal projects), but that just seems a bit much for a tutorial.

---

I guess my point in posting this is not that I want you to write a wrapper around OIS or some other input system (though an OIS wrapper would be very nice). Instead, if you have some time, would you mind helping me brainstorm on what is a good strategy for input in Mogre? The problem is twofold:

1. What we are currently doing with Winforms input is awful in terms of mouse input. It's perfect if we are writing a tool like Ogre Studio...but not for a game which tries to capture mouse input.

2. If we have Ogre create our render window for us, we don't have a good mechanism for getting the input out of there. It can be done with SDL, Managed DirectX (bad idea...lack of support), or something like OIS (no C# wrapper).

It would be very nice if we could figure out an input system which worked no matter if you are using winforms or if we let ogre create the render window for us....

If we can figure out a good way of "solving" this problem I'll work on turning it into a tutorial. For now I'll probably create a simple tutorial out of the winforms input system and come back to write another input tutorial later on.

Why not MDX1.1? I mean, sure it may not support the latest force feedback wheels, xbox controllers etc. but the tutorials won't be about input but about using a 3D engine; the input code will be just about capturing keyboard and mouse.

Of course the user will probably want to implement 'serious' input in his project, but it's up to him to go looking for a better input system, why complicate things for us

Another option would be to use the latest and greatest XNA input. An advantage with this approach is that there are people implementing the XNA namespace for Mono, so at least its input part will probably be cross-platform in the future. The disadvantage is that the user will need to get the XNA libraries, while MDX is common-place, I think, by now.

Afaik, MDX is not available at all on any other platform than windows (nor is XNA). Something like Tao.SDL (which already wraps SDL) or a wrapper port of OIS I feel is better than MDX. Why? Well, OIS for instance already has a pretty clean, and easy to use interface - DirectInput does not (maybe MDX is better?), OIS is already cross platform (Linux, Windows, OSX), and OIS is perfect for games

I don't know at this point what I want to do for a .net port of OIS - perhaps a CLI/C++ implementation, or maybe a MOIS type of progect, or maybe a SWIG'ed version. There is already a SWIG'ed version of OIS for python, so SWIG'ing it for .Net isn't too hard - nor is there a problem of casting, since you rarely need to cast stuff in OIS atm. OIS is small, so I think a pure CLI solution would be the least amount of work for the end user - no need for a wrapper.

Anyway, didn't mean to hijack your MOGRE poll... Just wanted to voice my Input on Input. Anway, I voted for Mono support, as I think that is a big deal to get MOGRE working under Linux

OIS is a perfect candidate for porting; small, stable and unlikely to change often (another example of such a project is OgreNewt).
If you had a poll of whether OIS should be ported or wrapped, I would vote for a port

Ok, thanks to all that voted.
Most people think that extending Ogre classes is more important and I have to agree with them; there are tons of useful staff that can be accomplished by subclassing Ogre classes.

On the other hand supporting Mono is very interesting "research topic" for me , so I'll probably put a bit of time on that area too.