Sgt_Baker

Haha! FC3 aircraft and full-fat DCS aircraft are coded very differently. Earlier this year I was successful in isolating all the displays of FC3's F-15C. However it was already evident by that point that the "grand shift" to DirectX 11 precluded any financially-realistic work in that direction, given that it would only further complicate the work taking place at present. The bottom line is that it's entirely possible at the proof-of-concept level. However it will not proceed until I've upgraded uMFCD to stable-DirectX 11 and have sorted KA-50 support. --Baker P.S. Here's a screenie of the preliminary stages of said "isolation" work.

I will guarantee that it will happen prior to our host star changing enough to cause significant disruption to life on Earth.

Without wishing to rain on anybody's parade, I would still urge caution when it comes to creating new maps for any aircraft sim, let alone DCS. It's much more work that meets the eye. There are ten-plus layers of "invisible" functionality on top of an average map in DCS. Things like telling aircraft what's a taxiway and what's going to tear off the gear, assuming you get as far as modelling actual air bases. Same for on-road/offroad navigation for land vehicles. ILS. Nav beacons. etc. Just be careful not to promise too much. :) It's no coincidence that it's taken ED longer than a decade to [not] release a single new map.

People who have been monitoring this thread closely will have noticed my saying, repeatedly, that "fullscreen mode will disappear completely very soon", as it really makes no sense whatsoever in Windows 7 upwards. And there we have it. :) Edit: And will also have noticed my saying "while fullscreen support is entirely possible, there is presently no intent to code for it." Now you know why.

Update 4 OK. We've got some funky DirectX 11 action going on. Initial tests indicate that UltraMFCD can easily keep up with/not tank the new and improved frame rate of DCS. While still a simplistic test, DCS is pegged firmly at the refresh rate of my monitor (60FPS) using an AMD 7970. For the technically minded, the significant FPS drop with UltraMFCD 1.0 was entirely down to severe restrictions regarding the flexibility of DirectX 9 - specifically being forced to copy all the MFCD data from the graphics card to system RAM, and then straight back to the graphics card again. This DX11 business is a brave new world, eh? :)

Yes, that is very much the plan.

Update 3 Quod erat demonstrandum. :)

26 Weeks. :P

Or had 12 months to plan for now. :smartass:

