idea: new C# wrapper which supports Linux, MacOS, etc.

In the big thread Seeking for a new maintainer started a discussion about a new C# wrapper, which supports Mono and by this additionally Linux, MacOS, iPhone, etc.

To improve the overview I created this new thread.
Related parts of the discussion I quote here. (hidden between other discussions)
Following wrapper discussion posts I moved here.

(This was a note by moderator Beauty)



Another fine idea: I could code a SDK maintenance utility combining all common maintenance tasks like building the SDK from a fresh compilation of MOGRE and so on.
A new all-in-one smart autowrapper tool would also be useful for future development.

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.


A new all-in-one smart autowrapper tool would also be useful for future development.

I don't see any problems with the autowrapper at the moment. It might not be the best solution because it needs more than just a click on a button to create the wrapper code, but it gets the job done and is, in my opinion, very easy to understand and extend.

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.

I think the only valid reason for creating everything new from scratch is to change the wrapper from C++/CLI to P/Invoke to make it compatible with Mono to support other platforms than Windows. I used and modified many different wrappers in the past, from simple C++/CLI wrappers to swig-based wrappers for commercial software and libraries that needed to support Windows and Linux/Mono.
In my opinion Mogre has a very clean structure and is incredible stable in most cases. We should not change a running system, but focus on fixing bugs in the codebase now to create a stable release as soon as possible.



A new all-in-one smart autowrapper tool would also be useful for future development.
Bekas (the author of Mogre) wrote, that his wrapper was just a dirty quick hack. If he would do the same job again, then he would do it much more better. But I don't know which details he mean. And I don't know if it's much work. But I think - our people had big problems to update the current wrapper code from Mogre 1.4 to 1.5. Maybe it will be more complex to start over for a new wrapper. Also - would the current Mogre applications be compatible to the new wrapper output?

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.
I can't talk about this. I have no C++ experience. When I tried to update the MogreNewt wrapper to my own I had much trouble. The lines are looking easy, but it was hard. For example I didn't know for which wrapped function I need * or ^ (managed/unmanaged pointers).
Marioco was working on a tool for autowrapping add-ons. Maybe this was the same project for autowrapping Mogre, too. He is out of the project, but if you really want to do such a job - we could contact him and ask for his code. He never published it, because it was not ready. (......... just in the moment I wrote Marioce a message and invated him to discuss here, too)


I think the only valid reason for creating everything new from scratch is to change the wrapper from C++/CLI to P/Invoke to make it compatible with Mono to support other platforms than Windows. I used and modified many different wrappers in the past, from simple C++/CLI wrappers to swig-based wrappers for commercial software and libraries that needed to support Windows and Linux/Mono.
In my opinion Mogre has a very clean structure and is incredible stable in most cases. We should not change a running system, but focus on fixing bugs in the codebase now to create a stable release as soon as possible.
Very good words. Also it's great to hear this assessment from somebody who has much experience with it.
If there is any real plan to create a P/Invoke wrapper - user boyamer wrote a C# wrapper by hand for his
Alimer Game Engine. He could be asked if somethimes this job is in progress.
User Wolfmanfx created an autowrapper by SWIG using P/invoke (similar to OgreDotNet). I suppose he didn't publish it.
About one year ago there was also a group of people offering help in revive the OgreDotNet wrapper method (by SWIG). The discussion was in the thread Mogre and OgreDotNet -- combine forces?

Currently I would say a new autowrapper is no important focus.
I just wanted to let you know about interesting people. So you have contact persons for further plans





By the way - does somebody has experience with the Axiom engine? It's a full C# port of Ogre and works on Mono. The last update was March 2010. So it's still not outdated.
Is the usage very different to Mogre? If not, maybe there is some stuff we could adopt (e.g. demos).

I used axiom long (,long,long ) time ago, before switching to OgreDotNet, before switching to Mogre. I don't know about their new releases but in the past there was always the problem most ports have compared to wrappers, they stay behind development for one or more versions. The last time I read something about axiom was when were still aiming at porting Ogre 1.2 when Ogre 1.6 was already released.

I think that Axiom would be something I would take a closer look at, if I wanted to target XNA on XBox or Linux without using the outdated OgreDotNet wrapper. It might be the best solution for somebody when the target platform won't support native libraries (like XNA for XBox).

