folder structure in src

Introduce your project and write about your work.

Moderator: PPS-Leaders

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

folder structure in src

Post by 1337 » Sat Dec 22, 2007 8:12 pm

Right now have the following structure in src:

Code: Select all

audio
loader
misc
network
orxonox
  core
  hud
  objects
    weapon_system
  particle
tinyxml
I think this is inconsistent, for instance: What exactly is the difference between audio and hud when it comes down to folder structure?

My suggestion is:

Code: Select all

misc
network
orxonox
  audio
  core
  loader
  hud
  objects (everything that inherits from BaseObject including its accessories; Of course exceptions on the basis of common sense are allowed ;))
    ai (doesn't exist yet)
    particle
    weapon_system
tinyxml
Of course this still leaves questions: why put network separately but audio not?

What do you think?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: folder structure in src

Post by x3n » Sat Dec 22, 2007 10:40 pm

Well, I'm not sure, but isn't the audio folder something like our "audio engine", so it should be on the same level as network and orxonox.
I would suggest something like that:

Code: Select all

audio
network
orxonox
  core
  misc/util/tools
    tinyxml
  loader
  objects
    hud
    particle
    weapon_system
or

Code: Select all

audio
network
orxonox
  core
  loader
    misc
    tinyxml
  objects
    hud
    particle
    weapon_system

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Sun Dec 23, 2007 11:17 am

Hmm, you're right about audio (I thought of it differently, but your point makes more sense).

misc/util/tools with tinyxml is a good idea, but I wouldn't put that folder in orxonox, since it doesn't really have something to do with it. It's rather general. I mean, audio could could use the String2Number functions as well (not technically speaking of course, since that is possible anyway).

And I agree about the hud.

I have 2 new suggestions:

Code: Select all

audio
network
orxonox
  core
  loader
  objects
    hud
    particle
    weapon_system
util
  tinyxml
or:

Code: Select all

audio
core
loader
network
objects
  hud
  particle
  weapon_system
util
  tinyxml
about the last: I don't exactly see a point in having an orxonox folder.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Sun Dec 23, 2007 1:59 pm

1337 wrote:about the last: I don't exactly see a point in having an orxonox folder.
Good point.
I like your last 2 suggestions. Makes sense, but we have to discuss about the orxonox-folder. The main argument in the beginning was: We want to separate libraries from orxonox. But as it's now, audio and network aren't really libraries, they're more something like "the audio/network related part of orxonox", so they could perfectly be in the same folder as the rest of orxonox...

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Sun Dec 23, 2007 5:22 pm

I see your point. As the project develops, the structure with the orxonox folder might be better.
The question is of course: will it ever be possible to actually have something like a separate library? With the network: yes. But with what else?
And having this structure just because of the network library...

Anyway: it doens't hurry, so I'm not gonna change anything yet.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Wed Dec 26, 2007 11:42 am

I have come to see that the core is more or less completely independent of everything else (except the forward declaration of BaseObject, which is no matter at all actually).
And moreover I suggest making the orxonox folder one single executable. This of course increases link time, but I have realised that most of the "subprojects" in src/orxonox (according to the suggested folder structure below) are somewhat dependant on orxonox itself (especially the Orxonox::GetSingleton() method).
And I really don't like having these dependencies in separate libraries/executables.

My newest proposition is as follows:

Code: Select all

audio
core
network
orxonox
  loader
  objects
    hud
    particle
    weapon_system
util
  tinyxml
And every folder in src represents a library of its own. Right now, the orxonox executable would only consist of 28 source files in 170KB (without the header files). A project like Ogre has about 170 source files of totally 3.5MB (without the headers again)...
I just don't see the point in having that much libraries. And anyway: I think this came mostly because of CMake and its AddSubdirectory feature.
I therefore rather suggest declaring variables like OBJECTS_SRC_FILES in the corresponding directories and then making the executable in src/orxonox.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Mon Dec 31, 2007 9:08 am

The core IS orxonox, so:

Code: Select all

audio
network
orxonox
  core
    (loader)
  hud
  objects
    weapon
  particle
  tools
util
  tinyxml
I would remove the hud and particle folder for now. I'm not even sure if there will ever be more than 2 files in these folders..
Anyway, if they exist, they better be placed in orxonox, not in objects.

EDIT: weapon_system --> weapon, since we keep names simple.
loader moved to core...
EDIT2: the weapon renaming doesn't seem to have worked
Last edited by 1337 on Wed Jan 02, 2008 1:38 pm, edited 2 times in total.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Mon Dec 31, 2007 9:27 am

I read this thread twice and tried to follow all your points of argument. The last suggestion looks quite good to use right now with a view into the future. As Orxonox will grow we just add new folders in the orxonox folder (should the HUD become bigger, why not create that directory again, shouldn't be a problem). When, for instance, some new module is added (physics) we have it outside in the src directory.
In the end, creating the orxonox executable in the src/orxonox folder is a great idea in my opinion.

I have nothing to add, to this last suggestion. What do you other guys think?
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Mon Dec 31, 2007 2:22 pm

Are we supposed to think?

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Wed Jan 02, 2008 1:24 pm

D'oh...

I told Reto already on IRC, that I think his proposal seems fine.
I vote for accepting.

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Wed Jan 02, 2008 1:31 pm

x3n wrote:Are we supposed to think?
Great, I love how my humble try to somehow participate in the discussion is crushed by your sarcastic, word bending humor.

Well, it looks like Reto started with it already... so..
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Wed Jan 02, 2008 1:36 pm

with the sarcasm or the folder structure? :D

Well, it wasn't me, btw. x3n did the work, again.

Right now we have:

Code: Select all

audio
loader
network
orxonox
  core
  hud
  objects
    weapon
  particle
  tools
util
  tinyxml
which is almost exactly like my last proposition, except for the loader. But that is a temporary subject anyway, right now.

EDIT: Beni, what about the AI? Seems to me like it's worth a folder anyway.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Wed Jan 02, 2008 2:47 pm

Or do we create an "input" folder, for steering (or control) and AI?

But I guess it is worth a folder - well at least on the middle run (on the long run we are all dead :> )

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Wed Jan 02, 2008 3:02 pm

I see, that you really look into the future, nico ;)

Well it's true, that the AI is quite close to the steering, but only at the lower level.

According to the three layer approach of Martin the AI is quite independent. It will use some stuff from the core and in the lowest level it will have to interact with a steering interface to control the object which is "intelligent".
At the moment the AI isn't a worth a folder, but even in the short run, the AI will grow more important.

I'm not yet sure, where to put it in the folder structure.

The AI isn't of course just input, so AI would be a more suitable folder name.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Wed Jan 02, 2008 3:08 pm

Someone will have to think about the whole steering thing anyways...

Right now, our current steering is inside SpaceShip, since x3n did some work during a very lengthy night before the presentation... ;)

I'm not even sure, if we have to extract that. We could just define a BaseShip with a basic steering and then derive every ship from that. And for each ship we can modify the steering as we want.
Of course this makes writing the AI a little bit more difficult, but if that were to be a problem, then we simply don't modify the steering in the derived classes.

I don't see any reason for any other thing to be in need of a steering (a spectator could easily control an invisible spaceship with a modified steering).

If my idea is worth something, then we'll have to create a ship folder sooner or later... and one for the AI, since next semester another pps student will take on the subject of artificial intelligence.

@nico: As for your input-folder: We may need that after all. Key-bindings is one subject and of course the everlasting problem of how to coordinate the input with the client/server situation.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests