Re: [patch] [Mesa demos] Make animation speeds constant

On Thu, Dec 30, 2004 at 04:11:36PM -0600, Marcelo E. Magallon wrote:

 >  I had to fix some of the magic numbers, many of them where obviously
 >  tuned to "look right" on slow hardware.  I just assumed all these
 >  programs once worked ok with an Indy or something like that
 >  (something with sync-to-vblank) and therefore ran at 60 Hz or some
 >  submultiple.

 And here's the same patch for the redbook examples and the X demos.

 I was somewhat put off about touching the redbook examples, since the
 code matches what's in the book.  I consider the code to be broken;
 some of the code is obviously written with a SGI from the early 90's in
 front of you.  Most of it is frame-based, meaning weird computations
 are performed on a frame by frame basis and a couple are hard to fix
 without rewriting some significant (even if small) part of it.  I took
 the most conservative approach, which is to put a brake on the number
 of times the screen in updated per second.  I'd would have gladly taken
 a more correct approach (one that doesn't hog the CPU for example), but
 then there's portability.  How do you usleep(3) portably?

 If the patch is applied, will it find its way to X.org?

 Happy 2005 

 Marcelo

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.

Re: [patch] [Mesa demos] Make animation speeds constant

On Fri, Dec 31, 2004 at 06:07:44PM -0600, Marcelo E. Magallon wrote:

 >  And here's the same patch for the redbook examples and the X demos.

 Here's the patch...

 This is the last time I do this this year, I promise.

 

 Marcelo

diff -x demos -ru Mesa-6.2.1/progs/redbook/alpha3D.c mesademos-6.2.1/progs/redbook/alpha3D.c
--- Mesa-6.2.1/progs/redbook/alpha3D.c	1999-08-18 18:55:40.000000000 -0600
+++ mesademos-6.2.1/progs/redbook/alpha3D.c	2004-12-30 19:59:57.000000000 -0600
 <at>  <at>  -49,7 +49,7  <at>  <at> 

 #define MAXZ 8.0
 #define MINZ -8.0
-#define ZINC 0.4
+#define ZINC .4

 static float solidZ = MAXZ;
 static float transparentZ = MINZ;
 <at>  <at>  -128,13 +128,27  <at>  <at> 
    glLoadIdentity();
 }

+double gettime()

Re: Dramatic improvement of depth buffer quality