On the pro side, my experience with Axiom was that it was always the easiest way to use Ogre in a .NET environment. For me it was even faster than the native C++ version of Ogre in some cases, maybe because the .NET JIT can do some pretty nice optimizations that are not (easily) possible with a C++ compiler. So I think, if you don't need the latest features of Ogre and just want some easy way to bring some 3D on screen with .NET, Axiom might be a good choice for you.

By the way - does somebody has experience with the Axiom engine? It's a full C# port of Ogre and works on Mono. The last update was March 2010. So it's still not outdated. Is the usage very different to Mogre? If not, maybe there is some stuff we could adopt (e.g. demos).

What I find especially appealing about Axiom (at least from the first look) is that it runs on Mono and therefor on MacOSX and on Linux. OgreDotNet is no substitute for Axiom as it's no longer developed, or am I wrong?

Hi to all,
I would take part of this long process.
Well yes,into Alimer Engine i have created full PINVOKE wrapper,updated to Ogre 1.8 (from trunk),and i had even fully ported the Paging Component and wrapped PagingTerrain and RTSS component system,for me won't be any problem create this process for Mogre too,in that way we would have Mogre running on Windows, OSX and Linux (throught Mono project), IPhone through MonoTouch, Android through MonoAndroid and so on.
I would like to see anyone else helping me out,so we could start working on full cross platform Mogre version.

As for Axiom,watch the license terms,its still LPGL and stands out on 1.2 Ogre version,but everyone can give a try on it.

Tell me what you think about.

Thank,
Amer Koleci

Well yes,into Alimer Engine i have created full PINVOKE wrapper,updated to Ogre 1.8 (from trunk),and i had even fully ported the Paging Component and wrapped PagingTerrain and RTSS component system,for me won't be any problem create this process for Mogre too,in that way we would have Mogre running on Windows, OSX and Linux (throught Mono project), IPhone through MonoTouch, Android through MonoAndroid and so on.
I would like to see anyone else helping me out,so we could start working on full cross platform Mogre version.

It would be nice to have support for MacOXS and Linux in Mogre. Perhaps we could use C++/CLI for Windows and PInvoke for Linux/MacOSX (where C++/CLI is not available). Not sure, however, if both approaches can be integrated in the same infrastructure easy enough.

In my opinion it would be really great to have a wrapper for Ogre that also works on other platforms than Windows. OgreDotNet did a good job in the past, but the project died long time ago. But I don't really know if this (portable) wrapper should be Mogre.

Mogre uses C++/CLI which has some nice advantages over P/Invoke. It's a much tighter integration which can make a lot of things easier. On the downside you need to modify Ogre source itself and it only works on Windows with MS.NET (so far).

What I would really like to see is this (I think MyGUI does something quite similar): The wrapper generator can create two kinds of wrappings, one for C++/CLI and the other one for P/Invoke. The P/Invoke version also requires a pure C++ layer that will "flatten" the C++ API to plain C calls. This allows to generate a C++/CLI wrapper to use on Windows and a P/Invoke wrapper that can be used on any platform that supports at least Mono.

@boyamer: Are you planning on releasing the sourcecode of your P/Invoke wrapper? If that's the case I would really like to discuss with you some way to integrate everything in one big wrapper project.

@everyone: What is your opinion about this? Would you like to see a combined wrapper that can generate both types of wrapper layer or do you think the projects should be kept separate?

