Support offer

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Support offer

Post by Ivanux »

Good evening everybody!

I'm not sure if I'm posting in the right forum section (in that case, please forgive me, because it's my first topic)! :oops:

To be straightforward, I'll simply say that I discovered VS a few months ago, and was really astonished by the qualities of this huge project! A dream was becoming reality... but (sorry, there is always a "but"), I could only try it in "free mode", because of the shortness of the main campaign in 5.0 stable release. (Don't stop reading, I'm not here to criticise this game! :wink: )

That's why I decided that I would offer my help to support this project.

Let me introduce myself in a few words: I'm a Belgian recently graduated developper with (let's be frank...) no real professionnal experience (and I'll probably never have any, because I'm now studying something else).

I have two main abilities that could help developing this project:

* Firstly: I'm a OO developper, familiar with design patterns and OO principes. I've mainly studied Java, but I've good basics in C++. And I think I'd quickly learn what must be learnt. I'm especially motivated, because I'm a regular Linux user and think that good free projects must be supported, and I also want to keep in touch with programming which is actually my passion. :)

* Secondly: I'm a native french speaker, and could help translating the game if necessary. (I saw a forum section for that.)

Well, the point of this topic is: what could I do to help (in any way) and who should I bother to know what should be done? :wink:

Thanks in advance!

Ivanux

PS: Just a silly question, is there a "head" who coordinates this project? Because if there is, I wasn't able to find who.
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

In reverse order:
Ivanux wrote:PS: Just a silly question, is there a "head" who coordinates this project? Because if there is, I wasn't able to find who.
There isn't, and hopefully there will never be. This project if finally starting to move, now, probably because of no longer having anyone in charge. Right now we govern ourselves by illumining each other to concensus, or by bashing each other into submission, and it works. :D
I'm not sure if I'm posting in the right forum section (in that case, please forgive me, because it's my first topic)! :oops:
We don't have a forum for such generic help offers; but as far as your OO background and passion for programming, this is the right place.
Quick test (no cheating):
1) Explain the Visitor Pattern. Where would you use it?
2) Where would you use a Factory Method, versus a Factory Class?
3) Can you explain the "header inversion idiom"?
To be straightforward, I'll simply say that I discovered VS a few months ago, and was really astonished by the qualities of this huge project! A dream was becoming reality... but (sorry, there is always a "but"), I could only try it in "free mode", because of the shortness of the main campaign in 5.0 stable release. (Don't stop reading, I'm not here to criticise this game! :wink: )
No offense taken. We're painfully aware of the lack of campaign and story. I've tried to talk people into contributing, but those who say programmers are hard to manage have never worked with artists :)
That's why I decided that I would offer my help to support this project.
Cool. We need TONS of it. In every aspect. The only thing we probably need the least is new ship models, but we get tons of offers for that. In the programming front there's only 2.5 of us... Err... looks like 1.5 of us, to do everything.
Well, the point of this topic is: what could I do to help (in any way) and who should I bother to know what should be done? :wink:
I can't answer this except at length; need to explain a bit of background to tell you where we're at:
Many moons ago, the original developers of this engine moved on to another project (Sirikata).
Before they left, for the previous 2 years, if not three, they put like 99% of their efforts into implementing multi-player mode, and very little progress was made in other fronts, except for the introduction of shaders. That was a great gift, and the shaders have been getting steadily better; so, good progress in the graphics department for the past year. If you got the svn engine and data (as opposed to the last official release, 0.5), you probably noticed. And if not, do so and fly around to find an agricultural base, or a diplomatic center. Unfortunately, those are the only models that currently use the latest shaders.
But you need a ps3.0 compliant gpu to appreciate them; preferably an 8800 or better.
Shortly after the the original engine developers left this project, the head of the game project left also.
So, there's just a bunch of us old timers running with the ball.
If that sounds like the project is hanging from its eye-brows, not quite so: The original developers were rather messy; they wrote code that only themselves would understand, and even opposed reformatting the code, in the sense that it would produce "false positives" in svn diffs. Since they left, we decided to to automatically reformat the sources using uncrustify. This uncovered a lot of dormant bugs, particularly with multi-line macros that were not properly wrapped in do{...}while(0) loops. So we fixed those problems and many others.
There was also a template class that was central to the whole engine, but which had refused to compile normally, and so it had been "fixed" by including the cpp file in the h file, rather than the other way around. This has been fixed, and now it compiles to its own .o.
Two large warning squashing campaigns were conducted. A third campaign should finish them all, soon.
Lots of un-used code's been got rid of; also some redundant code, like BSP, now uses the collider library.
In the works right now: A brand new sound system. FFMPEG. A brand new physics system (using Runge Kutta 4). A brand new simulation scheduling system.

I think we can proudly say there's been more happening in this project in the last few months than ever before.
Check out the commits and tickets on TRAC:
http://vegastrike.wcjunction.com/trac/t ... ate=Update

Now, as for the 'what to do?" question... I think the best way to go would be for you to check out the sources from svn, and have a look around; first. Then, either jump into what we're working on, or pick something you'd like to implement. There's a lot feature requests (many of them mine) in the Modding Engine Room forum.

