Frame Limiter Opitions

A "hack"? Strange way to call a feature Microsoft themselves added to an O.S and that you can disable with a simple click on any .exe. And if it is "hack", well then it has done wonders at some games for me, specially those where I suffer with the frametime and where RTSS only made things worse.

 

He just made a comment, you dont have to read it, if you are that bothered then either jog on or give it a try.

 

Anything that subverts the intended functions and I/O of an application is a hack.

FXAA injection is a hack
Gsync, is a hack.

Fullscreen Optimizations is a hack amongst various other hacks.

its nice when it works, but there is various cases where it doesn't work well, or prevents application start entirely.

 

With that logic, modern operating systems are a hack. They prevent programs from running all the time by preemptively suspending the process execution and giving the CPU to another process. So you can run more than just one program at the same time through a hack.

Maybe we should all use MS-DOS.

Why is g-sync a hack though? It doesn't do anything to the game.

 

And i "just" made one, too! You could have saved your comment, its not helping - you saw how many people like/approve my comment?

 

G-Sync is a PHYSICAL technology that cannot be replicated by anyone through software. It's not even a "hack", it's what the name implies, Graphics Sync, it syncs your nVidia GPU with the monitor so the frames the GPU throws don't make the monitor have a metldown. That's not even remotely a hack, in fact, G-Sync is the optimal way to make a GPU work since it literally makes the GPU communicate with the monitor more properly than any normal monitor ever could.

FXAA is the mosy basic AA form and it just blurring edges, no rocket science there or "hacks". You can force it at any game with any GPU, it does not interrupt anything, the GPU simple injects it into the game. A hack would be if you tampered with the game limits or rules; such as getting infinite ammo, auto aim, super speed, etc...

FSO is just something Windows 10 does, so you are saying Windows hacks itself and the programs it runs?

Here is a literal copy/paste of what hacking means:


Hacking
Definition - What does Hacking mean?
Hacking generally refers to unauthorized intrusion into a computer or a network. The person engaged in hacking activities is known as a hacker. This hacker may alter system or security features to accomplish a goal that differs from the original purpose of the system.

 

Gsync subverts the api designed swap interval, its a hack to run it on any windows prior to 10 where variable refresh is natively supported.

FXAA is an injected post process filter, unlike other driver settings it does not just promote an api CAP bit to a specific setting. its a hack.

Windows uses thousands of hacks(via the application compatibility layer) to make applications continue to work.

FSO is just the worst kind since it is applied globally as a default.
Microsoft developers have been misleading about FSO too, as there have been employee's posting that it is based on a white list of tested games (which has never been true)

The old "well my definition says this" nonsense.

Reducing the quality of filtering to gain performance in a benchmark is a "driver hack", so FSO is also a hack, because it subverts the intended behavior and function that the game expects in place of another.

 

It doesn't. With vsync ON, swap interval is the same as before. With vsync OFF, there is no swap interval, again just like before.

Edit:
Windowed mode g-sync is a hack, but DWM is already a hack so that doesn't count

 

It does, its injecting functionality in the swap chain to disconnect the swap interval from the framerate as well as the ability to adjust the panel to the current framerate and smooth out these transisions to achieve as little stutter as possible.

By limitation of design a double buffered swap chain should go from 144fps to 72 when you can't maintain 144 (particulary for pre d3d9ex usage)
Gsync behaves more like triplebuffering (but without the third buffer), there is a software component in the function of gsync on api's not Variable Refresh aware.

If it was all in the gsync module, we wouldn't have so many issues with applications not going into gsync mode correctly.

If you use particular versions (outdated that is) of fullscreen exclusive overlay and injection tools, Gsync can just not work because it doesn't replace the function it needs to, to function - in cases of this, the systems ability to adjust the refresh rate with the framerate also stops working.

It is also because of this that there is a cpu overhead involved in all variable refresh tech that can see reduced fps if you're cpu bottlenecked.

 

Hmm. I thought that this is not how the API works. With synchronous double buffering ("old-school" DX8 and some DX9 applications,) if you can't do the flip before the next vblank, you're forced to wait for the next vblank. With g-sync, the vblank period is extended to make it very unlikely that the application will miss it. The "hack" is at the display timing signal level, not at the application level and thus applications can be blissfully unaware.

So it didn't seem like there's anything injected to the game. And it seems weird that a driver would even need to even inject anything to an application. The driver's code is what is getting called at the end of the day. When a game is doing a flip, it's not actually doing a flip. It just tells the API to do a flip, and the API then in turn tells the driver to do the flip. No need to inject anything, since the driver sits at the bottom of everything. It's the driver that reads and writes buffers at the hardware level.

So what is g-sync injecting to applications? Third-party tools/injectors would do their own hacks that sometimes prevented flipping from happening at all and you'd get blitting instead. With blitting, g-sync doesn't work. (I can actually disable flipping at the driver level on Linux and force blitting, and indeed this prevents g-sync.) If g-sync was actually injecting anything and intercepting the various present()-like calls of the API, it wouldn't have this problem. But it seems that these tools breaking g-sync suggests that g-sync actually isn't intercepting or injecting anything.

Now, the above is what I thought is happening. G-Sync doing any API injection tricks is complete news to me. Where did you find out about this?

 

nvidia does their present handling in an nvapi_thunk function of nvwgf2um (for dx atleast), with gsync on there are additional functions and cpu utilisation goes from 0.13 to 0.70% (Crysis Warhead as example)

 

OK, this doesn't look like a hack to me then. How frame presentation is handled is an implementation detail, not part of the API. The whole point of an API is to shield applications from even knowing how it's implemented.

 

I can second this. At least most DX12 applications i have used demonstrate this.

Basically as long as the application fills the screen, even in borderless mode it will bypass DWM and produce double buffered rendering with a tearing line.

But the difference is that you can alt-tab and the screen doesn't go black (changing video modes/exiting exclusive fullscreen) so that you can quickly switch between other windows.

Any overlay of the screen that isn't part of the application itself will enable DWM.

So when applications code correctly for it (as far as I know it being supported in at least DX12), FO can produce similar swapchain behavior in borderless screen mode as exclusive fullscreen would normally produce.

 

Slow clap for the thread derail.


Also feelings matter. 0.1% and 1% lows are not the same as a variance graph.

The frame limiter needs to be used in full screen and without Vsync. What it does is the age old console trick of trying to sync with the monitor without actually doing a full sync, to keep response times up.

When it is enabled you will notice a small screen tear artifact on (usually) the top of the screen, as there is no Vsync.

And, yes, that means that the driver is actively trying to match the pacing of the render, to the monitor, so higher perceived smoothness might not be imaginary.

This doesn't work with all games and all engines, and it's usually a bad idea to combine it with other frame limiters.