My second question is that my actual game scene uses bound camera and I perform scrolling on that camera but my other scene uses the normal camera. So in this situation what to do? how to use multiple camera for single engine? or how to reset available current camera?
Our 3d game engine allows us to create as many render targets we wish. A render target is basically a window where we actually project the 3d scene. Generally, there is typically only one render target, but in some cases in the editor and tools, we do have up to 3 render targets.
A render target allows us to create as many viewports we wish within the render target's area and place them as we wish. Such a design allows you to create a minimap viewport or even a split-screen viewport often found in co-op or two-player console games. Viewports are basically a means of dividing the render target's area in specialized regions.
Then, in order to create multiple scenes, we do this by creating a new scene manager for each scene we want to manage. Each scene manager allows us to define as many cameras we want. I could place 10 cameras easily into a scene all with different vantage points of a scene.
The key here is that the viewports associated to the render target can be attached to a specific camera. By attaching a specific camera to a viewport, I now have associated a specific scene to a viewport and the perspective rendered is that of the attached camera.
I find such a design to be helpful in keeping things decoupled at various layers and is very flexible.
-> My first question is that this much loading of texture will create any problem in game performance,So all the scene in the game have reference to this TextureManager class and they access corresponding texture region using dot operator. if other better strategy for this texture loading then please suggest me.
It isn't uncommon to do some loading of resources, creating textures that may be needed later and keeping those in memory for use when needed. If you think about any console game, there is usually this "Loading" game state where a lot of this activity happens. The nature of consoles often require such management of resources and memory since background loading of assets isn't optimal as it may be on a PC for example.
In our case, we use a single TextureManager across all scenes. Our rule is that two scenes can't expect to use the same texture name if they're expected to be actually be different. Such a design imposes the responsibility on the scene loader to handle the cases as needed but allows the sharing of texture resources across multiple scenes if the need existed.
In the cases where the textures need to be different, the loader just loads the textures in the manager with a name scenename.texturename so that they are allocated uniquely per scene.