How to trap win32 event (WM_TIMECHANGE) in ogre

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
ritz
Gnoblar
Posts: 12
Joined: Tue Nov 02, 2004 6:16 am

How to trap win32 event (WM_TIMECHANGE) in ogre

Post by ritz » Mon Jan 24, 2005 3:19 pm

Hello ,

I need to trap WM_TIMECHANGE event in ogre application.
As their is no direct support for this.

How can i trap this event in any ogre application

rgds,
Ritz
0 x

User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD » Mon Jan 24, 2005 3:54 pm

You can make your own rendering loop, and process windows messages in it.
0 x

ritz
Gnoblar
Posts: 12
Joined: Tue Nov 02, 2004 6:16 am

Trapping win32 event

Post by ritz » Fri Jan 28, 2005 8:21 am

Hello,

Thanks for reply.
Can any body please give me any code sample for the same.


rgds
Ritz
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Fri Jan 28, 2005 2:40 pm

This is not exactly a common Ogre requirement. Use the Windows SDK docs, man :)
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Fri Jan 28, 2005 11:30 pm

Or post it in the "Back to Basics" area ?
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Sat Jan 29, 2005 12:14 am

Here is the 0.15 Root::startRendering loop:
//-----------------------------------------------------------------------
void Root::startRendering(void)
{
assert(mActiveRenderer != 0);

mActiveRenderer->_initRenderTargets();

// Clear event times
for(int i=0; i!=3; ++i)
mEventTimes.clear();

// Infinite loop, until broken out of by frame listeners
// or break out by calling queueEndRendering()
mQueuedEnd = false;
while( !mQueuedEnd )
{
#if OGRE_PLATFORM == PLATFORM_WIN32
// Pump events on Win32
MSG msg;
while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
#endif

if (!renderOneFrame())
break;
}



However, nothing requires you to use this method. You can write your own, duplicating most of the logic and adding any of your own. I believe you can simply add an if statement like the following:

MSG msg;
while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
if (msg.message == WM_TIMECHANGE)
{
; // anything you want here
}

}


Not sure if that's what you're looking for. Hope it helps.

Edit:

Not sure how to handle this part of the code though.

// Clear event times
for(int i=0; i!=3; ++i)
mEventTimes.clear();
Last edited by Silent on Sun Jan 30, 2005 1:06 am, edited 1 time in total.
0 x

User avatar
Kristian
Hobgoblin
Posts: 542
Joined: Sun Jan 12, 2003 7:35 pm
Location: Copenhagen, Denmark

Post by Kristian » Sat Jan 29, 2005 10:10 pm

Alternatively you could hook into the ogre render window message proc by writing a bypass and redirecting back to the original proc. and then process your window message here instead of having to rewrite the render plugin every time you have update ogre.
0 x
Kristian, crying out loud: "If it works. Don't fix it!" :p
HCA
HCA2
GuppyLife

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Sun Jan 30, 2005 1:11 am

Sorry, I guess my intention wasn't clear. I was proposing that the new rendering loop be implemented in the App code, not by modifying Ogre. I consider the Ogre startRendering method to be a convenience routine, to be used or not used as you see fit.

As an aside, I think the goal in writing a good library is that it should stand on it's own without the need for modification. So I tend to look for solutions that don't rely on changes in the core Ogre code. Of course, if a change is really needed ... :-)
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Sun Jan 30, 2005 12:00 pm

The startRendering() method really is convenience!
If you don't call it, you are free make your own rendering loop.
No need to touch the Ogre core.
And the example framework is just an example. Feel free to do your own thing. And take a peek at meshviewer, Yake, etc. for hints on how to code.
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

ritz
Gnoblar
Posts: 12
Joined: Tue Nov 02, 2004 6:16 am

capturing WM_TIMECHANGE

Post by ritz » Wed Feb 02, 2005 9:54 am

Hello,

Thanks for responsind.

I tried using the first approach .

a) replacing startRendering method.

I am not able to undertand how do i replace the complete code of this methiod.

Can any body plese tell me siginificance of the code written above and after the loop.

I do not want to touch any default functionality except for catching WM_TIMECHANGE event.


Code for startRendering
------------------------------
assert(mActiveRenderer != 0);

mActiveRenderer->_initRenderTargets();

// Clear event times
for(int i=0; i!=3; ++i)
mEventTimes.clear();

// Infinite loop, until broken out of by frame listeners
// or break out by calling queueEndRendering()
mQueuedEnd = false;
while( !mQueuedEnd )
{

#if OGRE_PLATFORM == PLATFORM_WIN32
// Pump events on Win32
MSG msg;
while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
#endif

if (!renderOneFrame())
break;
}



Approach -2 ) hook to ogre render window message proc - Can i get more details about th eproc. where i can get this.

I am not able to reach to the windowproc in ogre code.


rgds,
Ritz
0 x

ritz
Gnoblar
Posts: 12
Joined: Tue Nov 02, 2004 6:16 am

Trapping WM_TIMECHANGE

Post by ritz » Wed Feb 02, 2005 10:09 am

Hello All,

Here is the Objective of doing ALL this

I am creating a Calender widget using CEGUI library.

I need to update the current date in the calender when ever user changes the date in the system.

In order to reflect the change i need a notification for the system date change in my widget.

Is their any other way to know about the date change.

Most important is i donot want to touch the nase ogre or CEGUI code.

rgds,
Ritz



Tried Approach - 2 Also.
--------------------------
I did tried trapping event in render window proc, i am able to trap it.

But again the issue is i do not want to touch the base code

----
LRESULT D3D7RenderWindow::WndProc(
HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam )

-----

Is their any way to do it so that the changes remain in my code onle.
0 x

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Thu Feb 03, 2005 4:12 am

Silent wrote:Sorry, I guess my intention wasn't clear. I was proposing that the new rendering loop be implemented in the App code, not by modifying Ogre. I consider the Ogre startRendering method to be a convenience routine, to be used or not used as you see fit.
Here are some fragments from my own code (modified somewhat):

Code: Select all

void Application::start()
{
  if (setup())
    startRendering();  // call our rendering loop, not Ogre's
}


void Application::startRendering()
{
  renderSys->_initRenderTargets();

  while (true) {

#ifdef WIN32
    MSG msg;
    while (PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE)) {
      TranslateMessage(&msg);
      DispatchMessage(&msg);
    }
#endif

    if (!root->renderOneFrame())
      break;
  }
}
The Application class is based loosely on code from the Ogre tutorials, so it should look familier. I added the startRendering method and call it from the start method after setup has been called. The setup method does what you would expect, it creates the Ogre root object, etc..

I haven't rung out this section of code yet, in case someone spots any issues :-)

Hope this helps.
0 x

ritz
Gnoblar
Posts: 12
Joined: Tue Nov 02, 2004 6:16 am

Thanks

Post by ritz » Thu Feb 03, 2005 6:09 am

Hello Silent,

Thanks a Lot.

Now I am able to understand and implement it.

rgds,
Ritz
0 x

Post Reply