WoW maxfps when minimized limit setting

[alex_v]

There are two CVar's I am aware of: maxFPS and maxFPSbk.
When I minimize WoW, EndScene is still executing but with low fps: less or equal than 4 always. I am looking how to change this value, if possible.
Also, maxFPS and maxFPS have lower bounds - probably 8. Maybe someone knows how to make it smaller.
I've tried to write directly to "CVar_MaxFPS = 0x00C5DF7C", effect was the same.
If anyone reversed it or wishing to do so, I am interested in offsets for this game version: 3.3.5.12340
Probably need to start with reversing routine that reads 0x00C5DF7C (I can't do it.)

[Jadd]

Don't use an EndScene hook just to execute in the main thread. It's a bad idea for a number of reasons. This is yet another problem which can be solved by hooking WndProc. ntoskrnl | Hooking Threads without Detours or Patches

[aeo]

Very interesting link thanks JADD.

[alex_v]

Yes, thanks. Is it ok to enum visible objects from wndproc? and CTM/Interact?
But EndScene is useful too, for rendering at least.

[Jadd]

Yes, thanks. Is it ok to enum visible objects from wndproc? and CTM/Interact?

WndProc and EndScene occur on the same window/same thread, so yes.

[Corthezz]

Hey Jadd,
I am curious about those reasons against using EndScene. For the moment I can only imagine a few:
1. Interference with tools like Fraps, GameCam etc.
2. EndScene execution rate is affected by the performance of the computer.

Anything else?

Thanks in advance

[Jadd]

The rendering functions should be used for rendering purposes. IIRC WoW uses separate fibers to handle window messages and rendering, so work done through WndProc will not be such a hindrance to rendering performance (I don't have a source for this, I may be wrong.) I also prefer to hook WndProc because it is independent of DirectX, specific versions of DirectX, etc.

There's nothing wrong with hooking EndScene, but it's best to keep the workload related to drawing. Heavy workload stuff should definitely be kept out of the main thread, the best option is to do as much as possible in your own thread, including preparing drawing info (coordinates, translations, etc.) for the renderer. This way you know you're keeping FPS loss to a minimum.

Personally, I use a thread invoker which extends the previous code in the blog post, and I can immediately invoke anything from the main thread when needed.

Example:

    public static class Chat {
        ...

        /// <summary>
        /// Writes a line to the game's chat frame.
        /// </summary>
        /// <param name="type">A <see cref="MessageType"/> which will be used to determine the prefix text of the output.</param>
        /// <param name="text">A text string to write to the chat frame.</param>
        public static void WriteLine(MessageType type, string text) {
            var message = $"{GetPrefixString(type)}|cFFFFFFFF{text}";
            Thread.Invoke(CGChat__AddChatMessage, message, ChatMessageType.System, IntPtr.Zero);
        }
    }

I'll make another blog post soon with the details.

[alex_v]

I hooked WndProc using the code above and it solved few problems.
But one is still left - I cannot make wow main thread to call my routine with smooth FPS > 4 if wow window is minimized.
I am using 3.3.5.12340 client

I have tried to make my WndProcHook to be executed at 15 FPS, using win32 SetTimer first, and posting messages to windows after.
First, results using win32 SetTimer(two timers, every second + every 66 ms:

SetTimer(wowHwnd, 66, 66, 0)
SetTimer(wowHwnd, 1000, 1000, 0)
1) If window state is normal (not minimized).
Not precise, but good enough for my purposes.

[13:04:23.551] timer: 1000
[13:04:23.553] timer: 66
[13:04:23.628] timer: 66
[13:04:23.704] timer: 66
[13:04:23.781] timer: 66
[13:04:23.858] timer: 66
[13:04:23.942] timer: 66
[13:04:24.018] timer: 66
[13:04:24.094] timer: 66
[13:04:24.172] timer: 66
[13:04:24.248] timer: 66
[13:04:24.326] timer: 66
[13:04:24.412] timer: 66
[13:04:24.481] timer: 66
[13:04:24.560] timer: 1000
[13:04:24.561] timer: 66
[13:04:24.641] timer: 66
[13:04:24.721] timer: 66
[13:04:24.801] timer: 66
[13:04:24.871] timer: 66
[13:04:24.951] timer: 66
[13:04:25.030] timer: 66
[13:04:25.107] timer: 66
[13:04:25.187] timer: 66
[13:04:25.290] timer: 66
[13:04:25.339] timer: 66
[13:04:25.418] timer: 66
[13:04:25.497] timer: 66

2) If minimized, most of WM_TIMER messages are lost, but WndProc is still getting called with ~equal intervals.

[13:04:38.835] timer: 1000
[13:04:38.837] timer: 66
[13:04:39.088] timer: 66
[13:04:39.344] timer: 66
[13:04:39.600] timer: 66
[13:04:39.853] timer: 66
[13:04:39.860] timer: 1000
[13:04:40.115] timer: 66
[13:04:40.375] timer: 66
[13:04:40.630] timer: 66
[13:04:40.886] timer: 66
[13:04:40.893] timer: 1000
[13:04:41.146] timer: 66
[13:04:41.408] timer: 66
[13:04:41.673] timer: 66
[13:04:41.941] timer: 66
[13:04:41.945] timer: 1000
[13:04:42.199] timer: 66
[13:04:42.453] timer: 66
[13:04:42.707] timer: 66
[13:04:42.962] timer: 66
[13:04:42.964] timer: 1000
[13:04:43.216] timer: 66
[13:04:43.471] timer: 66
[13:04:43.729] timer: 66
[13:04:43.985] timer: 66
[13:04:43.988] timer: 1000
[13:04:44.243] timer: 66
[13:04:44.497] timer: 66
[13:04:44.751] timer: 66

Then, I tried to call win32 PostMessage every 66 ms, using
new System.Timers.Timer(66) and new System.Timers.Timer(1000);

Results when window is minimized:

[13:13:30.645] timer: 1000
[13:13:30.649] timer: 66
[13:13:30.653] timer: 66
[13:13:30.658] timer: 66
[13:13:30.912] timer: 66
[13:13:30.915] timer: 66
[13:13:30.919] timer: 66
[13:13:31.174] timer: 66
[13:13:31.177] timer: 66
[13:13:31.182] timer: 66
[13:13:31.185] timer: 66
[13:13:31.442] timer: 66
[13:13:31.446] timer: 66
[13:13:31.449] timer: 66
[13:13:31.705] timer: 1000

It is not better that SetTimer, because WndProc was called with the same interval (~250 ms). WndProc handling all WM_ messages, then main thread is going to sleep for ~250 ms, then waking up, looping WndProc until there are no messages left, then going to sleep again.
I suppose the problem is lying in WoW main loop, where GetMessage is called?