And, welcome aboard! :D
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

Quick answer (It's almost 1AM here):
chuck_starchaser wrote:There isn't, and hopefully there will never be. This project if finally starting to move, now, probably because of no longer having anyone in charge. Right now we govern ourselves by illumining each other to concensus, or by bashing each other into submission, and it works. :D
That's the answer I was expecting ;-)

chuck_starchaser wrote: Quick test (no cheating):
1) Explain the Visitor Pattern. Where would you use it?
2) Where would you use a Factory Method, versus a Factory Class?
3) Can you explain the "header inversion idiom"?
1) The visitor pattern enables a program to perform an action in an unknown object, knowing only the fact that it can handle it.
The "visited" object has to implement an abstract method such as "acceptVisitor(Visitor visitor)" given by an interface/abstract superclass common to all visitable objects. Therefore, when the "client program" wants to perform a specific action on this object, it sends the visitor's reference as parameter. The visited object executes the process on the visitor by a call such as "visitElementX(this)" [where this is it's ref], telling the visitor which kind of object it is and enabling it to do a downward cast to access the visited object's corresponding method.

The major interest of it is to enable different treatments (by using different objects implementing a single Visitor interface/abstract class) to be performed on a object, knowing only it's ancerstor's interface/abstract class. Because the client only knows that the object is visitable, and the object only knows that the visitor can use it whithout knowing why)

visitableXObject.acceptVisitor(visitorA); //param of "Visitor" generic superclass/interface
visitorA.visitElementX(visitableXObject); //param of "VisitableObject" generic superclass/interface
visitableXObject.doWhateverTheVisitorWants();

It is useful when visiting complex object structures such as trees with a composite pattern hiding the objects' real type, or generic chain lists, using different elements, etc.

2) Factory method pattern Vs Factory class pattern

Factory class pattern: the calling object doesn't know what type of instance he wants to get. For instance: if you want a "connection" object to send data, then you ask a Connectionfactory.getInstance().getConnection(); and it sends you back a connection object that can be of any type (wifiConnection, lanConnection, morseConnection,...) and gives the required functions described in the Connection interface/abstract class. Usefull when using a config file to choose the connection type at runtime, for instance.

Factory method: Here, a class also wants to create a generic object that could be used without knowing its type, but instead of calling another class to do so, it lets its concrete subclass create the object. For instance, a if you need a VS Vessel, you call an abstract method "Vessel createVessel()" and let the subclass create it. If the subclass is AndolianCreator, it will build and assemble the Andolian (Andolian structure, reactor, armor, ...) vessel and return it to its parent. If it's a MechanistCreator, it will create a Mechanist one (Mechanist structure, ...). The superclass gets a fully functional Vessel to use. It avoids to write the caller's code for each vessel type.
Generally speaking, I'd use that to build blindly a complex objects structure (here Vessels with different parts) that I could use later as an abstract object.

[I'm sorry for the explanations, I'm not used to explaining design patterns in English, if unclear I could give an example :wink: ]

