Starting up samples directly somehow doesn´t work here. I´ve added "StartupSample=Sample_Instancing" to (OGRE_BUILD)\bin\release\samples.cfg. When runing in release mode he just starts as usual...

The instancing demo has a bug. If you select 1000 entities there are actually less then 1000 in staticmesh/independent entities mode (I didn´t count them but its clearly visible that some of the upper ships disappear). The performance difference between is very small.

xadhoom, as mentioned earlier, Sample_Instancing is the filename of the sample plugin, which contains the sample with the title "Instancing". So change the line to StartupSample=Instancing, or whatever the title of that sample is.

Had a look at the instancing demo, as I also encountered something that looked strange. The 'instancing' option actually rounds UP the number of instances. I don't know if this is intentional or not, but that is what happens. When dealing with the razors (default model), there are 80 models per 'floor', and the instancing techniques rounds em up to the closest multiple of 80. So there will actually be 1040 razors at 1000 when using the instancing technique.

Now that i think of it, i think its intentional - the original default was 160 entities (a multiple of 80) so there was no difference between the techniques. I changed it to 100, but that makes the difference visible from the start (since instancing technique rounds up to 160 already). I'll just change the starting point back to 160...

The articles are finally done! I have to divide up the article into 3, because the original one exceeded 32KB or something. The one about the framework links to the ones about the tray manager and the camera controller.

Just watched your latest video, and I would propose to also allow the user to toggle the help dialog via the F1 key (in addition to H), as this is probably the more common key for that.

I also put your three articles in the SoG2009 category, however I don't know if that the most suited for them. Is there more to come about this sample thing or is everything documented now? Because an own category for three articles is perhaps too much...

jacmoe: Thanks for your comments. spacegaier: The F1 shortcut was added before I even made the video. I just didn't mention it. Heh.

I don't think Summer of Code 2009 is a good tag at all. Yes, this work was done over the summer, but it's now part of the trunk, and there's no reason for anybody to know/care that this code was developed during the Summer of Code 2009. "Samples" should work well. I don't think the number of articles within a category would make the category more/less suitable.

Okay, my first thought: No!!!But after rethinking it: Why not...Somebody could even write a little article about a specific sample and explain it in depth, which then would go in this category as well.

So, I am convinced now .

EDIT: One thing though (not only adressed at you, but everyone): If you enter code in the wiki, don't do this indentation hack to get it displayed in code style, but put a

We clearly stated that this sample framework will NOT be a simple application framework, and that ExampleApplication.h etc will remain.However, if all the demos are ported to the new framework, there won't be any usage examples of ExampleApplication.h in the SDK, which I think is bad. (New users might not be aware of its existence)

I see four ways to solve this :1) Keep some demos in the ExampleApplication framework2) Duplicate some demos and put them in both frameworks3) Add some of the tutorials to the SDK as ExampleApplication demos4) Add a link in ExampleApplication.h to the wiki, where tutorials using it can be found. (Tho, will everyone find ExampleApplication.h to look at the wiki?)

I left ExampleApplication.h and ExampleFrameListener.h in the repo simply to avoid unnecessarily breaking the code of users who already use them, and also to avoid invalidating all the tutorials that reference it. We won't be using it in the core anymore, but there's no point breaking stuff if we don't have to. If need be, we can add a simple unit test to prove that it still compiles as a backwards compatibility proof.

Going forward, it's been made clear to me that people wanting to learn how to create their own apps with Ogre would rather copy & paste a complete, self-contained template app as a starting point and hack on that, than to derive from 'example' classes. That's why I've been encouraging everyone to bear in mind the difference between the 2 groups of people making apps: the team and other users who just want to create a new sample or test an effect out (for whom the new sample browser is perfect), and those who want to learn how to make a new standalone app with Ogre, for whom something like the PracticalApplication in the wiki is more appropriate. ExampleApplication's problem is that it tried to cover both bases, and ended up doing neither 100% effectively. So yeah, maybe it won't be left to completely die until all the references to it are gone, but it will be considered legacy only from now on.

Omniter - I think I found a bug in the SelectMenu widget, probably related to item removal. To reproduce, get the latest trunk, and in the compositor demo do this :

1) Enable the "B&W" and "Laplace" compositors2) Select the Laplace texture from the RTT debug menu in the top right corner3) Disable the "Laplace" compositor4) Try to select a texture from the RTT debug menu in the top right corner