Nope i won't release my PINVOKE code because i have modified Ogre version and various changed this for my game engine
(http://www.ogre3d.org/forums/viewtopic.php?f=11&t=57833), but i would use my version to create a Mogre wrapper,so i will fully help out on wrapping using PINVOKE,other thing i like is the inheritance of PINVOKE,for example,currently in Mogre you can create your own MovableObject or override SimpleRenderable,using PINVOKE i had done this.

Tell me what you think.

Amer

@everyone: What is your opinion about this? Would you like to see a combined wrapper that can generate both types of wrapper layer or do you think the projects should be kept separate?

I think it would be better to keep those two wrappers in the same project, if possible. This way both versions could be kept up-to-date together and there is less a "risk" that the versions would develop in ... different directions. But in the end I think both approachs should at least share the same name to avoid confusion with just another C# ogre port.

I agree that the best way to do this is to have a wrapper generator that can generate both approaches (C++/CLI and PInvoke).

@boyamer:
Ok, then I don't think that we should use this to create a P/Invoke wrapper. The great thing about Mogre (and OgreDotNet in the past) is and was always that the sourcecode was available and everybody can create their own modifications as necessary. Even if you use your closed source tools to generate code that could be released, nobody else would be able to re-generate the code because your source code is closed.

Don't get me wrong, I really appreciate any help that anybody will provide for Mogre, but I think this should stay completely open source and only use tools that can be customized by everybody. As far as I understand your engine, it's a commercial engine that your company sells. So we would depend on your company to stay in business or the P/Invoke wrapper would die with it.

Let's just wait for some more opinions from other Mogre users, then we can discuss which options might make sense.

You don't understand me,
1) AlimerEngine pinvoke wrapper won't be released (Because all difference i've made into Ogre core)
2) I will create open source PINVOKE wrapper for Ogre
3) Whole source code will be released.
4) Separate AlimerEngine from Mogre, they will be 2 separated project.

So this means that we will have full open source MIT license Mogre wrapper
Hope you understand now

Thanks

2) I will create open source PINVOKE wrapper for Ogre

How? Manually? Or are you using any tools for this? And in that case: Are those tools open source (or at least freeware)?

@boyamer:

Ok, I apologize. I didn't get you right the first time. This would work very well, if all sourcecode is released then I'm more than happy to discuss ways to make this project happen.

I think that manski already had a very good point in mentioning that all wrapper code from one generator also implies that both wrapper types can take advantage of all development progress in the project. I'm currently not able to put too much time into Mogre, but I'll be back next weekend. So if everybody else can share their thoughts about this in these forums we can start talking about technical details at the weekend.

I also recommend to take a look at the MyGUI wrappers that are available from the MyGUI sourcecode repository. I realy like the way they organized their wrapper generator in a way that allows them to create a C++/CLI wrapper and a P/Invoke wrapper.

OgreDotNet is no substitute for Axiom as it's no longer developed, or am I wrong?
The maintainer of OgreDotNet switched to Python-Ogre and the development / update process stopped.
So the C# users used Mogre instead.
Maybe it's easy to update OgreDotNet to the current Ogre version. (Some boys did it about 1..2 years ago.) But I can't tell you more. I never used OgreDotNet and I don't know how usable it is. And I suppose all needed add-ons have to be updated, too.


