I'm about to abandon SWIG.

Honestly, SWIG has done most of the work here, but at this point, the complexity of the project is just too much for SWIG to handle.

In fact, running SWIG once wraps all of the functions. The problem is, to modify the way the functions are wrapped, you have to know how to tell SWIG to modify them.

Imagine it's like a text editor. Normally, you just type in to it. Now imagine an automated typist type of program where you have to learn how to type a second way so it can be translated in to the right typed text in to the original text editor. SWIG is that automated thing. In its default configuration, it does a lot of stuff for you, and you can extend it and modify the way it does stuff if you want... so you can optimize it for use after use.

The thing is, we already have a nice base to work with, so why not just work with it? SWIG is just a tool to get you to the destination in a predictable way each and every time. My thinking is, we're not going to be doing this multiple times. In fact, I don't even think the swig interface files need to be on the CVS. The .cs files that are generated by SWIG can now be taken and modified independantly from SWIG.

I'm going to test my theories here in the next hour before I have to go to work. I've been spending all of my time trying to figure out how to get SWIG to properly wrap some functions, when all I should have to do is modify the resulting CS files from where they are now.

I was thinking the same sort of thing - one of the difficulties of swig is that the code is so ugly, and that things are done automatically (once it's setup) but, automatic code is hard for humans to easily read. Making it harder than hell to debug. I spent all yesterday trying to figure out why ogre was using the non-overridden new[] creating out of memory exceptions left and right. But, that layer of swig made something that should be trivial a nightmare to negotiate around.

2005 has a real nice refractoring setup (rename all variables, functions, etc in an easy way) so I was going to go through and do this to the implemented ogre wrappers and see how much easier (harder?) things are to deal with. I was reluctant to do this, however, because that'd make these .cs files no longer swig compatible.

The thing is, we already have a nice base to work with, so why not just work with it? SWIG is just a tool to get you to the destination in a predictable way each and every time. My thinking is, we're not going to be doing this multiple times. In fact, I don't even think the swig interface files need to be on the CVS. The .cs files that are generated by SWIG can now be taken and modified independantly from SWIG.

I understand your position and I totally agree that it is quite difficult to change simple things I know one could change (more or less) easily by doing it manually, just because of the lack of knowledge in SWIG (or the long-winded way to do it). That makes it frustrating in a way.
Nevertheless the whole purpose of OgreDotnet, compared to Axiom as I understand it was to have changes made to existing ogre code automatically apply to OgreDotNet, thus making maintenance easier.
Therefore I think that abandoning SWIG should be overthought very well.

Just my 2 cents.
SphericalByte

I also agree that some more advanced stuff isn't easily wrappable at first with SWIG, but it does so much under the hood for us that the advantages are worth it IMHO.

I'm using it to wrap my framework in C# (to make an editor) and python (scripting) and I'm pretty happy of it so far.

It should always be possible to write new utility classes and functions by hand in the most C++-hellish parts.

Just my advice though...

Yeah, I think my frustration was showing... rastaman and I have been working on some of the base type mapping, and it's coming along nicely...