During the period of Feb 27. – March 27. we received 60 replies. At the same time the ogre 1.11.5 Windows SDK alone was downloaded 644 times. So while the results are significant, they are probably not representative.
As statistics are lies, better take a look at the actual numbers yourself.
Following the #MeanTweets idea I also wrote some short replies to the criticism, that you can read below:
23 HLMS Component users
Originally I wanted to deprecate/ remove the HLMS component from 1.12, but seeing these results I kept it. However I keep wondering why/ how you are using it? It does not give you much over plain #ifdef preprocessor directives in Ogre1. I would be glad if someone could report on their usage in the Forums
Claims to be platform independent, but my Linux and OSX students give up getting it to work on their platforms.
Linux is the main development platform. Maybe your course notes are too Windows specific? I suggest switching to OgreBites::ApplicationContext which takes care of most of the platform stuff. Aside: there is native python support in ogre since 1.10.
There is not much to be gained by Vulkan for Ogre1. Many Engines actually get slower by switching to a lower-level API as things get very vendor specific. Things that a vendor provided OpenGL driver currently takes care for you.
We are aiming to get SPIR-V shaders into our OpenGL3/ GLES3 back-ends though, as offline compilation is the right way forward.
Attaching depth buffers to compositor passes.
Get access to the depth buffer in compositor scripts 🙂
This is possible since Ogre 1.11.3, see here
Missing async texture streaming (DMA/PBOs)
PBOs are already used for texture upload within the GL3+ RenderSystem. There are still some bits missing in Main to fully expose them for buffered streaming.
Slow development cycle. When will we see 1.2 ?
C++11 is used by default since since Ogre 1.11
opengl 2 backend for low end systems in poor countries.
The OpenGL backend in 1.11 only requires OpenGL 1.5
Entered patreon email adresses