Hi to all,
I would take part of this long process. [...]
I would like to see anyone else helping me out,so we could start working on full cross platform Mogre version.
Nice to see you here (-:
If we want to create a PINVOKE wrapper your help and experience would be welcome!


In my opinion it would be really great to have a wrapper for Ogre that also works on other platforms than Windows. OgreDotNet did a good job in the past, but the project died long time ago. But I don't really know if this (portable) wrapper should be Mogre.

Mogre uses C++/CLI which has some nice advantages over P/Invoke. It's a much tighter integration which can make a lot of things easier. On the downside you need to modify Ogre source itself and it only works on Windows with MS.NET (so far).

What I would really like to see is this (I think MyGUI does something quite similar): The wrapper generator can create two kinds of wrappings, one for C++/CLI and the other one for P/Invoke. The P/Invoke version also requires a pure C++ layer that will "flatten" the C++ API to plain C calls. This allows to generate a C++/CLI wrapper to use on Windows and a P/Invoke wrapper that can be used on any platform that supports at least Mono.

[...]
@everyone: What is your opinion about this? Would you like to see a combined wrapper that can generate both types of wrapper layer or do you think the projects should be kept separate?

Generally it would be fine to support other operation systems than Windows. (I only use Windows, but I'm thinking global.)

A combined wrapper sounds interesting. But maybe it's more complex and difficult to create and maintain it.

I'm a little bit afraid of the possibility that the both wrappers have no fully compatible syntax. For example the methods names. (e.g. my.method() for C++ and my.Method() for Mogre)
Also for several Ogre methods (e.g. my.getProperty() and my.setProperty()) Mogre uses properties instead (e.g. my.Property).

When the new wrapper uses a different syntax or member structure then I think, our (small?) C# community will be splitted. This would be not nice for further development. When somebody create or update an add-on, only one part of the C# users have an advantage of it. Also the documentation, tutorials and the SDK would need a fork (with maintain effort).

So when we create a new wrapper, I would prefer a new name for it.

How big is the chance to keep the new wrapper compatible to the current Mogre version?
What are the disadvantages of that way?
(maybe it increases the effort for a wrapper update or makes trouble)

Maybe we can learn from the OgreDotNet wrapper process?

Marioco started to write a new wrapper some time (~1 year) ago. I don't know if it uses PINVOKE. He said with his wrapper it would be possible to autowrap Ogre and also it's add-ons. His (unready) wrapper would also be a good template for looking how a wrapper can be realized. Also Mariocos experience and problem report could be helpful when we create a new wrapper from the scratch.
Some days ago I wrote him a message. Unfortunately he didn't answered here.

Also I will invate Bekas to this discussion. He is the creator of Mogre and his thoughts could be useful.


But in the end I think both approachs should at least share the same name to avoid confusion with just another C# ogre port.
A port is when you re-write the whole Ogre core from C++ to C# (as done with Axiom).
A wrapper is like a translater. So you can use the original C++ library. Only for API changes you need to update the wrapper.
Just to let you know


2) I will create open source PINVOKE wrapper for Ogre
How? Manually? Or are you using any tools for this? And in that case: Are those tools open source (or at least freeware)?
Currently he wrote the whole wrapper manually.
But there are tools available wich support automatically wrapping.
A widespread tool is SWIG (as used by OgreDotNet).
An other one is cpp2java (as used by Mogre in a modified way).
Others are also available I suppose. More I can't tell you about .

By the way - does cpp2java supports only C++/CLI wrapping? Or is it also usable for P/Invoke wrapping?

Just to keep you informed,i've started creating PINVOKE wrapper of Ogre.

Will post code later..

I'm interested in details.
Do you write it from the scratch?
Do you use a tools like SWIG?
In you thread about the Alimer engine you wrote you prefer to do all wrappings by hand. Did you change you opinion?
I can't help with development, because I have no C++ knowledge, but I will follow you with interest

I'm interested in details.
Do you write it from the scratch?
Do you use a tools like SWIG?
In you thread about the Alimer engine you wrote you prefer to do all wrappings by hand. Did you change you opinion?
I can't help with development, because I have no C++ knowledge, but I will follow you with interest

Hand by hand as i want to have it full optimized:
with SWIG you have 2 instances when calling the same method,example:


RenderTarget rtt1 = Viewport.Target;
RenderTarget rtt2 = Viewport.Target;

rtt1 is not the same as rtt2


But into the wrapper i'm doing the optimization,caching the same classes and not having two instances that means the same thing.

I'm a little bit afraid of the possibility that the both wrappers have no fully compatible syntax. For example the methods names. (e.g. my.method() for C++ and my.Method() for Mogre)
Also for several Ogre methods (e.g. my.getProperty() and my.setProperty()) Mogre uses properties instead (e.g. my.Property).

That's the nice thing about creating both wrappers from the same source and wrapping methods. We can easily make sure that the interfaces will be the same, something that's very hard to ensure with two separate projects.

A widespread tool is SWIG (as used by OgreDotNet).
An other one is cpp2java (as used by Mogre in a modified way).
Others are also available I suppose. More I can't tell you about .

By the way - does cpp2java supports only C++/CLI wrapping? Or is it also usable for P/Invoke wrapping?

I've personally used SWIG a lot for my job in the past. It's a very powerful wrapper generator, but it has some serious disadvantages that makes it hard to work with the wrapped interfaces.
As far as I understand the current wrapping process, the C++/CLI code is generated by autowrapper after the files are preprocessed with cpp2java. My idea was to create a new autowrapper (or extend the existing one) to generate P/Invoke wrapper code from the same source files that are currently used by autowrapper to generate the C++/CLI code.

Hand by hand as i want to have it full optimized:
with SWIG you have 2 instances when calling the same method,example:


That's true for a default wrapper generated by SWIG. There are also ways to fix this in the wrapper, but they are not so easy to accomplish.

@boyamer: I really appreciate your help in generating a P/Invoke wrapper for Ogre. But I think we (everybody in this forum) should discuss the way to do this first, if we want a combined C++/CLI & P/Invoke wrapper in the Mogre project. Otherwise we would end up with two separate projects that have not much in common and should also have different names.
Just creating a wrapper that uses P/Invoke without making sure that everything is generated from the same source information and with the same wrapping rules (handling of properties, naming conventions, ...) will just create an update OgreDotNet. It will work and it will also be great for everybody who does not only want to support Windows,
but users (developers) will not be able to just switch between the two with out changes in their code.

Hand by hand as i want to have it full optimized:

Though this is nice if it works, this approach makes it much more harder to keep Mogre (PInvoke) uptodate - at least I would think so. I'd suggest an auto-generated solution whereever possible (if possible) so that new Ogre version can be adopted more easily.

I'm currently refractoring and documenting the whole AutoWrap code (which is quite hard as there's virtually no documentation at all in the code nor elsewhere). Perhaps this then could be used as starting point for creating a PInvoke wrapper but there's still a long way to go. You can check on the progress here:

