Update

Don't worry, things are alive and well, just briefly stalled.

- I'm busy with work as well as fighting off a stubborn cold. I'll probably be out of commission for another couple days.

- EagleEye has a new baby, so I don't expect much from him for a while (again grats, man!)

- dannomite is working on renaming all the functions that start with an underscore to make them CLS compliant. After that, OgreDotNet.dll should finally be 100% CLS compliant (though not CeguiDotNet or OgreDotNet.Cegui).

This weekened was a bit of a wash out for me. It was my birthday and I spent alot of time with the family and wife. Was very relaxing, which was nice after the mr mom week(wife left me with kids for a week, but we survived). I jumped back onto OgreDotNet last night.

Here's an update - many changes coming soon:

- Finally getting the common set of axiom/ogre enums to work with swig. I'm using an approach similiar to properties where I'm creating a wrapper method for each ogre function that uses an enum type argument, but where swig changed the argument to a generic int because I had used %ignore to suppress the ogre enums. I'm also renaming the ogre function to an alternate name, and perhaps even better to private access if I can get swig to do this, and the new wrapper method will have the ogre function name, pascal cased, so it will look seemless to the programmer. These are very thin wrappers and should not affect performance in the slightest. One concern I do have is that some enums might not be int value types, some might be short or byte and hopefully my %ignore of the ogre enums has not caused swig to generate incorrect pinvoke wrappers that generically use int wherever an enum function argument was %ignored. I'll know more tonight.

- Renaming all underscore prefixed public members to CLI compliant names. To me the biggest slowdown is jumping between all the ogre header named swig interface files to insert the directives, if it were all in one big interface file it would be easiar, but then would become harder down the road trying to dig through one big file trying to find things. Oh well.

- PascalCasing more public members.

- Figured out how we can implement DotNet3D interfaces with swig when the time comes. No swig interface files changes will be made for now though.

That's sweet dannomite, I look forward to looking at your enums code.

I too am coming off a nice break, if you can call being sick a break . Regardless it was nice to get away from coding for a while.

Actually inserting interfaces would be easy:

%typemap(csbase) Ogre::SomeClass "ISomeInterface";

I'm still not big on this idea though, I think they're going about it wrong. Developers aren't going to want to conform their engines to an API defined by someone else. Wrapper classes may have a slight overhead in performance, but would be far more practicle. And I'd prefer not to have to insert and maintain a ton of interfaces I'll never use.

Simply put, Realmforge/Rage/DotNet3D/whatever they're calling it should be flexible enough to conform to any engine, not force an engine to be designed a particular way.

The Realmforge guys are welcome to create their own version and do whatever they want with it though. They could even write a script or something that automagically inserts the typemap into the source any time they update from cvs.

I would agree with you if it was just a matter of forcing it on the end users with no benefit in sight. But, by having OgreDotNet, axiom, cegui, etc, use a common standard I think we'd all be adding a beneficial service and unity to the .NET gaming community and giving an even better reason for game programmers to adopt .NET. This is what DotNet3D is trying to accomplish, a set of useful standards - perhaps even in an Eclipse style someday. Perhaps there is a better, more tactful way of going about gaining support for this from other projects, who knows.
I just think DotNet3D is a positive way for seperate .NET gaming efforts to come closer together and make the .NET gaming community stronger. Maybe I'm naive, maybe folks really don't want to work more closely together with other projects, who knows. I'd really like to believe that's not true.

I have no problem with any of that good stuff, I do however have a major problem with its implementation.

- I like libraries to be independent, and I am absolutely not going to insert a bunch of common interfaces that would have to be defined in a common class library, so creating an unnecessary dependency.

The only reason I even made the concession of a common math library, is that the 3D math stuff is what gives developers the biggest headaches, so it would be nice to have a nice library out there that anyone can use. I use it in my own side project for example.

- By going this route, they'll be limiting themselves to Axiom and OgreDotNet. Nobody is going to alter their engine code to conform with their standards. I know I'm not with my own engine (not referring to OgreDotNet).

Ah well, it's better to discuss later on when the DoNet3D interfaces are complete and there is something working. Regardless, OgreDotNet rocks and your hard work and stewardship is greatly appreciated.