#6 A few CMAKE fixes, and one include fix

[Danduk82]

Hi,
Thanks for developing this camera control system, and Thanks for sharing your code: I I find it very usefull. This saves me probably hours of coding, nice job.

I have "fixed" a few things in the CMAKE projects, so that it is possible to compile the sources of CCS outside the sources tree, which is advised by CMAKE authors. I also one include missing due to OIS.

I would suggest to modify a litle bit more the CMakeList.txt in CameraControlSystemSDKDemo so that the directory can be added as subdirectory of OGRE/Samples sources, and in this case one shoud add the line "ogre_config_sample_lib(${sample_name})" so that it is configured right.

I append the "svn diff" patch to this thread.

Cheers

[Alberto Salguero]

Thanks a lot for your suggestions. The patch seems ok to me. I'll apply it as soon as possible but please be patient. I'm really busy at work now.

Regards,
Alberto

[Danduk82]

Thanks,
I was thinking to overload CameraControlSystem::CameraControlSystem, CameraControlSystem::registerCameraMode, and CameraControlSystem::getCameraMode to get an integer value defined in an enumerator (such as enum CAMERAMODE {FIRST_PERSON, ATTACHED, PLANEBINDED, etc} ; ) for efficiency reasons because string search is quite CPU consuming, and for practical reason because it is easier to search for a method name with Eclipse auto-completion in this way ;) . Do you think it is a good idea? The methods are not called that often, this is true...

May I suggest you to open a trunk or devel branch which I could lightly contribute, as I am playing around your code these days? You could accept the branch without need to apply the patches yourself by hand. Let me know.

Kind Regards,
Andrea

PS: I am developing a prototype engine based on Ogre for the community-based game "Hearts of Oak, Conquest of the Seas" of the "PiratesAhoy!" community. See our project <href="http: www.piratesahoy.net="" threads="" 2013-a-great-year-for-piratesahoy.21621="" "="">here</href> or <href="http: www.piratesahoy.net="" categories="" hearts-of-oak-conquest-of-the-seas.131="" "="">here</href>.

EDIT: I meant "overload", not "override" ,sorry for the typos

[Danduk82]

PS: the links are not working, here they are:
http://www.piratesahoy.net/categories/hearts-of-oak-conquest-of-the-seas.131/
and
http://www.piratesahoy.net/threads/2013-a-great-year-for-piratesahoy.21621/

[Alberto Salguero]

Well, thats not exactly the meaning of the methods getCameraMode and registerCameraMode. My fault choosing their names, probably. In fact, you could actually have different camera modes of the same TYPE (FIRST_PERSON, ATTACHED, PLANEBINDED...) assigned to a camera control system. You may have two different "third person" camera modes to switch between. Using an enum to identify the camera modes also forces other people to modify the lib if they are using custom camera modes (to extend the enum).

I'm going to recreate the project structure and give you write permissions to the repository.

Nice project, by the way. And really good looking! ;-)

[Danduk82]

Ok, I see. Thanks for the clarification. As I see it, overloading the functions should allow people to keep their current implementation, while extending the API at the same time.

I would keep the original "CameraMode * getCameraMode (Ogre::String name)" and add a new "CameraMode * getCameraMode (CSS::cameraTypeId cameraType)" or something similar. In this way both implementations are supported, and this does not break backward compatibility.

Thanks for giving me commit rights, I'll contribute as I can, and try to keep the code documented and backward-compatible. This is far better than re-writing almost the half of the work you did by myself ;)

BTW, Hearts Of Oak is a great project indeed. I got involved more or less by pure hazard and I am now part of the team. We have a lot of really good modelers, because it is first of all a modding community, but we lack of experienced programmers (usually it is the opposite, i.e. it is difficult to find modelers...). Initially we started with the UDK engine, but after one year we found impossible to bend it to our needs, so we are now evaluating 2 engines: CryEngine and Something custom based on Ogre3D. For this kind of project I definitely would prefer something completely open-source, but the decision will be made by voting. My short-term objective is to provide a small "proof of concept" game engine based on Ogre. Let's see what we get...

In the mean time, I also noticed your personal flight simulator on Ogre forum, looks great.

[Alberto Salguero]

I have added you to the "developer" group. You should be able to commit changes now. Please do it to the new "trunk" branch.

[Alberto Salguero]

I still don't see the reasons for such change. Unless you were switching between camera modes every frame, you are not going to notice any performance improvement. Anyway, you can always traverse the list of camera modes using the method getNextCameraMode. It uses iterators. It treats the camera mode list as circular, so you just need to store a reference to the camera mode you are searching for as a local variable. Actually, it could be improved a bit, because it always starts from the beginning of the list. But, again, you are not probably dealing with camera modes every frame, are you?

[Danduk82]

I agree, I have played with the code more deeply yesterday. I think I had misunderstood a couple of things in the beginning but I understand it right now.

You're right, no need to use integers, I won't change it every frame ;)

I'll submit a few fixes for the CMAKE project. I still cannot compile it properly using linux for the SDKdemo but I'll find a clean (hopefully) solution.