http://bitbucket.org/manski/mymogre/ (branch: autowrap-dev)

@boyamer: I really appreciate your help in generating a P/Invoke wrapper for Ogre. But I think we (everybody in this forum) should discuss the way to do this first, if we want a combined C++/CLI & P/Invoke wrapper in the Mogre project. Otherwise we would end up with two separate projects that have not much in common and should also have different names.
Just creating a wrapper that uses P/Invoke without making sure that everything is generated from the same source information and with the same wrapping rules (handling of properties, naming conventions, ...) will just create an update OgreDotNet. It will work and it will also be great for everybody who does not only want to support Windows,
but users (developers) will not be able to just switch between the two with out changes in their code.

Yes, the work of boyamer is a great support.
But I agree, to mstoyke.
An important disadvantage would be that add-on developer would also need to write 2 seperate versions of their add-ons. I suppose many add-on developers would only support one wrapper type (which he personally uses). So the add-ons wouldn't be available for the users of the other wrapper type. This is one thing I worry about.

The mstoyke idea of one multiple wrapper generator with 2 outputs generally sounds nice.
I don't know the needed effort for such a project. Maybe this would imply some other disadvantages. Also this could increase the effort to write the new wrapper.
Boyamer - what do you think about the idea of a multiple wrapper generator?
What are the disadvantages of such a generator in your eyes? (you have good wrapper experiences - so I like to hear your opinion.)


I'm currently refractoring and documenting the whole AutoWrap code (which is quite hard as there's virtually no documentation at all in the code nor elsewhere). Perhaps this then could be used as starting point for creating a PInvoke wrapper but there's still a long way to go. You can check on the progress here:

http://bitbucket.org/manski/mymogre/ (branch: autowrap-dev)
Great work

This is the first detailed documentation for the wrapping process.
Maybe the wiki would be a better place (e.g. for markup, overview, spontaneous correction edits), but this possibly could be done later.
On the other hand a redundant description could be bad to maintain.
Well, we will see.
Best is to HAVE such a documentation. Thanks !!

The wrapper documentation is a little bit hidden. Here are the direct links:
http://bitbucket.org/manski/mymogre/src/tip/build.txt (main doku)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/AutoWrap/readme.txt (main doku)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/cpp2java/readme.txt (tiny notes)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/mogre_xml/readme.txt (tiny notes)


@manski: Do you have wrapper experiences or is Mogre your first project to learn how wrappers work in detail?

Sorry for my late replies - currently I have no internet connection at home.

Hi guyz

Very interesting thread!
I'm really looking forward to a correct Axiom or a correct C# wrapper which supports Linux, MacOS, etc.
At home, I use both linux and Windows. In one of the games I'm developping, I can easily swith to AXIOM or Mogre with some

#if AXIOM
...
#else
...
#endif


With AXIOM mode, it is nearly fully working on linux. Only the mouse and keyboard support are missing.
Currently I haven't much freetime but if I can help you writing wrapper or some tools, I would really appreciate!
I haven't read everything in this thread yet but I will come back soon.
Keep on that way!