3)Well... here I'm more confused. Never heard about "header inversion". It's maybe a difference of naming, because I learnt to program in French. (Or maybe not, I said I was familiar with patterns, which is true, but I'm still a young graduated with the experience that comes with this.)
chuck_starchaser wrote: Cool. We need TONS of it. In every aspect. The only thing we probably need the least is new ship models, but we get tons of offers for that. In the programming front there's only 2.5 of us... Err... looks like 1.5 of us, to do everything.
Well if there is something I'm obviously not, it's a 3D/2D designer... :wink:
chuck_starchaser wrote: I can't answer this except at length; need to explain a bit of background to tell you where we're at:
Many moons ago, the original developers of this engine moved on to another project (Sirikata).
Before they left, for the previous 2 years, if not three, they put like 99% of their efforts into implementing multi-player mode, and very little progress was made in other fronts, except for the introduction of shaders. That was a great gift, and the shaders have been getting steadily better; so, good progress in the graphics department for the past year. If you got the svn engine and data (as opposed to the last official release, 0.5), you probably noticed. And if not, do so and fly around to find an agricultural base, or a diplomatic center. Unfortunately, those are the only models that currently use the latest shaders.
But you need a ps3.0 compliant gpu to appreciate them; preferably an 8800 or better.
Shortly after the the original engine developers left this project, the head of the game project left also.
So, there's just a bunch of us old timers running with the ball.
If that sounds like the project is hanging from its eye-brows, not quite so: The original developers were rather messy; they wrote code that only themselves would understand, and even opposed reformatting the code, in the sense that it would produce "false positives" in svn diffs. Since they left, we decided to to automatically reformat the sources using uncrustify. This uncovered a lot of dormant bugs, particularly with multi-line macros that were not properly wrapped in do{...}while(0) loops. So we fixed those problems and many others.
There was also a template class that was central to the whole engine, but which had refused to compile normally, and so it had been "fixed" by including the cpp file in the h file, rather than the other way around. This has been fixed, and now it compiles to its own .o.
Two large warning squashing campaigns were conducted. A third campaign should finish them all, soon.
Lots of un-used code's been got rid of; also some redundant code, like BSP, now uses the collider library.
In the works right now: A brand new sound system. FFMPEG. A brand new physics system (using Runge Kutta 4). A brand new simulation scheduling system.

I think we can proudly say there's been more happening in this project in the last few months than ever before.
Check out the commits and tickets on TRAC:
http://vegastrike.wcjunction.com/trac/t ... ate=Update

Now, as for the 'what to do?" question... I think the best way to go would be for you to check out the sources from svn, and have a look around; first. Then, either jump into what we're working on, or pick something you'd like to implement. There's a lot feature requests (many of them mine) in the Modding Engine Room forum.
Well, I tell you a few things that you'd better know about myself if I can help you:

1) I'm still a student. I'd try to use as much time as I could on VS, but I think I'll need some time to get used to this "beast's" structure, and the school remains my priority.
2) Unfortunately, I've only a few basics in OpenGL & other graphic tools. (In fact, I've just written a 3D textured Tetris game in OpenGL for school purposes). But I'm sure that in such a huge game, there are not only visual parts.
3) I NEVER let an uncommented/undocumented code. On the contrary I prefer to use a lot (maybe sometimes a bit too much) of comments and UML diags in order to help a successor.
4) I love well done jobs. Bugs can happen, but I really take care of avoiding them.
chuck_starchaser wrote: And, welcome aboard! :D
Hope I'll be able to contribute to VS! :wink:
(As dev... or in any other way, if you aren't satisfied with my knowledges, what I could surely understand.)

Ivanux
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

Ivanux wrote:1) The visitor pattern enables a program to perform an action in an unknown object, knowing only the fact that it can handle it.
The "visited" object has to implement an abstract method such as "acceptVisitor(Visitor visitor)" given by an interface/abstract superclass common to all visitable objects. Therefore, when the "client program" wants to perform a specific action on this object, it sends the visitor's reference as parameter. The visited object executes the process on the visitor by a call such as "visitElementX(this)" [where this is it's ref], telling the visitor which kind of object it is and enabling it to do a downward cast to access the visited object's corresponding method.

The major interest of it is to enable different treatments (by using different objects implementing a single Visitor interface/abstract class) to be performed on a object, knowing only it's ancerstor's interface/abstract class. Because the client only knows that the object is visitable, and the object only knows that the visitor can use it whithout knowing why)

visitableXObject.acceptVisitor(visitorA); //param of "Visitor" generic superclass/interface
visitorA.visitElementX(visitableXObject); //param of "VisitableObject" generic superclass/interface
visitableXObject.doWhateverTheVisitorWants();

It is useful when visiting complex object structures such as trees with a composite pattern hiding the objects' real type, or generic chain lists, using different elements, etc.
EXCELLENT! You know more than me, for sure; I merely think of it as a way of "turning the table 90 degrees", turning a virtual table into an overload resolution paradigm.
2) Factory method pattern Vs Factory class pattern

Factory class pattern: the calling object doesn't know what type of instance he wants to get. For instance: if you want a "connection" object to send data, then you ask a Connectionfactory.getInstance().getConnection(); and it sends you back a connection object that can be of any type (wifiConnection, lanConnection, morseConnection,...) and gives the required functions described in the Connection interface/abstract class. Usefull when using a config file to choose the connection type at runtime, for instance.

Factory method: Here, a class also wants to create a generic object that could be used without knowing its type, but instead of calling another class to do so, it lets its concrete subclass create the object. For instance, a if you need a VS Vessel, you call an abstract method "Vessel createVessel()" and let the subclass create it. If the subclass is AndolianCreator, it will build and assemble the Andolian (Andolian structure, reactor, armor, ...) vessel and return it to its parent. If it's a MechanistCreator, it will create a Mechanist one (Mechanist structure, ...). The superclass gets a fully functional Vessel to use. It avoids to write the caller's code for each vessel type.
Generally speaking, I'd use that to build blindly a complex objects structure (here Vessels with different parts) that I could use later as an abstract object.

