-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
WPF and FSX
- Thread starter karijno
- Start date
Here's what I've found based on my testing - hopefully others have better news:
1) yes, but you need to write your own native wrapper for it to get that functionality and avoid having to use a message loop. You will still need some type of loop to call the dispatch handler to see if a message is available. Marshalling the data types returned by the native SimConnect API is pure torture in .NET because it has data types squarely designed for C++. Marshaling is unfriendly to pointers that can point to different structures depending on the call, and on top of that, the API has pointers to pointers and worse, variable arrays of pointers are just insane in some cases. I ended up writing a custom marshaller to handle variable arrays and pointers correctly, as the default mashaller only supports fixed arrays (size known at compile time). A custom marshaler also helps with indexed values that even the SP1 delivered wrapper doesn't handle. The .NET wrapper provided in the SDK only gives you the messaging loop route.
Next, I found out that loading the CLR in an FSX DLL (internal - see the code posted in this forum) can cause FSX to give you an out of memory error by exceeding the maximum allowed memory per process (2Gb) under XP 32 if you have your sliders set to the right. There is no easy solution for this outside of using the /3Gb switch on XP (meaning, have more physical memory and allow processes to use more than 2Gb), or using FSX under XP64 or Vista where the problem goes away. The problem is that when you load the CLR inside FSX, you use FSX process memory, and the managed footprint can get very large.
2) from my testing, no with WPF 1.0 on Windows XP and DX9. The directX context and the WPF context don't mix, in that it's not possible to overlay multiple DX contexts. You end up with an undefined situation. That undefined situation ranges from a black background (FSX DX context wins), flicker (unusable), FSX crash or lockup when switching between full screen to windowed mode, and vice versa. My tests showed that WPF windows show correctly when not above the FSX DX window, but start havoc when dragged over the FSX window (or any other DX content for that matter). My understanding is that the next version of WPF will actually support multiple contexts and support overlays better. DX10 also has better support for multiple contexts. There is however one workaround, but somewhat defeats the purpose of WPF hardware accelerated graphics: render to memory, grab a bitmap, and blit it. I'm now waiting for a test under Vista to see if it works better, but it will also mean I need to wait for my next box.
Hope this helps,
Etienne
1) yes, but you need to write your own native wrapper for it to get that functionality and avoid having to use a message loop. You will still need some type of loop to call the dispatch handler to see if a message is available. Marshalling the data types returned by the native SimConnect API is pure torture in .NET because it has data types squarely designed for C++. Marshaling is unfriendly to pointers that can point to different structures depending on the call, and on top of that, the API has pointers to pointers and worse, variable arrays of pointers are just insane in some cases. I ended up writing a custom marshaller to handle variable arrays and pointers correctly, as the default mashaller only supports fixed arrays (size known at compile time). A custom marshaler also helps with indexed values that even the SP1 delivered wrapper doesn't handle. The .NET wrapper provided in the SDK only gives you the messaging loop route.
Next, I found out that loading the CLR in an FSX DLL (internal - see the code posted in this forum) can cause FSX to give you an out of memory error by exceeding the maximum allowed memory per process (2Gb) under XP 32 if you have your sliders set to the right. There is no easy solution for this outside of using the /3Gb switch on XP (meaning, have more physical memory and allow processes to use more than 2Gb), or using FSX under XP64 or Vista where the problem goes away. The problem is that when you load the CLR inside FSX, you use FSX process memory, and the managed footprint can get very large.
2) from my testing, no with WPF 1.0 on Windows XP and DX9. The directX context and the WPF context don't mix, in that it's not possible to overlay multiple DX contexts. You end up with an undefined situation. That undefined situation ranges from a black background (FSX DX context wins), flicker (unusable), FSX crash or lockup when switching between full screen to windowed mode, and vice versa. My tests showed that WPF windows show correctly when not above the FSX DX window, but start havoc when dragged over the FSX window (or any other DX content for that matter). My understanding is that the next version of WPF will actually support multiple contexts and support overlays better. DX10 also has better support for multiple contexts. There is however one workaround, but somewhat defeats the purpose of WPF hardware accelerated graphics: render to memory, grab a bitmap, and blit it. I'm now waiting for a test under Vista to see if it works better, but it will also mean I need to wait for my next box.
Hope this helps,
Etienne
Last edited: