Page 2 of 5

Re: Clean up

PostPosted: 05 Mar 2011, 01:10
by andrewbuck
I could do that, and I actually plan to do something like that when I switch to the binary format but for now the string representation of the binary format is the best mix of readability/easy to code. In the future, all I will have to do is convert the file opening statement to open the stream in binary rather than ascii and all my existing code should work flawlessly, except it will load much faster. With XML, this requires external libraries, and a redesign of the already functional (and futureproof) system.

-Buck

Re: Clean up

PostPosted: 07 Mar 2011, 09:08
by StefanP.MUC
Just pushed a svn and git commit, cleaning up the Ogre font (gave good names and cleaned the content of the fontdef).

Re: Clean up

PostPosted: 14 Mar 2011, 08:14
by StefanP.MUC
I just pushed a commit (both, SVN and Git) with the removing of the Media folder. I also adjusted the source code and cmake files. Hope I didn't mess something up.

Maybe there should be global constants holding the paths (like PATH_GUI = "gui/"), it will be a lot easier to change something later on then.

I updated the list in the first post here.

Re: Clean up

PostPosted: 14 Mar 2011, 14:14
by oln
Haven't tested, probably works fine. Though, the media used ingame should have it's own folder on svn so you don't have to check out the source and other stuff

Re: Clean up

PostPosted: 14 Mar 2011, 14:21
by oln
Also, the locations for most things are defined by the resources.cfg file, which is then parsed by ogre and used for resource management. Currently everything is loaded as one resource type, which may be a bit messy.

GUI and levels are hardcoded i think. I agree that the paths should either be a define, or we should adapt it to use the ogre resource manager.

Re: Clean up

PostPosted: 14 Mar 2011, 15:12
by svenskmand
oln {l Wrote}:Haven't tested, probably works fine. Though, the media used ingame should have it's own folder on svn so you don't have to check out the source and other stuff

Yes we need that. Please undo it on the SVN.

Re: Clean up

PostPosted: 14 Mar 2011, 16:43
by StefanP.MUC
Yes, you are right. Having an extra SVN folder sounds reasonable. Sorry for the mess.
Ah, didn't knew about the resource.cfg. I'll change it accordingly to the new folders.

Re: Clean up

PostPosted: 14 Mar 2011, 17:13
by TheAncientGoat
Stefan: The entire point of the SVN repo is for the media...

Re: Clean up

PostPosted: 14 Mar 2011, 17:14
by StefanP.MUC
Oh, by the way. In my Linux VM I noticed that the following in CMakeList.txt doesn't seem to work properly:
{l Code}: {l Select All Code}
set(OPENDUNGEONS_OGRE_PLUGIN_DIR ${OGRE_LIBRARY_DIR_REL}/OGRE)


It just sets the plugin dir to "/OGRE", ignoring the "${OGRE_LIBRARY_DIR_REL}" in front of it. I need to add "usr/lib" by hand.

Re: Clean up

PostPosted: 14 Mar 2011, 17:48
by oln
Yes, that accidentally happened in a change I did. I am in the process of cleaning up the cmake script, which should fix this, I've just been busy/lazy and haven't finished it yet.

Re: Clean up

PostPosted: 14 Mar 2011, 17:49
by oln
StefanP.MUC {l Wrote}:Yes, you are right. Having an extra SVN folder sounds reasonable. Sorry for the mess.
Ah, didn't knew about the resource.cfg. I'll change it accordingly to the new folders.


This is why we use version control :), just one command and it's all undone.

Re: Clean up

PostPosted: 14 Mar 2011, 17:54
by StefanP.MUC
I think the "Media" removing is done. I just tested it in my Linux VM and everything works.

Edit: Reverting the SVN also reverted the gui file content (they have "Media/" again). ;) I'll update them again to the new folders.
edit2: done.

Oh, another question: In the gui files I have to set the paths relative to the OD root, not relative to the gui files. For example:
OpenDungeons.scheme loads OpenDungeons.imageset. Both are in teh same folder, but in the scheme file I need to have "gui/OpenDungeons.imageset" instead of the same without "gui/".
This doesn't feel right, IMHO.

Re: Clean up

PostPosted: 14 Mar 2011, 18:22
by svenskmand
StefanP.MUC {l Wrote}:Oh, another question: In the gui files I have to set the paths relative to the OD root, not relative to the gui files. For example:
OpenDungeons.scheme loads OpenDungeons.imageset. Both are in teh same folder, but in the scheme file I need to have "gui/OpenDungeons.imageset" instead of the same without "gui/".
This doesn't feel right, IMHO.

