Amazing! This is the first working version of DisplayMagician using the new NVIDIA and Windows CCD library. It works properly, and now I can start to tidy up some of the additioanl functionality I need to sort out before a release. I also then need to work on the AMD library as well!
This is the initial version of the spanned screen bitmap drawing. It woks by showing one giant screen, but it currently doesn't insert any information about the individual screens that make up the spanned screen at all. I'm going to add that improvement at a later date, because the main thing is to get the new libraries up and running, and used by people.
Still have an issue where the 'Equals' doesn't detect that there is a different primary screen, so it won't let me save a new profile for the slightly changed display settings.
NVIDIA Profiles can be created, JSON file saved ok, and the bitmaps and icons are drawn correctly and showin in the Display Profile window. The problem comes when the DisplayProfiles_2.0.json file is loaded. JsonConvert causes an exception trying to populate ProfileBitmap, and I can't figure out why!
This change fixes Steam launch parameter passing.
There is still work to test and/or limit launch parameter
passing to only those libraries that support it. This will
need a bit of work. Fixes#27.
Have managed to get process priority working, but
need to do more testing before I'm sure it works in all
scenarios. I don't have enough different game types to
test the various different code paths, so thats going to
be something that my users will unfortunately need to
bug test. Adds feature #29.
Fixes#25. When you attempted to create a shortcut
that didnt run a game or executable, the program would
save the shortcut, but would crash when trying to show
it in the Shortcut library. This was because the _shortcutBitmap
wsn't being populated when no game or executable was
chosen. This has been fixed now, as it will use the profile bitmap
as the shortcut bitmap in these instances.
Have almost integrated the new CCD, AMD and NVIDIA
libraries into DIsplayMagician. The CCD library is working
fine. The AMD library is partially completed, but is awaiting
some help from AMD, as it appears one of their driver functions
is broken (or at least incorrectly documented). The NVIDIA
library is currently still under development, but I've still copied
it across so that I could work on the additional profile objects
that need to be prepared in order for this to work.
As I am waiting on a response from AMD, the plan is now that
I will swap over to an NVIDIA based video card in my test machines
and I will start work on the NVIDIA library. The NVIDIA library seems
straight forward compared to AMD, so that hopefully won't take too
long to do. Once that library is compete, I'll test it within NVIDIAInfo
application until its working, and then I'll port it back over to
DisplayMagician. That will then let me complete the last bits of the
integration so that I can complete the last of the NVIDIA tests.
Hopefully by the time all this happens I will have heard back from
AMD and I will be able to continue work with that section of code.
Added some basic CCD library functionality
to be able to set Windows displays directly
from the code. This will enable future native
HDR support through windows, as well as
allow positioning and screen setup to work
better through here than via the AMD driver.
Will still need to work on AMD Eyefinity support
once this is completed.
AMD Profile applying task now correctly reports
a true result when the AMDLibrary reports the
profile has been successfully applied.
Now all the scaffolding is complete, and an AMD
profile can be created, saved, loaded from a JSON file
and then an application of that AMD profile can be
tried.
Now comes the difficult part. I need to test out which
bits of the AMD ADL SDK I need to grab/store/load in
order to actually make the screen layouts change. And
then once that works with separate screens, I need to
add code to undertstand and recognise AMD Eyefinity
screen setups, and to make them able to be used.
This is going to take some time :/.
Now have the DisplayProfile storing the minimal set of
data that it needs. It also recreates the Screens list (used
for creating profile bitmaps and icons) and recreates the
DisplayProfileBitmaps each time at present. I will add some
logic to deerialise the bitmaps again at a later date once
I've compeleted actually applying the AMD display confs.
Now works with single screens and similar
so that they show correctly on the page without
being hidden by foreground stuff. Still might
make the DisplayView larger if it makes sense.
Have managed to get a working displayview
for AMD (not working in spanned mode) and
currently playing with the colours and layout.
Once I have something locked in, I'll troubleshoot
the ProfileDisplay file writing.
Trying to figure out a video card agnostic way
of generating the display icons fo both standard
and spanned displays. Still trying to figure out
exactly which AMD ADL calls I need to make to
get all the information I need. It is NOT very well
documented. It's actually really annoying! AMD
need to do better.
Trying to make the DisplayView and ProfileIcon
image drawing logic more generic so that it will
work with NVIDIA, AMD , Intel and Windows video
card drivers. Having to reverse engineer the amazing
wok that Soroush did with this stuff. I just know that
I'm going to break this before I fix it, but I really think
this is needed in order for this new video card
separation refactoring to work. This is going to take a
while I feel!
This is part of the new strategy to split the
ProfileItems into different derived clases with
one per Video card technology. The purpose is
to allow each video card driver to produce a
slightly different profiledata section which is
customised to the needs of that video card.
This will allieviate the need for us to extend
the Path object to support AMD, as we'll be
doing the differentiation at each ProfileItem.
Time will tell if this is a better strategy or not.
This is all to do with my even longer term
strategy of devloping video card driver library
files inhouse. This strategy was directly created
just so that I can make changes in my own code
if I need to support some additional features
such as HDR support within the profiles. It is very
difficult to do this if I'm using another video card
library. Much more simple to update my own code!
Moving to a situation where each library has
it's own ProfileData structure which will require
me to break the existing Profile structure.
This will be better once finished, but it could
be a month before I get this rewrite finished :/
Decided that the DisplayProfile changes would
have to be breaking changes if I was going to
add HDR support, and be able to handle adding
future video cards from different manufacturers.
This all requires a change to the DisplayProfile
format. So now this is going to use a file called
DisplayProfiles_2.0.json rather than a file called
DisplayProfiles_1.0.json. This is because the
profiles will need to be generated again from
scratch, as they will all be completely different
to the format in DisplayProfiles_1.0.json.
We have to do this as we will be moving
to a new video card library-based way of
getting the Display Profiles information.
This is designed to enable me to add new
video card drivers in the future, such as
Intel, in order to support 'combined'
video screens,