Greetings from Belgium

This is the first detailed documentation for the wrapping process.
Maybe the wiki would be a better place (e.g. for markup, overview, spontaneous correction edits), but this possibly could be done later.
On the other hand a redundant description could be bad to maintain.

In my opinion, this is one of the big difficult decisions in creating a software. The wiki can present the content better than a text file (with images, bold text, code snippets, ...) but it's not tied to each version of the software. If something changes in AutoWrap (which needs the documentation to be updated), the wiki will be updated for the most recent version of AutoWrap but there is no easy way to link a certain (older) revision of AutoWrap to a certain version of a wiki page. A very prominent example are the "How to build MOGRE" page where there is a page for each MOGRE version.

On the other hand one could keep the documentation in the code repository and would never have this problem (i.e. the documentation would always fit the current AutoWrap revision - if updated properly). This becomes more important, if the project (such as AutoWrap) has no explicit versions (unlike MOGRE). However, using a text file as documentation is not nearly as good as a good formatted wiki page (as mentioned above).

I'm not sure which version is the better one. Currently I'm tending towards the text file version but mainly because I don't want to fill the wiki with my development stuff. With a text file I can update it while the development is progressing without concerning myself of breaking/Invalidating an existing documentation (in the wiki). Any comments on this would be appreciated.

@manski: Do you have wrapper experiences or is Mogre your first project to learn how wrappers work in detail?

I'm not sure what to answer here. I know what a wrapper (in common programming language terms) means and how to write a wrapper for a class. But I've nearly no experience with MOGRE's wrapper system. I'm still trying to understand what each wrapping type actually does (and especially where the differences between seemingly identical types are).

A very prominent example are the "How to build MOGRE" page where there is a page for each MOGRE version.
This was my idea

But your argument for the documentation revision is also qualified.

Hi,
how is this new wrapper project/idea going? It sure would be nice to have Mogre support linux and mac too (and maybe others too which uses mono).

We are currently focused on extending the existing Mogre wrapper to support missing features. A new or extended wrapper that also supports other platforms than Windows is still under consideration, but it will take some time before we can even start to work on it.

I think it's important to support other platforms in the future, but at the moment there is a higher demand for features like support for the new terrain component and other missing parts of Ogre.

Don't expect too much too soon. Creating and maintaining a working wrapper is hard work and supporting more than one target platform is even harder.

I agree. From time to time I'm working on Mogre's wrapper generator but it's slow work (as unfortunately there is little to no documentation in its source code). I think it there is a good chance that the rewritten wrapper generator can be adopted to create a PInvoke wrapper. In fact that's one of the goals I keep in mind when rewriting the source code. But how good this will work we'll see when I'm finished and when nobody else came up with a different way by then.

Hi all,

Just wanted to say that I'm really happy that I see Mogre buzzing with activity, that's awesome!

I also offer my apologies to manski for dealing with some gruesome code and my admiration for his abilities to do so!
It's a bit embarrassing that I had to release its source at this state.

I took a look at manski's modifications to the generator and they were great!

Hi all,

Just wanted to say that I'm really happy that I see Mogre buzzing with activity, that's awesome!

I also offer my apologies to manski for dealing with some gruesome code and my admiration for his abilities to do so!
It's a bit embarrassing that I had to release its source at this state.

I took a look at manski's modifications to the generator and they were great!
Hello Bekas,

good to see that you're still around. We are trying hard to keep this great piece of software that you started alive.

I also had the "pleasure" to dive into the wrapper generator code to fix some issues for the terrain wrapper and it's still some work left before it will wrap all terrain functions properly. The code is not that bad, it just lacks a lot of comments so people can understand the inner workings easier.

After working on the wrapper for some time now, I would really like to see more components and add-ons wrapped with it, but I'm not sure yet how much work it would be to update it to support other libraries. I think the biggest issue might be that you need to modify the C++ sourcecode of a module to support the CLRHandle stuff properly.

I will soon take some time to review the code changes that manski made. Then I will merge them into the official repository and I think manski might very soon have write access to the repository I just need to make sure first that his changes will not break the code changes that were necessary for the new components.

