MFD to FIP (saitek instrument panel)
i wrote a little program which exports the mfd content to saitek instrument panel. To do this i had to bitblt the DC’s of the export windows to my own app and sent the content to the FIP. This approach has some problems.
The first one is to sync with the export windows. Atm the only way i found is simple polling. Which means every time the update on FIP is complete i make a new copy of the DC. This causes some kind of aliasing (i.e. short hickups when moving cursors). I looked for WM_* messages with spy++ on the export windows to hook in but no luck (good job devs ).
So my first question is how to retrieve the moment a new update is made (would be interesting for shared mem data as well)?
The second problem is that the export windows must also be visible cause the dc of a non visible window is never updated.
So the second question is probably more a feature request. Is it possible to read the MFD pics from a shared memory area? How does the export utility do its job?
Thanks in advance
The MFDs are rendered into a shared mem area already, that’s how all the existing tools work. Screen capture is not the way to go here.
Check out Lightnings tools over at viperpits.org, links with source code for e.g. MFD extraction tools are provided in his forum signature.
Thank you for the quick reply!
Which is then the appropriate mem area for the mfd images?
I found only this ones (“flight data.h”):
Ok i think i found it, seems to be: FalconTexturesSharedMemoryArea.
Any reason why the exporter only works in windowed mode? May i run into this problem also while using the above area?
The BMS built-in exporter can only export to the same PC, hence it has to use windowed rendering. External tools can read the shared texture memory area in any mode, fullscreen or windowed. However, the shared texture memory area is OFF by default, as it is not used by the BMS internal external display rendering. You need to manually activate it (this is NOT related to the “Cockpit Displays to External Windows” config editor setting, the built-in export method and the shared texture memory area are completely independent things) by adding the following line to your BMS config file:
set g_bExportRTTTextures 1
Dunce äh Danke
That’s really worthwhile information. Hopefully the last thing i need is something like “flight data.h” which gives me the information how memory is mapped in detail. Is something like that around?
Okay… bad news. Assuming that the beginning of the area is a simple DDS_HEADER i can gain access to the textures area. Bad thing is that all members of the struct in spite of dwReserved1 map to null values. I set the g_nRTTExportBatchSize to 1 but makes no difference.
Btw.: to avoid read backs from GPU i’m still very interested in how the export utility works.
Any help on this?
the functionality of the internal export utility is of no use to you, because it is a part of the BMS exe process itself and hence you can not mimic it’s behavior.
Again, the easiest way to gain insight in the external exporter utilities and their functionality is contacting Lightning on the viperpits.org forums. As I said, his signature includes links to his MFD extractor source code and other utils (like shared mem / shared texture mem readers) that are meant to be used by 3rd parties. So please check them out over there. His code examples will show you all you need to know.
I know lightnings tools very well and appreciate his work. All information about the FalconTexturesSharedMemoryArea i have come from his sources. Anyway to hassle around with COM interop is not an option for me. I prefer to access shared mem through direct API calls.
Regarding this thread (AV8Rs post) its also not working with lightnings tools so far. Also my experience with shared memories tells me that there’s something wrong if you can gain access but contents are null (maybe you wan’t to look into this thread also ). Please don’t feel bothered i just really wan’t to get this working.
btw.: the dwResult1 member i mentioned above contains the value of the shared mem pointer itself which seems at least plausible. ALL others null
Ok, after some testing i found that the device context of the export windows is updated regardless of visibility. This seems strange but is a really neat feature
So for now i concentrate on capturing again. The real problem arises from the low fps values i got in windowed mode making the sim unplayable for me. Since the DC’s are update in non-visual state also, there seems to be no more need not to go full screen. Regarding to your kind explanation the decision to go windowed was for reason and not for necessity. So keeping in mind that this would be a very special case i still want to ask weather its possible to get the extractor functional in full screen mode?
Thanks in advance
What I’ve read over at viperpits from Lightning about extracting the mfd data yourself is that it is currently not possible. He wrote that bms needs a slight source code change for it to work, I haven’t looked deeper at it. At one point I thought of writing some emulated graphics device that made windows think “oh here is a new gpu and monitor”, but when I started realizing how much work that would be I skipped it ;).
I don’t think Lightning ever made a simple stand-alone DLL for shared texture extraction from BMS4, but using his MFD Extractor program with his F4TexSharedMem DLL, you can get shared textures from BMS4 in full-screen mode. I didn’t notice any framerate hit, either. Here’s my program:
Source code here (kind of messy, sorry): https://github.com/Raptor007/Falcon4toSaitek