Config dialog extendability

[RAegis]

Hello all,

I try to create a complete free game engine and I use Ogre for the graphic part. ( Everything I say here is subject caution, I'm beginner with Ogre).
I try for now to create a "unified" config dialog for all aspects of the engine (ie. graphic, sound, input, ...). I mean I'd like to have only one config dialog for all of them with tabs for each one (ie. A tab for audio, another one for graphic, ...).
The default Ogre config dialog do not allow it. So, I think it could be a good idea to had methods to return the window handle and provide "event" methods. The main dialog should contains only "ok" and "cancel" buttons, and clicking on one of them should send an "ok" or "cancel" event to each tab.

I also suggest you to use a better "enhancement requests" software than a simple forum. There is many tools available for bugs/enhancements tracking.

I'd also like to talk about the ogre architecture. There is something I don't understand. Ogre is a 3d rendering engine. So, why to have a generic plugin system in the core
Ogre should concentrate on the 3d rendering part and let the other parts (physics, ...) to the game engine. I don't understand why everything is so "intricate". In fact, I think the "destiny" of Ogre is not well defined. You should just move all "non core 3d" parts in a separate project ( ) or implements the other parts by yourself ( ), but not use an hybrid solution ( ).

Regards,

[jacmoe]

I moved this topic to Help, because you clearly have a lot to learn about Ogre.

Do you see anything not directly related to rendering in Ogre?

Config dialog is by choice very basic.
If you need more, write one yourself.
That's what everyone else does.

Don your flameproof vest, you'll need it.

[RAegis]

Do you see anything not directly related to rendering in Ogre?

Hum, well, yes. I just check the code before replying and it seems (OMHO) that a lot of energy is spent to make Ogre very extendable.
Just take 2 examples.
- Why creating an "Archive interface" with a "zip implementation" ? I haven't checked, but I'm sure you have a strategy pattern to choose the right implementation to use. Why don't you just say "Ogre use Zip file for 'this thing or this one' " ? I'm sure you need Zip, but you don't need an interface or a more generic one for file.
To go further on this, just look at this method name: "getModifiedTime". Why a 3d engine should have to know the date of modification of a zip file ?
- And what about scripting ? Why is there scripting classes in Ogre ???

Config dialog is by choice very basic.
If you need more, write one yourself.
That's what everyone else does.

Yes, that's what I have planned to do.

[EDIT: Changed the term "framework" by "engine" => Related to a post below]
But "That's what everyone else does." means that it could be a good thing to do it in Ogre. The goal of a engine is to perform standard tasks and you have created a screen which is, in fact, just an example. Because nobody can use it like this, everybody has to rewrite it...

I'd also like to tell that my writing can seem "hard" (I have had some reflections before), but my thought are not, I just try to explain what I think. I'd also want to add that I'm working (professionnaly, I mean) on a framework (Not related to game nor c++), and Ogre is a very good one. But I'm sure you should rethink of what you want Ogre to be in the future. Because, it is very very complete, but too much complete on things it should not. And some parts could be removed. But you're right, I just read doc, tutorials and examples on Ogre for now, and I haven't practive a lot yet, and I have a lot and a lot to learn about it.

And please, think about using real "enhancement request tracking" softwares...

[banal]

Hum, well, yes. I just check the code before replying and it seems (OMHO) that a lot of energy is spent to make Ogre very extendable.
Just take 2 examples.
- Why creating an "Archive interface" with a "zip implementation" ? I haven't checked, but I'm sure you have a strategy pattern to choose the right implementation to use. Why don't you just say "Ogre use Zip file for 'this thing or this one' " ? I'm sure you need Zip, but you don't need an interface or a more generic one for file.
To go further on this, just look at this method name: "getModifiedTime". Why a 3d engine should have to know the date of modification of a zip file ?
- And what about scripting ? Why is there scripting classes in Ogre ???

So you're basically saying that Zip is just fine for everyone and there's no need for other Archive types? That's like saying: 64kb ought to be enough for everyone.
Since a 3D Engine also deals with files (textures, meshes, etc.), you'll need file handling. Since getting the modification date of a file is platform specific and Ogre isn't, there's a good reason to have a platform independent accessor like "getModifiedTime".
I don't know what you're trying to say here.. Ogre has too many features? I mean.. isn't that a good thing? From my perspective, Ogre is a very feature-complete 3D rendering engine. It doesn't try to be a Game-Engine or 2D engine or anything else. I think the direction/purpose of Ogre is pretty well defined.

And please, think about using real "enhancement request tracking" softwares...

Are you talking about something like this: http://www.ogre3d.org/mantis/ ?

[RAegis]

So you're basically saying that Zip is just fine for everyone and there's no need for other Archive types?

No, perhaps I give a bad explanation. I'm saying that's not up to Ogre to do this.
Interfaces are excellent to allow specialisation, but in this case, there is no need, because it is Ogre which load files, and not an foreign program. Or, if you really need an interface, why having an archive one ? A "file" interface or "folder" one should be enough. You don't have to care if you are in an archive or folder...

Since getting the modification date of a file is platform specific and Ogre isn't, there's a good reason to have a platform independent accessor like "getModifiedTime"

Ok, never mind. I'm ok if you really use it in Ogre core, not if you have coded it for extensability, Ogre is not a "file accessor wrapper".

Are you talking about something like this: http://www.ogre3d.org/mantis/

Something like this, yes, but where are the enhancement requests ?

To summarize, these posts are to say only one simple thing. Ogre is a very very good and complete engine, that's why I tried it and will probably continue with it and that so many people like it. But adding "non suitable" functionnalities can be a drawback because the architecture become more and more complex, and very difficult to understand.
Personnally, I prefer to have a "relatively small" core classes and understand well it all, than to have a lot of classes and search for hours to know how to code or enhance something without breaking another part. This is just a observation, not a judgement. If I had to code a 3d engine, I'll code a core project and eventually some other "utility projects", but it is always easier to say it than to do it.
Just to summarize again, take a look at the API reference page:

It's so BIG!
Yes, yes it is (and thank you for noticing).

If you know it, perhaps it is time to refactor something, no ?

[t0tAl_mElTd0wN]

Perhaps this will help. In the project I'm working on, filesystem access is extremely important. Our game logic is defined by a scripting system, and we need to be able to read script files and interpret them. If Ogre had isolated it's filesystem access code from us, we would not be able to use it. (Using Ogre's filesystem code allows us to standardize on exactly one single way all game resources are accessed.) Additionally, we would not be able to extend it to, for example, stream files over a network, or read them from other archive formats. By having an open, extensible interface for filesystem access (you can apply the same principle to any extensible system in Ogre) it allows us tremendous freedom in the direction we want our projects to take.

[milliams]

Are you talking about something like this: http://www.ogre3d.org/mantis/

Something like this, yes, but where are the enhancement requests ?

Log in, go to Report Issue then under severity select feature.

[RAegis]

Log in, go to Report Issue then under severity select feature.

Ok, never mind... I'll check before next time...

Perhaps this will help.
...
for example, stream files over a network, or read them from other archive formats.

Yes, it helps, streaming over a network is a good reason to use an interface, and I agree, having a file/folder interface is definitevely a good (or not so bad ) idea.
But...
The problem of implementation is still here. Implementations should not be (once again OMHO) in the core project. But be an utility project. Even for thing as common as zip files.
Commons utilities should be packaged and distributed with the core project, but "hard packaged" implementations should not exists.

Because of now I know how to create enhancement requests, I will directly create one !

Thanks for all !

PS. Just a last remark, please, add a "READ FIRST" note on top of this feature forum. And give the the URL of Mantis, it will allow dummies to post features correctly (When I say dummy, I do not speak of me ! or a very very few...).

Regards

[banal]

I think you won't be taken too seriously with feature requests, when your experience with the Ogre framework is close to zero. I suggest you have a closer look at the framework first (use it in some projects), before you request design changes. Sure, it's always good to get "fresh" opinions on something, but uninformed opinions will probably not help much.

I for one wouldn't dare to suggest a design-change with my current knowledge of Ogre.

[jacmoe]

I'd also like to talk about the ogre architecture. There is something I don't understand. Ogre is a 3d rendering engine. So, why to have a generic plugin system in the core

Everything is a plugin.

That means that you get ultimate freedom, because rendersystems, scenemanagers, resources, just about everything, are plugins.
That pluggable architecture is one of the neatest things about Ogre.

[Speedo]

I'd also like to talk about the ogre architecture. There is something I don't understand. Ogre is a 3d rendering engine. So, why to have a generic plugin system in the core

Unless you know of a way to write one 3D engine which can capably handle all types of scenes, the plugin system is pretty much mandantory for OGRE. Without it you'd have to shoehorn the engine into supporting only a few types of applications.

[RAegis]

I suggest you have a closer look at the framework first (use it in some projects), before you request design changes. Sure, it's always good to get "fresh" opinions on something, but uninformed opinions will probably not help much.

You're right, but I don't consider myself as a newbie. I have now many years of professionnal development and then architecture on a framework. Of course, Ogre is not a framework but an engine, but these kind of projects are "close enough", I think, to me to be able to talk about it. And the change is not a big one, and not related to development but to high level design. It was in fact, a request to "move" unrelated parts to external plugins. But you're right, I have had to take a deeper look to the design before posting, but coding with Ogre before, is not, on my opinion, a real issue. Or perhaps just for credibility.

Everything is a plugin.

Unless you know of a way to write one 3D engine which can capably handle all types of scenes, the plugin system is pretty much mandantory for OGRE. Without it you'd have to shoehorn the engine into supporting only a few types of applications.

Ok, I now understand that everything is plugin and that plugins are the way you choose to extend Ogre, but the original question was not concerning scene, materials, or everything related to the "core". But the things which are not related (Archive, Log, font or even sky domes or particle systems, (but I know the 2 last are subject to troll, so, don't consider them for now, we'll talk about them when you'll be convinced about the 3 firsts )).
In fact, the first question was about physics, etc, but it was a bad request, but the mind is still the same, just the components have changed.

Extract from the first post:

You should just move all "non core 3d" parts in a separate project

I know, I'm a little headstrong, but I seem to not have explained my though clearly.
So, can anyone give a good reason, to let the non core parts (ie. Archive, Log, ...) into a one single big core project ?

[sinbad]

This has been raised before. My problem with this is that you can decimate a project to the Nth degree and it doesn't actually make it any easier to work with - quite the opposite in many cases. You go from having to find headers & link settings for 3 projects and end up having to find them for 10 instead.

I take the point that there are some things that could be separated - math, logging, archives etc. However I question the actual practical difference this will make. If you want to save code size in cases where you only reference a subset of Ogre, just include the headers you need and statically link. This will have the exact same result as if we separated Archive, Math etc out, except that it's much simpler, both for us within the project, and people referencing it. I think a lot of this argument is down to theoretical nicety than concrete practicalities.

[RAegis]

Ok, thanks.

It respond to my question. It was not a practical problem (size or whatever), but more a "philosophical" one, because I think Ogre will continue to grow.
Furthermore, It can be technically "harder" or longer to reference expatried plugins than removing them, but to take care of this you can propose for download a "core" package (nude) and a "standard" package (with standard plugins), for example, if you want to provide a framework and not engine.
And it also have the advantage that when you want to change a component, you don't have to re-release the entire application. And transitions between technologies can be made smoothly. It gives flexibility.
But, when there is flexibility , there is more maintenance ... The choice is yours.

[sinbad]

All the things that are really worth separating are already separated in my opinion. Scene managers, terrain components, paging components etc. The 'core' of math, archive and logging etc is really very small beer in comparison. That's why I think this suggestion is more theoretical than practical.

[t0tAl_mElTd0wN]

For the most part I agree with Sinbad. Ogre's core is healthy the way it is. It's big, but it's features justify that easily.

The one exception I'd make is in, for lack of a better term, the "utility" classes. Vector, Quaternion, Matrix, ConfigFile, Math, StringConverter, Radian, Degree, ColourValue, etc. The things that don't rely on an Ogre::Root in any way. These would make an excellent secondary utility library for projects that could make use of such classes without linking with all of Ogre and it's GUI dependencies.

But I would hardly call it a "problem". :)

[nullsquared]

without linking with all of Ogre and it's GUI dependencies.

Just a small correction, Ogre doesn't have any GUI dependencies.

[t0tAl_mElTd0wN]

GUI was a bad word. I don't mean in-game GUI, I mean things like, X libraries. FreeImage. Things, basically, that a dedicated server with no graphical output or rendering system would need. In the end OgreUtility (whatever it got named) would have no dependencies.

Then again, I could be totally way off the mark here thinking any of those are required. If they're not, awesome! :D

[Rasengan]

Config Dialog extendability ? That 's your first question, no?

-So,inherits from Ogre::ConfigDialog, personalize it according your needs... (new splashscreen, additonal options, tabs, icons bar, ..., honey, sugar )
-Inerhits from Ogre::Root and redefine showConfigDialog() to instanciate "YOUR new personalized" configDialog.

An easy and fast way to take advantage from actual config dialog system, with additonal options and personalized "blink blink" Dialog.

What else?

If this doesn't fit your needs, then yes, write once from scratch.