Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Aszarsha on May 20, 2007, 10:27:19 am
-
Before anything else : sorry for my poor English... :blah:
So... I would like to take part of this project. I'm a C.S. student, not so bad with C++ programming, and I love AI.
I've looked through CVS repos. for 30 minutes.
What's the policy over the source code language ?
The code is A LOT more C than C++ ; in fact, haven't seen any C++ specific thing. Do you want to maintain the C-ish inclination of the code or are you ok for more (really more) C++-ish constructions, since the code seems to be compiled through a C++ compiler. Are you ok to use Boost libraries (http://www.boost.org) witch are improvements/implementation/adds of/over the standard C++ library.
Do you want, at long term, FS2_open be more a SpaceSim engine or just FS2 engine improvements ?
Haven't seen the original source from Volition, but it seems that the actual code is more improvements over it than major changes. Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).
I've never modded, nor inspected modifications but it seems that the actual engine support little, if any scripting. Do you want it to change ?
It's not easy to understand a such project code from scratch ; can some main developers here tell me where i should begin my read ? Is there any UML (or other) diagram somewhere that could help ?
Thank you to have read me, hope my English allow me to be understood. :)
-
I can't help you...or.... yes :) I CAN help you ;)
FS2Source (http://www.mediafire.com/?2ovdl7eimzy) :)
And I understood you quite well ;)
(If hosting source code is illegal - just give me a word and I will delete it ;) )
-
A good bit of the code written for freespace2 was written back in 1993/94 as part of the descent codebase, which is why 99% of the code is written in C. I think a few additions have been added by us that use some simple c++, such as the inheritance in the 'jump_node' class that WMCoolmon rewrote a year ago. We're probably not planning on modifying the underlying code to use the regular oo features (inheritance/polymorphism) because that would take too much time for little return. Yes it may be easier to follow and for new coders to pick up, but we need to weigh the performance benefits (if any) as well as if the actual time spent coding could be put to better use (optimizing existing code, fixing bugs, adding new stuff).
We don't have any UML diagrams to show you, the only thing that could be of any use is the Doxygen output of the original source released by volition, located here: http://fs2source.warpcore.org/dox/. We haven't run Doxygen for fs2_open ever, and I really dont see much of a point since most of us use Visual C++ and intellisense does alot of that for us.
:welcome:
-
As far as major new features are concerned the SCP has mostly been busy with supporting the total conversions recently so we don't mind big changes as long as the goal is to make the best Space Sim engine ever. :)
-
/me gets out his scissors
Before anything else : sorry for my poor English... :blah:
So... I would like to take part of this project. I'm a C.S. student, not so bad with C++ programming, and I love AI.
I've looked through CVS repos. for 30 minutes.
AI is one of those fields which it would be great to have some improvement in, but there seems to be a black hole buried somewhere in there. Every programmer who's offered to work on the AI code has disappeared. Maybe one of them is actually working behind-the-scenes and this thread will bring him out of the woodwork. But regardless, the AI is a tangled mass of code that is generally treated as a black box, partly because it's virtually impossible to improve AI behavior without breaking a lot of the existing msssions.
What's the policy over the source code language ?
Don't break backwards compatibility.
The code is A LOT more C than C++ ; in fact, haven't seen any C++ specific thing. Do you want to maintain the C-ish inclination of the code or are you ok for more (really more) C++-ish constructions, since the code seems to be compiled through a C++ compiler. Are you ok to use Boost libraries (http://www.boost.org) witch are improvements/implementation/adds of/over the standard C++ library.
Adding boost seems a bit silly, given that it would require someone to go to a considerable amount of effort to make it useful. Then it would also require us to include it in CVS, and include the license in all additional documentation. It doesn't seem very useful to try and modify things, at this point, to use Boost.
Do you want, at long term, FS2_open be more a SpaceSim engine or just FS2 engine improvements ?
Haven't seen the original source from Volition, but it seems that the actual code is more improvements over it than major changes. Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).
I've never modded, nor inspected modifications but it seems that the actual engine support little, if any scripting. Do you want it to change ?
http://www.hard-light.net/forums/index.php/board,145.0.html
and/or see code/parse/lua.cpp (http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/parse/lua.cpp?rev=2.85&content-type=text/x-cvsweb-markup)
It's not easy to understand a such project code from scratch ; can some main developers here tell me where i should begin my read ? Is there any UML (or other) diagram somewhere that could help ?
Thank you to have read me, hope my English allow me to be understood. :)
What are you trying to do?
-
Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).
I think that retaining the backward compatability is one of the major reasons there where no major changes.
-
Tough ****. We're not breaking backwards compatibility.
Given the length of time it takes to makes a campaign we'd have 2 years of a great engine with absolutely no playable missions for it.
Besides I don't believe that backwards compatibility is holding us back half as much as some people like to complain it does.
-
Besides I don't believe that backwards compatibility is holding us back half as much as some people like to complain it does.
I think that a bigger problem is that some sections of the code are just really awkward code-wise...
-
Yep. That's the big issue really.
People who want to break backwards compatibility generally haven't thought things through. Say we do break it? What happens a couple of months later when we find something else we could make cooler by breaking compatibility? What reason do you give to say why the previous change was allowed and this one shouldn't be? And if you allow that change what happens the next time?
Breaking backwards compatibility results in an engine with no games and which doesn't remain stable long enough for there to actually be any games for it.
-
Backwards compatibility is exactly why so many of the AI improvements that have been added have then been removed. The code that caused turrets to not fire through their parent ship, as well as the code for huge beams to not target bombs, broke compatibility in at least one mission (In the latter case, it pretty much was just one mission).
The last big coding discussion on AI was about how one should go about trying to branch things to maintain backwards compatibility. In the end, nobody seemed to come up with a solution without at least one major flaw.
It is virtually impossible to change any aspect of the AI code without breaking backwards compatibility in some fashion. The alternative - keeping track of every change and enclosing it in conditionals - will only make the AI code more convoluted. Altering the AI code in any respect, to make it more organized, is, of course, more or less impossible because it would break backwards compatibility. Complete replacement with another conditional statement to optionally switch to the new code is the only way of really cleaning things up (on some level) without risk.
When one does make a change to the AI code, even if they follow all the rules, once they choose to upgrade it, they will have to provide toggles for every additional change that they make, if it was actually used for something.
That backwards compatibility doesn't even play enough part in all of that to be worth mentioning is not a premise that I accept. You can tout all the good reasons if you like, and pretend like it hasn't, nor ever will be, a reason for excluding code, and I suppose I will just have to agree to disagree.
But I don't think that will help when somebody who wants to work on the AI comes along, and realizes that his time is probably better spent on a project that really wants AI improvements. Where he can actually spend time on building a better AI, coming up with something new and interesting. It's a far cry from the SCP, where AI improvements are only OK if they either fit into the extremely complex, rigid, and hacked-together structure of the AI code, so they don't break backwards compatibility, or if he's willing to spend the time to completely redo those segments before he (or she) can do anything else.
-
AI is one of those fields which it would be great to have some improvement in, but there seems to be a black hole buried somewhere in there.
I love AI, but i don't think I'm actually as good as it would need to do really better AI than actual one. Maybe in one year after my AI class and a lot of books in my head ! :)
I also love game programming in general, and that's why i want to take part of the project. I also love Science Fiction, and particularly Space Opera ! ;)
I think that a bigger problem is that some sections of the code are just really awkward code-wise...
Yes, some parts of the code are.... Not reader friendly. But of course backward compatibility must be saved. Maybe, the code should be reworked...
At least some parts of it. It need to be modularized ; maybe, a better interface, a lot less monolithic and really more scripting-efficient, should be implemented and the actual code encapsulated inside and no more changes (just minor) should be done on it.
This would allow new module done, not necessarily from scratch, for example physic module with Newtonian physics, or AI module that could be... just readable, it would be a great change ! :p
If this if done, I think (and I of course could be wrong) that Boost (at least the TR1 implementation part) could be a great help. Allowing staticaly-sized array, witch is a lot less error prone than C array, while having 100% of it's speed, for example.
Also, adding Boost to the project is not really a problem since it don't need any compilation ! It's 97% (yes, some part of it that are useless here) done with template.
I'm not totally objective since I really love C++, and I don't really understand why people continue using C. :rolleyes:
There is also another thing in the actual game (FS2_open 3.6.9 build ; haven't looked through the code) that astonish me : every interaction with the player is ASCII and QWERTY based ! You have understood, I'm not English, and my keyboard isn't QWERTY. It's in my mind one of the most important thing that have to be done to make it more an engine than FS2 improvements. The player have to be able to have accentuated letters in his name, and see an A and not a Q (for an AZERTY keyboard) in the control selection while actually want the A key on his keyboard.
I've never done anything related to internationalization through, so I don't know how it could be done.
For scripting, sorry WMCoolmon, haven't seen your work before. It seem really powerfull and very well built ! :)
What are you trying to do?
I'm actually trying to understand the whole engine. And it's a hard work... I don't really know where to beggin, so I just jump from a file to another, without really understanding the ins and outs ; without really understanding anything in fact that's related to data flow. C programs that long are a pain to read.
I've found some indentation inconsistencies through the code (HEAD branch) and it don't simplify the job. I also have some compilations error that I don't know how to solve : some VFX_* constants in swff_lib.cpp that are don't known, and an overload to CreateLuaState in lua.cpp that isn't known also.
I'll continue to read, but if there is somewhere I should really look, please tell me ! ;)
EDIT : my message was written and post before i saw WMCoolmon's one.
If I, a day (don't know how to say that in English, sorry), understand the engine, I'm ok to try the BIG work of encapsulating actual code, maybe rewrite it in C++ fashion some parts, before beginning another. It will improve my programmation skills and that would not be lost time ! ;)
-
There's nothing preventing us from making a pluggable AI, the way Phreak set up radar and radarorb. We'd just have to stub out ai_frame for a new AI module, and go from there.
-
I've found some indentation inconsistencies through the code (HEAD branch) and it don't simplify the job.
I agree, and I hate it when the others do that. Using different formatting styles for brances, comments, and spacing, does nothing but complicate the code. It is nothing less than a bug. Almost the entire code base is K&R style, but Goober, karjorma and Kazan use C++ style brace formatting. WMCoolmon uses a freakish mix, often using several different brace styles in the same function. Bobboau doesn't actually have a style, at least nothing consistent, unless you consider "Bobboau" a coding style. ;) And all to often, white space (at least horizontal if not vertical) is of no concern what so ever.
I'm not totally free in those issues either. I use a mixed K&R style. In part to stick with the formatting of the existing code base (which every good coder should do automatically, and without question), but "mixed" with the idea of formatting that greatly helps with bug finding/fixing. Since I'm the one that does most of the work on bug fixes, it only makes sense to give myself an easier time of it. I tend to use single-line if statements without braces, and I use a different formatting style on switch statements. The switch statement formatting is my biggest diviation from the existing code formatting, but done for ease of readability, ease of future maintenance, and ease of debugging. But I still feel dirty from using a different formatting style as the existing code every single time that I do that.
Thankfully, Turey seems to be more of the K&R type, which means that he can bring some more stability to the code formatting, and my spiral into complete insanity can be delayed for a little while longer. :)
There is also another thing in the actual game (FS2_open 3.6.9 build ; haven't looked through the code) that astonish me : every interaction with the player is ASCII and QWERTY based ! You have understood, I'm not English, and my keyboard isn't QWERTY. It's in my mind one of the most important thing that have to be done to make it more an engine than FS2 improvements. The player have to be able to have accentuated letters in his name, and see an A and not a Q (for an AZERTY keyboard) in the control selection while actually want the A key on his keyboard.
I've never done anything related to internationalization through, so I don't know how it could be done.
This is already planned to be fixed for 3.7. There is a lot that has to go into it though, not just in the input code, but also the pilot file code, graphics code, adding TTF support, better lcl support, better text file format handling, many data type changes, etc. It is not a small task.
If I, a day (don't know how to say that in English, sorry), understand the engine, I'm ok to try the BIG work of encapsulating actual code, maybe rewrite it in C++ fashion some parts, before beginning another. It will improve my programmation skills and that would not be lost time ! ;)
I actually prefer C, and only use very small parts of C++. I have just never understood the appeal of C++ really. I agree that it has a lot of positives to it, but not everyone agrees with how "positive" those are, including me. Most of the C++ in the code is just tacked on, though with some sections obviously being written for C++ in the first place (like the UI code, audio steaming code, some of the joystick code, etc.). But most of the C++ is actually not from :v: at all, such as the audio streaming code being a copy&paste from original work by a Microsoft developer, and the Windows FF code being mostly from a Microsoft SDK.
Mixing C and C++ to the extent that some of it is done does little more than hurt readability and future maintenance. But it's not exactly easy to complain about that, since that generally results in not getting any code at all. :sigh:
A lot of the code is in C, and I personally think that it needs to stay that way. Some of us have been using the code for 5 years now, so if anyone were to go in and start redoing things to be more C++-ish, that would only hurt those of us that are already very familiar with the code. I've spent years getting to know the code layout very well, and I have not intention of doing that again. :)
-
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.
the reason i don't see this happening is that:
a) there are alot of vm_vec_* calls
b) i don't know if this will hurt performance.
-
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.
-
In fact, function overloading WILL improve performance, if well done. Is it like any function call at worst, so there can't be any perf. lost, however it can be inlined (operator are this functions that greatly benefit from it) witch is also doable form actual functions, but would need some work as operators. The only perf. lost would come from binary size increase, witch would finish to cache miss... But on today's processors, it's worth doing.
For indentation inconsistencies, as I will read almost the whole code, I can try to correct this, but i'll need a guidline. And a CVS write access, too. ;)
Bah, it's not for today, nor this week (, nor mouth ?), so there is times...
I've found that the MS2005 project is also machine dependant. There's plenty of c:\project\... inside ! :ick: Corrected this, too.
For vec3d, why not implementing operators, beginning using it, and change old functions call while finding one ?
-
Backwards compatibility is exactly why so many of the AI improvements that have been added have then been removed. The code that caused turrets to not fire through their parent ship, as well as the code for huge beams to not target bombs, broke compatibility in at least one mission (In the latter case, it pretty much was just one mission).
First up I was talking about the entire codebase not just AI. I agree that in the AI code it can be a problem but even there it's not an insurmountable one.
That backwards compatibility doesn't even play enough part in all of that to be worth mentioning is not a premise that I accept. You can tout all the good reasons if you like, and pretend like it hasn't, nor ever will be, a reason for excluding code, and I suppose I will just have to agree to disagree.
Who said it wasn't an issue? Turey got the point. The issue is not being compatible with the way the engine worked but the fact that the horrific AI code makes it hard to add changes and stay compatible. As you say that means that the engine needs a lot of work before we can make AI changes easily. Goober's suggestion of making the AI pluggable is the way to go.
However every time you raise the issue of backwards compatibility you'll get comments from some halfwit (and I'm not referring to anyone in this thread) who believes that we should throw out compatibility and just improve the AI. That's what I was on about when I said it wasn't as big a problem as some people believe. Not what you seem to think I was talking about.
-
The code isn't nessecarily awkward, it's just that it appears to hardcoded and fit around the original Freespace 2 Campaign. If you want to grasp how one little bit works, you pretty much need to grasp how the majority of the codebase works(not that this in in anyway uncommon). Add inconsistencies throughout the code and the fact that FSO is seemingly void of direction and you scare away a lot of developers. Something I would really see is some "Guide to the Source", you've probably seen a lot of Open Source project have these, they are filled with DO's and DON'T's of indentation, (curly) braces, naming convention, whatever. And most importantly, the general idea.
This project is great, every time I got the spare time(and energy) I sit down with the code, hack'n'wack at it, trying to understand it a little better. Never forgetting that this is the code that allowed us to play the best space sim ever conceived by man. And good advancements are being made, advancements that have enabled modders to do amazing stuff.
But the lack of direction, the (from an observers perspective) stale developer community and the uncomfortable surrounding "tone" of secrecy( e.g the lack of spirit of the letter of the GPL ) is anything but welcoming.
I'm not having a go here, I'm just saying. :)
-
( e.g the lack of spirit of the letter of the GPL )
What do you mean by this? FSO isn't under the GPL. In fact, FSO isn't really Open at all, according to the definition (http://www.opensource.org/docs/osd) at opensource.org:
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
We can't sell any program with this code, and therefore FSO isn't under an open license. This is why we can't use code under the GPL, because GPL is an (extreme example of an) open source license, which "infects" (For lack of a better word) the FSO code and would cause the SCP to be in violation of one of the two agreements. The conflicting clauses are:
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
conflicts with:
"Copyright (C) Volition, Inc. 1999. All rights reserved.
All source code herein is the property of Volition, Inc. You may not
sell or otherwise commercially exploit the source or things you
created based on the source."
Modifications by members of the FreeSpace Source Code Project are
released under whatever terms the individual authors choose, but the
above notice continues to apply to all fs2_open code.
Any code under LGPL or some of the other, less forceful licenses (Including my personal favorite, EPL1.0 (http://www.opensource.org/licenses/eclipse-1.0.php)) can be used with FSO with little or no problem.
As always, if I got anything wrong, don't hesitate to correct me.
P.S. Wow, I got kinda off-topic with this post. Sorry about the off-topic-ness and the length.
-
Oh! I'm by no means talking about actual licensing here. I'm referring to the ambition to invite, learn, open and so forth in regards to development.
And my apologies for the hijacking of this thread.
-
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 alot 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.
-
ive been using alot 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.
-
ive been using alot 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. :(
-
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.
-
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.
-
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
-
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 ! ;)
-
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. :p
-
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. :p
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) ?
-
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.