Sign in to follow this  
NumberXaero

Handling timing and updates in an editor

Recommended Posts

NumberXaero    2624
How are timing and updates handle in a gui app like an editor? These apps tend be event driven with multiple widgets containing 3d sub views, which may animate and at the very least will probably need a camera moving through it. The camera should probably be taking time into account to get smooth movement instead of jumping some fixed amount when an input event is triggered.
Whats a good way to structure the timing and updates of 3D views in this environment. If updates are done whenever input is received, then there is no traditional "game loop" running with accurate time info available, I cant figure where any continuous movement at all would reside when windows are going in and out of focus randomly, so if you plug an engine in, where does the traditional loop/timing get handled for such things?

Share this post


Link to post
Share on other sites
szecs    2990
How about a state machine? You have event-driven-update-thing state, and game-loop-like-update state? Or using Windows' timers and WM_TIMER message handling? I use that, but I think it's not the best practice, the code is a bit messy.

Share this post


Link to post
Share on other sites
taz0010    277
I use a seperate thread for rendering in directX. The reason for this is that certain calls in the message loop are blocking so the usual PeekMessage() implementation that people use in games do not work properly for window based editors.
Since I'm using threads to overcome a limitation and not for performance reasons, I have my render loop acquire a mutex every frame, and my editor functions running off the message loop acquire the mutex when they need to make changes to objects the renderer uses. This definitely isn't the optimal way of doing this.

The render loop manages 4 different viewports, which are all child windows/directX render targets. I have a seperate timer for each viewport and run the typical render/update cycle on each. I also decided to handle certain input events on the render thread, such as when the camera is moved. When the render thread moves the camera, it inserts WM_MOUSEMOVE messages into the message queue, which greatly simplifies tasks such as allowing the user to manipulate objects while simutaneously moving the camera around.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this