Fifteen

Oh, right, supersampling and hardware multisampling are actually different approaches, that makes sense! I really like the way you're splitting up the various families. MSAA working with defertred rendering, though? I'm clueless as to how it would work.

Well, you can't arbitrarily sample parts of your scene and then blend the results together with deferred rendering because they're stored in a normal framebuffers that are composited together later on. Any of the fancier sampling patterns can only be used on single buffers at a time (Color, Depth+Stencil, etc.), but you'll have lost that information by the time it gets mixed with the others. From what I've read, that makes MSAA and CSAA almost impossible to pull off, which might be why Nvidia pulled the plug on CSAA with their Maxwell and Pascal architectures, why Temporal AA and Post-proc AA have been getting more and more attention as of recent years and why downsampling is making comeback lately even though it's technically inferior to proper spatial antialiasing.

I've done some more research, and now I'm pretty much convinced that we need to split AA methods by family since none of the proper supersampling methods work on engines that rely on deferred shading, which is no small detail and should definitely be brought up in the article.

I'd rather he have 2 or 3 pages, one per "family" of AA methods, and have pages like "MSAA" or "FXAA" redirect to anchors on those pages. Like I said before, the differences between each family is generally minimal, meaning we can have more general explainations that apply to the family as a whole, then maybe add a few distinctions for each one of them, like vendor exclusivity, sample positionning, relative performance cost, etc. Might be worth experimenting with info-boxes too, I get a feeling those could be well-suited to hold that kind of information in a concise manner. EDIT : Also, if we're going to use sample images to show the difference between each AA method, it should probably be animated, otherwise we can't demonstrate Temporal AA methods, and aliasing tends to become noticeable on moving objects anyway.

You're right, though, that kind of wording would imply that the game has distinct "keyboard mode" and "controller mode" under the hood, which is not only beyond what the end user can or should know, it's also not the case for all games, which only treat it as an additionnal input method, so "switching" is hardly the best way to put it. Really, all we need to convey is that using a controller doesn't disable the mouse and/or keyboard like it would in, say, Fallout 3/NV/4 or Skyrim and word it so "yes" is a positive awnser to that. "Non-exclusive controller input", perhaps?

The thing is that on the surface, most methods don't differ that much relative to each other aside from the general idea behind it (CSAA and EQAA are literally the exact same thing). If you make a page on each of those AA methods, you won't really have much to say beside stuff copy-parted from other articles about AA methods. What we *could* do, however, is split this article into 3 separate one, to highlight the fact that Supersampling AA, Temporal AA and Post-Processing AA are utlimately unrelated to each other and can actually be used simultaneously.

I'll always defend more hierarchised models, but I see where you're coming from. I'll probably try forking this article on my own personnal page over the next few days to see if I can get some sort of a preview going, to better show how I envision that article.

I get that, but how is the average user supposed to figure out which one is better if the article skims over giving a brief explaination on what makes every method different? For all your average wiki-goer knows, the difference between all of these is the combination of letters before the "AA" part and that some of them only work on Nvidia cards. If you split them into families like that, you can say "Oh, EQAA a Cover-buffer samplig AA method, so it doesn't render everything at double the resolution but it at least checks for the edges of objects and uses that to blend those boundaries where it can. Now I know it's going to be far less taxing than MSAA. Thank you, PCGW!" At the very least, you need to start explaining somewhere.

The whole list feels a bit cluttered to me, it could probably use some more hierarchy. Grouping those various methods by family would allow us to have broader descriptions for each of those families, whereas individual methods would only need to be compared to each other. Here's what I mean : The article could then focus on comparing each one of those in a more meaningful manner instead of aimlessly trying to name every algorythm under the sun and leaving it at that. What would you guys think?

Now that you mention it, I think "Dynamic input selection/switching" is most fitting, since that's what most games actually do. In Bioshock Infinite, for instance, the game appears to technically have distinct keyboard-controller modes, but can receive input from both methods simultaneously (even though that messes with the prompts, as you just mentionned). No, native bindings are precisely there so the steam controller doesn't have to emulate other input methods, and instead just communicate with steam controller-specific hooks in order to trigger in-game actions. While XCOM 2's interface still relies on mouse-control, actual mouse control is kept separate from scrolling, which can be done either via edge-scroll or by binding scrolling to the left trackpad. The game switches action sets on its own, with 3 different sets of actions and mappings depending on whether you're in the menus, on the strategic mac or on the tactical map and you don'T need to configure any of the keyboard and controller bindings in game for any of this to work, just like on other games with native support. What you're describing here is native controller support, which is a valid thing to look for when judging a game, but ultimately unrelated to the SC (or at least, not exclusively).

I was thinking aboout adding an "exclusive" state to the controller support propriety, but considering it's supposed to be about the state of controller support rather than the extent of it, a new propriety might be in order. How about "Hybrid controller support" or something similar? EDIT : Come to think about it, there are a few proprieties related to Steam Controller compatibility that might be worth adding, like Native Steam controller bindings (The way XCOM2 and TF2 currently do it).