[I'm sorry for the explanations, I'm not used to explaining design patterns in English, if unclear I could give an example :wink: ]
EXCELLENT AGAIN!!! I asked this because the question was recently in my mind. So, thanks for clarifying it for me.
3)Well... here I'm more confused. Never heard about "header inversion". It's maybe a difference of naming, because I learnt to program in French. (Or maybe not, I said I was familiar with patterns, which is true, but I'm still a young graduated with the experience that comes with this.)
Header inversion is a trick used to avoid header inclusion cycles when function calls go against the normal flow.
There's many ways to represent a program graphically: Hierarchy oriented graphs (UML), data flow graphs, time graphs for protocol, whatever. One useful type of graph is as a command hierarchy. Usually, low level classes are at the leafs of the calling hierarchy. But sometimes you have cases where a leaf class needs to inquire about a top level state of the program. Now, suppose that you have a top level class MyProgram, whose functions call functions of classes of the next lower rank, and so on. So, the top level class includes the headers of the lower classes, which in turn include headers of yet lower classes. But now you have a low level class that wants to call a function in a high level class. Including the high level class header might result in a header inclusion cycle. Even if it doesn't, it is still "ugly"; bad form.
That's when you would use the header inversion idiom:
Essentially, your top level class can inherit from an abstract class that will, in turn, multiply inherit many abstract classes; and those abstract classes are defined together with the low level classes that need high level class access. So, if a low level class wants to know if the eyes of the high level class are open (or closed), it simply defines the function bool eyes_are_open() in a special abstract class which the top level class ends up inheeriting.
So, the next time the programmers working with the high level class try to compile, they get an error: a virtual function remains undefined! And so they rush to implement this function, which now becomes available to the low level class by re-linking. Essentially, what the header inversion trick allows is for a low level class to call a function in a high level class without knowing anything about the high level class, except that function (because it itself defined it).
Well, I tell you a few things that you'd better know about myself if I can help you:

1) I'm still a student. I'd try to use as much time as I could on VS, but I think I'll need some time to get used to this "beast's" structure, and the school remains my priority.
2) Unfortunately, I've only a few basics in OpenGL & other graphic tools. (In fact, I've just written a 3D textured Tetris game in OpenGL for school purposes). But I'm sure that in such a huge game, there are not only visual parts.
3) I NEVER let an uncommented/undocumented code. On the contrary I prefer to use a lot (maybe sometimes a bit too much) of comments and UML diags in order to help a successor.
4) I love well done jobs. Bugs can happen, but I really take care of avoiding them.
Well, everyone here has lives too; and those of us left here have high visions of what this engine's code should look like, some day; but the way it is now is just horrendous. Get ready for shock and awe, because the code we've inherited is just horrible. Even now, after reformatting it; --imagine before, when the indentations were all over the place. There's no idioms, no design patterns, and most classes make their data members public, and management of allocation of pointer members is often left to clients of the class... THAT's how bad the code is. Variable names make no sense; function names make no sense; there's "fog" and "fawg" and neither has anything to do with fog; welcome to Code Hell.
It's easier to rewrite than to try to understand.
Really. Klauss is rewriting the sound system. Errol is rewriting the physics. I'm rewriting the scheduling.
Hope I'll be able to contribute to VS! :wink:
(As dev... or in any other way, if you aren't satisfied with my knowledges, what I could surely understand.)

Ivanux
HAHAHA, your knowledge is excellent. The test was to see whether you cared about patterns and good code practises; and you obviously do.

P.S.:
If you want to see the worst parts of the code, check the files in the ai folder. Have your medicines and glass of water nearby, tho.
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

chuck_starchaser wrote: EXCELLENT! You know more than me, for sure; I merely think of it as a way of "turning the table 90 degrees", turning a virtual table into an overload resolution paradigm.
...
EXCELLENT AGAIN!!! I asked this because the question was recently in my mind. So, thanks for clarifying it for me.
...
Thank you, I wasn't sure that it would be clear enough. :D
chuck_starchaser wrote: Header inversion is a trick used to avoid header inclusion cycles when function calls go against the normal flow.
There's many ways to represent a program graphically: Hierarchy oriented graphs (UML), data flow graphs, time graphs for protocol, whatever. One useful type of graph is as a command hierarchy. Usually, low level classes are at the leafs of the calling hierarchy. But sometimes you have cases where a leaf class needs to inquire about a top level state of the program. Now, suppose that you have a top level class MyProgram, whose functions call functions of classes of the next lower rank, and so on. So, the top level class includes the headers of the lower classes, which in turn include headers of yet lower classes. But now you have a low level class that wants to call a function in a high level class. Including the high level class header might result in a header inclusion cycle. Even if it doesn't, it is still "ugly"; bad form.
That's when you would use the header inversion idiom:
Essentially, your top level class can inherit from an abstract class that will, in turn, multiply inherit many abstract classes; and those abstract classes are defined together with the low level classes that need high level class access. So, if a low level class wants to know if the eyes of the high level class are open (or closed), it simply defines the function bool eyes_are_open() in a special abstract class which the top level class ends up inheeriting.
So, the next time the programmers working with the high level class try to compile, they get an error: a virtual function remains undefined! And so they rush to implement this function, which now becomes available to the low level class by re-linking. Essentially, what the header inversion trick allows is for a low level class to call a function in a high level class without knowing anything about the high level class, except that function (because it itself defined it).
Hmm thanks for the explanations. The reason why I didn't know that is that multiple inheritance in java doesn't exist. :)
chuck_starchaser wrote: Well, everyone here has lives too; and those of us left here have high visions of what this engine's code should look like, some day; but the way it is now is just horrendous. Get ready for shock and awe, because the code we've inherited is just horrible. Even now, after reformatting it; --imagine before, when the indentations were all over the place. There's no idioms, no design patterns, and most classes make their data members public, and management of allocation of pointer members is often left to clients of the class... THAT's how bad the code is. Variable names make no sense; function names make no sense; there's "fog" and "fawg" and neither has anything to do with fog; welcome to Code Hell.
It's easier to rewrite than to try to understand.
Really. Klauss is rewriting the sound system. Errol is rewriting the physics. I'm rewriting the scheduling.

