[phreak]

probably the only good c++ like extension i'd like to see in the source code is overloaded operators for the vec3d class so we could write something like v3 = v2 + v1; instead of vm_vec_add(&v3, &v2, &v1);.  It should help the readability a bit, but thats about the only positive thing i see coming out of it.

Agreed.  That is one thing this tends to piss me off at random times in the source.  Having working things like "dp = vec3d.dotproduct(vec3d)", "vector = vec3d", "vec3d = vector", etc. would be a lot nicer than what we have to deal with now.  I don't know about speed, but I'd bet that it would likely be both faster and slower, depending on the function in question, and would end up being about the same overall.

But, you are right, there are a LOT of vm_vec_* calls.  But if someone had the time and patience to do it then it might be worth while for everyone.

i actually started working on this, but ran into a little snag since an object with a user-defined constructor can't be used in a union (see the matrix struct).  I just worked around it by commenting out my constructors.  hell of a workaround .  I'd like to get rid of the a1d crap, but i see its used in the collision detection functions, but i figure i could add a toArray method of some sort that'll return an array representation of the vector and just keep the x,y,z access thats used 90% of the time.

[Nuke]

ive been using of operator overloading in my nuke 3d engine, to the point where i think im overdoing it. ive been debating wether to stop at basic math ops for everything including vectors,  matrices, to quaternions, and may even go as far as making it possible to apply transformations with an operator (though i havent decided which one). i havent bothered to do research into wether or not this will cause any degradation in performance though it does make coding it all much easyer. though im still stuck on getting a working model class to test all this stuff on.

of course once you stard replacing member functions with operators, doesnt that make your classes somewhat more convoluted to have 2 ways of doing everything. working oo in lua seems like its a good way to slow everything down. but in c++ its a different animal all together. i dont know how this applies to a primarily c application. but if the code moves to take on a more oo style it can only help to get more people like myself into freespace coding.

[Aszarsha]

ive been using of operator overloading in my nuke 3d engine, to the point where i think im overdoing it. ive been debating wether to stop at basic math ops for everything including vectors,  matrices, to quaternions, and may even go as far as making it possible to apply transformations with an operator (though i havent decided which one). i havent bothered to do research into wether or not this will cause any degradation in performance though it does make coding it all much easyer.

Overloaded operators are exactly the same thing as regular function, but with pretty names. Operators can't hurt performance, nor improve it in any way a function can't do ; just they are usualy more prone to be inlined. Operators must only be used for operator mathematicaly defined in user defined types, only specials class need some other type de operator, operator() for functors or operator-> for iterators for example.
I also tend to think that binary operation that are not coded with operator should be with static functions. I hate the way Java does, say, a cross product; c = cross_prod(a, b) is the way we think, instead of c = a.cross_prod(b) and should be done that way ! Maybe, if a.cross_prod(b) does modify a, why not; but a = cross_prod(a, b) is a lot more clean for the sake of a very little perf. lost.

of course once you stard replacing member functions with operators, doesnt that make your classes somewhat more convoluted to have 2 ways of doing everything.

It does, but it's worth doing in my mind. Regular functions should be declared deprecated, too. This should allow an easy way to replace older function call; giving warning (so with file and line) at compile time.

but in c++ its a different animal all together. i dont know how this applies to a primarily c application. but if the code moves to take on a more oo style it can only help to get more people like myself into freespace coding.

C++ give the same performances as C, but few people understand that. In fact, the only performance lost I've ever found in C++ is with virtual functions in inheritance due to late binding; and lot of people claim that. But : 1) nobody is forced to use virtual functions and 2) try to implement late binding as efficient as the C++ compiler does in C, and comme back telling me how well have you done !

I actualy think that this project need to be rethinked from scratch in a more efficient, interface based, orientation if the goal is to make an Space Sim. engine. Not only it will allow new programmers to be involved, but it will also be necessary for actual programmers at more or less long term. I of course understand that already here programmer that know that engine and how it work don't want doing so again.
Haven't read enought actualy, and I may change my mind when I will more understand how the code work.


And do you know that anonymous access to CVS is broken ? I can't access it since two or three days.

[taylor]

And do you know that anonymous access to CVS is broken ? I can't access it since two or three days.

I was just complaining about the same thing.

WebCVS still works, if all you want to do is look at the code, but you can't access the repos directly at the moment.

[phreak]

And do you know that anonymous access to CVS is broken ? I can't access it since two or three days.

I was just complaining about the same thing.

WebCVS still works, if all you want to do is look at the code, but you can't access the repos directly at the moment.