Hey mstoyke, you deserve lots of kudos for instilling new life in Mogre, many thanks!

I think the biggest issue might be that you need to modify the C++ sourcecode of a module to support the CLRHandle stuff properly
Yeah, that's a disadvantage but I think getting the correct CLR object from a function call worths it. Manually casting types, like when using SWIG, is a big no-no for me.

Hey mstoyke, you deserve lots of kudos for instilling new life in Mogre, many thanks!
The project you started helped me a lot in the past to get some prototypes and tools done quickly without causing too much pain, so I really enjoy having the opportunity to do this. In my opinion this is the idea behind most open source projects and doing this for Mogre is my way to say "thank you" for making my life easier. As many other programmers, I'm a lazy person and Mogre helped me to get the problem solved without reinventing the wheel.

I think the biggest issue might be that you need to modify the C++ sourcecode of a module to support the CLRHandle stuff properly
Yeah, that's a disadvantage but I think getting the correct CLR object from a function call worths it. Manually casting types, like when using SWIG, is a big no-no for me.
I agree that SWIG is not handling this well. I used SWIG a lot in the past and it was always a painful experience, but if I can find another solution that does not need changes in the code of Ogre (or other libraries that I want to use), it would make wrapping them much easier and more libraries could be wrapped.

I think it works very well the way it is, but it would be nice if it were an option, not a requirement, to change Ogre. There is a discussion about Mono support going on and one of my long term goals is to extend the wrapper in a way that allows to create a C++/CLI wrapper and a P/Invoke wrapper with the same tools. If we ever get this started I will certainly look into alternatives that are easy to use and don't need code changes in the Ogre code.

The SlimDX team did a great job dealing with this issue and they don't have the opportunity to change DirectX in any way. I found a problem in their code some time ago that was related to a similar problem, so I already got some ideas how this could be handled in a reliable way.

Hey guys,

I'm glad you like the changes I made to the AutoWrap code (and I'm even more glad that the original author likes them, too).

@Bekas: If you have the time, I'd like to ask you some questions about your code; just to understand some classes more easily (one example: what's a native director??) I'm sure I would figure them out eventually but things would go a lot faster with some help of the original author. PM would be great, but some IM (ICQ, Skype, you name it) would be even greater. We can discuss this in PM, though. Just say, wether it's ok with you.

I will soon take some time to review the code changes that manski made. Then I will merge them into the official repository and I think manski might very soon have write access to the repository

I'm not sure whether you really want to review all code changes (as there are many) As for the code changes: I'm trying to be very careful about all code changes. Therefore before I commit a change, I always regenerate the whole MOGRE source code and compare it with the previous version. This way I can ensure that I don't introduce bugs/code that changes the code generation in some unwanted way. (This make the code rewrite much easier btw as the MOGRE code is my test suite.) However, it's still possible that I introduce bugs (by mistake, of course) in methods that aren't currently used for MOGRE's code generation. In this case (as in all others) any feedback is appreciated.

Regarding merging the code into the official repository: There are some changes that you should be aware of:

1. I've slightly changed the UI so screenshots and tutorials need to be updated.[/*:m]
   