...

If you want to see the worst parts of the code, check the files in the ai folder. Have your medicines and glass of water nearby, tho.
Well... I just had a look, and was really surprised. What shocked me the most was the absence of comments and structure "empty lines". In fact this "brick code" is almost not understandable. (I didn't try to, I just had a quick look).

In the next time I'll try to understand the general structure and read the wiki pages about dev, and learn C++ specific good practices. I'll probably not be able to start a real participation until the end of my examinations (15th of june... erh... I know it's far away from now... :( but teachers don't care about students' life ).

Just a few basic questions that could help me to spare a lot of time:
- Are there any UML/doxygen/other format documentation? [I suppose not, but asking is better than regretting.]
- Is there a point I should really start with? I mean: some specific part of the project you would advise me to understand before the others.
- Do you all use Visual Studio? [I saw VS projects in SVN, and in this case I would reinstall mine to avoid IDE conflicts].

Thank you in advance :)

Ivanux
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

Ivanux wrote:
chuck_starchaser wrote:If you want to see the worst parts of the code, check the files in the ai folder. Have your medicines and glass of water nearby, tho.
Well... I just had a look, and was really surprised. What shocked me the most was the absence of comments and structure "empty lines". In fact this "brick code" is almost not understandable. (I didn't try to, I just had a quick look).
Ehm... That may have been me; I absolutely hate blank lines, and got rid of quite a few (not all). In my mind, a blank line is "wasted screen space". My reasoning goes that either the sections the blank space separates are worthy of an introductory comment, rather than a NO-comment (blank line); or they are not worthy of being separated by space. But this is obviously just me, because Klauss complained about my blank space removals. Oh, well; matters of taste are hard. I mean, I want blank space between functions. Blank space within a function gives me pause, feels like the flow is broken, to me...
I'll probably not be able to start a real participation until the end of my examinations (15th of june... erh... I know it's far away from now... :( but teachers don't care about students' life ).
No rush.
Just a few basic questions that could help me to spare a lot of time:
- Are there any UML/doxygen/other format documentation? [I suppose not, but asking is better than regretting.]
Nope.
- Is there a point I should really start with? I mean: some specific part of the project you would advise me to understand before the others.
Hmmm... Good question. I remember I once asked it and got no answer; now I'm on the receiving end of it and don't know what to recommend.
By elimination:
Definitely not the AI; that is hopeless.
Definitely not the Collide library folder; it works fine.
Definitely not the graphics or sound; Klauss is firmly in charge of those two, by reason of not just his knowledge of them, but of all the plans we have for the future, which he has a lot of ideas how to implement.
If you want to get familiar with the code in general, you could start with class Unit, in /src/cmd/unit_generic.h/.cpp (WARNING: Horrible code; everything thrown into that one class; MONSTRUOUS). That class is inherited into a template class called GameUnit, in unit.h/.cpp. Initializations are in unit_xml.cpp, I believe. So, that's the heart of the medusa, you could say. You won't be able to learn much; but you can browse those files to get a general feeling. unit.h is included by just about everything else in the engine, so whenever you change unit.h, or anything included by unit.h, you get a cascade of recompilation of all the sources, practically; a problem we intend to tackle soon.
So, it depends what you want to work on.
One task that should be straightforward and very useful to us would be, precisely, to find out what header files are NEEDED to be included in each header file. This is a huge amount of work, naturally; but it would be a perfect way for you to get familiar with the filenames and folders, at least. Basically, wherever you got a pair foo.h and foo.cpp, first of all, if foo.cpp includes 25 header files, to move the #include "foo.h" to the top (as we want header files to be self-sufficient, rather than depend on the .cpp including something else first). Then moving header files included in foo.h to foo.cpp one at a time and recompiling to see what happens. If the compiler complains that class bar is not declared within the scope, try adding a forward declaration "class bar;", see if it compiles. If that fails, then bring back bar.h to foo.h, and try the next header file.
So, in stage 1 you'd move as many header file includes from header files to .cpp files as possible.
In stage 2, you'd comment out one header inclusion at a time, in .cpp files, to find out which are really needed.
(Comment out, rather than delete, because some header files may be required or not based on compilation options; so, at least for a year or two we should not delete them, I think.)
If you feel adventurous, some classes may benefit from using a PIMPL idiom; but we should discuss them first, as there may be better plans for some of them.
If you like cleanup and refactoring work, another HUGE job that needs to be done, sooner or later, is to make data members of classes private, and write get functions where necessary.
More advanced stuff: const-correctness. Many functions that should be const are not so attributed.
Constructors with a single argument should be declared explicit.
Also, but this falls more into refactoring, if you're as big a fan as I am of "query/command separation": Functions should either return a value and be const (and preferably be "pure" (--i.e.: change nothing)); or be non-const and return void. In other words, non-const functions (commands) should never return a value (not even a status; that's what exceptions are for). But this is a HUGE job, because there are gazillions of functions all over the engine that mix up command and query functionalities.
- Do you all use Visual Studio? [I saw VS projects in SVN, and in this case I would reinstall mine to avoid IDE conflicts].
None of us developers has Visual Studio, and in fact we have had no up-to-date windows binaries for two years!, --until shenle showed up recently and compiled the engine for windows from svn for us. Actually, it's a bit more complicated: I think Klauss has Visual Studio 8 or 9, but the last version that could compile a working VS engine was 7, and that's what none of us had, anymore; but shenle does. VS8.0 compiles the engine, but the runtime always crashed mysteriously.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Support offer

Post by klauss »

Actually, we need someone to inspect system generation, understand it, and hopefully fix it to work the way we need.

Right now planets aren't using techniques and all the nifty graphical effects, because the XML generator (for pseudorandomly generated systems) is really outdated, using only features found long years ago.

And that is probably a lot more approachable than trying to figure out the Unit class. And will pay off faster.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Support offer

Post by pheonixstorm »

Ivanux wrote:Just a few basic questions that could help me to spare a lot of time:
- Are there any UML/doxygen/other format documentation? [I suppose not, but asking is better than regretting.]
- Is there a point I should really start with? I mean: some specific part of the project you would advise me to understand before the others.
- Do you all use Visual Studio? [I saw VS projects in SVN, and in this case I would reinstall mine to avoid IDE conflicts].

Thank you in advance :)

