Question for General Game/Engine Structure post

[codeslasher]

Hi,
thanks for that great post, very clear and easy to follow. Great information there.

My question has to do with tools and how they could be created using the setup described in the post.

The main drivng force for the application using that engine structure is the CGame class and the state factory.

How would a standard tool like a level editor with 4 views be created using the same setup from that post?

It would be great to discuss how a different type of application with different needs from a game, could be made with this engine setup.

Thanks

[L. Spiro]

As you know there are quirks about OpenGL specifically in regards to contexts etc. and if you were using Qt you would have to deal with that, however here I will make no assumptions as to which API you are using, since that is another separate issue.

Conceptually this is very simple but I have to introduce the next idea in the structure of the game, which is how your scenes and draw calls are handled.

In L. Spiro engine, this is decoupled from the engine structure etc. For example having a game world is not necessary if you just want to draw a menu. Your states are entirely free to do what they please, and the low-level graphics functions are available to them so you don’t have to jump through hoops to get something simple done. For example drawing a few lines and a few sprites here and there does not mean you need to create a game world and try to put objects into it that go where you want them to be on the screen etc.

Following those lines, the engine does not draw anything for you unless you tell it to do so within your CMyState::Draw() method. You can draw whatever you want as many times as you want.
That applies to basic things such as lines and sprites, up to 3D models, up to entire game scenes (CSceneManager).

So in a level editor, you would use a CSeneManager object to manage the scene you are creating and all the objects in it etc. Drawing it from 4 different views simply means rendering it 4 times with 4 different cameras.
In my engine I anticipate the need for split-screen games so the way it works for me is to simply register 4 different cameras that correspond to the 4 viewports of the screen, and then I would rendering it 4 times, once for each camera.
The scene knows that camera 0 is meant for the upper-left portion of the screen, camera 1 is the upper-right, etc. In my case, those details are managed easily for me.


But an easier way, instead of trying to draw to different viewports on the same view/control/widget, is to have 4 different views/controls/widgets, and when those need to be refreshed, just draw the scene with the camera assigned to that view/control/widget.


Again I mention that this is decoupled from the engine structure. There is no game loop here (still will be a CGame, but not running in its own loop), and probably no CState classes. Those aren’t needed in order to make models and scenes. This decoupling is essential for tools since tools are event-driven.


L. Spiro

[codeslasher]

There is no game loop here (still will be a CGame, but not running in its own loop), and probably no CState classes. Those aren’t needed in order to make models and scenes. This decoupling is essential for tools since tools are event-driven.

Could you explain this some more please. This is actually the points am stuck on.
How would we then drive it? Would the main funtion for an editor be different from the wWinMain function you showed in the post?
I am assuming we would still set it up to use Engine::Run ().

Following those lines, the engine does not draw anything for you unless you tell it to do so within your CMyState::Draw() method. You can draw whatever you want as many times as you want.
That applies to basic things such as lines and sprites, up to 3D models, up to entire game scenes (CSceneManager).

My render system uses render queues. You create a render queue for a specific view, and then submit meshes to be rendered to a specific queue. Each render queue has its own view matrix, When the render subsystem is processed by the engine, it executes all the draw calls in each queue, using the settings in that queue.

I did this because, It allows you to send the model to the render system once and have it rendered every frame with no futher call to render it.
However, this then meant that I had to provide an alternative means for immediate rendering/ rendereing things that you dont want to put in a queue.

In my engine I anticipate the need for split-screen games so the way it works for me is to simply register 4 different cameras that correspond to the 4 viewports of the screen, and then I would rendering it 4 times, once for each camera.
The scene knows that camera 0 is meant for the upper-left portion of the screen, camera 1 is the upper-right, etc. In my case, those details are managed easily for me.

But an easier way, instead of trying to draw to different viewports on the same view/control/widget, is to have 4 different views/controls/widgets, and when those need to be refreshed, just draw the scene with the camera assigned to that view/control/widget.

Does this mean that the CGame class can create more windows/views/widgets besides the one created for it by the engine (using the lse::CEngine::LSE_ENGINE_SECONDARY_INIT structure)?
Does your CGame class have a function per message type it can be sent from the engine? (e.g. CGame::OnMouseMove (...), CGame::OnPaint (...))

[L. Spiro]

Could you explain this some more please. This is actually the points am stuck on.
How would we then drive it? Would the main funtion for an editor be different from the wWinMain function you showed in the post?
I am assuming we would still set it up to use Engine::Run ().

There will not be an Engine::Run(). Tools are event-driven. If you were to inherit from QGLWidget, you would use the OpenGL context created by that widget and only update your scene when the widget needs to be updated. Use a timer to make that happen more often, but still rely on that for updates, not the game loop.

My render system uses render queues. You create a render queue for a specific view, and then submit meshes to be rendered to a specific queue. Each render queue has its own view matrix, When the render subsystem is processed by the engine, it executes all the draw calls in each queue, using the settings in that queue.

In my case, the scene itself has a single render queue, and it takes advantage of per-frame temporal coherence, but it is not a bad idea to have multiple render queues, one for each camera, since using the same render queue between different cameras would thrash its temporal coherence. I might change to have one-per-camera later.

I did this because, It allows you to send the model to the render system once and have it rendered every frame with no futher call to render it.
However, this then meant that I had to provide an alternative means for immediate rendering/ rendereing things that you dont want to put in a queue.

This sounds like a problem spot. A render queue should be populated and re-sorted every frame with a stable sort. Typically a templated index-based insertion sort.
As I mentioned, I only have one primary one to represent the scene, but in either case when you render the scene the render queue is populated, sorted, and used for rendering. Temporal coherence improves sorting speed, but having a render queue that does anything more than sort an array of objects to render (or rather indices into an array of objects to render) is having it do too much.

Does this mean that the CGame class can create more windows/views/widgets besides the one created for it by the engine (using the lse::CEngine::LSE_ENGINE_SECONDARY_INIT structure)?
Does your CGame class have a function per message type it can be sent from the engine? (e.g. CGame::OnMouseMove (...), CGame::OnPaint (...))

No. The engine won’t create any windows at all. In my case I have shown some example code where I have 2 initialization steps. The second step has only the purpose of creating the window and then creating the OpenGL context etc.
These things are done for you in Qt (for example) so you never call the second initializer when making tools.


L. Spiro