Alexander Nolting 887789 Posted April 14, 2011 at 02:53 PM Posted April 14, 2011 at 02:53 PM In Process client can also run on different cores, FSInn does (and core load balancing). There is a difference between threads and processes. Hacking into a game is never the first choice, but ask all the users on a single full screen MSFS machine if they like to go out of process. Another solution would be to hack out of process into the DirectX rendering engine. But this takes a complete new level of complication and skill, very few application developers in the software world succeeded in. And I am not talking about out of process FSUIPC offset address tinkering, a complete different level of MSFS interfacing. You could make PHP or COBOL do this BTW Peter Dowson himself is not thinking that a new project for FSX should be based on FSUIPC. He just want to maintain backward compatibility. His FSUIPC FSX interfacing is 95% simconnect interfacing. I would call this a wrapper for simconnect (an asynchronous interface! that is why you needn't care about 15ms in FSUIPC that is historically synchronous, the data you receive isn't always real time). “the biggest enemy of freedom are happy slaves“ Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 15, 2011 at 12:15 AM Posted April 15, 2011 at 12:15 AM In Process client can also run on different cores, FSInn does (and core load balancing). There is a difference between threads and processes. I'm aware of the difference - I wasn't aware that modules in FS could run on anything other than the main FS thread. My reading of the docomeentation indicated that the module entry point was executed once per frame, but admittedly I have done very little reading on the subject because I've never been particularly interesting in writing FS modules. Hacking into a game is never the first choice, but ask all the users on a single full screen MSFS machine if they like to go out of process. I agree that it's less than ideal, but I'd bet that for the majority of time flying on VATSIM has been a multi-process, multi-window experience. For my users, in a perfect world they do not need to interact with my software during flight so it can be in the background anyways. BTW Peter Dowson himself is not thinking that a new project for FSX should be based on FSUIPC. He just want to maintain backward compatibility. His FSUIPC FSX interfacing is 95% simconnect interfacing. I would call this a wrapper for simconnect (an asynchronous interface! that is why you needn't care about 15ms in FSUIPC that is historically synchronous, the data you receive isn't always real time). That's a good point. FSUIPC4 is little more than an abstraction layer for SimConnect - and that is the beauty of it. Rather than coding to 3 or more different sim interfaces, I have a single one to target. When FSX and FSUIPC4 came out, 99% of our ACARS code ran without alteration against FSX. I have 4 real cores on my desktop here and 3 of them are sitting idle. My iMac at work has an i7 which means it's about 10% faster clock for clock and has an additional four virtual cores thanks to HyperThreading. My CPU time has increased exponentially over the years, but the time I have available in a day to code has not (yes, my productivity has gone up, but my time has gone down). I'll take a little performance loss for speed in development. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Claudio dos Santos Marinho Posted April 15, 2011 at 07:19 PM Posted April 15, 2011 at 07:19 PM Excellent idea! It is time for a new software on VATSIM. A software package that has an upgraded air traffic, where we can properly view the paintings of Airlines. It's about time! Link to comment Share on other sites More sharing options...
Recommended Posts