Support : How do you remove jaggys ?

[kuyondo]

This is what it looks like in game. Is it just me?
Texture Filtering: Trilinear
Anisotropy: 16
Resolution: 1360 x 768

[Chris]

Enable anti-aliasing in the launcher (or edit settings.cfg to enable it manually). Seems to be a bit of a crapshoot as to whether it'll work or not though, since anti-aliasing has various restrictions on how the rendering is done and the hardware's capabilities.

[kuyondo]

Enable anti-aliasing in the launcher (or edit settings.cfg to enable it manually). Seems to be a bit of a crapshoot as to whether it'll work or not though, since anti-aliasing has various restrictions on how the rendering is done and the hardware's capabilities.

I didn't even know there was an anti-aliasing option in the launcher! Well, thanks chris, that solves it.
Oh by the way, would it be possible to add the option to change the anti-aliasing value in game? Just like anisotropy..

[scrawl]

Oh by the way, would it be possible to add the option to change the anti-aliasing value in game?

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.

[Chris]

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.

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.

[AnyOldName3]

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.

[scrawl]

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.

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?

Another possible 'hack' is to create an invisible, 1x1 window to hold the graphics context so that the actual game window can be recreated whenever we want.

I'm kind of surprised that with all the recent advances in OpenGL we still don't have easier ways to change AA :/.

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.

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.

[AnyOldName3]

These days, most AAA games use deferred rendering, so MSAA doesn't work. When you're stuck with SMAA or something similar, you don't need to recreate the graphics context, so there's no huge demand for such features from their developers. Simulators and CAD software and the like aren't likely to be run on a huge range of hardware (one company is likely to have a gazillion identical workstations), so tweaking settings at runtime isn't likely to be needed (as the IT guys can do it once and then leave it forever), so there's no demand from their developers.

[Chris]

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.

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).

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?

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.

I'm kind of surprised that with all the recent advances in OpenGL we still don't have easier ways to change AA :/.

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.

[AnyOldName3]

Is gamma correct rendering an issue (disregarding the fact that Morrowind specifically doesn't do it)? I thought it was as simple as enabling GL_FRAMEBUFFER_SRGB and then it magically worked when you emit 32-bit floats from the fragment shader.