After the project is compiled successfully, you can start learning.

1. Analysis of document structure

• CMake
• Components component
  • Hlms
  • MeshLodGenerator
  • Overlay
  • Paging
  • PlanarReflections
  • Property
  • RTShaderSystem
  • SceneFormat
  • Terrain
  • Volume
• Docs
• OgreMain
• Other
• PluIns
  • BSPSceenmanager
  • CgProgramMaanger
  • EXRCodec
  • OctreeSceneManager
  • OctreeZone
  • ParticleFX
  • PCZSceneManager
• RenderSystems
  • Direct3D9
  • Direct3D11
  • GL3Plus
  • GLES2
  • Metal
  • NULL
• Samples
  • 2.0
    • ApiUsage
    • Common
    • Showcase
    • Tests
    • Tutorails
  • Media
    • 2.0
    • DeferredShadingMedia
    • Hlms
    • ...
• Scripts
  • BuildScripts
• SDK
  • Android
  • iOS
  • OSX
  • Win32
• Tests
  • CapsReport
  • Components
  • Media
  • OgreMain
  • PlayPen
  • src
  • VisualTests
• Tools
  • 3dsmaxExport
  • BitmapFontBuilderTool
  • ...
• BuildingOgre.txt
• NewTips.txt

Previously familiar with ogre1 X, very familiar with these file structures.

Look at Docs

There is not much useful information. You can take time to have a look.

BuildingOgre.txt 

How to compile ogre next on each platform

NewTips.txt

Some are described with ogre1 X different places. This pair was previously used ogre1 X's classmates are very useful.

• Names are no longer unique and objects are no longer distinguished by name. Use id instead.
• Entity visibility that is not attach ed to scenenode cannot be set to true, which will cause a crash. If it doesn't work, why break it down
• Shadow change
• Camera relative rendering has been removed. Change to the SceneManager that supports modifying the root scene node: setRelativeOrigin

Just getting started ogre, we can't understand it, and we don't dare to say.

Because there are not enough documents, the information available here is limited.

Look at the project solution.

Roughly divided into:

• OgreHlmsxxx
• OgreMain
• OgreMeshxxx
• OgreOverlay
• Samplesxxx
• Plugin_xxx
• RenderSystem_xxx

There's no useful information. The grouping is missing. It can't be like ogre1 Like x, distinguish functions

Go directly to Tutorial

Run Sampel_Tutorial01_Initialization, there is only one full screen window with color. Because two screens are used, it affects the other screen at runtime. bug!

Look at the code, there are several classes

GameState

MyGraphicsSystem : GraphicsSystem : BaseSystem : MessageQueueSystem

Ogre 1.x calls the function of creating and initializing windows bits, which belongs to components. Here it is changed to GraphicsSystem, and the incoming parameter is called GameState, graphics system / Game state? It doesn't feel like a match. Or 1 The Application of X is more appropriate. GraphicsSystem is better matched with Game. GraphicsSystem belongs to Sample, which is not structurally distinguished. Or 1 The bits of X are better. namespace is a Demo. GraphicsSystem hasn't been incorporated yet.

1. Create a MyGameState myGameState;

class MyGameState : public TutorialGameState

 class TutorialGameState : public GameState

    class GameState : public MouseListener, public KeyboardListener, public JoystickListener
    {
    public:
        virtual ~GameState() {}

        virtual void initialize(void) {}
        virtual void deinitialize(void) {}

        virtual void createScene01(void) {}
        virtual void createScene02(void) {}

        virtual void destroyScene(void) {}

        virtual void update( float timeSinceLast ) {}
        virtual void finishFrameParallel(void) {}
        virtual void finishFrame(void) {}
    };

Look at GameState and find a strange thing

        createScene01, createScene02

This creation scenario also specifically indicates SCENE01 and scene02, which cannot be defined as a general base class.

2. Create graphicsSystem

    GraphicsSystem graphicsSystem( &myGameState );

    myGameState._notifyGraphicsSystem( &graphicsSystem );

    graphicsSystem.initialize( "Tutorial 02: Variable Framerate" );

    if( graphicsSystem.getQuit() )
    {
        graphicsSystem.deinitialize();
        return 0; //User cancelled config
    }

    Ogre::RenderWindow *renderWindow = graphicsSystem.getRenderWindow();

    graphicsSystem.createScene01();
    graphicsSystem.createScene02();

Then, I found that there are also createscene01 and createscene02 in GraphicSystem.

So we can guess that GraphicsSystem and GameState can only belong to Demo level.

There may be similar problems in the future The bits of X appear.

3. Game cycle

    while( !graphicsSystem.getQuit() )
    {
        graphicsSystem.beginFrameParallel();
        graphicsSystem.update( static_cast<float>( timeSinceLast ) );
        graphicsSystem.finishFrameParallel();
        graphicsSystem.finishFrame();

        if( !renderWindow->isVisible() )
        {
            //Don't burn CPU cycles unnecessary when we're minimized.
            Ogre::Threads::Sleep( 500 );
        }

        Ogre::uint64 endTime = timer.getMicroseconds();
        timeSinceLast = (endTime - startTime) / 1000000.0;
        timeSinceLast = std::min( 1.0, timeSinceLast ); //Prevent from going haywire.
        startTime = endTime;
    }

beginFrameParallel, update, finishFrameParallel, finishFrame. At least not like 1 X, a startrendering contains everything.

Yes, 1 X's learning experience, 2 If you are familiar with X, you will no longer run and analyze each sample.