Ogre Forums

Hi!, are you guys thinking in including in the next release of the ogre sdk an updated version of CEGUI?, it is being a while(27th March 2008) since the CEGUI project move from 0.5.x to 0.6.0, and its really a pain not to have the precompiled binaries that comes with the ogre sdk with at least one of the CEGUI 0.6.x, and every time I download a new version of ogre I have to do update the source code and generate the OgreCEGUIRenderer, like this -> http://www.cegui.org.uk/phpBB2/viewtopi ... gre+update, I think once in a while it will do no harm to update CEGUI in the sdk, well it is just a suggestion maybe everybody is used to do that, thanks any way, and beautiful work, I love Ogre!

It has been requested before, and sinbad recognised it.

But it was like "when there is time, then..."

AFAIK, the local CEGUI will update whenever a stable Ogre gets released. IIRC.

Actually the dependencies issue is very important. Although OGRE has a very much plugin oriented interface, it is not that plugin friendly because of following issue:

If I use a custom built OgreMain.dll, the plugins built with other compilations of OgreMain.dll (or any other dll like rendersystemXX.dll) wont work with my dll (causing entry point etc. exceptions)

So, lets say I developed plugin for OGRE, I cant just distribute the DLL or SO and other people use it as it is. They need to compile it with their version of OGRE in order for it to work.

The only solution to this problem is to use OGRE SDK for the builds. If I compile my plugin with OGRE SDK, it will run as it is on any other people's machine which is using the SDK without any problems.

But then comes the dependencies problem. the version of CEGUI used with OGRE SDK is a bit outdated, if you want to use the latest features you need to rebuild with latest CEGUI, then comes the incompatibility of the DLLs issue.
Since CEGUI is a special case it may not be that important. But we cant say the same for CG. The current version of CG used with OGRE SDK has some serious problems which are fixed with the newest CG SDK. Now if I compile with the new CG dependencies, my DLLs wont be compatible with the pre-built plugins created by other people.

So, using the latest version of Dependencies with each OGRE SDK would be very helpful in terms of Plugin compatibility since all plugins built with the SDK release will be compatible with the SDK Dlls and can be distributed as pre-built plugins. Also using the latest stable releases of dependencies may help finding reasons of the bugs (some bugs are fully dependencies related)

Thats my 50 cents

A LITTLE NOTE: Actually there is a slight problem with the attitude of OGRE Team (no intention to offense anyone, OGRE is an awesome work presented by very good programmers). The problem can be called as "Developer's Syndrome". It occurs to me that the TEAM prefers to think that everyone using OGRE is a programmer who can tailor OGRE to his/her needs and prefers to think as if there are no final users. Thats exactly the same syndrome which linux developers had once. A bright OS like linux had a user base of %0.1 in whole computer world, although its FREE. The problem was : Although linux was a powerful and customizable OS, its interface was only usable by expert programmers and was like an AlienMachine for a regular user. Only when user friendly interfaces to customize linux started to spread, it had a sudden jump in terms of user base. So, we need more user friendly approaches for OGRE along with programmer friendly approaches. We need more Editing interfaces for OGRE, for people who doesnt know or arent interested in inner workings of engine, but who just wants to visualize their dreams. We need an up-to-date common SDK which can be used as a common library to create distributable plugins (which dont require a rebuild on users machine) etc. etc.

I know that I am very new in the community, I am sure that the developers may have spent quite a lot of time deciding the way to go and to give the final decisions about the subjects I mentioned here, I even feel like I have no right to criticize the decisions made by the TEAM and believe me have no intention to offense anyone in any way, but needed to share my feelings from the experiences I had with OGRE.

Ismail TARIM,

This is not actually Ogre's fault, but the fault of C++. You simply can't make C++ plugins which work across different compilers or even across different versions of dependency libs. Unless the core lib / application is limited to a single platform and single compiler the only reasonable way to distribute C++ plugins for it is by source. I wouldn't even bother with precompiled plugins. You've already spotted the disadvantages

CABAListic:

I cant imagine people recompiling Photoshop or MAX or any other popular application's plugins
There are 2 feasible ways of making plugins universal:
1 - Use a fixed Exports Definition for the core libraries (which is kinda hard for an ever growing api)
2 - Use a common pre-built SDK for building the plugins

so, if the main application is using OGRE SDK, all plugins compiled with OGRE SDK on any machine will be automatically compatible with the main application.

The problem here is the even the newest SDK 1.6.1 is not compiled with the newest dependencies like new CEGUI and CG. So to support plugin compatibility we need to sacrifice the features and bug fixes of new dependencies.

ismail,

Your example doesn't fit. Photoshop and Max are both commercial closed-source applications with a single or at least a very limited number of platforms and compiler variety. Furthermore I'm not even sure whether they expose true C++ interfaces for plugins (if all communication between the host and the plugin is done via a C API, then the whole problem is reduced quite a lot; unfortunately this is not an option for Ogre).

Not so with Ogre. You make it sound as if there was only *one* Ogre SDK. This isn't true. There is at least one SDK for VC8, VC9, MinGW, and that's just on Windows. In addition, the SDKs have a fixed and potentially limited set of compile options, for example they ship without threading support. sinbad has often mentioned that the SDKs are more of a quickstart option, but they cannot and will not cover all bases of Ogre usage. Therefore many Ogre developers are using source releases, anyway. So I hold my claim: The only feasible way to distribute Ogre plugins is as a source release. Anything else is not only extremely time-consuming for the plugin developer (you have to offer a precompiled binary for each of the mentioned SDKs, updated whenever Ogre releases a new patch release), it also severely limits its usability.