To me the paths relative to the OD-root is the most logical, and what should cause the least troubles and misconceptions. If this was not the case how would you know which folder you are currently in? Also if other people are going to look through the gui-configuration files and other stuff it is clear to them which files a referenced with a absolute path from the OD-root compared to a ../Folder1/Folder2/File like relative path, which is not clear what path it is relative to :S

Re: Clean up

PostPosted: 14 Mar 2011, 18:43
by oln
StefanP.MUC {l Wrote}:Oh, another question: In the gui files I have to set the paths relative to the OD root, not relative to the gui files. For example:
OpenDungeons.scheme loads OpenDungeons.imageset. Both are in teh same folder, but in the scheme file I need to have "gui/OpenDungeons.imageset" instead of the same without "gui/".
This doesn't feel right, IMHO.


This has to do with the resource management settings for CEGUI, think it's just set to look in the root folder at the moment.

Re: Clean up

PostPosted: 14 Mar 2011, 20:06
by StefanP.MUC
svenskmand {l Wrote}:To me the paths relative to the OD-root is the most logical, and what should cause the least troubles and misconceptions. If this was not the case how would you know which folder you are currently in? Also if other people are going to look through the gui-configuration files and other stuff it is clear to them which files a referenced with a absolute path from the OD-root compared to a ../Folder1/Folder2/File like relative path, which is not clear what path it is relative to :S

Paths should always be relative to the place from where they are called. If a file A "OpenDungeons/gui/A" needs a file B "OpenDungeons/gui/B" then the path reference in A to B should simply be "file=B". But currently it has to be "file=gui/B". I find this highly unintuitive. While testing the GUI this often caused a crash of the game, which I only found because of the great CEGUI log files. Also, with absolute paths from the OD root folder it isn't easy to move files later on (you need to change every occurrence of paths strings by hand).

Re: Clean up

PostPosted: 14 Mar 2011, 22:15
by svenskmand
StefanP.MUC {l Wrote}:Paths should always be relative to the place from where they are called. If a file A "OpenDungeons/gui/A" needs a file B "OpenDungeons/gui/B" then the path reference in A to B should simply be "file=B". But currently it has to be "file=gui/B". I find this highly unintuitive. While testing the GUI this often caused a crash of the game, which I only found because of the great CEGUI log files.

I do not really agree here.

StefanP.MUC {l Wrote}:Also, with absolute paths from the OD root folder it isn't easy to move files later on (you need to change every occurrence of paths strings by hand).

Very true, a good argument for using relative paths.

Re: Clean up

PostPosted: 07 Apr 2011, 17:12
by StefanP.MUC
Updated the list in the first post. It's getting shorter and the average priority of the remaining points decreases. :D

Re: Clean up

PostPosted: 07 Apr 2011, 18:06
by svenskmand
You can remove the last point of merging git and svn. There is no reason for doing that. Svn is for the media content and git is for the code.

Re: Clean up

PostPosted: 08 Apr 2011, 08:37
by MCMic
svenskmand {l Wrote}:You can remove the last point of merging git and svn. There is no reason for doing that. Svn is for the media content and git is for the code.

And what is the point of keeping it appart?

Re: Clean up

PostPosted: 08 Apr 2011, 09:36
by svenskmand
You do not need to know about the depth parameter to check out only the newest revision, this will likely cause allot of trouble for people.

What are the benefits of keeping it together?

Re: Clean up

PostPosted: 08 Apr 2011, 10:10
by TheAncientGoat
Artists aren't going to work with code. SVN is slightly easier to get set up on Windows. SVN handles large binary files slightly better/repos are smaller thusly. So yeah, that's why it's kept apart

Re: Clean up

PostPosted: 08 Apr 2011, 12:45
by svenskmand
True another benefit of having it separately.

Re: Clean up

PostPosted: 20 Apr 2011, 16:11
by StefanP.MUC
Updated the first post. Removed the git/svn merge and added a new point that could help getting some startup/loading speed.

Re: Clean up

PostPosted: 20 Apr 2011, 16:13
by oln
Yea, zipping that might be a good idea.
I think we should also make a plan for how the code should look after refactoring, that is, what classes do what, what new classes should we create, what should be split up etc.
I've done some thinking, will write a more lengthy post about it when the release is out.

Re: Clean up

PostPosted: 20 Apr 2011, 17:54
by svenskmand
Zipping sounds good :) I will updating my tarball/build scripts this week so we can use them entirely to make new releases, let me know when zipping is implemented/supported, then I will add it to the scripts. I will also begin work on making scripts for windows to have one-click build/packaging.