🚀 go-pugleaf

Daniel,

To clear some things up.

> >
> >Of course it does..... how do you think the information gets to the
> >GeForce....
>
>
> No it doesn't. Do you know what transform and lighting are? Mathmatical
> computations, that's what.
> Now the geforce on board chip can do it which is designed to, or the CPU
can
> through software instructions, and
> that is what UT does. Sweeny even said he would not use in place openGL
> calls for these because
> they were not effecient enough and he would hand code the routines [CPU].
> Why I can't figure out, since
> their OpenGL sucks so much it makes a crack hoar look like an amatuer with
> his highly optimized routines, but...
> Actualyl I can, but we all know about Sweeny's loyalty to 3dfx so we don't
> need to go there. Mysteriously diamond
> provides metal for UT which out performs the 3dfx cards and the latest UT
> patch breaks it. Hmmm.......

No point arguing here.... u clearly didnt understand my post.

>
> >You need to feed it.... forget all the _crap_ about 'frees up cpu time'.
> >Your cpu is feeding the GeForce, and _currently_ no CPU can feed it fast
> >enough to reach the Transform limits of the GeForce so it just gets
faster
> &
> >faster.
>
> No, your bus is feeding the geforce, your CPU is doing computations and
gate
> operations.

Ohhh, so since our bus speeds are going to stay the same then there is no
point upgrading.....
Clearly u are stating that a faster CPU will provide no additional benefit
here.... hmmm

>
> >No, its not a con. The GeForce does the T&L much faster than _any_ CPU.
>
> To date.
>
> >Yes. There are many ways around the CPU, but that just speeds up the
> >transfer and leaves the CPU idle....
>
> Umm, no it leaves the CPU to do other computations like AI, sound,
network,
> etc...
>

Okay, i didnt give the full story. Yes, u can do useful things once you have
a bundle of data prepared for the card, but not all software can benefit
from this. Not all the T&L acceleration facilities can be uncoupled from CPU
intervention. The majority of software will though.

>
> The reason UT runs so bad is it was designed around the Glide API, which
is
> almost nothing like
> the D3D API, thus optimizing the interface is virtually impossible. the
> engine sets up info the way
> glide likes it, than  moves it all around so D3D can use it. Its a 3dfx
> game, like it or not, and it always will be
> unless somone codes a Glide API driver [not a wrapper] for the other cards
> which would require the
> company, in this case riva, releasing technical information about thier
> chipsets to the public or thier programers
> adding the support to the drivers which they have already stated they will
> not do.
>

I wouldnt know about the glide interface, but given the trouble all other
software developers have had converting glide to D3D/OpenGL I dont think u
can blame EPIC too much. I am happy with the OpenGL performance of the UT
engine.

>
> The D3D driver for UT has been public src's by EPIC in hopes someone else
> will fix their problem for them, but
> I wouldn't bet on it....
>

I remember Matrox patching Unreal, they are not good candidates now ?