MogreNewt programming style

Hi!

I don't mean to be annoying here. But why is it that the progrmaming style in MogreNewt is not consistent with Mogre.

I mean, properties are not used at all, methods names start with lowercases, etc... Would you accept a path if I were to make one ?

Mat

Hi again!

I spent the last hour and a half modifying MogreNewt.

I basically converted all the get/sets to properties and added uppercases to methods. I looks much better. I will update the 2 examples aswell.

Anyone interested in the patch, how can we add this in the SVN ? Do I have the right to modify the SVN directly ?

BEFORE


AFTER


Mat

Hey, it's been a productive night.

I added debug line coloring so we can see if bodies are active or not (a la OgreOde). There is still some z fighting, but my video card doesnt support depth biasing lines.

Where do I send the patch ?



Mat

Did you enable OgreNewt's built in debugging lines, or did you make your own?

Wow, this is great!
You can submit the patch on Mogre's sourceforge page

Thanks a lot!

Cool. Patch coming soon.

I modified MogreNewt debuglines directly.

During the debugger initialization I create two materials (green/red) and during the NewtonForEachBody() thing, I start a new ManualObject section with the appropriate material depending on the body state.

This means it will probably only work in Ogre 1.4.+ because older ManualObject had to have only a single material I think.

Mat

A gigantic patch has been submitted (#1705154). Hope everything goes smoothly.

Mat

Patch accepted, works great.

Would you like to be maintainer of MogreNewt with SVN access so that you can add improvements (like the one for debugger performance), samples, etc. directly ?
I'd just need your sourceforge account.

I really don't want to argue, but I'd prefer the more Java-like code style if I were asked...
it is much clearer if something is a class, a member, an argument or a public method if this code style is used.

class ManagedOgreSomeClass
{
private int someMember;
public int getSomeMember();
}

compared to

class ManagedOgreSomeClass
{
private int SomeMember;
public int GetSomeMember();
}

Do you see the difference?
I really don't understand why Microsoft didn't "copy" that scheme, too, when they started developing .NET (which of course doesn't resemble Java... ).
Instead, they rely on naming things correctly, which is harder than actually format the name according to the type of entity.

Well, no problem with me if it stays the way it is now, I'm just a user and not a contributor (well, at least not yet) and I can get accustomed to almost everything , but maybe think about the naming scheme for a minute and decide how to do it and why you do it the way you do, and keep it for god's sake.
Nevertheless, keep up the good work.

think about the naming scheme for a minute and decide how to do it and why you do it the way you do, and keep it for god's sake.
Nevertheless, keep up the good work.
MogreNewt didn't follow the .NET naming conventions (as Mogre) only because of pure laziness.
At the time I was only interested in getting it to work, so I only did the necessary (as 'important') changes to the C++ OgreNewt code and left the C++ naming scheme intact (which is like Java).
It was my intention to go back and change the names according to .NET conventions but I never did get around to it.

I didn't complain, if you thought so.
But you will agree that a stable code style, whatever standard it is following, is absolutely neccesary for developers who might not be interested in revisiting their old code again and again because of case-sensitivity changes in the libraries they use...
So, switching is difficult in that way; delivering both options and marking the old interface as deprecated would have been a more elegant and stable solution to this - after like, two minor revisions or so the deprecated interfaces could have been dropped.
Anyway, if you use .NET schemes, stick to it.
Doesn't prevent me from using Java schemes in my code, so it doesn't hurt anyone

I agree, but we are not talking about a gigantic framework made of thousands of classes. MogreNewt has about 20-30 classes, including the collison classe which have no method at all... After the migration, It took me 2 minutes to migrate the examples and my own code. VS2005 will highlight you all the errors.

Also, you seem to forget that .NET (and formely COM) has a little thing called properties to wraps accessors/modifiers which result in much cleaner code that get/set IMHO.

BEKAS : About being the maintainer. I would love to, but right now I am working real hard on a project and I should be done within a month or so. After that, I dont think I will have much time to spend on this with school and all. Very sorry. Until then I will try to help as much as I can as a simple patch supplier.

Mat

Until then I will try to help as much as I can as a simple patch supplier.
Thanks, patches are always welcomed