Announcement

Collapse
No announcement yet.

Am I the only one ? UT & zbuffer quantization errors

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Am I the only one ? UT & zbuffer quantization errors

    The title says it all, even if the situation got *slightly* better with the new drivers, zbuffer in UT seems still screwed up, even with the zbuffer set to 32 bit.

    Most 'slanted' surfaces show bad quantization errors while moving, and the more far away they are, the worse this is.

    This is especially evident in the CTF map with the two high towers very far away, walking towards one or the other makes their slanted fronts appear & disappear. This is especially sucky when sniping

    Like I said, with the new drivers the situation got a little bit better, but the problem is still present.

    5.41/G400Max/W98SE/PIII
    Tags: None
  • #2
    UT (as well as Unreal) uses a custom direct3d driver. Tim Sweeney seems to beleive many parts of directx are fairly inefficient, so he rewrites things such as texture management in a d3d driver that unreal uses instead of directx's default one. Sometimes these "speed hacks" can cause anomalies on one card, yet the rest seem fine. UT's way of handling direct3d code is going to be somewhat different than a generic game using direct3d. It's something you'll have to live with for now.

    Since the g400 came out, I have always witnessed textures out of place in every version of Unreal/UT with every available driver release. It's pretty obvious that it's a z-buffering error, but it's hard to say if the problem is due to Unreal's engine or g400's drivers. I wont blame either without some hardcore proof. Distant textures are always fighting over each other as to who's in front or in view. Using the registry hacks or g400tweak won't help, the unreal engine has absolute power over most those direct3d switches. It almost looks to me like Unreal's engine doesn't utilize 32-bit zbuffering at all... but then again there's no proof to I can offer. In theory using a 32-bit z-buffer is very precise, at the cost of a little more video ram and performance. Who's the culprit here? Your guess is as good as mine...

    Comment

    • #3
      Have the same problem. Installing the new 4.02 UT patch seemed to make the problem worse.

      PIII550, G400 MAX, 256MB RAM.

      Comment

      • #4
        On the upside, you can see people hiding up top on Facing Worlds, trying to snipe - they appear in front of the walls they're behind. :-)

        Just my $0.02
        The pessimist says: "The glass is half empty."
        The optimist says: "The glass is half full."
        The engineer says: "I put half of my water in a redundant glass."

        Comment

        • #5
          Is this still unresolved?

          I've tried enabling 32-bit textures as well (via the .ini file), but it still seems like the ZBuffer is in 16-bit mode (or the full range of the ZBuffer is not being used correctly).

          Is this a Matrox driver issue, or an UT coding problem? Matrox care to comment ... ?

          UPDATE: Okay, I read the thread "Unreal Tourney Image Clipping" and understand that Matrox are aware of the issue and it's on their "to-do" list.

          [This message has been edited by Lewpy (edited 08 January 2000).]

          Comment

          Previous template Next
          Working...
          X