Jump to content

JB3DG

Commercial Member
  • Content Count

    661
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

186 Excellent

About JB3DG

  • Rank
    Member
  • Birthday 01/26/1993

Profile Information

  • Gender
    Male
  • Location
    South Africa

Flight Sim Profile

  • Commercial Member
    Yes
  • Online Flight Organization Membership
    VATSIM
  • Virtual Airlines
    Yes

Recent Profile Visitors

1,986 profile views
  1. Incorrect. You can use FSUIPC or not, you just mustn’t do the calibration in FSUIPC. Instead you do that in the MVAMS, just like the MJC Q400, which was my inspiration for designing the system.
  2. Hot keys? You get to choose those in the MVAMS.
  3. Are there even 150 3rd party dev companies in existence?
  4. This. It’s what we are all hoping for.
  5. When PMDG made their announcement, there were a lot of things assumed by development community and little was actually known for certain. MS was still asking developers questions about what they needed and it was assumed that we would absolutely get what we needed. Now, while there is considerable uncertainty, developers are more wait and see.
  6. Regarding synthetic vision displays, let me clarify. I didn’t say they wouldn’t be possible, I said that the many different styles of SVS won’t be possible unless the devs are given access to the underlying 3D engine with the ability to use custom shaders and textures. Without that, Asobo’s SVS is only useful for Garmin displays, nothing else.
  7. I didn’t say it would mean we can’t port old code. I pointed out that there are things in various displays that simply won’t be possible to do with the new system period. It’s like expecting developers to use the default gps map in their displays. And the comment about devs not wanting to get with the times is rather amusing, because speed of innovation is critical to our survival. When the tools we need for innovation (namely lower level code) are removed, it’s effectively telling us that we should go die.
  8. Let’s just say it is rather far off
  9. And lastly, some comments on the hope that devs will "find a way", or "hack" etc. Forget it. WASM is explicitly designed to *prevent anyone* from doing just that. Those who use it, are entirely at the mercy of the authors of the backend driving it.
  10. When PMDG made their announcement, there was literally *zero* information on what the SDK would look like beyond some vague statements about SimConnect. My personal opinion is they assumed that not giving developers low level C++ access would be suicidal to the success of the project. Where they are now, I do not know. They may, like most devs, including myself, be taking the position of "we will wait and see". If the rumblings mentioned by other devs here continue till the public release, I would say expect a reversal on PMDG's part.
  11. I see several posts asking what is/isn't possible with WASM and pointing to the advanced displays already developed. So a couple things to point out, since glass is my specialty in my job, with the caveat that I have been heads down on work and not paying much attention to the latest FS updates. 1: (See caveat) So far the only "advanced" display is the G1000. So for starters, try comparing the terrain and weather radar displays of the 737NG, the A320 family, the PL-21, and a wide range of other advanced glass displays. Spoiler alert: They are VASTLY different from eachother. 2: Compare the navigation symbols for waypoints and flightplans etc. You will find commonality and diversity. 3: Compare the synthetic vision of the Garmin displays with the Proline Fusion, the various HUD SVS displays, the Honeywell Primus Apex (I think that's what Dassault or Gulfstream use in their jets, I forget which). Again, considerable differences not only in terrain rendering but also airport markers. 4: On the topic of airport displays on navigation displays, again lots of variety. 5: Unless provided access, no IR/TV cam views for enhanced vision displays on HUDs, or taxi cams in the cockpit. Now a quick break before I continue on other points. What do all of the above have in common? Advanced raster image generation. Not possible with a simple 2D vector graphics library. If, and this is a big if (Those who know, can't say due to NDA, those who don't, don't know for certain), If Asobo has designed their background graphics engine to interface with the HTML or WASM or whatever they use specifically for the G1000, then it is tantamount to absolutely useless for most of the common avionics suites in use in other aircraft, beyond the most basic of functions (magenta line, text, compass rose or ADI/VSI/ASI/Alt/Engine instruments etc). Forget about custom designing advanced map and navigation displays. The current advantage of even the old FS9/FSX display system is that we had direct access to the raw image buffer for each gauge, and could use whatever rendering method we liked for advanced raster image generation. With P3D's PDK it got even better because we no longer needed to implement obscure weird low level CPU/GPU interfaces to get images that had been rapidly generated on the video card into the CPU buffer we had access to for the gauge image, which then went back onto the video card for display in the sim. Instead we got direct access to the DirectX texture surfaces which are mapped to the 3D model or displayed on the screen in 2D popups. This allows use of custom shaders for extremely efficient and rapid raster image generation which is so critical for navigation displays. It also allows considerable streamlining of rendering arrays of small objects like VOR/airport/Waypoint symbols. All of this disappears when locked down to a 2D vector library with no access to the underlying 3D rendering engine objects. The mention of lack of thread support is another concerning item, even if a sandboxed file access is granted. Sometimes files are large enough that they need to be loaded on the fly, or conducting searches/indexing in them once loaded in memory needs to be threaded to run in parallel or turn the sim into a slide show every now and then. Next, there are a good many windows and other external libraries used by developers that may not necessarily be available in WASM, unless specifically granted access. And another item: Debugging. Visual Studio has an exceptionally great debugger allowing the use of breakpoints to intercept code execution wherever we like and examine the state of variables and objects and even raw process memory (a critical item. I have lost count of the number of occasions I have been able to trace corrupted memory via direct views of raw memory and working through ASM registers etc). I have my doubts as to whether WASM will support such low level debugging, which gets more and more critical the more complex an aircraft becomes. Oh, and one last item: Forget about using the F1 or RXP GTN/GNS/G500/G600 gauges which use the actual Garmin trainers. That involves extremely low level C++ inter-process communications which WASM is explicitly designed to *prevent* with its sandboxing. Another last edit: From the comments about speed of execution, forget about external flight models, where speed of execution is absolutely *critical* for best performance.
  12. https://www.youtube.com/watch?v=zvfD5rnkTws
  13. Hey "pisseth" is in the Bible. And yes the original hebrew is not the polite term. Neither of the individuals who used it were in a polite state of mind when they used it and with reason.
  14. The AF A380 I was on during my trip back home from France last year was a heck of a lot quieter than the the KLM 777 that took me there.
  15. Neither sim is adequate in and of itself when it comes to systems and FDE. As such, all your high end developers end up making much of the systems platform independent, ie custom physics engines etc, and only the user interface is dependent on the platform. Both are pretty complex tasks for a high end addon, and the teams are actually smaller than you might think. A large team can actually slow the process down unless properly organized (a very difficult task itself), especially in the programming department. MJC for example has only 2 programmers if I recall correct for their q400, and the Aerosoft CRJ had only one. Both took at least 10 years. Milviz has only a few programmers split up over several of their commercial military projects, although the KingAir team is larger. VRS has only 3 or 4 members, only one of which is full time. PMDG and FSLabs are probably on the larger side, but still smaller than a full on gaming studio.
×
×
  • Create New...