Two question about FSUIPC and screen capturing

[Alexey Morozov]

Hi Pete,

Thank you for excellente work with the FSUIPC!

I have a couple of questions to you.

I need to perform screen capturing of the FS window to make an AVI file. The question is: Is there any possibility or not to get the information (event or CALLBACK functions)as soon as each frame is rendered and displayed. For example, I fix the target frame rate at 10 frames per second and want to receive notification as soon as each frame is displayed on the screen.

The second question is a bit odd.

For screen capturing I try to use the Camtasia Screen Recorder SDK from TechSmith (ActiveX version) and Borland C++ Builder. It seems to be a conflict in some cases between this SDK and FSUIPC. If I use them on the main form of my application it works good. The problem appears when I try to create the form and Capture object that is placed on this form inside the dll. In this case the FSUIPC_Close function is called automatically (not by me) each time I call any method of the Screen Recorder object. This results in connection to the FS to be lost and I need to establish new connection each time. Do you have any ideas on this matter? May be there are some problems with COM and threads? This screen capture facility establishes some threads for capturing.

Regards,

Alexey Morozov

[Pete Dowson]

Is there any possibility or not to get the information (event or CALLBACK functions)as soon as each frame is rendered and displayed. For example, I fix the target frame rate at 10 frames per second and want to receive notification as soon as each frame is displayed on the screen.

I assume you mean from something running inside FS?

I am afraid I really don't know the answer to this. I hook into the FS chaining system (which used to be managed my CHAIN.DLL, but which was merged into the base EXE in FS2002 I think). There are a large number of chains which occur at various times, and at least one of these seems to be related to what FS calls the "frame rate" -- but is that frame rate the actual graphics rate, or is it just referring to the computation cycle?

Maybe someone who is more involved with graphics design in FS can help. That side of it is a complete unknown to me. Folks who do moving parts for aircraft and scenery may well have a much better knowledge of what happens when, graphics-wise. Even gauge designers trying to make smoothly moving needles might know more than me.

In this case the FSUIPC_Close function is called automatically (not by me) each time I call any method of the Screen Recorder object. This results in connection to the FS to be lost and I need to establish new connection each time. Do you have any ideas on this matter? May be there are some problems with COM and threads? This screen capture facility establishes some threads for capturing.

Sorry, but you've lost me really. This system is operating as an FSUIPC client gauge or DLL?

Assuming you are using the library code I provide, the internal Close call doesn't touch FSUIPC at all, it simply clears the address of the memory, provided by the DLL or Gauge, and that flags the connection as closed. In fact that's pretty much all the external Close call does -- if closes the Memory-Mapped file and frees the Atom with the string filename. It also doesn't touch FSUIPC.

There are potential problems in any case with multi-threaded use, but most of these boil down to accreditation problems. For accreditation the Open2() call used to always have to be from the main FS thread, but in the latest version of the library, and with current versions of FSUIPC, that call can be from other threads.

Otherwise only the usual care needs to be taken with multiple threads -- i.e. protecting the data area being updated by FSUIPC_Read and Write calls so that only one such call is executed at a time. There are no semaphore locks in the library code I provide, you'd need to apply those yourself.

Regards,

Pete