codeslasher wrote: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.
codeslasher wrote: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.
codeslasher wrote: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.
codeslasher wrote: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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them.
- L. Spiro 2011