1. 29
  1.  

  2. 9

    When running at 60hz, and especially with a major subsystem disabled, Way of Rhea easily spends the majority of the 16.66ms frame blocking–waiting for the next vblank–and apparently this lead Windows to believe that the workload was low priority and should be throttled, increasing both the frame time and frame time variability, causing me to start occasionally missing vblank which is how I noticed the problem in the first place.

    Awesome to see that Windows is still actively making it difficult to write games for it.

    1. 8

      Is it though? They provide a knob you can tweak to get the behaviour you want, and try to apply heuristics if you don’t. They can never get the intent from the code itself - for example what’s the difference between a game which does very little processing an a dashboard display? I want the first one to use more power and be smooth and the other to use little power because I don’t care about dropped frames.

      1.  

        I think the issue isn’t so much the technology, but the fact that the only way to find out that these tricks are necessary is to use Windows every day for years and slowly accumulate a list of them–hence me writing up this article sharing my list, to try to help shortcut that process for other people.

        I would be okay with the current state of things, to a greater extent, if this stuff was easily discoverable. e.g. if Microsoft wrote up this article instead of me, as an official guide for developing games on Windows. They could do even better by sticking this stuff in the “Remarks” sections of the docs for the various relevant functions, or integrating the knobs more clearly into the APIs they affect, but an up to date official guide alone would make a world of difference.

        I think, unfortunately, that’s probably not going to happen for two reasons. The first being that there isn’t much in it for them, since they already have a monopoly on PC gaming, but the primary reason I suspect this won’t happens is that I don’t think this stuff is 100% intentional–I suspect that there isn’t any one person at Microsoft who fully understands how all of the systems that can affect the perf of a game on Windows interact, and that the tribal knowledge engine developers build up over time actually outpaces anything Microsoft could put in an official guide.

        1.  

          Maybe I’ve misunderstood. It seems like any process that waits for vsync could simply be scheduled to wake as soon after the vsync as possible, and that would handle all cases. All such processes would be run in as condensed a period of time as possible, which would maximize core sleep time and therefore minimize power usage. Is there a reason that wouldn’t work or doesn’t make sense?

          1.  

            I agree it’s possible it would be better, but it depends on the specific CPU - is burst + more sleep going to be better than low-freq + less sleep? Does it change when you have separate performance and efficiency cores? Can’t know today without hard data.

            There’s a few things that could wait for vsync, but I would prefer them not to be treated as performance sensitive: desktop effects animations, video conference, any website animation, …

        2. 1

          What platform(s) are easy to write games in?

          1.  

            As far as I can tell, none that are commercially relevant.