Controlling the Game - HeroesReplay/HeroesReplay GitHub Wiki

Native Windows Calls

Native windows functions from user32.dll, gdi32.dll and kernel32.dll are used for the following reasons:

  • Sending input to the Game Window (HotKeys)
  • Copying image data from the Game Window for State detection (Start, Running, Paused, End) via reading the Timer at the top.

Running the process

  • The process will automate launching the replay via heroesswitcher_x64.exe
  • The process will write some information to a text file about the current replay.
  • The process will kill the game after every game has ended.
  • The process will launch and authenticate through Battlenet authentication.

The reason that the process is killed and re-launched is because launching replays is much simpler than having to exit the current replay, go back to a menu in the existing game client, launch a new replay file etc, and there is strange behaviour which logs you out of the game session with battlenet, so its much simpler to just kill the process and re-launch per replay. It also means we can mitigate a long running game process and make sure the process is repeatable per replay.

OCR and Screen capture

The OCR is using the Windows Media OCR which is a native built in OCR Engine in Windows 10.
The process uses the OCR for the Game Timer displayed at the top center of the game.

A portion of a rendered frame is passed onto the OCR engine which returns the Timer.
This timer is used to track the state of the game up until the end.

A combination of the WELCOME TO, MAP NAME, and HEROES on the map loading screen is used to determine when the game replay file has loaded. The Core Death Time (analyzed before the replay loads) is used to determine the end state of the game. Once the Timer reaches this time. The game process is killed.

Screen capture is not using a hook like how Streaming Software hooks to a process. These require more complicated and sophisticated methods to acquire frames for minimal latency and DX11 hook in etc is more complicated than simply using a Screen Capture each second.

This process uses two main ways to get a capture for OCR usage.

CaptureFromScreen

This will capture the entire screen. This is usually needed if the Hardware requirements cannot use BitBlt.

Bitblt

This is a low level method supported by many devices, this allows other screens to be on top without causing a capture problem.
This is the preferred approach to capturing the game. This should also be more efficient and reliable than CaptureFromScreen.

None

If the Capture Method is set to None in the settings, the game process itself is stubbed and a fake Timer is returned from the Game Controller engine. This is usually just for local testing and integrating into other things that need to run or be tested, such as downloading S3 files, controlling OBS etc where actually loading the real game process is not needed.