Ivanux
About VS. If you have a copy of VS/VC 2008 that would work best. I havent worked on the vc9 compile in a little while now mostly due to getting a new script system brought about as well as other projects and a newborn to deal with (Wife finally delivered on the 15th).

As far as a good place to start Kluass and chuck have suggested the best places. Either Universe generation or the AI. Not sure which has the greatest need.. probably the AI but its a real mess right now.

Welcome to the few, the crazy, the VS dev team.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Support offer

Post by pheonixstorm »

@Chuck. Do you know if shenle ever tried to get VS9 to compile? I know VC7 works and runs, VC9 compiles but flakes out at odd points.. I will get back to working on it when I get some more time.. probably when the baby is sleeping more than 2-3 hours at a time. I hated my dysfunctional binary... And is the latest binary still holding up well or is it too falling apart?
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

pheonixstorm wrote:@Chuck. Do you know if shenle ever tried to get VS9 to compile?
Donno any more than you do.
I know VC7 works and runs, VC9 compiles but flakes out at odd points..
VC8 AND VC9, bot compiled, but the executable crashed with "the runtime has asked to terminate in an unusual way" or some like that.
I will get back to working on it when I get some more time.. probably when the baby is sleeping more than 2-3 hours at a time. I hated my dysfunctional binary... And is the latest binary still holding up well or is it too falling apart?
Building it right now with cmake; we'll see. The situation WAS, recently, that shenle's binary had a number of issues with PU; BUT, the latest SVN has issues with PU in Linux too; same ones basically; so it's PU, not the binary, it seems. I've been waiting for someone to try shenle's binary with vegastrike.
I'll post again when the build is done and tested.
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

klauss wrote:Actually, we need someone to inspect system generation, understand it, and hopefully fix it to work the way we need.

Right now planets aren't using techniques and all the nifty graphical effects, because the XML generator (for pseudorandomly generated systems) is really outdated, using only features found long years ago.

And that is probably a lot more approachable than trying to figure out the Unit class. And will pay off faster.
Well, I think it could actually be a good start to get familiar with "the beast". Now I've installed an IDE (I chose NetBeans, because I've used it for ages) I'm gonna try to understand the system generation.

But to be sure: you are talking about the way the universe (planets, systems, etc) is generated and store in files to be restored next time? If that's it, I'll start asap.

Could you just explain me (in a few words) what are "the nifty graphical effects" you're talking about? 'Cause, as I already wrote: if it is using pre-defined graphical functions, that's not a problem. But I wouldn't be able to use advanced OpenGL tools, shaders etc.

[I feel a bit useless ATM, but I'll try to pay back your time investment later. :wink:]
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

Ivanux wrote:Could you just explain me (in a few words) what are "the nifty graphical effects" you're talking about? 'Cause, as I already wrote: if it is using pre-defined graphical functions, that's not a problem. But I wouldn't be able to use advanced OpenGL tools, shaders etc.
Don't worry about graphics; we got a handle on that already; what Klauss is talking about is that, precisely, he has already written a nifty shader for planets (with clouds, and cloud shadows, atmospheric scattering... the works); but he's been unable to integrate it, because his new shader needs additional textures for each planet, but he doesn't know how to add them, because he hasn't had the time to really hunt down where and how planets are generated, and where and how their textures are determined.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Support offer

Post by klauss »

Ivanux wrote:Well, I think it could actually be a good start to get familiar with "the beast". Now I've installed an IDE (I chose NetBeans, because I've used it for ages) I'm gonna try to understand the system generation.

But to be sure: you are talking about the way the universe (planets, systems, etc) is generated and store in files to be restored next time? If that's it, I'll start asap.
Well, I'm not sure how it works exactly, but the thing goes a bit like this:

