Ok if you have a Cubesim device there’s a setting to disable OpenGL double buffering. Look at the MFDCougar.ini file for the Cubesim support.
This is written up in the manual.
This is written up in the manual.
Release Elite Cougar MFD Cockpit Display - game changing new companion app
- Thread starter Bionic Bytes
- Start date
Managed to get through Norton, then repositioned the screens. Both then locked, so closed everything down, restarted, and this is the view after start:
One grey screen only. Also tried running it from my C drive. Definitely did not like that, and kept getting error messages that it had access denied, then exception issues?
One grey screen only. Also tried running it from my C drive. Definitely did not like that, and kept getting error messages that it had access denied, then exception issues?
Thanks for the update.
This is a strange one. Nobody else has reported anything like this before.
I wouldn’t recommend using c:\program files folder because of the file system user permission restrictions in place.
Instead I’d create a folder somewhere else, eg c:\elite utlities\MFDCougar
It does seem like your system is preventing execution or restricting the app from creating subfolders and files in the application folder.
Try giving “full control “ file permission to the app folder.
With regards to the grey screens. It seems the app is running into an issue creating the open gl contexts and attaching them to the windows. The app create log files to help diagnose where in the process it has succeeded or failed.
Have you downloaded the utility files from the website?
http://cougardisplay.site/downloadfiles.html
Scroll to the bottom and download OpenGL Utility. This uses the same rendering engine as the app and draws some simple shapes.
Hi BB - I am so sorry but really appreciating the assistance. Thought I had it cracked just after my last post, started Elite in windowed mode (hate windowed mode!), let the Cougar displays initiate before doing anything with them, paused, repositioned. Halfway through moving and resizing noticed the applet still gave me the option to pause. Got both screens up and running, selected pause/resume, nope - resolutely stays on pause. Shut everything down, restarted - back to single grey screen.
There does seem to be some other issues. So - if I hit pause, it either retains the ability to select pause, ie doesn't change, or the little selection window stays on screen. When I do the initial set up, select pause, both windows appear but then remain (not responding) for a good few minutes before I can do anything with them or they show initialising.
Only games installed on the PC are Elite and DCS, both on a separate SSD away from Windows. Only thing I have done recently is swap my graphics card out for a new one which went seamlessly.
Message received regarding the C:/Progs so will create another custom folder for it to sit in when next giving it a go later tonight.
Final update - cannot download the GL Util as Norton keeps removing the files everytime I unpack them?
There does seem to be some other issues. So - if I hit pause, it either retains the ability to select pause, ie doesn't change, or the little selection window stays on screen. When I do the initial set up, select pause, both windows appear but then remain (not responding) for a good few minutes before I can do anything with them or they show initialising.
Only games installed on the PC are Elite and DCS, both on a separate SSD away from Windows. Only thing I have done recently is swap my graphics card out for a new one which went seamlessly.
Message received regarding the C:/Progs so will create another custom folder for it to sit in when next giving it a go later tonight.
Final update - cannot download the GL Util as Norton keeps removing the files everytime I unpack them?
I’ll help you as much as you need - so no worries I’ll try my best to get this working on your system.
Honestly it shouldn’t be this much hassle. It should (and does on other systems) just run with no fuss or effort.
The only times there has been an issue is with drivers (AMD xt series) and Cubesim.
The fact that you can’t download and unzip is a worry. Seems like Norton is intent on killing the app and utility files.
Come on to the discord channel and raise a question. Maybe others have used Norton and they know a solution.
Also you can then send me the zip of the LOGs folder.
OK. Signed up to discord so job for tomorrow.
Eventually got both MFDs 'working', albeit the wrong way round!? In the end used the cubesim workaround which seems to have helped. So had the red screen on the left, green on the right - properly sized etc. If I exited the game and then went back in, would get something like this:
I would then pause and reposition. If I pressed an MFD button on my left cougar the icon on the right would illuminate - so for instance press lights and heat sink would flash.
I then went into full screen and had same - no matter what I did I could not get the screens to position correctly and always some sort of overlay?
Eventually got both MFDs 'working', albeit the wrong way round!? In the end used the cubesim workaround which seems to have helped. So had the red screen on the left, green on the right - properly sized etc. If I exited the game and then went back in, would get something like this:
I then went into full screen and had same - no matter what I did I could not get the screens to position correctly and always some sort of overlay?
The cube sim INI setting is a workaround for a driver issue/OpenGL compatibility issue.
This seems to be needed when there are additional usb monitors attached to windows. The driver for these monitors uses some sort of fudge to get OpenGL contexts and needs double buffering disabled. This weird behaviour shows itself when the OpenGL windows are created on another monitor other than the main monitor.
The app uses a file called MFD.ini to record the size and position of the windows on your desktop. You can manually edit this file once you’ve closed the app to double check the x,y position and width/height.
The Cubesim option temporarily creates the GL contexts on monitor 0, then moves them onto your preferred monitor (as specified in the mfd.ini file) once the context is properly initialised.
Another way to demonstrate the issue is to set the OpenGL windows to use the main monitor (ie edit MFD.INI and change the x,y positions to be 0,0 for example). This will create the windows on the main monitor where the nVidia GPU will be used to create the OpenGL contexts.
Did you have to install a driver for those other screens?
The utility I linked to Earlier clearly shows the issue with OpenGL Double buffering and helps determine if this is an
Issue or not.
Last edited:
The overlap is weird. So there’s still something preventing the app running properly.
For instance, the left display is missing all the centre graphics and text.
Do you have any windows settings to change monitor DPI ? Or extra large fonts, stuff like that. Just a guess as to what might cause the app to wrongly position windows or workout the size of windows.
Finally managed to get this downloaded and run. All appears good - two coloured boxes with some spining cubes in the middle. Have zipped the logs up - so will send them across. I have now manually adjusted the ini file to position the screens, as also managed to run the Window test - which showed them overlayed. Tried it all in game - still no. Both screens overlaid again, came out, and ran the windowtest, and the ini file had been altered so the window positions were thus (MFD 1 started out at X3840):
In addition everytime I clicked in a window or pressed a cougar button the window would shift right?
Bit more testing - not so good. I have 3 screens - 2 x 28" 1920/1080 and a third (for the MFDs) 11.6" 1920/1080. If I run the windows GL test from screen 1 - all is good. If I run it from screen 2 I get a coloured left hand box (occasionally), if no coloured box then both are black. If I run it from the 11.6 screen I just get black boxes. I can see both boxes appear on screen 1 then jump across, but stay black. In addition the debugger then goes into 'not responding' and have to resort to task manager to close it down.
Screen 1:
Screen 2 and 3:
Checked all my current monitor settings - all set at 100%, 60 hz, native resolutions etc - and to my knowledge do not have any changes to DPI etc...
OK - starting to feel a wee bit foolish now! After my last post - downloaded and installed the latest Nvidia drivers in the vain hope. Went through the display settings - screen 1 100% (recommended); Screen 2 125%; Screen 3 100%. Screen 2 changed back to 100% (recommended) and 3 to 125% (recommended) and the GL tester works - on all 3 screens. Whether some setting got changed when I was messing with DCS MFD settings back along without my realising things when I was dragging screens around - but certainly not something I knowingly did?
Now just need to have a proper configure as they are crossed - as before if I push lights heat sink lights up and vice versa - so need to configure the keys properly or swap the screens - not sure if that is a USB thing as the cougars are aligned - so MFD0 is on the left with cougar light top left, MFD 1 on the right with cougar light top right.
Now just need to have a proper configure as they are crossed - as before if I push lights heat sink lights up and vice versa - so need to configure the keys properly or swap the screens - not sure if that is a USB thing as the cougars are aligned - so MFD0 is on the left with cougar light top left, MFD 1 on the right with cougar light top right.
Ok that’s great news. Glad the basics are showing on screen now.
So in the end a driver update resolved the weird behaviour?
Your displays look Correct with the green weapons to the right of the red flight console. Are you saying That the assigned Thrustmaster cougars are mapped the wrong way round for you? If you use the mouse on the icons do the correct elite actions get invoked?
Note: you can run the elite key tester utility to observe the key press sequences being generated by the icons.
I have a feeling that the app auto assigns mfd joysticks to displays 1 and 2. The MFD.INI file contains the mapping of the joysticks to the console displays.
If there’s still something wrong, you can run the thrustmaster mfd config tool and reassign which cougar is 0 and which is 1.
I’m not on the PC right now, but I think the app has a joystick mapping UI so you can see which cougar is which and test their inputs and assign one of them to the display windows.
Hi BB - no - I think that purely by updating the drivers made me to check other things than I normally would - I tend to go back over things to ensure all is as it should be - and that is when I noticed that the screen displays of 2 and 3 were not at the recommended settings -(i.e. 100% and 125%) respectively - so somehow that was messing with the program. I can go back in and break it again by simply changing away from recommended settings under display, scale and layout. Might also explain some graphical glitches I was seeing in DCS.
Need to have more of a play with the key settings etc - as obviously been using all effort to try to get to the bottom of the initial issue, but will report back findings as I go, but yes currently if I push MFD button light the heatsink flashes. TBH I didn't realise they were mousable/clickable so will give that a go in due course.
Still get some nasty Norton warnings - both the window and GL tester were quarantined - think maybe because they download as executables?
Thanks for the clarification.
I may have a play with the screen scaling as it has a profound impact. Seems to me that the windows APIs aren’t taking that into account and thus all calculations are off. Maybe there are newer APIs that I should be using?
OK - one thing worth reporting (I guess?) is after setting the 11.6" screen to 125% (Recommended), if I ran the windows test the scaling was off, so had to adjust the ini file to reflect the oversize by reducing the x/y values - so as an example my set up has the screen width of 850, but to display under the test I needed to reduce it accordingly by a fifth (25% of 125%) - so 680. If then I run the MFCD the displays would show at 80% - so had to revert back to 850 - so there appears to be a mismatch between the program proper and the windows test prog, but basically the program appears to works fine in terms of sizing. Hope that makes sense?
Last edited:
Here's the GUI options to assign joysticks to the display consoles.
You access it from the Design Console button.
Thanks for the info. I have re-uploaded the test windows utility with a change to support monitor DPI. Tests show that this works with any monitor scaling now.
So - still have MFD 'cross over' issues. Have run the tm profiler (target software or is it something different?), all appears to be up and running correctly, so MFD 0 identifies as the left hand MFD, and if I press any of the MFKs I get a corresponding key light - same with MFD 1. Not whether there is any setting in the MFD.ini I can swap out - have noticed there is some IDs in there - did try changing 0 to 1 and 1 to 0 but made no difference and were reverted back. If I click the torch icon on the left MFD - nothing, admittedly didn't try clicking on the heatsink to see if the light came on, but it does if I push the heatsink icon MFD button on the right MFD.
And 'weirder'. I set the Cubesim setting back to 0. Ran the program, selected start and had 2 grey/white screens only - though at least this time they were in the right place. Only way I could get them to initialise was put the cubesim setting back to 1. The screen is a bog standard 'Wimaxit 11.6 HDMI monitor', no drivers required? Does anything get written to the registry that may affect things? On a positive note, the MFK keys now correspond to the correct screens, just not 100% what I did that actually made the fix.
LOL, computers eh?
Are your monitors USB or HDMI?
If they are USB I'd put money on it that a driver would have been installed to get them to display as a monitor with the Windows desktop. I had to do this with mine (although it was a manual driver install). As a result, some drivers use some sort of DX/OpenGL trickery but as a consequence they don't support double buffering - and hence the grey screens as the OpenGL context fails to be created.