Discussione about unused old chips features
- Thread starter Simon82
- Start date
No chip other than r200 supported truform - not the r200 derivatives (rv250 etc.) nor the next generation (r300). Some cards with other chips (can't remember which ones exactly, could be dependent on driver version too) had software emulation of this feature however.
It wasn't that the developers wouldn't use it, it was more a problem that no standard API's exposed it, which was in tern because it it could only be done sensibly on our hardware
Unused/virtually unused features on Kyro/PowerVr Series3 - 8 layer multi-texture support and EMBM, teh later inparticular as you coudl do some pretty cool stuff with it...
John.
No, it was exposed in D3D but apparently some developers didn't even believe it was possible.It wasn't that the developers wouldn't use it, it was more a problem that no standard API's exposed it, which was in tern because it it could only be done sensibly on our hardware
The internal 24bit of the 3dfx pre-V5 cards was never understood in my opinion. Effectly I've never seen any differences changing the famous option on the control panel to enable that sort of smooth palette.
Just like another never-seen feature, the first anti aliasing the theorically even the Voodoo1/2 was capable of on the corner of the polygons (?).
There are two options. Postfiltering:
24 bit rendering -> dithering -> 16 bit frame-buffer -> RAMDAC postfilter -> 22bit effective output
there were 2 postfiltering kernels (4x1 and 2x2... the later was supported by V3 and newer and didn't cause line-artifacts).
The other possibility was 24bit display output (supported on V2, not sure about other voodoos). This feature worked only for lower resolutions (1024x768 @SLI + 24bit caused color artifacts). The difference was clearly visible on display, but not on screenshots. I have one example, but jpeg compressin is a bit high.
Standard:
24bit output:
you can see, that the vertical color banding disappeared...
24 bit rendering -> dithering -> 16 bit frame-buffer -> RAMDAC postfilter -> 22bit effective output
there were 2 postfiltering kernels (4x1 and 2x2... the later was supported by V3 and newer and didn't cause line-artifacts).
The other possibility was 24bit display output (supported on V2, not sure about other voodoos). This feature worked only for lower resolutions (1024x768 @SLI + 24bit caused color artifacts). The difference was clearly visible on display, but not on screenshots. I have one example, but jpeg compressin is a bit high.
Standard:
24bit output:
you can see, that the vertical color banding disappeared...
That was hardly "never seen" - it was available on a lot of early Glide games. It worked (for example) on the DOS Glide version of Tombraider (and looked absolutely superb).
It worked by drawing a 50% translucent line round the edge of each triangle. It therefore didn't do anything for texture aliasing, but it worked beautifully for crawlies along polygon edges.
Handheld camera I would guess.
But was it supported only by Glide games? And developers would support the effect inside the code?
Megadrive1988
Veteran
PowerVR PMX or PMX1 / PowerVR 250 used on the Neon250 cards? Is that what you couldn't remember Simon ?
But I'd imagine that it was used in Dreamcast/NAOMI and NAOMI 2 games since those were closed platforms.
When you said very few developers made use of that, do you mean on the PC side ?
Anyway, if I recall correctly, the PC PMX1 / PowerVR250 in Neon 250 was delayed about a year, was clocked higher @ 125 MHz than the PowerVR2DC (CLX2) which was 100 MHz, but CLX2 was still more powerful because it had more pixel elements in its ISP, or something like that ( CLX2: 32x32 tiles vs 32x16 tiles in PMX1), and maybe a few other rendering features that CLX2 had that PMX1 did not.
IIRC the CLX2 was the 3D-only implementation of PowerVR2 for consoles & arcades, while PMX1 / PowerVR250 was the released implementation of the Highlander project that included a slightly less powerful 3D engine combined with 2D & audio for PC.
Last edited by a moderator:
I certainly assume so. I'm wouldn't even know if Sega's API allowed you to turn it off
Yes.
No, it was exposed in D3D but apparently some developers didn't even believe it was possible.
The special DC version of D3D added a state to control it but this never got adopted on the desktop because no one else could do it. I remember at the time a lot of devs where keen to use it but given that they would still need to support all other hardware its benifits where constrained.
John.
Blazkowicz
Legend
it depends on countries : in germany it censors svatiskas, in the US it censors breasts, in communist countries it allows red blending (replacing alpha blending).
lmao, thank you, I needed the laugh today.
Murakami
Regular
I saw it: Quake 3 smoke had less banding.
yet, nVidia users had to wait longest. Matrox supported EMBM from G400. nVidia followed not until three generations later. (something to do with the fact that all the others bought license to do it from Bitboys?)
anyways, still no one has mentioned the Parhelias technologially most impressive feature: Displacement Maps with Mipmap LOD support. Only tech demo used it, while it was part of the DX9 feature set and it was really impressive. Basically only card before Parhelia capable doing that was Pyramid3D. (it would been quite slow in it most likely, but still capable as it's vertex engine supported data reads from anywhere in memory space.) Most of the Parhelia's Disp. Mapping glance took Carmack's angry missinformed comment it being quad only, which he corrected after that, but it was too late, not many read that correction.
During that time, Carmacks word had huge effect as Doom 3 was coming as being biggest game ever. Was it really? and does anyone give a sh*t what John says nowadays? Not that much at least as it used to be I think...
However, I think it's gonna be while before we see it again in use. (I rad somewhere that D3D 11 will have more powerful tools to do it via tesselator interface...)
Similar threads