ok i thought it was me for a second.

[Fabian]

Aszarsha, the best way to get into a new code base is to actually work on something.

(At least that is my experience with wine, linux / linux kernel modules, snes9x, and so more big projects ...)

Because then you are goal oriented. You want something done, so you do it .

If you want to make a new AI for example, its quite easy:

copy ai/aicode.cpp to ai/aicodenew.cpp, rename all the functions and global variables in this
file.

Then change ai_frame to check if the type is "new_AI" then branch into your new code.

(=> backwards compatibility remains)

Then you can start hacking away on you copy of the old AI code ...

A way to understand how the AI works is to adding temporary fprintfs to see what is actually going on ...

That was quite useful, when I worked on the AI part of the new stealth code for BtRL ...

Of course you can pick also some other feature request from one of the MODs or general Freespace feature requests. Or think of something you are missing in the game and start implementing it.

So in my opinion the way to get to know a new codebase is to actually work on it.

cu

Fabian

[Aszarsha]

It's exactly what I actually do ^^
I work on the code... But not really for a user goal, but programmer goal.


I've found all the mathematical code the uglier I've ever encountered in any project. And there is some functions that don't work as expected, look at vm_test_parallel for example.
Many return-arguments (which is a relic from old days where compilers were not able to optimize temporary object return), 0% const-correct (which is a very bas thing, since the compiler can optimize better const-correct code); for example.
Lots of functions are macro defined to avoid casting from float to double. Since C++ overload each functions with every floating point types, it no more mean better performances, but worst, it increase compilation time and do not help the new programmers understanding the code.

So I've jump into the work of making a totally new math. library, made of template (which could allow later optimization through template meta-programming, allowing performances FORTRAN-like).
It's a.... HUGE (!!) work, changing nearly all the actual code to use the new lib.
I've done some perf-tests with the old and the new lib., the new library is 5% faster with double precision floating point ; certainly because everything is inlined.
It's not actually done, but it's in my head : the matrix would be a 4x4 (saved as a 4x3) matric instead of a 3x3, it would allow a common 3D optimisation, making rotations and translations together, avoiding two functions call ; it will of course need changes to vector class too.
But I don't know if my works will be accepted by most actual programmers in the project as it use as many C++ features as I find usefull...

Anyway, I'll do it, alone if I have to ; even if it's not used.


Thanks Fabian for your advice !

[WMCoolmon]

I didn't know that preprocessor macros were treated as actual functions by the compiler - I was under the impression that it just subbed in the code contained in the macro, and then the compiler went over it as if the macro didn't exist.

I also thought (I don't think I ever confirmed this anywhere, though) that overloaded functions were assigned at compile-time, so there wouldn't be any slowdown between a non-overloaded function and an overloaded function. I've never seen any way to pass a different type of variable to a C++ function at runtime.

I didn't write any of the math code, but I sometimes like to optimize my code to the point of anality.

[Aszarsha]

Ah sorry, I was not enough clear... My English is not for nothing there...

I didn't know that preprocessor macros were treated as actual functions by the compiler - I was under the impression that it just subbed in the code contained in the macro, and then the compiler went over it as if the macro didn't exist.

Of course they are not... In fact it would be better in some case ! It's the preprocessor job... And as every job, it's not instantaneous ; preprocessing involve operation on files, which in some case (bad compilation chain for example) will lead to longer compilation (read Preprocessing + Compilation + Linking) time.
That's one of the reasons inlined function were introduced... Other reasons are so numerous that I cannot quote them all here, but function safety in macro-function performance is a major one; something I use and abuse in the library which I'm working on.

I also thought (I don't think I ever confirmed this anywhere, though) that overloaded functions were assigned at compile-time, so there wouldn't be any slowdown between a non-overloaded function and an overloaded function.

Hu... I haven't said what I wanted to or you haven't understood me. Ok, it's a lot more likely the first.
What I mean, is that with the so old C89, there were only double versions of mathematical functions, fabs for example only exist in the form double fabs(double); which involve one or two cast when using single precision floating point.
In C++ this function exist in three form : float fabs(float), double fabs(double) and long double fabs(long double). So there is no need to macro define fl_abs to fabsf, since it no longer involve casting.


EDIT :
Here is a little question : do you want/prefer vector/matrix be column major (OpenGL) or row major (DirectX) ?

[Nuke]

i think the general consensus is to use open gl over dx at all costs, so i figure using ogl style would work best. but then again i wont touch fs with a 10 foot pole (yet), so i wouldnt know.