That is not what Croteam says. . .
Where did they say that? You do know there is a rather large difference between the engine used in SS:FE and SS:SE. From my understanding it does use the static T&L features of video cards.
That is not what Croteam says. . .
madshi said:That should be Delphi, my favorite language.
Theres also a difference from enabling or disabling T&L when running in DirectX.
Pascal is a good language, and in the past I have used some interesting improved versions with support for very large programs (compiler dependent) runing in large mainframes.ChrisK said:madshi said:That should be Delphi, my favorite language.
Are Delphi and Pascal considered to be different languages? I always thought of Delphi as a (convenient) Pascal IDE. It's been a long time since I've last touched anything related to Pascal, though
The difference, however, would rest of the developer/programmer. A programmer can choose to use their own T&L engine instead of the default APIs', in which case, it would depend on the developer/programmer to specify if it is to be accelerated in hardware or by the CPU. For an app/game that has both APIs as rendering options, it will entirely depend on what the developer wants.DaveBaumann said:Given the similarity between the DX7 T&L pipe and the standard OpenGL pipeline my impression would be that if the DX Hardware T&L pipe is used (which it is) so too would the OpenGL Transformation pipeline and hence if that is used it would automatically be accelerated by hardware with hardware geometry abilities.
Well, Croteam doesn't feel the need to say it... that's the difference. Croteam doesn't mess with OpenGL's built-in availability of hardware T&L. Hence, SS is a "T&L game" without Croteam needing to say it.noko said:
Reverend said:The difference, however, would rest of the developer/programmer. A programmer can choose to use their own T&L engine instead of the default APIs', in which case, it would depend on the developer/programmer to specify if it is to be accelerated in hardware or by the CPU. For an app/game that has both APIs as rendering options, it will entirely depend on what the developer wants.
That's obviously because 0xAF forces point sampling.BoardBonobo said:Has anybody noticed that with the new dets, default settings, the water in the nature test and also the pixel shader test has a distinct blockiness to it? This dissapears if you either set the Ansio to 1x and above or check texture sharpening in the FSAA section. You don't need to enable FSAA.
Xmas said:That's obviously because 0xAF forces point sampling.BoardBonobo said:Has anybody noticed that with the new dets, default settings, the water in the nature test and also the pixel shader test has a distinct blockiness to it? This dissapears if you either set the Ansio to 1x and above or check texture sharpening in the FSAA section. You don't need to enable FSAA.
Is [0xAF] the driver default setting ??
Doomtrooper said:Xmas said:That's obviously because 0xAF forces point sampling.BoardBonobo said:Has anybody noticed that with the new dets, default settings, the water in the nature test and also the pixel shader test has a distinct blockiness to it? This dissapears if you either set the Ansio to 1x and above or check texture sharpening in the FSAA section. You don't need to enable FSAA.
Is this the driver default setting ??
1. First off all: Looks like 4X aniso is the same as 8X in the drivers (therefor the pictures from UT2003 I posted earlier).
Galilee said:To sum it up. As jb said: Looks like they did some nice things with the Pixel Shaders, but other than that these drivers are mediocre.