Texture Filtering: Trilinear
Anisotropy: 16
Resolution: 1360 x 768
![Image](http://i64.tinypic.com/20u8zcx.jpg)
![Image](http://i65.tinypic.com/6zydn5.jpg)
I didn't even know there was an anti-aliasing option in the launcher! Well, thanks chris, that solves it.
To change anti-aliasing at runtime, the window has to be recreated (and all the OpenGL resources with it). Then we'd have to go over the scene graph and any caches to make sure the associated OpenGL objects were cleared. It's certainly possible, just a bit of work.Oh by the way, would it be possible to add the option to change the anti-aliasing value in game?
In theory we could render to an offscreen renderbuffer (which is blitted/resolved to a non-anti-aliased backbuffer and swapped for display). Renderbuffers can be individually anti-aliased, so changing anti-aliasing should just need changing the renderbuffer.
We could, it will just be slightly slower, similar to how running a compositing window manager vs. a non-compositing one (or one that disables itself in full-screen) can affect gaming performance.In theory we could render to an offscreen renderbuffer (which is blitted/resolved to a non-anti-aliased backbuffer and swapped for display). Renderbuffers can be individually anti-aliased, so changing anti-aliasing should just need changing the renderbuffer.
If a restart is required then I suppose I don't see the point of adding the option ingame when it's already in the launcher.Lots of AAA games still require a restart after changing things like AA, so it's not unreasonable to just display a popup saying that some changes will only come into effect after the next restart, then offer the option to do it immediately or let the user handle it themselves.
We'll need to render offscreen anyway for post-process effects. Render to an offscreen surface, then render that surface to another surface with the appropriate pixel shader or OpenCL program. The window-provided backbuffer also can't deal with floating-point render targets which will be necessary for various things (such as gamma-correct rendering and various tone-mapping effects, where 8 bits per color aren't enough).scrawl wrote: ↑16 Oct 2017, 00:01We could, it will just be slightly slower, similar to how running a compositing window manager vs. a non-compositing one (or one that disables itself in full-screen) can affect gaming performance.In theory we could render to an offscreen renderbuffer (which is blitted/resolved to a non-anti-aliased backbuffer and swapped for display). Renderbuffers can be individually anti-aliased, so changing anti-aliasing should just need changing the renderbuffer.
If the window and GL context supports some level of AA, I don't see why an FBO with an AA renderbuffer wouldn't also support it. If anything, FBOs with an AA renderbuffer may allow the driver to do more since it doesn't have to rely on the windowing system's knowledge of AA on backbuiffers.Does support for anti-aliased windows always mean that framebuffers can be anti-aliased to the same level, or could there be a system that supports one but not the other?
From my perspective, I don't understand how it seems to be so difficult still. With modern rendering you're rendering offscreen anyway since you're going to be doing post-processes and greater color depths, so changing AA just means allocating and using a new renderbuffer object with the desired AA level. It should be doable near-seamlessly.I'm kind of surprised that with all the recent advances in OpenGL we still don't have easier ways to change AA :/.