How do you hook into the FS window procedure?

[Guest Patrick_Waugh]

After reading this:> How does this kind of timers work? First, we create a timer,> specify its elapse time, and (optionally) attach it to a > window. After the timer is created, it sends WM_TIMER messages> to the window message queue, or if no window was specified, to> the application queue. We can process this message to call the> code that we want to be executed in regular time intervals. The> timer will send WM_TIMER messages until it is destroyed.I am wondering how I can get notified about the WM_TIMER messages, since I do not have access to the application's or window's message loop.I'm guessing I can hook them, and with some "WindowEx()" procedure or something.Can anyone tell me where to look on how to do this?

[Guest Patrick_Waugh]

Never mind, I realized that I can't use Windows message based timers for 20ms events.I'm going to have to use a high resolution timer, so I'm off to get this working.

[Guest Patrick_Waugh]

In case anyone else wants to know one way to setup one type of timer, here is what I do:// Que timers require Win 2000 min#define _WIN32_WINNT 0x0500#include #include // link with winmm.lib & kernel32.libHWND hFsWnd = NULL;HANDLE hTimer = NULL;HANDLE hTimerQueue = NULL;extern GAUGEHDR gauge_header;void CALLBACK TimerCallback( PVOID lpParameter, BOOLEAN TimerOrWaitFired ){ // Stuff you want to do every 20ms DoSomethingReallyQuickOften();}void FSAPI module_init(void){ HRESULT hr; hFsWnd = FindWindow( L"FS98MAIN", NULL ); hTimerQueue = CreateTimerQueue(); CreateTimerQueueTimer( &hTimer, hTimerQueue, (WAITORTIMERCALLBACK)TimerCallback, NULL, 1000, 20, WT_EXECUTEINTIMERTHREAD);}void FSAPI module_deinit(void){ DeleteTimerQueueTimer( NULL, hTimer, NULL ); CloseHandle( hTimer );}Keep in mind that FS updates things very infrequently or at most every 55ms. So, as Arne has pointed out in the past, if you are trying to find derivatives, you may find that consequetive values need to be checked for no change, and averaged.

[WarpD 824]

Adding timers adds overhead, just an FYI.The timer's interrupt will suspend FS's process loop every 20ms. This can have a significant impact on all 3D rendering. As well, you MUST ensure that the code you're going to process from this timer doesn't come even close to 20ms in execution time.I avoid using timers myself.

[Guest Patrick_Waugh]

>Adding timers adds overhead, just an FYI.Adding ANYTHING adds overhead... so what's yer point. :-xxrotflmao>The timer's interrupt will suspend FS's process loop every>20ms. Yeap, that's the idea. :-xxrotflmao>This can have a significant impact on all 3D rendering.It could, just as it could in ANY callback if you stay in the callback too long.> As well, you MUST ensure that the code you're going to>process from this timer doesn't come even close to 20ms in>execution time.Yeap, which is 20,000 nano seconds, plenty of time. =)>I avoid using timers myself.I am finding them quite useful, but only when needed to do something (like DirectSound) more often than 55ms, and on a more consistent time table.They are indeed best used judiciously.

[WarpD 824]

Ok... your response comes across as argumentative... and I'm really not certain why you feel the need to counter all I posted.My post is to ensure that others, who read your post and decide timers are a "wonder cure" for processing independant of FS's own loop, don't manage to cripple the sim's performance with code that chokes it.If you have a timer function that utilizes 5ms of time... that's 5ms out of total CPU time every 20ms, for a total of 25ms which is 1/40th of a second. Sounds small... until you start adding more timers and/or longer duration functions. Then you start to take a hit.So... as I originally stated... this is an FYI... and I hope others pay attention to it and take it to heart, before they do something that mangles their FS performance.

[Guest Patrick_Waugh]

>Ok... your response comes across as argumentative... and I'm>really not certain why you feel the need to counter all I>posted.>>My post is to ensure that others, who read your post and>decide timers are a "wonder cure" for processing independant>of FS's own loop, don't manage to cripple the sim's>performance with code that chokes it.This is, of course, an important point, but much clearer than what you said earlier. Of course, we don't need timers to cripple performance, they are just the best and fastest way to do it. :D>If you have a timer function that utilizes 5ms of time...>that's 5ms out of total CPU time every 20ms, for a total of>25ms which is 1/40th of a second. Sounds small... until you>start adding more timers and/or longer duration functions. >Then you start to take a hit.In practice and profiling, I have found that FS is running on about 40% (on average) of my CPU thanks to the wonders of the OS, and since the timer is running on a kernal thread (in my case), the time is not really calculated like that. If you use a different timer from a different thread pool, your mileage may vary. :D>So... as I originally stated... this is an FYI... and I hope>others pay attention to it and take it to heart, before they>do something that mangles their FS performance.Yes, agreed. FS is already slow enough for most of us. :D

[Guest ghrasko]

I agree that timers might be useful, but in fact they might be misleading in most FS related activities. Timers are triggered by specified intervals based on the CPU and not based on time passing within FS! In several of my applications I realized that it is better to rely on the FS "ticks" than on a CPU tick, as FS ticks measure how time is passed in FS - at least if I understand correctly. My navigation gauges should be based on FS simulation time rather then CPU time (you mast also keep in mind pauses and simulation rate, so in fact "time elapsed" is even more useful).This is only an additional point to keep in mind. Of course sound handling is another thing at it might be reasonable that it should be handled real (CPU) time.Gabor

[Guest Patrick_Waugh]

>I agree that timers might be useful, but in fact they might>be misleading in most FS related activities. Timers are>triggered by specified intervals based on the CPU and not>based on time passing within FS! In several of my applications>I realized that it is better to rely on the FS "ticks" than on>a CPU tick, as FS ticks measure how time is passed in FS - at>least if I understand correctly. My navigation gauges should>be based on FS simulation time rather then CPU time (you mast>also keep in mind pauses and simulation rate, so in fact "time>elapsed" is even more useful).Wow, you are so right. In my rush to get this done, I forgot that for physics I have to use FS time, not CPU time. Good thing I took a break form this for a couple of days to do my web site and forums or I would have wasted alot of time, haha. Thanks.>This is only an additional point to keep in mind. Of course>sound handling is another thing at it might be reasonable that>it should be handled real (CPU) time.Yes, it works great for both my sound (letting me do it fast enough), and DirectInput stuff (letting me do it slow enough).