Page 3 of 5

Re: Clean up

PostPosted: 20 Apr 2011, 18:34
by StefanP.MUC
As far as I understood it there's no code change needed.

We simply have to convert a normal folder into a zip file (and change the according entry in the resourcec.cfg).

Example of how the resource cfg needs changing:
Now: FileSystem=/models (containing the mesh files in the folder root)
Then: Zip=models.zip (containing the mesh files in the ziip root)

Re: Clean up

PostPosted: 20 Apr 2011, 20:44
by svenskmand
Ok :)

Re: Clean up

PostPosted: 02 Jul 2011, 12:27
by StefanP.MUC
I added a new point: remove the OGRE example debug overlay (the thing that shows FPS, etc.)

I came accross this while cleaning up the frame listener. If we need this numbers, it's not hard to display them in a hidable CEGUI window or as a text overlay. This would also lead to the removal of some of the OGRE example media (-> decreasing the installer size and speeding up resource loading).

Re: Clean up

PostPosted: 03 Jul 2011, 14:49
by svenskmand
Where do you have FPS count show? When I start the latest release I only see the main menu, and then when I start the game I see the normal GUI.

Re: Clean up

PostPosted: 03 Jul 2011, 16:34
by StefanP.MUC
When you hit "F" on keyboard the normal CEGUI overlay gets hidden and a Ogre::Overlay containing some basic internal numbers pops up. That's the thing why we have a "packs\OgreCore.zip" file.

I think this is a leftover of all this example stuff from the Ogre example application.

If we really need these numbers, we can put them in a CEGUI window (then the OgreCore.zip is not needed anymore), but in my opinion we could also throw it away completly (I needed quite a lot of coding and playing OD to find out that this thing exists ;) ).

The only really important number in there is the current fps. Then it has min fps, max fps, average fps, triangle count and batch count (no idea what this last thing is). And an Ogre Logo.

IMHO, the best thing would be to display the fps number with our TextRenderer class and drop the rest of this overlay.

Re: Clean up

PostPosted: 03 Jul 2011, 17:34
by svenskmand
Yes, lets do that.

Re: Clean up

PostPosted: 03 Jul 2011, 18:35
by StefanP.MUC
OK, removed it. With the same commit added a FPS counter to the terminal text. This also cleaned up the framelistener by >100 lines and reduced the binary size.

Now we can remove the packs/OgreCore.zip (also from resources.cfg)

Re: Clean up

PostPosted: 11 Jul 2011, 00:20
by svenskmand
You did not do the clean up properly, I just compiled the newest version and got the error in the attached shot when running the game. It still wants the OgreCore.zip.

Re: Clean up

PostPosted: 11 Jul 2011, 08:53
by StefanP.MUC
Oh, yes, the resources.cfg get's recreated on building... Need to figure out where this is done, then I'll remove it on the next commit.

If you want to run the game, you'll have to delete the [boostrap] group from your resources.cfg manually.

Re: Clean up

PostPosted: 11 Jul 2011, 09:23
by oln
StefanP.MUC {l Wrote}:Oh, yes, the resources.cfg get's recreated on building... Need to figure out where this is done, then I'll remove it on the next commit.

If you want to run the game, you'll have to delete the [boostrap] group from your resources.cfg manually.

You have to edit config/resouces.cfg.in

Re: Clean up

PostPosted: 11 Jul 2011, 09:56
by StefanP.MUC
Ah, thanks. :)

Pushed the fix.

Re: Clean up

PostPosted: 11 Jul 2011, 12:11
by svenskmand
Ok I will build it again tonight.

Re: Clean up

PostPosted: 17 Jul 2011, 11:27
by svenskmand
It runs again :)

But there is a new bug which might have to do with you refactoring of the keyboard input. When you use wasd and the arrow keys to control the camera it moves in a weird way. First it jumps very far in the direction you want to move, then it acts more less normal by accelerating the speed in the direction you move.

Re: Clean up

PostPosted: 17 Jul 2011, 13:57
by StefanP.MUC
I can't confirm the "jumping". The acceleration works for me. What happen however is that the input manager for some reasons remebers the old state:
Fly left, then stop, now fly forward, now the bug comes: it flys exactly one step left, but changes then automatically to the forward direction.

