Downsides of example framework?

[milos]

I've read people talking how example framework is dirty and things in Ogre shouldn't be done the way they are in the example framework, but no one said what exactly is wrong, and what are the specific things that should be done some other way.
Could someone clarify this for me?

[jacmoe]

I don't have a problem with it, but apparently lots of people don't like it.

They say that it hides the workings of Ogre, but Ogre itself hides the workings of DirectX and OpenGL..

It's a matter of taste.

But, the old example framework uses headers only, and that's not really an example of good coding practices.

[Klaim]

The problem is that most beginner look at the code and don't understand some parts because there is common code that is outside each project.
More than that, newcomers often take the example framework as some kind of "basic example of simple Ogre-based application".
But in fact, each example is a basic example of a specific feature or a specific graphic technique.

Then come the rants on the forum and answers pointing to the wiki tutorials...

[milos]

Ok, thanks. What about OgreRefApp? I see it's removed from Ogre 1.7.

Also, would you suggest using "Basic Ogre framework", or not?

[bvanevery]

But, the old example framework uses headers only, and that's not really an example of good coding practices.

I must admit, I just looked at this, and my first reaction was "WTF?" Why are they doing this? Now I have to worry if the examples are all based on some kind of bizarre plugin, subclassing, and callback control flow, with maybe some kind of function pointer swizzling to boot. What's wrong with starting from main() or WinMain() and having a "first we do A, then we do B, then we do C" approach? Samples and tutorials should Keep It Simple Stupid and at first glance, this stuff is not doing that.

If you want to look at a really useless sample framework, look at the MS DirectX SDK. Mountains and mountains of useless boilerplate garbage to get very little done.

[jacmoe]

Get laid.

[bvanevery]

Relevance?

[jacmoe]

Judging from your latest 15 posts, it looks like you've got an axe to grind?

What's wrong with starting from main() or WinMain() and having a "first we do A, then we do B, then we do C" approach? Samples and tutorials should Keep It Simple Stupid and at first glance, this stuff is not doing that.

Repeating the same code over and over and over really doesn't KISS it.
And, the example framework you're referring to has absolutely nothing to do with a tutorial framework - they are header only, simply because it seemed like a good idea to not require the samples to link to a common framework, or directly include the implementation files.

We discussed this recently:
http://www.ogre3d.org/forums/viewtopic. ... 61#p381095

[Nargil]

Yep it really sux for people who think that way:
1. mmhm I really need this cell shading
2. ok I open the Demo_CelShading project
3. what now ?! Oh I'll build my game on top of it !
4. profit ???
5. Fuuuuuuu!

But it's a good way for showing only a certain piece of code.
The problem is with newbies, who think of the samples as if it was a "how to use ogre sample". I had to admit I was one of them some long time ago.

[bvanevery]

We discussed this recently:
http://www.ogre3d.org/forums/viewtopic. ... 61#p381095

I actually read that thread in the archives before posting here. It's hard to tell people how not to write confusing code, especially when they don't value the same things.

Axe: the MS DirectX SDK has an atrocious sample code framework.

[jacmoe]

Axe: the MS DirectX SDK has an atrocious sample code framework.

I agree completely.

[bvanevery]

- they are header only, simply because it seemed like a good idea to not require the samples to link to a common framework, or directly include the implementation files.

Maybe people had historical reasons for that. But in a CMake driven build system, I see no reason to avoid having libraries or linkage. At least in a MSVC universe, all of this stuff is going to turn into browseable code that you just click on to figure out what depends on what. If I were writing a sample + tutorial for a complex, convoluted piece of code, as what happens when you try to set up low-level 3d graphics pipelines nowadays, I would concentrate on making each piece of the pipeline very simple, and part of a library. So Tutorial 1 would use 5 pieces of the library, Tutorial 2 would use 7, Tutorial 3 would use 12... you get the idea. MS does not get the idea. Or, to the extent that they do, they put their effort into XNA so they can brainwash everyone into using C# and .NET.

[MrD]

Axe: the MS DirectX SDK has an atrocious sample code framework.

I agree completely.

That does also have it's advantages. Since the DX examples, and the DX example framework is so bad it forces you to figure out what things are doing so you can implement them properly in your own code. While I agree that that might not be very convenient for new programmers, or people who just want a copy/paste solution, it is convenient later down the line when you realise you need to make a change to it, since you should have a rough understanding (at least) of what it is actually doing and why.

No doubt you could in fact build a game by copy/pasting code, however I would bet that you would eventually reach a point where something broke, or something was not suitable and you found you had to fix it... only you couldn't, because you don't actually know what any of this code is doing.

IMHO it is always better to use samples as an example of how something can be done, and then implement it yourself using that as a working reference rather than just copy/pasting code blindly, since that is how you learn.

[bvanevery]

That does also have it's advantages. Since the DX examples, and the DX example framework is so bad it forces you to figure out what things are doing so you can implement them properly in your own code.

No it doesn't. Other options are to find other people's DX11 sample code, investigate OpenGL, or a 3D engine such as Ogre to put a layer in between you and the grief. As you might surmise I've currently worked up to option #3.

IMHO it is always better to use samples as an example of how something can be done, and then implement it yourself using that as a working reference rather than just copy/pasting code blindly, since that is how you learn.

I'm old enough to not be terribly interested in learning for its own sake. I've learned dozens of things over the years that are now obsolete, and of all the techs out there, the latest greatest DirectX is certainly ephemeral. This kind of MS SDK nonsense wastes my time, and I'm not getting paid for that time. As far as I'm concerned it should all be handled on a "need to know" basis.

[MrD]

I'm old enough to not be terribly interested in learning for its own sake. I've learned dozens of things over the years that are now obsolete, and of all the techs out there, the latest greatest DirectX is certainly ephemeral. This kind of MS SDK nonsense wastes my time, and I'm not getting paid for that time. As far as I'm concerned it should all be handled on a "need to know" basis.

I'll admit that there are times when you just don't give a shit about how something works, and just want to get on with it and get it done. However I enjoy programming, it is my hobby as well as my job, so I enjoy working out how things work and tinkering with things that should probably be sanely left alone. Apparently I am not yet old enough to have had that love and joy beaten out of me.

[Kojack]

I've been coding for 26 years, and I hope I never reach the point where my driving motivation is cash.

[bvanevery]

I'll put it this way, those who have no passion never do as well as people who do have a passion for what they do. It's only natural.

No it isn't. You clearly haven't spent time around starving artists, musicians, actors, and writers, i.e. traditional media. Consider yourself lucky that you were passionate about things that were worth money to society.