(Note: This commit also modifies the ipc-util/seg-service modules)
When compiling the final project, always compile
ipc-util/get-graphics-offsets/graphics-hook/inject-helper/seg-service
with static MSVC runtimes to prevent the need of requiring the MSVC
runtimes for both architectures.
Whenever a cursor is captured and the cursor icon changes, it creates a
new texture. This isn't particularly optimal, so instead just store a
cache of cursor textures (based on size), and make the textures dynamic.
Doing this will prevent unnecessary texture reallocation.
Even if the hotkey is not enabled, always allow configuration of the
hotkey. Fixes a bug where the hotkey configuration settings would not
save if the settings were changed.
Annoyingly this means that the hotkey will still be shown to the user,
possibly confusing the user as to whether they can use it, but for the
time being it's better than having their hotkey configuration removed
each time they change the mode.
It's supposed to look for patch segments in ascending order, from the
smallest offset to the largest offset. Patch type/comparison is
identical to the one it's being swapped with, so only the offsets need
to be swapped.
Prevents the common problem of injecting in to certain processes and
getting the hook DLL "stuck":
- windows explorer
- steam
- battle.net
- gog galaxy
- skype
- uplay
- origin
- microsoft visual studio
- task manager
- league of legends lobby window
- windows 10 system settings window
Changed the first property of game capture to be a "mode" list (with
"any fullscreen window", "specific window", and "hotkey").
When hotkey mode is set, it'll add a hotkey pair to hotkey settings to
activate/deactivate game capture. When the hotkey to activate is
pressed, it'll treat the current foreground window as the target window
similar to "selected window" mode; it'll keep trying to capture the same
window even if the window or its application closes/reopens, and will
continue to do so until deactivated via the deactivate hotkey, or until
a new window is set via the activate hotkey.
This reverts commit 4c505e7030.
Reverting this for the time being due to issues with quakelive. This
will be more thoroughly tested and hopefully added again.
Tested using FTL (steam): SwapBuffers ultimately calls wgl_swap_buffers
causing an additional copy which just isn't necessary
This also causes game capture to sometimes capture overlays even when
not intended
Removing this union fixes the internal compile error that would occur on
visual studio 2015 update 2 and above when these variables were all in a
union.
Fixes a bug where if a D3D9 program recreates its device the capture
would become invalid. Certain games (especially blizzard games) will
completely recreate their Direct3D device if a critical D3D9 error
occurs.
This reverts commit 8d520b970d.
This can actually cause a hard lock due to the windows API when
destroying window capture. When the graphics thread locks the source
list for doing tick or render, and then the UI thread tries to destroy a
source, the UI thread will wait for the graphics thread to complete
rendering/ticking of sources. The video_tick of window capture would
then check windows in the same process and try to query the window's
name via GetWindowText. However, GetWindowText is synchronous, and will
not return until the window event has been processed by the UI thread,
so it will perpetually lock because the two threads are waiting for each
other to finish.
Prevents game capture from acting as a global source. This fixes an
issue where a game capture in another scene could capture a window and
prevent a separate game capture in the current scene from being able to
capture that same window.
Completely shut down monitor capture when it's not being shown in the
program (for example in a different scene). This fixes an issue where
it would cause lag when a game enters fullscreen mode.
When using a chain hook method (forward or reverse), it was unwisely
assumed that the previous hook in the chain would not overwrite new
hooks when it's called. When the game capture hook calls the previous
hook in the chain, certain other programs that hook (in this case,
rivatuner on-screen display) would overwrite the hook with older data
and erase the game capture hook, causing it to only capture the first
frame and then never capture again.
This patch ensures that the hook is always saved before calling the next
hook in the chain and then restored after the call returns. It also
preserves any new hooks that may be added on top of it at any point.
Originally this on by default, but then was changed to being off by
default because it was thought that there were permission issues, but it
turned out that the permission issues were a separate bug, so it's safe
to have this be default to on again.
This is a fast/immediate solution to a possible bug with caching the DLL
versions for game capture hook addresses - may as well just reload game
capture hook addresses each time the program is run for the time being
just to be safe. Load time will increase a little for the time being
but it's worth it to prevent any issues with game capture.
Certain types of sources (display captures, game captures, audio
device captures, video device captures) should not be duplicated. This
capability flag hints that the source prefers references over full
duplication.
Darkest dungeon uses an unusual technique for drawing its frames: a
fixed 1920x1080 frame buffer used in place of the backbuffer, which is
then stretched to fit the size of the screen (whether the screen is
bigger or smaller than the actual texture).
The custom frame would cause glReadBuffer to initially fail with an
error. When this happens, their custom frame buffer is in use, so all
that needs to be done is simply reset the capture and force the current
output size to 1920x1080 while that custom frame is in use.
They presumably did this in order to ensure the game looks the same at
any resolution. Instead of having to use power-of-two sprites and
mipmaps for every single game sprite and stretch/skew each of them
(which would risk the final output "not looking quite right" at
different resolutions), they simply use non-pow-2 sprites with no
mipmaps and render them all on to one texture of a fixed size and then
stretch that final output texture. That ensures that the actual
composite of the game still looks the same at any resolution, while
reducing texture memory by not requiring each sprite to use a
power-of-two texture and mipmaps.
Some games don't catch GL errors via glGetError, so there's a
possibility that an error will pass through to the capture calls,
causing a false failure.
The most simple solution is to just clear the error flag on each capture
call.
jp9000
Gol-D-Ace
Palana
Richard Stanway
sorayuki