Gsdx future discussion

[tsunami2311]

guess i alone in thinks brz look really bad in 16bit sprite games. that water painted effect is far worse on those games

[Blyss Sarania]

I'm not against changes that will open better ways to improve the emulator, but removing a feature that's important to many games like AF does not seem like the right move.



It's more obvious in full screen:

http://i.imgur.com/CyLLeXX.webm

Notice that this is slowed to 30-fps compressed footage, it's actually looks worse than that, try it. This is not a minor difference by any means.

I don't know why people here say AF is useful only in a limited number of games, it's not. Any game with far or even a mid-range visible distance will be affected by it.

If AF really can't be done efficiently with this new method, maybe limit this method to the games that need it or look better with it than the old one?


I like it a lot with most 16-bit and before games, and many games in 32-bit era.

It's still a VERY minor effect compared to the normal difference between AF and no AF in something like a PC game. It basically only reduces shimmering in PCSX2. Whereas in normal cases it drastically improves the quality of textures that are at oblique angles to the camera.

I don't like the idea of removing it either, but there seems to be a lot to gain here.

[rama]

I guess the AF option doesn't work quite right currently because it's missing some data (was it mipmaps?)
A software re-implementation could probably do it better.

[gregory]

Technically AF is a kind of mipmap but not square. However I dunno if the hardware unit need some pre-calculated mipmap to do the job correctly. Actually maybe "basic" mipmap would be enough. Maybe you can check the SW rendering with mipmap enabled.

As a side note, I think PC got better texture. In this scene, the grass texture is 256x256 (quite big for the PS2). And upscaling reduces mipmap requirement.

Here the texture    

[gregory]

Forget to say: honestly I don't know, maybe AF will still be possible with extra computation. Even if it is possible, it would be a very low priority.

[Blyss Sarania]

How'd you dump that texture?

[wareya]

Mipmapping comes into play when a texture starts scaling down past one texel per screen pixel. The mipmaps are just lowpassed versions of the texture, and they have no high frequency data so they can be downscaled. It just so happens that cutting a texture's resolution in half is an efficient gauge.

Where AF comes into play is, when a texture's aspect ratio is changed when it hits screenspace, the renderer has to make a choice between picking a mipmap that's good for the squished direction and a mipmap that's good for the stretched direction. You either get serious blur or flickering, both bad things.

AF method is traditionally decided in driver, where you upload a texture and ask it to do AF with it, and it should oblige, or something along those lines.

Something people commonly point to to explain AF is RIP mapping (rectangular mip mapping) (but AF is not always implemented this way). For example, looking at a RIP mapped texture at a 45 degree angle will always give the non-AF result. The other related method is SAT, as in http://web.cse.ohio-state.edu/~hwshen/78...iasing.pdf , which is like "RIP mapping at runtime in constant time", and they specifically say it still has the diagonal problem.

There's also Elliptical Weighted Average sampling, which is a tilt-correct runtime texel lowpass. In actual graphics code, for performance reasons, you would have to implement it on top of mipmapping and with constraints on how many samples it can pull (much like limiting RIP maps to 2:1 to reduce memory usage). Even if you only pull two samples, the result is still going to be a lot better than pulling one sample (pure mipmapping). For a pathological example implementation, see: http://www.pmavridis.com/ewa.html

[gregory]

How'd you dump that texture?

A wizard without trick is a poor man

You can dump everything (shader, texture, vertex model) with a GPU debugger. All textures can be dumped with GSdx built-in debug mechanism.

@wareya thanks for the info.

[BlackTelomeres]

Wasn't there just a github discussion in February that concluded there was no real reason to remove the DX9 renderer? What is the advantage of removing it?

[gregory]

Yes I know. But you see it in the wrong way. The main goal is to drop support of unsupported-by-vendor openGL drivers. I puts several alternate paths and emulation layers for them. The current situation is
1/ GL is better than DX because of latest feature which aren't supported on old drivers.
2/ AMD is dropping support of catalyst for linux.

New code will rely more and more on "new" features. So the idea was to create a legacy GSdx for openGL. So why not put DX9 in the same boat. Xp supports will be completely dropped very soon.