VS has a set of xml files stored in data/sectors/<blah>/...
Those define the "major" stuff that will be present on each system, major being stations, planets, asteroid fields, stationary (always in orbit) capital ships, but not regular ships. Those XML files could use some extensions that I'll mention later... for now just know that they're there.

Now, when VS needs to load a system, it will go looking for that file. It will look into the main data folder (/data) and the user's personal data folder (.vegastrike). The why will be clear a bit later... but if it find the file, it just initializes the system according to what the xml says: planet here, planet there, star here, asteroid field there.

Now, suppose VS can't find the file... does it mean there's an error? Nope... VS assumes the file should be randomly generated, and thus invokes some routine (and here's where I lost track of it all) to create an xml file (in the user's personal data folder). Then it retries, this time it will find the generated file, and all proceeds as normal.
Ivanux wrote:Could you just explain me (in a few words) what are "the nifty graphical effects" you're talking about? 'Cause, as I already wrote: if it is using pre-defined graphical functions, that's not a problem. But I wouldn't be able to use advanced OpenGL tools, shaders etc.
Now, the nifty graphical features are the techniques, which allow for multipass shaders. Ships don't need such complex shaders ATM, but planets do - rendering planets with any kind of cinematic or photographic accuracy is really complex, and requires shaders with many passes and input textures and parameters.

When the system generation routine was written, a planet was simply a sphere with a single texture and, perhaps, a weird mesh that rendered the atmospheric glow effect and city lights.

Now, planets can be rendered even more "easily" (not accounting for shader complexity): a sphere, rendered through a special shader set in a certain sequence. That's all handled by the graphics system (using technique files), but we're missing a few key data points that need to be fed to the graphic system:
  • Texture SET: now planets consist on MANY textures, not just one.
  • Technique parameters: now planets should specify a lot of non-texture parameters, like atmosphere thickness and color, for instance.
  • Technique: and there could be many different techniques (shaders) for many different planet kinds.
Those data points should be on the XML, passed over to the graphics system and generated by the random generation routin.

I can take care of passing over the data from the XML to the graphics system, so you don't need to understand OpenGL or anything like that, but I had a hard time following the code when I tried to add the variables to the randomly generated XML, and haven't tried again since then.

So, for now, if you can decipher that code, find out how to add to the generation system, I can prepare a list of parameters that should be added to the XML. In the meanwhile, merely documenting how system generation works as you decipher it would be a big help to other contributors.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

klauss wrote:So, for now, if you can decipher that code...
And document how it works...
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

Hi everybody,

Sorry for the late answer but I've been really busy this week.