I know of this bug since I refactored the input, but I really can't find the location where it happens (because I didn't change any code logic or calculations, only moved the functions into a separate file). Seems I have to go through the movement calculations agian. :D

But the input calculations need some reworking anyways (I have the feeling that currently it is extremly inefficient because it always runs through very big calculations even if the camera isn't moving at all).

Re: Clean up

PostPosted: 23 Jul 2011, 09:37
by StefanP.MUC
Another question, about the source code folder stucture. We have a dep(endencies) folder that currently holds only pthread.

Would it be good to store AngelScript also in this folder? Currently I did split AngelScript up into "scr/angelscript" and "include/angelscript", but I just realized that this could make problems with official AngelScript add-ons from which I wanted to use at least one (stdstring add-on giving Angelscript the possibility to nativley use std::string). Originally all AngelScript files (h and cpp) were in one single folder.

Re: Clean up

PostPosted: 23 Jul 2011, 09:44
by oln
Yeah, we should probably put angelscript there.

Re: Clean up

PostPosted: 23 Jul 2011, 09:49
by StefanP.MUC
Ok, then I'll change it.

Re: Clean up

PostPosted: 23 Jul 2011, 10:16
by StefanP.MUC
Ah, cmake again, It still isn't my friend. :D What do I have to change in the cmake files if I put the AngelScript SDK in the dep folder?

AngelScript comes with its own cMakeLists file for building a angelscript.lib, can we use that? Or do I simply have to add ALL the sub folders from the dep/angelscript path to out central cMakeLists.txt (and within the subfolders new cmakelists conatinig the files)?

Re: Clean up

PostPosted: 23 Jul 2011, 10:21
by oln
Should be able to use the cmake-file from AS. I'm just not sure how that is done.

Re: Clean up

PostPosted: 23 Jul 2011, 10:25
by StefanP.MUC
If it's ok, I could push it to the repo so that you or someone else could have a look, but then we won't be able to build, until the cmake things are solved.

Re: Clean up

PostPosted: 23 Jul 2011, 16:47
by svenskmand
I think we should just depend on AngelScript as a library instead of copying their source and putting it into our source tree. If somebody wants to help me out I can put it into my PPA, that would be the easiest I think. I now have allot more understanding of debhelper and debian packaging, so making a package for the AngelScript library should not be a big problem.

Another thing by the way I get this rather peculiar warning when I build our packages:
{l Code}: {l Select All Code}
dpkg-shlibdeps: warning: dependency on libsfml-system.so.1.6 could be avoided if "debian/opendungeons/usr/lib/games/opendungeons/OpenDungeons.bin" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libopenal.so.1 could be avoided if "debian/opendungeons/usr/lib/games/opendungeons/OpenDungeons.bin" were not uselessly linked against it (they use none of its symbols).

So apparently debuild/dpkg claims that we are not using any of the libraries in SFML and OpenAL, but we do have sound in the game, any ideas what causes this warning?

Re: Clean up

PostPosted: 23 Jul 2011, 17:14
by oln
Maybe it's being linked to by the CMake script. I think it's needed on windows, but not on linux, so will have to check that up.
Anyway, it shouldn't be a big problem for now.

Having angelscript in the PPA would be an option. Though it seems it's more common to statically link the library, so if we did that it would only be needed for building.

Re: Clean up

PostPosted: 23 Jul 2011, 17:35
by svenskmand
Regarding the AngelScript then lets do the most common thing.

What do you mean that it is only used on Windows? We use SFML and OpenAL indirectly through SFML on both systems, and the *.so files are linux libraries?

Re: Clean up

PostPosted: 23 Jul 2011, 17:53
by oln
OpenAL is used indirectly, but it seems the game itself might not need to be linked against it on linux. Same with the system library in SFML. Linking to that might not be needed on any of the platforms.

Re: Clean up

PostPosted: 23 Jul 2011, 18:26
by StefanP.MUC
We would have to build the AngelScript libraries ourselves, because they don't provide pre-built libraries. This seems to be common practice with all the scripting languages. And accoding to some other open source projects that I took a look at for learning AngelScript, they all distribute the whole AngelScript source package.

I don't have much experience with all these dependency stuff and whether to link dynamically or statically on the different operating systems to decide what is the best way of going here.