Felix Kühling wrote:
> Hi,
> 
> I want to share an idea that I had, which drastically improves the depth
> buffer quality on Savage4 hardware. Maybe the same can be applied to
> different hardware too.
> 
> Short version: reverse the depth range (z' = 1 - z) such that far
> coordinates map to z'=0 and near coordinates to z'=1. Then use a
> floating point format to store depth values in the depth buffer. Of
> course the hardware needs to support a floating point depth buffer.

I'm a bit sceptical that this really improves depth buffer quality in 
general. With D3D it is (if the hw supports it) possible to use a w 
buffer instead of a z buffer, which has the same precision for far and 
near objects. However, the loss of precision for near objects was often 
considered unacceptable. (Radeon R100 and R200 support this, but R300 
and up no longer do, or at least the driver doesn't expose it, so it 
looks like it wasn't that useful after all, and not many applications 
afaik requested w buffers).

Roland

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
--

Re: Dramatic improvement of depth buffer quality

Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00:
> Felix Kühling wrote:
> > Hi,
> > 
> > I want to share an idea that I had, which drastically improves the depth
> > buffer quality on Savage4 hardware. Maybe the same can be applied to
> > different hardware too.
> > 
> > Short version: reverse the depth range (z' = 1 - z) such that far
> > coordinates map to z'=0 and near coordinates to z'=1. Then use a
> > floating point format to store depth values in the depth buffer. Of
> > course the hardware needs to support a floating point depth buffer.
> 
> I'm a bit sceptical that this really improves depth buffer quality in 
> general. With D3D it is (if the hw supports it) possible to use a w 
> buffer instead of a z buffer, which has the same precision for far and 
> near objects. However, the loss of precision for near objects was often 
> considered unacceptable. (Radeon R100 and R200 support this, but R300 
> and up no longer do, or at least the driver doesn't expose it, so it 
> looks like it wasn't that useful after all, and not many applications 
> afaik requested w buffers).

The Savage hardware can handle W buffers too. In fact I experimented
with that and the quality looks good. But it doesn't work under all
circumstances. If the viewing transformation is changed in the middle of
rendering a frame, the meaning of W changes and depth ordering is messed
up.

As to loss of accuracy with near objects, I havn't seen any such
problems yet with the applications I tested. OTOH, the improved quality

Assertion failure in Mesa 6.2.1

Hi all,

Why trying to debug a game that works fine in Windows but that fails to
display the 'scenery texture' in Wine, I ran it with a MESA_DEBUG enabled
version of Mesa (great tool BTW to find problems, it helped me a lot in my
D3D developments).

This showed me to some glTexImage2D problems in (it seems) the application
itself (I will need to investigate further to see what the really problem
is).

The real reason of this mail is that once the game really starts, I get
this:

swrast/s_texture.c:848: sample_2d_linear: Assertion (a * (1.0F-b) * 65536.0F) >= 0.0F' failed.

So is it allowed for a (maybe) buggy application to trigger an assertion in
Mesa or could this be a Mesa bug ? How can I proceed further (knowing that
with the speed of my box and the problem of debugging when running in Wine,
I would like to prevent doing 36 runs to pin-point the issue  ) ?

FYI, the last call before the crash is a 'glDrawElements' call (which is
maybe not very helpful). If needed, I have a trace with all functions called
with their parameters but alas not a dump of content of pointers.

Thanks,
        Lionel

--

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: Dramatic improvement of depth buffer quality

> The Savage hardware can handle W buffers too. In fact I experimented
> with that and the quality looks good. But it doesn't work under all
> circumstances. If the viewing transformation is changed in the middle of
> rendering a frame, the meaning of W changes and depth ordering is messed
> up.
> 
> As to loss of accuracy with near objects, I havn't seen any such
> problems yet with the applications I tested. OTOH, the improved quality
> of far objects is very noticeable for instance in FlightGear and TORCS.
> As Vladimir pointed out, it might be a problem for CAD applications
> though. Making float depth a configuration option would be a good idea.
> And I will have to support both in the driver anyway, since
> Savage3D-based hardware doesn't support floating point depth buffers.

Are this changes already on savage snapshots?

Thanks in advance,

    Albert.

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
--

Re: Re: Dramatic improvement of depth buffer quality

On Sat, Jan 01, 2005 at 10:21:24PM +0100, Felix Kühling wrote:

 > As to loss of accuracy with near objects, I havn't seen any such
 > problems yet with the applications I tested. OTOH, the improved
 > quality of far objects is very noticeable for instance in FlightGear
 > and TORCS.

 Off the top of my head, you might want to take a look at armagetron, it
 tends to have z-fighting problems with some hardware/low resolution
 z-buffers.

 Marcelo

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Dramatic improvement of depth buffer quality

Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00:
> Felix Kühling wrote:
[snip]
> I'm a bit sceptical that this really improves depth buffer quality in 
> general. With D3D it is (if the hw supports it) possible to use a w 
> buffer instead of a z buffer, which has the same precision for far and 
> near objects. However, the loss of precision for near objects was often 
> considered unacceptable. (Radeon R100 and R200 support this, but R300 
> and up no longer do, or at least the driver doesn't expose it, so it 
> looks like it wasn't that useful after all, and not many applications 
> afaik requested w buffers).

[... following up to my other reply ...]

Another problem with W buffers is that linear depth interpolation
doesn't give the correct results with intersecting surfaces. This is
only achieved by the perspective division which is not applied to W (in
fact the perspective division divides x, y and z by W). This makes
W-buffers unsuitable for OpenGL. But this is not what I am proposing,
just in case I was misunderstood. Reversing the depth range and using
floating point numbers just changes the encoding of depth values in the
depth buffer, it does not change the semantics, like a W-buffer would
do.

> 
> Roland
--

-- 
| Felix Kühling <fxkuehl <at> gmx.de>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |

Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

Am 24.12.2004 04:04:14 schrieb(en) Adam Jackson:
> CVSROOT:	/cvs/mesa
> Module name:	Mesa
> Repository:	Mesa/src/mesa/drivers/dri/trident/
> Changes by:	ajax <at> gabe.	04/12/23 19:04:14
> 
> Log message:
>   Get trident building and -Werror clean.
>

unfortunately it doesnt build with
make linux-dri-x86

have a look at attached patch.

best regards,
Andreas Stenglein

Re: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

On Saturday 01 January 2005 22:12, Andreas Stenglein wrote:
> Am 24.12.2004 04:04:14 schrieb(en) Adam Jackson:
> > CVSROOT: /cvs/mesa
> > Module name: Mesa
> > Repository: Mesa/src/mesa/drivers/dri/trident/
> > Changes by: ajax <at> gabe. 04/12/23 19:04:14
> >
> > Log message:
> >   Get trident building and -Werror clean.
>
> unfortunately it doesnt build with
> make linux-dri-x86
>
> have a look at attached patch.

Applied, thanks.

- ajax