Discussione about unused old chips features

in the x1000 series ati cards (think i got the right series) was trueform removed alltogether or just removed from the hardware and done in the driver ?

ps: cant the r600 tessellator accept and execute trufrom commands ?
 
in the x1000 series ati cards (think i got the right series) was trueform removed alltogether or just removed from the hardware and done in the driver ?
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.
 
I was referring to CLX2 (DC) and the later PMX<can't remember the number> for the (PC). The trans sort feature was dropped from later PC chips because very few developers ever made use of it <shrug>.

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.
 
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 :(
No, it was exposed in D3D but apparently some developers didn't even believe it was possible.:???:
 
I recall a Matrox EMBM demo with fairies flying around on meadow which refused to run on my GF3 ( IIRC ) because it did vendorstring check at startup. a couple of bytes of patching later it ran fine, although menu fonts were weird.
 
PowerVR and Matrox suported internal 32bit rendering. 3Dfx suported internal 24bit rendering and only nVidia and ATi used 16bit... But later GPUs (R300-R580) used 32bit anytime MSAA was enabled.

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:

sstv2_video_24bpp0.jpg



24bit output:

sstv2_video_24bpp1.jpg


you can see, that the vertical color banding disappeared...
 
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 (?).
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.
 
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.

But was it supported only by Glide games? And developers would support the effect inside the code?
 
I was referring to CLX2 (DC) and the later PMX<can't remember the number> for the (PC).

PowerVR PMX or PMX1 / PowerVR 250 used on the Neon250 cards? Is that what you couldn't remember Simon ?

The trans sort feature was dropped from later PC chips because very few developers ever made use of it <shrug>.

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:
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.
 
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).
 
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.
I saw it: Quake 3 smoke had less banding.
 
I recall a Matrox EMBM demo with fairies flying around on meadow which refused to run on my GF3 ( IIRC ) because it did vendorstring check at startup. a couple of bytes of patching later it ran fine, although menu fonts were weird.

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