I am the author of this library. I'd like to say before anything else, thanks for all the attention the community here gave the project.
I went from 60 stars to 200+ overnight. I only found out it was from here when I looked at the traffic data for the project. That is motivating and rewarding as a newer developer who started during C# 6.0.
I intend to review the rules and general rules of thumb over here and contribute where possible.
Second, yes it will be under MIT in its current form. You have my word you are safe to use it under MIT conditions. If you would like to use it before I add the license.I can not guarantee all versions in the future will, but any release out and for the next foreseeable release MIT it shall be.
I intend to fix the NuGet and bugs that exist this week and get a stable version, a NuGet, and license up. From there I will improve what I can and add in stable d3d support with an easy way to load your dll and the clr into another process (using this https://github.com/lolp1/DomainWrapper).
From there you will be able to detour Present or EndScene in both x64/32 d3d11/9.
In windows 8/10 can you still use the 'glass' blur in overlays? I wrote a similar thing on top of XNA a few years ago and remember there existing a flags/clear color combination which made the background of the frameless window look like the blurry aero glass.
The start menu in W10 has that effect, so there must be still a way to do it?
Indeed, you can use the same effect as the start menu via the undocumented API SetWindowCompositionAttribute [1]. Note it only works properly with frameless windows, if you have a titlebar there are slight artifacts around the window.
I write tools to interact with games - ctrl+p to do a price lookup for item under mouse, track which cards have been played/are in your deck, that sort of thing - and it'd be really useful there. DLL injection is kind of a pain (and it can be detected as cheating, which this little framework probably doesn't solve), so the fastest route for prototyping ideas tends to be AutoHotKey or something else that can spawn tooltips easily on top of D3D windows. Obviously that has tons of drawbacks, so if this is quick & easy and runs on a 'real' platform like .NET, it'd be a lot more powerful.
Some people suggest it is mostly for "hacks". I disagree. One example I give to people is an overlay I made presents all text messages, skype message, forum private messages, etc in a mid size transparent overlay to toggle on/off and some buttons/input box to reply.
Now while in-game I can quickly reply to things and not juggle browsers, tabs, apps, etc with alt tab.
You could probably modify it to do this, yes. It's creating a transparent window that overlays the host window, so you could use the same technique to overlay the desktop with a transparent topmost window.
I've done this before for similar input purposes and the only caveat is that some applications are able to 'push' topmost windows to the bottom - there are some workarounds, though.
You can also do this with raw GDI (if you do the pixel pushing yourself) or with GDI+, since all you need at the base level is an ARGB buffer to feed to the windows compositor.
For example, I wrote an overlay for my dualshock4 driver that would visualize touchpanel inputs at the bottom right corner of the screen and describe the inputs it had synthesized from them.
https://github.com/kg/DS4_PSO2/blob/master/DS4_PSO2/GestureO...
"I've done this before for similar input purposes and the only caveat is that some applications are able to 'push' topmost windows to the bottom - there are some workarounds, though"
Are there? I would think that is a weapons race you cannot win. If you can force your window to the top of all other windows, including those of other applications, so can others.
The only way out of that is if the OS has a notion of "this is the one and only topmost full screen window".
Right, that's why in this case you just periodically push yourself to the top of the stack. If you're not capturing input (and the user opted into it) it's relatively sensible.
Exclusive mode fullscreen applications will crush you anyway since the compositor turns off, but otherwise it seemed to work OK.
At best, I would call that "You win or you lose". Yes, there are all kinds of hacks that might give you a better chance, and you may be able to make it very likely you will get what you want, but to do so you have to be very naughty.
For example, another hack involves removing the real screen from the OS and creating a virtual screen of the same dimensions and bit depth, intercepting calls to the virtual screen, and essentially writing one's own compositor in the video memory of the real screen. If my program does that, your messages to move your window to the top will never work. Your window may end up on top on the virtual screen, but that's not what the user looks at. If you counteract by using the same trick, how do you know that want you think is the real screen isn't already a virtual one created by a program that ran earlier, of that a program running later doesn't enumerate the hardware and figures out where the real memory lies?
I also could try and patch your program when I detect it, patch it in memory to send fewer or no such messages, intercept its messages, or even crash it when I see it, etc.
It remains competition for a scarce resource; because of that, I don't see how two identical copies of such a program could both win, let alone if I run ten of them.
I am the author and I will be releasing it under MIT - you can take my word for it you can use it freely or wait a week or two for another commit and license add. Sorry for inconvenience.