2. I've reformatted some files of AutoWrap's code with my own styleguide. So some files are still in Bekas' style and some in mine. Sorry about that but Visual Studio is simply a horrible IDE (in some places) and doesn't allow me to specify a code style on a per-project- or per-solution-basis.[/*:m]
   
3. Currently the generated code will use two spaces instead of one tab for indention (I'm not a big fan of tabs as everyone has different tab widths) and use Windows line endings (instead of Linux line endings), though this is configurable.[/*:m]
   
4. The biggest changes (so far) is that my AutoWrap implementation creates set accessors for boolean property (where the old implementation create set methods). You can find the change to the code in changeset f24fcc3ed3fc. This is change is important as it breaks backward compatibility. I did this code change, as IMHO the code now does the correct thing.[/*:m][/list:u]
   
   I just need to make sure first that his changes will not break the code changes that were necessary for the new components.
   
   Do you mean changes you made to AutoWrap itself or changes to MOGRE's code?
   
   Just my 2 cents.

Good boy.
I'm happy to see how active our Mogre project is.
Now we have several people who has the focus on different parts of Mogre.

my AutoWrap implementation creates set accessors for boolean property (where the old implementation create set methods)
I like C# properties (instead of setSomething, getSomething methods).
For the backward compatibility I don't care so much. But it's good to write a changelog on a public place (as done for Ogre main, like CthughaNotes).
In the past we had tiny API changes (like the remove of SceneNode.WorldPosition). When the people know, then it's no problem.

We could create a Mogre changelog wiki page which includes important changes.
On the other hand this always should be updated. Alternatively we could have a changelog in the repository (although it's only plain text). Redundant changelogs could cause confusions if they are not suncronized. So maybe we should decide of the changelog in the repository OR in the wiki.

Additionally we could keep the old method names for a while (e.g. one version step), replace it's content by a NotImplementedException with a message which tells the developer the new property names.

what's a native director??
If I remember correctly, this is for creating managed classes that can "override" the methods of a native class (if you override a virtual method from the managed class it gets called by the native object).

PM sent.

We could create a Mogre changelog wiki page which includes important changes.
On the other hand this always should be updated. Alternatively we could have a changelog in the repository (although it's only plain text). Redundant changelogs could cause confusions if they are not suncronized. So maybe we should decide of the changelog in the repository OR in the wiki.

I think, I'd prefer the changelog being in the repository (as text file) and a link in the wiki to the file.

Additionally we could keep the old method names for a while (e.g. one version step), replace it's content by a NotImplementedException with a message which tells the developer the new property names.

Currently this can't be easily done as this would require adding (read: "invent") obsolete code to AutoWrap. Also throwing an exception would also be a bad idea as compile-time errors are always preferably over run-time errors (read: exceptions).

About 2 years ago the retired Mogre maintainer Marioko (or Bekas?) tried to compile the Mogre dll file in a way, so that the C++ OgreMain.dll is inside of the Mogre library.
As result the Mogre library file has the name OgreMain.dll (managed), which contains a copy of the unmanaged C++ Ogre core (which is currently the content of OgreMain.dll).
Or in simplified words it's like this:
Copy OgreMain.dll into Mogre.dll and then rename Mogre.dll to OgreMain.dll.
(I hope now you know what I mean.)

This wasn't possible in the past, because after some hours of compilation there was an out of memory exception.

But I remember that Marioko (or Bekas) wrote, that this would have some advantages.
Unfortunately I don't remember details and I couldn't find the forum post.
Maybe then it would be something more easy in relation to the namespace. Maybe also for add-on integration/details.

If somebody knows about the advantages (Bekas?), then please tell it to us.
If we do so - does the wrapper needs some (many?) modifications?

Additonally we could try to compile Mogre that way again. Maybe now it's possible by the use of Win x64, because it can access the full RAM size (not only ~3.5 GB on x86 systems). Also there could be a better compilation support by Visual Studio 2008/2010.

About 2 years ago the retired Mogre maintainer Marioko (or Bekas?) tried to compile the Mogre dll file in a way, so that the C++ OgreMain.dll is inside of the Mogre library.
As result the Mogre library file has the name OgreMain.dll (managed), which contains a copy of the unmanaged C++ Ogre core (which is currently the content of OgreMain.dll).
Or in simplified words it's like this:
Copy OgreMain.dll into Mogre.dll and then rename Mogre.dll to OgreMain.dll.
(I hope now you know what I mean.)

This wasn't possible in the past, because after some hours of compilation there was an out of memory exception.

But I remember that Marioko (or Bekas) wrote, that this would have some advantages.
I tried that. The issue is that we have 2 sets of files, the debug Mogre/OgreMain and release Mogre/OgreMain and if you mix them (which can happen easily with visual studio coping the Mogre file around) you get the dreaded and totally useless FIleNotFoundException. If we linked Mogre.dll into OgreMain.dll we would only have one debug/release OgreMain.

[edit]Another advantage is that it would eliminate the 2-step linking process (build OgreMain with LINK_TO_MOGRE 0, then Mogre, then OgreMain again)[/edit]

If we do so - does the wrapper needs some (many?) modifications?
This is mostly about modifying the VC project of OgreMain to link in all the stuff from the Mogre project statically so it doesn't affect the wrapper.