Update 2 UltraMFCD internal builds now running alongside DCS 1.5 Openbeta without crashing DCS outright. No exports as yet (because that's the previously mentioned "complicated bit" requiring all the analysis and headaches), but encouraging signs.

Update for DCS 1.5/2.0: Good news! Having taken a good poke around the innards of DCS 1.5 Open Beta, the prospects of UltraMFCD 2.0 working at all/as expected are very good indeed. Furthermore, a surprising amount of code can be carried over from UltraMFCD 1.0 without much if any modification. Must have been doing something right, eh? Have already tested the basic proof of principle that UltraMFCD requires in order to function, and that all works, so now it's very much a matter of analysing the functioning of DCS's new rendering engine in order to account for the move from DX9 to DX11. End transmission.

Situation update, reasoning and The Future The first section of this post is for the technically inclined, or those simply interested in uMFCD's history, along with people interested in the current state of affairs. There are a number of ways to build an application dealing with graphics. Broadly speaking, they fall in to three categories: 1. A Windows-only app. These are by far the simplest and most fail-safe of all applications, even for graphics. All operations and image processing are performed on the CPU, using programming that is essentially idiot-proof. The downside is that while this may appear to be the logical solution, any meaningful graphics processing, particularly real-time graphics, quickly exhaust all available processing power - even on modern multi-core CPUs. This is how the initial prototypes of UltraMFCD worked, when we only exported the A-10C's left and right MFCDs. Unfortunately, each MFCD would essentially demand a whole CPU core's computing power in order to keep up. If that weren't bad enough, RAM bandwidth (which is often ignored completely by developers) was pegged at a good 75% on the development machines. Clearly not an acceptable situation, given that UltraMFCD is supposed to run alongside a high-end combat simulator at maximum FPS. 2. A pure DirectX application. As many of you will know, DirectX is one of a number of programming "languages" (strictly an API) that deals purely with graphics. Purely, efficiently and is very fast indeed. While the CPU does still perform a lot of work, the vast majority of the really hardcore processing takes place on the graphics card, all of which contain specialised hardware optimised to perform the type of mathematics associated with image and geometry processing at mind-blowing speed. As a scientist, I still have trouble getting my head around just how quickly all those calculations take place compared with that which we had available when I first got in to this field. Then again, looking up at the night sky and attempting to appreciate distances any further away than the moon also gives me the willies. So the logical choice for something like UltraMFCD would be a pure DirectX approach, right? No. While this approach is extremely fast and efficient, DirectX understands essentially nothing more than how to perform image/geometry calculations very fast. Simple things such as - just for the sake of illustration - "what is a window?" and "how should a button behave?" mean absolutely nothing to DirectX, whereas this is clearly very well understood by the windows-only apps. Consequently, with this approach, one is forced to reinvent the wheel that is Windows pretty much from scratch, at vast cost in terms of time and expense. Sure, games developers do this all the time, but UltraMFCD isn't a full-fat game. 3. A hybrid Windows/DirectX approach. The best of both worlds. The simplicity and ease of maintenance of a Windows-only app along with the terrifying processing power of DirectX. This is what UltraMFCD is in its current (and likely all future) incarnations. It works by performing to two styles of programming separately, then saying to Windows™, via some very simple commands, "Hey, I've got some data in graphics card memory. Please stick it in this Window over here." The great advantage is that the data never leaves the graphics card. This is the step that is currently bugged, and since it's inside Windows™, is completely beyond my control. The Future So what can be done to remedy this? As it stands, there is no immediately-sane solution to the slow update bug, as briefly mentioned in an earlier post. Both UltraMFCD 1.x and DCS 1.x are presently stuck in the world of DirectX 9, which as a technology is about ten years old. To put it another way, it feels a bit like using an abacus on the bridge of the Starship Enterprise. Both DCS 2.0 and UltraMFCD 2.0 are to use DirectX 11, which is the most modern version of the API that will run on Windows 7 machines - the OS that accounts for the vast majority of users. Microsoft plan to release a vastly-improved version of "Hey, I've got some data in graphics card memory. Please stick it in this Window over here." at some point in the next few months, which will be wholly compatible with all versions of DirectX, not just DX9. As such, it would be deeply foolish to attempt to flog out a workaround for the slow-update bug (which would probably involve reverting to the windows-only approach of ancient versions of uMFCD or completely ditching support for Windows 7). The plan is this: I am going to update UltraMFCD's front-end to DirectX 11 using the "pure" approach mentioned above. Once Microsoft release the fix, it should be trivial to to patch the DX11 code in to the publicly-available versions of UltraMFCD - what with all the hard work already having been completed. The new front-end should be good for another ten years without any severely disruptive revisions, such as that which we're experiencing at the moment. Unfortunately, you, as users, will not be able to see, touch or play with the new code until MS release their patch. Not that it will behave differently in any appreciable manner. :) What about DCS 2.0? This is where things do get complicated. In order to get UltraMFCD to function in the way it does, I am essentially forced to work out, in my head, how DCS's source code functions without ever having seen a single line of it. All of this happens by means of deduction, logic, analysis and a coincidental two decades in programming. While this approach has clearly been very effective with DCS 1.x, there is absolutely to guarantee that the same feat can be repeated with DCS 2. All I can say is "I will try, and I am not easily deterred."

Might this help?

It's worth noting that uMFCD works fine with 1.5 OpenBeta as it stands at the moment. For Nvidia users: Driverset 347.52 was the last known to work for everybody. For AMD users: Anything prior to 15.20.1062.1004​ (at least on Win 10) should work.

Right. Bad news. Having performed the an experiment whereby I stripped ALL the funky rendering code out of the front end and simply replaced it with "paint a solid colour and nothing else", I can confirm that the issue we've been experiencing with slow updates is caused by AMD/Nvidia updating their drivers for future cards and scenarios yet MS not keeping pace with a specific component within Windows. Unfortunately there is very little I can do about this in the immediate sense. MS are, however, introducing a completely revised subsystem for "DirectX inside a window" with the release of .NET 5.0, which is scheduled to arrive in "late fall 2015" (Coincidence?! I'm not making this up!) . No wonder keeping the present system up to date has lapsed somewhat, eh? Given the other options for resolving this issue, all of which involve huge amounts of work and probably wouldn't be finished by the time .NET 5 arrives, I'm inclined to wait.

Thanks, Erik. That, in a sense, is excellent news. It means that the bug I'm seeing here must be the same thing, except I'm on an AMD card. Will post again shortly once I've confirmed a hypothesis...

Mind performing another quick test? Do the displays update any more quickly if you continually drag one of the MFCDs around? I.e. not the CDU/RWR/Clock etc.

OK, a question for users who've been experiencing extremely slow display updates on Nvidia cards: Do the touchscreen buttons show up immediately when you mouse-over where they should be? (yellow highlights - watch the demo video where I'm clicking the MFCDs) Can you click them and do they work? That's all, really. --Baker

BINGO! Have just managed to reproduce the "displays not updating/lag" bug - albeit only for a single display. Watch this space...

Yeah, this is a tricky issue since the actual conflict has come about as the result of some change or the other at the driver level. Initially this only affected Nvidia cards, but there are now reports of certain AMD cards succumbing too. The only way I have of reproducing this is to purchase the affected cards until I can reproduce the problem locally. Thanks for the info! :)

Which exact model of nVidia card are you using?

P.S. The fact that a product disputing its license causing a product to dispute its license is an irony not lost on me. :megalol:

MS, good to their promise, have sorted the issue with Visual Studio. Have consequently updated the licensing server, so uMFCD should run happily again. Apologies for the outage.

You're flying the KA-50 with this? That code is still only "proof of concept". Glad you like it. :)

Yep. That's the next port of call. Unfortunately, Community Edition will not happily coexist with Ultimate on the same box. Giving MS the requested "48 hours" to get this solved before I uninstall everything and start from scratch.