I have the following setup for the game:
launcher.exe - starts under Steam on Windows and provides some settings UI for the user.
Then launcher.exe starts actual game.exe.
Problem is that the launcher.exe is using H/W accelerated UI - uses Direct2D/DirectX.
This page https://partner.steamgames.com/doc/features/overlay states:
Your game does not need to do anything special for the overlay to
work, it automatically hooks into any game launched from Steam!
But in my case that creates problems - the overlay is created on wrong window. So launcher.exe (uses DirectX) has the overlay but window that is created by game.exe (real game, uses DirectX and/or OpenGL) is not.
And the question is: how can I modify code of my launcher.exe window to prevent Steam overlay to be created on it "automatically"?
Update, response from Valve's TS:
Sorry, there's no code in place to selectively enable or disable the
overlay between launchers and games!
The only "option" is to disable DirectX drawing in the launcher.exe. In this case their injected DLL will not create that thing. But that effectively means no GPU accelerated UI drawing under the Steam... Kind of "640kb is enough for everybody" type of design.
Ideally Steam should send some custom message to the window to ask how and where the window wants that overlay to be rendered. But apparently there is no such thing, or is it?
Just for the context, the launcher looks as this:
Related
I created a simple windows app that i want to pin to my desktop similar to a wallpaper widget. I am using a nodeJS module that is almost doing everything i want. Essentially from my limited understanding this module is utlizing windows libraries and its creating a progman worker and sending the 0x052C instruction to create a Window on the desktops wallpaper plane.
I think its defining the type of window and its position (wallpaper) based on this value? 0x052C
// Message to Progman to spawn a WorkerW
static int WM_SPAWN_WORKER = 0x052C;
The app is built with Electron which is NodeJS enviroment so im a bit ignorant in the world of C++ and C#. But i have 2 issues right now with my window.
Issue #1: My window doesnt allow any mouse interaction. I can not push any of the buttons in my app for example. I assume this is because its on the desktop wallpaper plane.
Issue #2: My window is allowing my desktop icons above it. Which makes sense. But I wanted to find a way to make them on the wallpaper but not behind the icons. But behind every other window.
Question 1: where can i learn about this value and possible other value's I can send to progman? 0x052C or am i misunderstanding?
Question 2: how can i draw above the desktops wallpaper but under all normal windows? Is there a tutorial i can follow to learn how to achieve this and solve Issue #1 and Issue #2?
A big reason i used this method was to avoid getting my window hidden from the "show desktop" feature in windows. Trying to get my window to behave like a desktop gadget.
I just need a starting point or a spark to find the correct library/instructions to use. Thanks for any insights!
I want to use Chromium Embedded Framework as GUI of my OpenGL application.
I am using Off-screen Rendering.
How to detect when a HTML button/link is clicked on?
I tried to google this but with so generic search term there is only noise.
The General Usage wiki also doesn't contain this.
I think you should catch an event in JS code and send a message to C++ code. It can be done using a message router described here:
https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage#markdown-header-asynchronous-javascript-bindings
It is also possible to implement a custom message router using JS integration mechanic:
https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md
Do you pass any UI events to CEF from your OpenGL application?
In general you shall attach OpenGL and CEF instances to the same window. You shall also override request to invalidate window's area to notify your OpenGL code that it needs to rerender window including content of that on-screen buffer.
Sequence of actions:
Window receives mouse move event.
Window passes it to your CEF instance.
If CEF determines that it needs to apply :hover state to your button then it will call window.invalidateArea(areaOfTheButton).
You handle that window.invalidateArea() by updating OpenGL scene including new version of your off-screen bitmap.
From CEF you should also receive various secondary DOM events in response to mouse move/up/down/etc. on window.
And check this: http://sciter.com/sciter-and-directx/ - it is DirectX window with integrated HTML/CSS UI with my Sciter Engine. At the moment I am designing the same but for OpenGL.
I'm developing a 3D desktop application like this where I duplicate the desktop by creating planes in 3D space using each window's bitmap as texture and then passing mouse and keyboard input to them (background windows) via windows API.
This approach causes several issues and the main one is that some clicked windows generate new popup windows like menus that popup on top of 3D app and steal focus.
Is it possible to properly duplicate a desktop behavior inside another app like this - without losing focus and keeping 3D app on top?
Only workaround for this that I can think of is to have 3D app running on secondary monitor, let user work with regular desktop on primary monitor as usual and 3D app will just duplicate that and use windows hooks for any 3D app specific input.
Apparently IInspectable is right. No reliable way to do this without losing focus.
I was looking at how sometimes when you right click, the menu goes outside of the window.
Is this implemented with a separate window? If so, how can I get this functionality. I am trying to use GLFW, but I understand if it isn't possible.
Currently I am on windows, but I like keeping my options open, which is why GLFW would be preferable.
I noticed that GLUT has such a feature. If you are confused to what I am looking at then look at that.
Thanks for any help!!
Overlapping menus (in MS Windows) have to be implemented as a new top-level window, you would have a new OpenGL rendering context and draw the menu in that space - yes, it's a fair bit of work all for the edge-case of a menu overspilling the parent window,
However this isn't often a problem in OpenGL programming because if you're working on a full-screen game then the menu will always be displayed within the main window, and even if it isn't a full-screen a game your users really won't notice them as games tend to use different UI concepts like radial-menus which wouldn't overspill the parent window.
Or if you're working on a non-game title, chances are it isn't full-screen and is going to be an OpenGL rendering area within a larger application that is rendered using a native UI toolkit (e.g. 3ds Max, AutoCAD, etc), in which case no problem: just use native menus.
You can, of course, use native menus in an OpenGL application anyway, provided you do the necessary plumbing for native window messages.
I am trying to draw on top of another process while it is in immersive full-screen mode.
I know this is possible using GDI and I have 2 questions:
Is it possible using a top-level transparent window ? (on top of the immersive process)
Is there a higher level API witch I can use instead of GDI?
Thank you :)
In Windows, you have two possibilities for creating a fullscreen window:
A full-screen application with exclusive drawing rights to the display.
A borderless window that extends to the full desktop resolution.
The first option allows you to change display properties like resolution, bit depth and refresh rate, while the second option is bound to use the same options here as a normal (windowed) desktop application.
Overlaying a fullscreen window with a top-level window is only possible if the fullscreen application is implemented with option 2. In that case however, any code that is able to create a transparent top-level window will do (be it pure WinAPI/GDI, or something more sophisticated, like Qt).
With option 1, as the description suggests, the fullscreen application has exclusive drawing rights to the display. Attempting to bring another window in front of it will either minimize the fullscreen application or force it into windowed mode.
There are some hacks how you can still get an overlay in this case, but they are rather invasive. For example, with a fullscreen application based on D3D, you can hook into D3D's Present routine and have D3D draw your overlay before displaying the back buffer. The important point here is that the code for drawing the overlay is executed from within the process of the fullscreen application, as that is the only process that is allowed draw to the screen at that point.
Note that some applications (in particular video games protected by anti-cheat software) do not like it very much if you inject code into the process this way.
Note that the Win API also provides an interface for so called hardware overlays, which allow drawing on top of exclusive fullscreen applications. Unfortunately, this mechanism is not widely supported on consumer hardware and might not work depending on which graphics card you are trying to run it on.