So, where I am:
- I installed my IDE, I chose Netbeans (I'm used to it).
- I compiled Vegastrike (from u-t-d SVN sources), with no problem.
- I ran it and got... a segfault. [Wouldn't have been fun, otherwise.]

So, on my desktop PC, I run VS 0.5 with no problem of any kind, but on my laptop, it fails.

Due to the drop of support of non HD*** cards of ATI, I'm using the "free radeon" driver on my laptop. May that be the cause? (My box runs a proprietary ATI one).

Whatever, I'll try to compile and run the SVN sources on my box, when its screen will be fixed. (It's... broken in two pieces. No I'm not a violent person, it was an factory weakness.).

Now, the real aim of this post:

* Firstly I confirm I'll focus on dynamic universe generation and storage. I'll try to understand how it works, document it, and think about fixes/improvements.

* Secondly, could basically tell me how you compile sources with debugging symbols activated? I'm a bit lost with the existing makefile, and would love to locate the cause of this segfault.

Thank you in advance
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

I've no idea what the problem with debug symbols is, but I'll try to compile with debug and see what happens.
Note: I abandoned autotools for cmake a while ago; so, I'll try building with debug under cmake first; and if that
works I'll try with autotools.
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

Yup, I think my question was unclear.

Well. I spent a few hours fighting the beast and finally found how to build it in debug mode. I was indeed using an autotool-generated makefile.

With cmake, I got something similar:

Code: Select all

Out of hw temporaries
Out of hw temporaries
...
Out of hw temporaries
Segmentation fault (core dumped)
After a few researches on the web, I found that that was the MESA driver that was unable to allocate new resources for vertex computation (or sthing like that...).

I think it's because of the free driver that isn't able to use the full performances of my card, so you can forget it, unless I get the same results on my box later.

Have a nice day :wink:
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

Sorry, I did make half the experiment, yesterday, but forgot to post. I managed to compile with debug in cmake, and the
program ran without segmentation fault or any problems at all. Didn't try with autotools; but I guess you found the problem
already, anyways.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Support offer

Post by klauss »

Did you try disabling shaders on the config file?

(there's a tiny app, vssetup, which can do it for you rather easily)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

klauss wrote:Did you try disabling shaders on the config file?

(there's a tiny app, vssetup, which can do it for you rather easily)
Well done, you were right! :idea:

What a pity to have a Radon x2300 and not to be able to use shaders because of a sad "deprecated driver" story. I tried all shader levels with the same result. It only works when I disable every shader.

Anyway, I don't think it's interesting to look for a solution for that problem, because the driver is REALLY to slow to play VS (ATM, I get 15FPS max in 3D rendering, with a card which could easy get 60 with the proprietary driver).
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Support offer

Post by klauss »

Ivanux wrote:What a pity to have a Radon x2300 and not to be able to use shaders because of a sad "deprecated driver" story. I tried all shader levels with the same result. It only works when I disable every shader.
MESA does progress on that front slowly but consistently... you'll get better drivers eventually.

Sadly, though, new drivers usually come only with newer distros... installing a newer MESA driver on an old distro isn't easy.

Although... the bad news is that, with intel as well, and nVidia, "free" drivers only get you somewhat decent desktop performance, but nowhere near what a game needs.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

klauss wrote: MESA does progress on that front slowly but consistently... you'll get better drivers eventually.

Sadly, though, new drivers usually come only with newer distros... installing a newer MESA driver on an old distro isn't easy.

Although... the bad news is that, with intel as well, and nVidia, "free" drivers only get you somewhat decent desktop performance, but nowhere near what a game needs.
Exactly. In fact my distro (gentoo, so no "new release") is too recent to use old FGLRX.
Let me explain: you need a 2.6.28 kernel, and xorg-server 1.5... And this one isn't provided by gentoo anymore. (We're on 1.7 stable, 1.8 testing...). So I'm stuck with a recent MESA driver but not yet powerful enough for gaming. (but which is better than ever, I must admit! Able to run accelerated 3D effects on desktops, ...) I just regret ATI did something so... unpleasant to their customers.

The real pity is that it's r300 based, and doesn't really support r550 features... Will come someday!

Anyway, VS runs fine on my other box, which has fglrx running with on its HD2600XT
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
Ivanux
Explorer
Explorer
Posts: 11
Joined: Thu Mar 04, 2010 9:51 pm
Location: Brussels

Re: Support offer

Post by Ivanux »

Hello,

I've spent a few hours wandering (yes, I think it's the best verb) into the source code.

What frightened me the most is the structural division: it seems everything is bound to everything else, almost like a full-meshed network...

This has a major disadvantage because everything you change could make the entire squid collapse.

Are you planning to refactor the whole structure? Because I think that a neat package structure, using (for instance) a simple facade pattern (and other patterns to unbind non directly related classes) would make the maintaining part highly easier.

Of course, it's the meaning a someone who just discovered the code, but I think it's so frightening that the risk exist to see the project die because no new developer would be able to apprehend it.

In fact, it really takes a while to find where a simple XML value goes, and how it is finally used, going through loads of different (and sometimes apparently unrelated) classes. But don't worry I'll keep on.

To help me, I tried to use a UML reverse-engineering tool, but with a simple subset (Galaxy, StarSystem, Universe, Planets) my CPU almost melt and it gave me the most unclear diagram I've ever seen. I'll forget it.

So what I'd like to know: is there somewhere on this forum where you discuss the present and future structure of the beast?

Thx,
Ivanux

... potential VS junior developer.

[If you wanna f*ck up a C++ program: do it Java-like.]
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Support offer

Post by klauss »

You'll have to use the search function of the forum creatively and a lot, but there's already talk of refactoring graphics, AI, physics and sound. Sound is already in progress. Physics too, although mostly on the low-level computations rather than a "redesign".

Summary:

We're going as opportunity arises with that kind of stuff.

Whenever we have the need to implement something that gets really hard on the current code base, we "set to rewrite it". Because, as you may have seen, it can get impossibly difficult to track side effects on the current code base.

First it happened with audio, audio is mixed an interspersed with graphics and physics, it's impossible to work on it, and I wanted to add streaming capabilities (so that music tracks need not be loaded fully into RAM, for instance), and positional effects, doppler and the like. But in order to do that, the best way to go about, was to write an entirely new subsystem. The difference with other subsystems, is that audio code was so... ad-hoc in VS, that one could say VS had no audio system, only a bunch of OpenAL API calls here and there.

For graphics, we intend to (eventually) use a mature rendering engine like Ogre. The problem with Ogre has been of resources: Ogre handles its resources in a strict and very different way, so we either force all mods into a huge refactoring to stay compatible with the engine, or we provide an automatic refactoring tool, or we make the "Ogre-ified" version of VS compatible with the current dataset. The ogre branch has attempted to do a mix of the above that seemed fine, but the task has proven to be a lot of work that was never finished.

For physics, we're trying to take the experience of a professional physicist-coder and apply accurate force integration so we can finally have proper gravitational simulation, and get into cool scenarios like black holes and neutron stars. That prompts the refactoring of the physics system, to separate it from AI which is currently very intermingled. Progress here is limited to the underlying rk4 algorithm and the design of a new scheduling algorithm attempting to better use the hardware to simulate hundreds of physical units (note: not AI units, just physical, we're thinking asteroids and such).

For AI, there's been talk of refactoring. Mostly because there are many many bugs there that noone can find, track or fix, because noone understands how AI works. Progress here is limited to that: "let's refactor it" sums it all up ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Support offer

Post by chuck_starchaser »

I think what we said about the AI was "let's rewrite it", more so than "refactor it".
Post Reply