FSAA in 2D games? How could it be possible?

[Kreshna Aryaguna Nurzaman]

Well I stumbled upon this article, and pretty much surprised with what I read.

The article says that enabling V5 FSAA in StarCraft slightly smoothes the sprites. Also, using V5 FSAA in Diablo II really smoothes the terrain.

Well, both of them are 2D games. Granted Diablo II uses direct3D, but IIRC it is only for lightning effects. The rest of the game is 2D.

On the other hand, I thought Voodoo5 multisample FSAA method can only work in 3D, because it renders multiple samples of the same frame while slightly 'rotating' the geometry (RGSS). So since it needs geometry data, I guess it only works in 3D.

Or maybe I was wrong? Maybe, in 'rotating' the frame, the Voodoo5 MSAA doesn't use geometry data, but only the pixels?

[ps47]

well starcraft is a 2d game and FSAA doesnt work in 2d,so that info is probably wrong.as for diablo2,the game is 2d,but it runs under glide,that means its using the cards 3d to display 2d.in this case,FSAA will work (tested myself).the game itself looks very good,but the inventory is really blurred..

[Kreshna Aryaguna Nurzaman]

Nevertheless, I wonder whether Voodoo5 multisample FSAA really needs geometry data to take multiple samples of the image? In order to produce slightly different samples, does the Voodoo5 only offset (jitter) the "pixel matrix" of the given frame, or it also jitter the polygon as well?

My impression is that jittering the polygons is necessary in other t-buffer effects like motion blur, because it takes multiple samples of a specific 3D object. But in FSAA, it takes the entire frame. So is it necessary to jitter the polygons as well?

[bloodworm]

My understanding at the time was that the V5 FSAA was designed for ALL applications and especially DOS games which are 2d....... I think it says so right on the box!  blurry text was an after effect of the FSAA because of the way it "blurred" the whole screen to hide jaggies.  messing with the LOD numbers helped with the text.

[Dr.Yak]

The internal mechanics of the 3DFX in FSAA mode :

* each chip can render up to 2 frames independently.
* Whenever the game sends polygon data to the 3DFX, each chip renders the polygon slighly offset in its own frame buffer. To the game eveyrthing looks like a standart 3D card, when in fact it's like 4 card working in parallel to create FSAA 4x.
* Whenever something try to read from the frame buffer (either by the game, or by the RAMDAC to display, or even by the chips themselves to do transparent textures) the corresponding pixel is read in each frame buffer from each chip and the result are mixed on-the-fly to provide a single pixel. To the game software, it looks like the card has 1 standart buffer.
* Whenever something is written to the frame buffer (game writing directly on frame buffer to display something without using the 3D engine) the same pixel is written to each frame on each chip. You don't get any AA, but at least it doesn't ****s up the frame buffers.

FSAA in 2D games : eveyrthing depends on how the data is written on screen.

* 2D games that write directly to the screen (like most old DOS games and a few windows games and also the Windows GUI itself) : no FSAA. In fact they don't even initialise the hardware into FSAA mode.
* 3D games using hardware acceleration (DOS games using Glide#x.OVL, Linux & Windows games using OpenGL or DirectX) : FSAA on per-polygon basis.
* 2D games that uses hardware acceleration to draw sprites on screen (GTA 1 and 2 come to mind. They use Glide/OpenGL/DirectX and represent sprites as flat polygons) : FSAA on per-polygon (aka per-sprite) basis.
* Emulators of 2D consoles (like MAME) or video players (like VLC) that use hardware acceleration to update and scale-up screen : if an FSAA enabled API like Glide/OpenGL/DirectX-3D is used the VSA-100 tries to apply FSAA on the single huge polygon that makes up the display. FSAA is on but actually makes the picture worse (blury). Either disable FSAA, or stick to other APIs : DirectDraw/SDL/XVideo/Xshm

I haven't experimented with StarCraft and I don't have Diablo.
But GTA 1 is a nice exemple of an (almost) 2D games where the sprites (cars, by standers, etc.) are considered as polygons and benefits from FSAA & a correct LOD Bias (less jaggy when rotating).

"Designed for DOS Games" : Only those that use Glide#x.ovl to display. For them everything is just automagically handled by Glide and everything seem to work as if there wasn't any FSAA involved. (Compare this to the FSAA in GeForce 2 where the single frame buffer was constantly scaled up and down, and sometime when directly writing to frame buffer, the wrong pixel could be writen).
DOS games that either try to control Voodoo hardware directly (and mostly fail, because they were disgned with Voodoo 1 hardware in mind) or don't use any hardware acceleration don't benefit at all from FSAA, for them your 3D works like a plain SVGA/VESA card.

(Reply based on 3DFx documentation and personnal experience tweaking my V5.)