-
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.
Form behind FSX
- Thread starter giggetto
- Start date
Since you are using a .Net language, I'm assuming that your addon is running as a seperate .EXE, in which case, there isn't really any way to make your form appear on top of the FS window (I'm also assuming you are in full screen mode) - you will probably need to switch to windowed mode in order to see your add ons form.
sgrunt
You can, in fact, run .NET as a DLL inside the FSX process space (see my code sample in this forum on how to start the CLR and load your assembly inside the FSX process space). You can run a WPF window inside FSX as a window.
The question becomes whether it is practical, and I would not recommend the approach at this time.
Issue 1 is memory management as the CLR is large and tends to increase the "out of memory" errors in FSX on 32 bit systems with 2Gb or less. Even with a custom memory manager for the CLR, it is exceedingly difficult to not run out of memory because by itself, FSX can easily get to the maximum single process space memory block, let alone you adding the ~512Mb you need for the CLR and the average assembly.
Issue 2 is performance, as frame rates can take a very serious hit. The primary reason is that the rendering pipeline cannot be multi-threaded, you can only render the UI on the same thread FSX uses (the main thread). As rendering is very intensive in FSX, I've seen a 30% to 50% drop in performance running a WPF window, and there isn't a lot of wiggle room.
Issue 3 is the amount of interop needed between managed and unmanaged memory.
I've concluded that while the technology does work, C++ and the old APIs are a necessary trade-off. Until processors get much faster and everyone runs 64 bit operating systems with more memory, this is probably going to stay experimental as far as .NET inside the FS process space. For now, external EXEs are the way to go with the .NET world.
Etienne
The question becomes whether it is practical, and I would not recommend the approach at this time.
Issue 1 is memory management as the CLR is large and tends to increase the "out of memory" errors in FSX on 32 bit systems with 2Gb or less. Even with a custom memory manager for the CLR, it is exceedingly difficult to not run out of memory because by itself, FSX can easily get to the maximum single process space memory block, let alone you adding the ~512Mb you need for the CLR and the average assembly.
Issue 2 is performance, as frame rates can take a very serious hit. The primary reason is that the rendering pipeline cannot be multi-threaded, you can only render the UI on the same thread FSX uses (the main thread). As rendering is very intensive in FSX, I've seen a 30% to 50% drop in performance running a WPF window, and there isn't a lot of wiggle room.
Issue 3 is the amount of interop needed between managed and unmanaged memory.
I've concluded that while the technology does work, C++ and the old APIs are a necessary trade-off. Until processors get much faster and everyone runs 64 bit operating systems with more memory, this is probably going to stay experimental as far as .NET inside the FS process space. For now, external EXEs are the way to go with the .NET world.
Etienne
Last edited:
Hey Etienne,
That's why we don't currently "officially" support managed code within the main apps process space (that and the guy that did all the original SimConnect work is rather anti-managed code :-> ).
There are a few things I've been wanting to investigate, but just haven't had the time :->, including:
Disclaimer: All the above is wishful thinking, none of those are future features at this time, so don't quote me :->
That's why we don't currently "officially" support managed code within the main apps process space (that and the guy that did all the original SimConnect work is rather anti-managed code :-> ).
There are a few things I've been wanting to investigate, but just haven't had the time :->, including:
- a custom WPF hosting layer (if possible) so I can get WPF to use a Sim-Owned texture to render onto
- Try hosting just the DLR or, if possible, just Silverlight (or any other .Net-Lite version :-> ), to lessen the memory overhead
- A weirder one, create a WPF top level app that can load the Sim's native DLLs (with appropriate interop glue) and then rig the sim engine so it uses a D3D Texture owned by WPF as its top level surface - that would be cool, all the UI could just be regular WPF windows :->
Disclaimer: All the above is wishful thinking, none of those are future features at this time, so don't quote me :->
- Messages
- 497
- Country
Ahhh, so now we know why 