UltraMFCD - drag, resize and click display exports. Zero configuration.

[Devrim]

Hi.

 

Baker, that's a great application. Thanks so much!

 

At first sight, no problem for A-10C. Worked great, but the clock.. some issues.. wasn't displayed well. I won't use it, though.

 

I didn't read pages, but I think it isn't ready for Ka-50. Huge Shkval and ABRIS on the screen with no function.

 

Thanks for your efforts man! See you.

[Laurius]

Hi Sgt Baker,

 

I finally jumped in your App few days ago, for exporting both MFDs and I really love it !!

 

Though it took me some fps down, it's still very enjoyable and I could recover this damn sun glare which I've lost by editing my monitorsetup.lua to make my Lilliputs work long time ago (speaking for A-10C mainly).

 

By the way , something is a bit strange. As I don't need the kneeboard, I have to uncheck the corresponding box each time I start your App.

Otherwise, everything else is perfect so far.

 

A last word, reverting back to the 347.52 Nvidia driver was also an important thing. Glad you mentioned it on your website.

 

Thank you for this amazing App !!

A happy user !

:thumbup:

[Sgt_Baker]

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

 

Watch this space...

[Sgt_Baker]

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

[eriks71]

Sgt_Baker, I just tried it. And while the displays don't update like they should the yellow parts are working and work immediately.

 

I use a gtx680 myself

[Sgt_Baker]

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.

 

Sgt_Baker, I just tried it. And while the displays don't update like they should the yellow parts are working and work immediately.

 

I use a gtx680 myself

Edited September 27, 2015 by Sgt_Baker

[eriks71]

yes the displays (both mfcd's) update more quickly if you move one of them around. not smoothly but (in my case) at about every 2 seconds.

 

if you have more tests to do please ask :-) I will check here a few times a day, and am in the Netherlands

Edited September 27, 2015 by eriks71
addition

[Sgt_Baker]

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...

 

yes the displays (both mfcd's) update more quickly if you move one of them around. not smoothly but (in my case) at about every 2 seconds.

 

if you have more tests to do please ask :-) I will check here a few times a day, and am in the Netherlands

[Sgt_Baker]

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.

[eriks71]

Baker, to be honest i think it IS the smartest thing to do to wait until .net 5. Especially if fixing this now means that you have to do this in a few months again.

 

I for 1, understand that with such a change (win10 and all its drivers) plus the upcoming version 1.5/2.0 means a whole lot of work. especially if the tools (in this case .net5) are absent.

Its a decision of you offcourse but i would wait until you have the proper tools.

[Sgt_Baker]

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.

[JaBoG32_Prinzartus]

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.

 

Baker, thaks for the "heads-up".

 

Anyone managed to use Driver 347.52 on Windows 10 hindering Windows10 forcing an upgrade to an WHQL driver? I failed, so far.

[Sgt_Baker]

Might this help?

 

Baker, thaks for the "heads-up".

 

Anyone managed to use Driver 347.52 on Windows 10 hindering Windows10 forcing an upgrade to an WHQL driver? I failed, so far.

[Sgt_Baker]

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."

Edited September 28, 2015 by Sgt_Baker

[Pikey]

Good luck! This is probably the best app out there for moving your MFCD's simply and i guarantee theres a few folk relying on it with their complex setups!

[eriks71]

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."

 

I'm very confident in you're knowledge and skills to make the ultimate DCS 2.0 companion (uMFCD) and I also understand the difficulties and needed time. Especially since (at least at this moment) it's still a labour of love.

Anyway i hope this nut isnt as hard to crack as i think that the logic behind it is probably more or less the same (old modules are working and those are the ones uMFCD work now with).

I for one whish you good luck and will be a buyer as soon as it is available.

 

ps. i do like occacionally updates on how things progress (or not), be it on twitter or here. And the most important thing is if you want somethng to test ask me :):thumbup:

 

Erik

[Sgt_Baker]

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.

Edited October 2, 2015 by Sgt_Baker

[Sgt_Baker]

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.

[Pikey]

good news, you are super fast there!

[Sgt_Baker]

good news, you are super fast there!

 

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

[eriks71]

and 2 weeks left :music_whistling:

[Sgt_Baker]

and 2 weeks left :music_whistling:

 

26 Weeks. :P

[icemaker]

Good news Sgt_Baker!

[SageOT]

UltraMFCD - drag, resize and click display exports. Zero configuration.

 

So life© has kept me away from DCS for the last few months. I finally take a look at the forums and Boom! Hit with a positive update for my essential DCS add on utility. Great news and excellent work as always Sgt_Baker. If you want to start collecting money for pre-orders I am positive there are plenty of us ready to throw cash at you so you can get this thing up and running in 2.0. Again, keep up the good work.

 

Sage

[Sgt_Baker]

Update 3

 

Quod erat demonstrandum. :)