From: Gareth H. <ga...@va...> - 2000-11-28 19:05:06
|
I'm in the final stages of testing the ati-4-1-1 code before it gets merged into the trunk, so if you have an r128 card and can run your favourite GL apps I'd appreciate it. After tonight's work, the only outstanding issues I know of are: - Glean blend func test failures. Probably precision errors. - Glean ortho pos test failures. Possibly sub-pixel precision errors? - Q3A "High Quality" causes strangeness in texture LRU, which can lead to segfaults. I'm tracking these down, but once they are done I think we'll be ready to go. I've been running this code for several months and have ironed out all but these last few problems. Performance, stability and interactivity should all be greatly improved over the 4.0.1 driver. -- Gareth |
From: Brian P. <br...@va...> - 2000-11-28 19:41:49
|
Gareth Hughes wrote: > > I'm in the final stages of testing the ati-4-1-1 code before it gets > merged into the trunk, so if you have an r128 card and can run your > favourite GL apps I'd appreciate it. > > After tonight's work, the only outstanding issues I know of are: > > - Glean blend func test failures. Probably precision errors. How many bits of error does Glean report? And what pixel depth are you using? The tdfx driver at 32bpp fails with up to 1.7 bits of error, IIRC. > - Glean ortho pos test failures. Possibly sub-pixel precision errors? Most likely. You can look in the tdfx-3-0 driver to see how I handled this. Here are the offsets I'm using there: #define TRI_X_OFFSET ( 0.0F) #define TRI_Y_OFFSET ( 0.0F) #define LINE_X_OFFSET ( 0.0F) #define LINE_Y_OFFSET ( 0.125F) #define PNT_X_OFFSET ( 0.375F) #define PNT_Y_OFFSET ( 0.375F) -Brian |
From: Adam K K. <ad...@vo...> - 2000-11-28 20:24:30
|
Gareth, Pulled it when this message arrived, compiling now. When I get home I'll pop in the AIW-128 and let you know. Mind you, I am using PCI, and last I heard you (or perhaps Kevin) had disabled the ati-4-1-1 branch for PCI cards, saying they should stick with ati-4-1-1-stable (or something similar), so let me know if my testing is doomed to failure :-) Adam On Wed, 29 Nov 2000, Gareth Hughes wrote: > I'm in the final stages of testing the ati-4-1-1 code before it gets > merged into the trunk, so if you have an r128 card and can run your > favourite GL apps I'd appreciate it. > > After tonight's work, the only outstanding issues I know of are: > > - Glean blend func test failures. Probably precision errors. > - Glean ortho pos test failures. Possibly sub-pixel precision errors? > - Q3A "High Quality" causes strangeness in texture LRU, which can lead > to segfaults. > > I'm tracking these down, but once they are done I think we'll be ready > to go. I've been running this code for several months and have ironed > out all but these last few problems. > > Performance, stability and interactivity should all be greatly improved > over the 4.0.1 driver. > > -- Gareth > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel > |
From: Adam K K. <ad...@vo...> - 2000-11-28 23:07:27
|
Gave it a whirl... First, I tested with the main branch so I could compare b/w the two. I'm not sure if my testing was doomed to failure since it's a PCI card, but failure is what I got :-) Trunk: Tuxracer and Quake3 kept giving me errors like: r128UploadTexImages: upload texture failure on local texture heaps, sz=4096 r128UploadTexImages: upload texture failure on local texture heaps, sz=256 r128UploadTexImages: upload texture failure on local texture heaps, sz=262144 r128UploadTexImages: upload texture failure on local texture heaps, sz=262144 r128UploadTexImages: upload texture failure on local texture heaps, sz=4096 With tuxracer, the screen turned blue, but the menus didn't seem to be displayed. I was able to hit enter enough to get to the first track... However, I only got tux. No background to speak of. Quake3 I can only describe as "screwed up"... UnrealTournament... I think that would qualify as "screwed up" as well. :-) No textures for glplanet... And I noticed there's still some flickering and flashing with some GL apps (sproigies, for example). ati-4-1-1: Pretty much the same as the trunk... UT had the same problem. Q3A and Tuxracer gave the same error as with the trunk. Although with Tuxracer I had a background... All the flags and fish where big blue blocks, though (as was the entire landscape now that I think about it). No texture on earth with glplanet, and the same flickering for sproingies. No game I started up was at all playable (viewable, even). Anyway, I'm going back to my V5500 now... I think it's safe to say that you haven't broken anything for PCI cards, but there are still problems for them. Adam On Tue, 28 Nov 2000, Adam K Kirchhoff wrote: > > Gareth, > > Pulled it when this message arrived, compiling now. When I get > home I'll pop in the AIW-128 and let you know. Mind you, I am using PCI, > and last I heard you (or perhaps Kevin) had disabled the ati-4-1-1 branch > for PCI cards, saying they should stick with ati-4-1-1-stable (or > something similar), so let me know if my testing is doomed to failure :-) > > Adam > > On Wed, 29 Nov 2000, Gareth Hughes wrote: > > > I'm in the final stages of testing the ati-4-1-1 code before it gets > > merged into the trunk, so if you have an r128 card and can run your > > favourite GL apps I'd appreciate it. > > > > After tonight's work, the only outstanding issues I know of are: > > > > - Glean blend func test failures. Probably precision errors. > > - Glean ortho pos test failures. Possibly sub-pixel precision errors? > > - Q3A "High Quality" causes strangeness in texture LRU, which can lead > > to segfaults. > > > > I'm tracking these down, but once they are done I think we'll be ready > > to go. I've been running this code for several months and have ironed > > out all but these last few problems. > > > > Performance, stability and interactivity should all be greatly improved > > over the 4.0.1 driver. > > > > -- Gareth > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > http://lists.sourceforge.net/mailman/listinfo/dri-devel > > > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel > |
From: Gareth H. <ga...@va...> - 2000-11-29 01:46:56
|
Adam K Kirchhoff wrote: > > Gave it a whirl... First, I tested with the main branch so I could compare > b/w the two. > > I'm not sure if my testing was doomed to failure since it's a PCI card, > but failure is what I got :-) Okay, that's a worry. It shouldn't have initialized any hardware rendering -- can you send the output of glxinfo? Or Mesa/demos/glinfo? -- Gareth |
From: Adam K K. <ad...@vo...> - 2000-11-29 02:09:31
|
On Wed, 29 Nov 2000, Gareth Hughes wrote: > Adam K Kirchhoff wrote: > > > > Gave it a whirl... First, I tested with the main branch so I could compare > > b/w the two. > > > > I'm not sure if my testing was doomed to failure since it's a PCI card, > > but failure is what I got :-) > > Okay, that's a worry. It shouldn't have initialized any hardware > rendering -- can you send the output of glxinfo? Or Mesa/demos/glinfo? > > -- Gareth > glxinfo: display: :0.0 screen:0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_get_proc_address GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Precision Insight, Inc. OpenGL renderer string: Mesa DRI Rage128 20000630 OpenGL version string: 1.2 Mesa 3.4 OpenGL extensions: GL_ARB_multitexture, GL_ARB_tranpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.2 Mesa 3.3 beta glu extensions: GL_EXT_abgr visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 24 0 r y . 8 8 8 8 0 32 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 32 0 16 16 16 16 0 0 None 0x26 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 8 0 32 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 dc 0 24 0 r y . 8 8 8 8 0 32 0 16 16 16 16 0 0 None 0x2a 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None -------------------- glinfo: GL_VERSION: 1.2 Mesa 3.4 GL_EXTENSIONS: GL_ARB_multitexture GL_ARB_tranpose_matrix GL_EXT_abgr GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_MESA_window_pos GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp GL_RENDERER: Mesa DRI Rage128 20000630 GL_VENDOR: Precision Insight, Inc. GLU_VERSION: 1.2 Mesa 3.3 beta GLU_EXTENSIONS: GL_EXT_abgr GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 I'm not particularly familiar with cvs, but I pulled the code this afternoon with: cvs -z3 -b ati-4-1-1-branch co xc Was this incorrect? Adam |
From: Gareth H. <ga...@va...> - 2000-11-29 02:12:59
|
Adam K Kirchhoff wrote: > > glxinfo: > > ... > OpenGL vendor string: Precision Insight, Inc. > OpenGL renderer string: Mesa DRI Rage128 20000630 > OpenGL version string: 1.2 Mesa 3.4 Okay, that's the trunk code. > I'm not particularly familiar with cvs, but I pulled the code this > afternoon with: > > cvs -z3 -b ati-4-1-1-branch co xc > > Was this incorrect? Yes. Try: cvs -z3 co -r ati-4-1-1-branch xc I think I'll update the CVS policy guide, as I think it's wrong here. -- Gareth |
From: Frank W. <fwo...@ho...> - 2000-11-29 06:13:36
|
This is interesting, I am still working on the page and will add this to the new policy guide. I will upload the work I have done on the weekend. Frank On Tue, 28 Nov 2000 19:09:56 Gareth Hughes wrote: > Adam K Kirchhoff wrote: > > > > glxinfo: > > > > ... > > OpenGL vendor string: Precision Insight, Inc. > > OpenGL renderer string: Mesa DRI Rage128 20000630 > > OpenGL version string: 1.2 Mesa 3.4 > > Okay, that's the trunk code. > > > I'm not particularly familiar with cvs, but I pulled the code this > > afternoon with: > > > > cvs -z3 -b ati-4-1-1-branch co xc > > > > Was this incorrect? > > Yes. Try: > > cvs -z3 co -r ati-4-1-1-branch xc > > I think I'll update the CVS policy guide, as I think it's wrong here. > > -- Gareth > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel > |
From: Gareth H. <ga...@va...> - 2000-11-29 01:44:05
|
Adam K Kirchhoff wrote: > > Gareth, > > Pulled it when this message arrived, compiling now. When I get > home I'll pop in the AIW-128 and let you know. Mind you, I am using PCI, > and last I heard you (or perhaps Kevin) had disabled the ati-4-1-1 branch > for PCI cards, saying they should stick with ati-4-1-1-stable (or > something similar), so let me know if my testing is doomed to failure :-) Yes, PCI card support is disabled. I'm working on PCI GART support this week, so we'll see how that goes. Hopefully, there won't be any nasty surprises and it will be straight forward. -- Gareth |
From: marcoghidinelli <ma...@at...> - 2000-11-29 00:07:54
|
On Wed, Nov 29, 2000 at 06:02:02AM +1100, Gareth Hughes wrote: > I'm in the final stages of testing the ati-4-1-1 code before it gets > merged into the trunk, so if you have an r128 card and can run your > favourite GL apps I'd appreciate it. > > After tonight's work, the only outstanding issues I know of are: > > - Glean blend func test failures. Probably precision errors. > - Glean ortho pos test failures. Possibly sub-pixel precision errors? > - Q3A "High Quality" causes strangeness in texture LRU, which can lead > to segfaults. > > I'm tracking these down, but once they are done I think we'll be ready > to go. I've been running this code for several months and have ironed > out all but these last few problems. > > Performance, stability and interactivity should all be greatly improved > over the 4.0.1 driver. > i have a problem with a atirageRF128 at work... the card is really fast.. but it seems that the 'rendered' window is under a 'stroboscopic' light... example: gears runs fast, but it seems 'freezed'.... the 'gears' seems blocked.. and after few frame seems very slow... than again freezed.... |
From: Nathan H. <na...@ma...> - 2000-11-29 00:37:05
|
On Wed, Nov 29, 2000 at 01:05:06AM +0100, marcoghidinelli wrote: > i have a problem with a atirageRF128 at work... > > the card is really fast.. but it seems that the 'rendered' window is under a > 'stroboscopic' light... > > example: gears runs fast, but it seems 'freezed'.... > the 'gears' seems blocked.. and after few frame seems very slow... > than again freezed.... This is completely normal. If you're rendering at 650fps but your vertical refresh is 65fps you will only see every 10th frame, and it's likely to look "frozen". It's nothing to worry about. |
From: Ben O. <be...@se...> - 2000-11-29 01:07:22
|
* marcoghidinelli (ma...@at...) wrote: > On Wed, Nov 29, 2000 at 06:02:02AM +1100, Gareth Hughes wrote: > > I'm in the final stages of testing the ati-4-1-1 code before it gets > > merged into the trunk, so if you have an r128 card and can run your > > favourite GL apps I'd appreciate it. > > > > After tonight's work, the only outstanding issues I know of are: > > > > - Glean blend func test failures. Probably precision errors. > > - Glean ortho pos test failures. Possibly sub-pixel precision errors? > > - Q3A "High Quality" causes strangeness in texture LRU, which can lead > > to segfaults. > > > > I'm tracking these down, but once they are done I think we'll be ready > > to go. I've been running this code for several months and have ironed > > out all but these last few problems. > > > > Performance, stability and interactivity should all be greatly improved > > over the 4.0.1 driver. > > > > i have a problem with a atirageRF128 at work... > > the card is really fast.. but it seems that the 'rendered' window is under a > 'stroboscopic' light... > > example: gears runs fast, but it seems 'freezed'.... > the 'gears' seems blocked.. and after few frame seems very slow... > than again freezed.... > i experience the same problem with gears with the mga driver, although the gears reports 761+ FPS. I don't experience the same problems with the NVIDIA drivers and my girlfriends TNT2 card and it scores a similar framerate. > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel -- Ben O'Shea | The primary difference [...] is that the Java Server101.com Webhosting | program will reliably and obviously crash, whereas be...@se... | the C Program will do something obscure http://www.server101.com/ | -- Java Language Tutorial roady@EFNet | 83AA D412 D55F 4744 B114 DC69 A29F 99C8 AFC8 A365 |
From: Brian P. <br...@va...> - 2000-11-29 16:12:51
|
Ben OShea wrote: > > i have a problem with a atirageRF128 at work... > > > > the card is really fast.. but it seems that the 'rendered' window is under a > > 'stroboscopic' light... > > > > example: gears runs fast, but it seems 'freezed'.... > > the 'gears' seems blocked.. and after few frame seems very slow... > > than again freezed.... > > > i experience the same problem with gears with the mga driver, although > the gears reports 761+ FPS. I don't experience the same problems with > the NVIDIA drivers and my girlfriends TNT2 card and it scores a similar > framerate. If an app's framerate is not synchronized with your monitor's refresh rate you'll sometimes get strobing effects. It's kind of like the illusion of a wagon wheel spinning backward in a movie. Gears is a really simple demo that can render really fast. It is also very regular and cyclic by nature. When it's rendering at hundreds of frames per second it can appear to be running fast, slow, backward or even standing still. Any irregularity in the framerate will look like stuttering or freezing. I think temporal aliasing is the applicable term. I bet that if you resize the windows on your MGA and NVIDIA cards you'll find them acting pretty much the same. -Brian |
From: Gareth H. <ga...@va...> - 2000-11-29 01:49:40
|
marcoghidinelli wrote: > > i have a problem with a atirageRF128 at work... > > the card is really fast.. but it seems that the 'rendered' window is under a > 'stroboscopic' light... > > example: gears runs fast, but it seems 'freezed'.... > the 'gears' seems blocked.. and after few frame seems very slow... > than again freezed.... What's the framerate you're getting? -- Gareth |
From: Ove K. <ov...@wi...> - 2000-11-29 20:04:14
|
On Wed, 29 Nov 2000, Gareth Hughes wrote: > I'm in the final stages of testing the ati-4-1-1 code before it gets > merged into the trunk, so if you have an r128 card and can run your > favourite GL apps I'd appreciate it. Tried a few of them today... results: tuxracer - usually works (although Tux wing is probably lit too white). xracer - don't work for me (could be a packaging problem though): xracer:texture.c:171: fatal error: gluBuild2DMipmaps failed (GL error: invalid enumerant) xscreensaver-gl (gears etc) - only shows anything after moving the window slightly (icewm)... the package is apparently linked against nvidia libGLcore.so.1 instead of libGL.so.1, if that has anything to do with it half-life under wine - totally messes up (not a wine problem, nvidia users apparently happily run half-life under wine in opengl mode): -first few seconds: bad flicker (seems to be double-buffering issue) -After moving around and such, suddenly the screen went black, my monitor displays "signal error" with strange refresh rates (about 19 Hz vertical refresh, don't remember horizontal), and computer is completely locked up tuxracer/win32 under wine - works just as smooth as tuxracer for linux... |
From: Lars M. C. <c9...@st...> - 2000-11-29 22:05:56
|
On Wed, Nov 29, 2000 at 09:03:52PM +0100, Ove Kaaven wrote: > half-life under wine - totally messes up (not a wine problem, nvidia users > apparently happily run half-life under wine in opengl mode): > -first few seconds: bad flicker (seems to be double-buffering issue) I also have flickering with half-life under wine and the tdfx branches, so this could be a generel problem. I get no crashes (not anymore though). -- Lars Munch |
From: Ove K. <ov...@wi...> - 2000-11-30 11:32:00
|
On Wed, 29 Nov 2000, Lars Munch Christensen wrote: > On Wed, Nov 29, 2000 at 09:03:52PM +0100, Ove Kaaven wrote: > > half-life under wine - totally messes up (not a wine problem, nvidia users > > apparently happily run half-life under wine in opengl mode): > > -first few seconds: bad flicker (seems to be double-buffering issue) > > I also have flickering with half-life under wine and the tdfx branches, so > this could be a generel problem. I get no crashes (not anymore though). Ok. Have you tried Half-Life's "noztrick" render option? I recall from testing a while ago (a year?) that even Mesa's software-rendering failed to render correctly if I didn't set noztrick. But I can't try that myself now, since everything crashes... Oh yeah, I tried again today after a cvs update. This time the screen didn't go completely black with signal error, now the screen changed to vertical strips on a black background... |
From: Lars M. C. <c9...@st...> - 2000-12-01 11:18:02
|
On Thu, Nov 30, 2000 at 12:31:46PM +0100, Ove Kaaven wrote: > > On Wed, 29 Nov 2000, Lars Munch Christensen wrote: > > > On Wed, Nov 29, 2000 at 09:03:52PM +0100, Ove Kaaven wrote: > > > half-life under wine - totally messes up (not a wine problem, nvidia users > > > apparently happily run half-life under wine in opengl mode): > > > -first few seconds: bad flicker (seems to be double-buffering issue) > > > > I also have flickering with half-life under wine and the tdfx branches, so > > this could be a generel problem. I get no crashes (not anymore though). > > Ok. Have you tried Half-Life's "noztrick" render option? I recall from > testing a while ago (a year?) that even Mesa's software-rendering failed > to render correctly if I didn't set noztrick. But I can't try that myself > now, since everything crashes... Woohoo. The "gl_ztrick 0" option made flickering go away. Now I have some cool screenshots of Counter-strike running HW accelerated under wine using DRI, this is the first time ever :-). Anyway it seems to be a z-buffer issue. The text or the gl_ztrick option is: "Some older, non-3DFX cards have a problem with clearing the z buffer and this can cause parts of the screen to flash. If you are seeing this, put this line in your opengl.cfg or d3d.cfg file" -- Lars Munch |
From: Brian P. <br...@va...> - 2000-12-01 21:07:16
|
Lars Munch Christensen wrote: > > On Thu, Nov 30, 2000 at 12:31:46PM +0100, Ove Kaaven wrote: > > > > On Wed, 29 Nov 2000, Lars Munch Christensen wrote: > > > > > On Wed, Nov 29, 2000 at 09:03:52PM +0100, Ove Kaaven wrote: > > > > half-life under wine - totally messes up (not a wine problem, nvidia users > > > > apparently happily run half-life under wine in opengl mode): > > > > -first few seconds: bad flicker (seems to be double-buffering issue) > > > > > > I also have flickering with half-life under wine and the tdfx branches, so > > > this could be a generel problem. I get no crashes (not anymore though). > > > > Ok. Have you tried Half-Life's "noztrick" render option? I recall from > > testing a while ago (a year?) that even Mesa's software-rendering failed > > to render correctly if I didn't set noztrick. But I can't try that myself > > now, since everything crashes... > > Woohoo. The "gl_ztrick 0" option made flickering go away. Now I have some > cool screenshots of Counter-strike running HW accelerated under wine using > DRI, this is the first time ever :-). > > Anyway it seems to be a z-buffer issue. The text or the gl_ztrick option is: > > "Some older, non-3DFX cards have a problem with clearing the z buffer and this > can cause parts of the screen to flash. If you are seeing this, put this line > in your opengl.cfg or d3d.cfg file" Does anybody know exactly what gl_ztrick does? -Brian |
From: Daniel V. <vo...@lo...> - 2000-12-01 23:39:55
|
On Fri, Dec 01, 2000 at 02:12:18PM -0700, Brian Paul wrote: > > > > "Some older, non-3DFX cards have a problem with clearing the z buffer and this > > can cause parts of the screen to flash. If you are seeing this, put this line > > in your opengl.cfg or d3d.cfg file" > > Does anybody know exactly what gl_ztrick does? I assume it is the "usual" Z trick that tries to avoid clearing the Z buffer by doing something like the below (and therefore diminishing the precision). Usually done to save fillrate in older games. if( ZTrickToggle ) { ZTrickToggle = 0; glDepthRange( 0.0, 0.5 ); ZTrickFunc = GL_LEQUAL; } else { ZTrickToggle = 1; glDepthRange( 1.0, 0.5 ); ZTrickFunc = GL_GEQUAL; } glDepthFunc( (GLenum) ZTrickFunc ); Daniel Vogel, Programmer, Loki Software Inc. |
From: Brian P. <br...@va...> - 2000-12-02 16:37:51
|
Daniel Vogel wrote: > > On Fri, Dec 01, 2000 at 02:12:18PM -0700, Brian Paul wrote: > > > > > > "Some older, non-3DFX cards have a problem with clearing the z buffer and this > > > can cause parts of the screen to flash. If you are seeing this, put this line > > > in your opengl.cfg or d3d.cfg file" > > > > Does anybody know exactly what gl_ztrick does? > > I assume it is the "usual" Z trick that tries to avoid clearing the Z > buffer by doing something like the below (and therefore diminishing > the precision). Usually done to save fillrate in older games. > > if( ZTrickToggle ) > { > ZTrickToggle = 0; > glDepthRange( 0.0, 0.5 ); > ZTrickFunc = GL_LEQUAL; > } > else > { > ZTrickToggle = 1; > glDepthRange( 1.0, 0.5 ); > ZTrickFunc = GL_GEQUAL; > } > glDepthFunc( (GLenum) ZTrickFunc ); I'm putting this bug in the database so it's not forgotten. -Brian |
From: Michael P. <po...@tr...> - 2000-12-01 23:47:45
|
Brian Paul <br...@va...> writes: > Does anybody know exactly what gl_ztrick does? I think it came originally from Quake 1, which has the same command. I had gl_ztrick on (IIRC) and when I compiled QWTF for XFree86 4.0 plus the new Mesa (several months ago -- this was not the current revision of the DRI), I had to turn it off to have the maps drawn correctly. It seemed almost like it was drawing each frame from front to back, and not Z-clipping. When ztrick is set, the relevant source appears to call call glDepthRange and glDepthFunc with these parameters, alternating on each frame: glDepthRange(0, 0.49999); glDepthFunc(GL_LEQUAL); glDepthRange(1, 0.5); glDepthFunc(GL_GEQUAL); (If it is off, it uses glDepthRange(0, 1); glDepthFunc(GL_LEQUAL);) -- Michael |
From: Nathan H. <na...@ma...> - 2000-12-05 19:28:21
|
On Fri, Dec 01, 2000 at 06:47:43PM -0500, Michael Poole wrote: > Brian Paul <br...@va...> writes: > > > Does anybody know exactly what gl_ztrick does? > > I think it came originally from Quake 1, which has the same command. > I had gl_ztrick on (IIRC) and when I compiled QWTF for XFree86 4.0 > plus the new Mesa (several months ago -- this was not the current > revision of the DRI), I had to turn it off to have the maps drawn > correctly. It seemed almost like it was drawing each frame from front > to back, and not Z-clipping. > > When ztrick is set, the relevant source appears to call call > glDepthRange and glDepthFunc with these parameters, alternating on > each frame: > > glDepthRange(0, 0.49999); glDepthFunc(GL_LEQUAL); > glDepthRange(1, 0.5); glDepthFunc(GL_GEQUAL); > > (If it is off, it uses glDepthRange(0, 1); glDepthFunc(GL_LEQUAL);) AH-HA! This is the cause of the bug in quake.glx that has been driving me insane for weeks. Quake is broken here but I think I might be able to workaround the fault in Mesa. I'll be so bloody happy if I can knock this one off my list. -- Sydney 2000 - The Best Olympic Games Ever |
From: Andreas E. <eh...@ly...> - 2000-12-01 23:58:41
|
On Fri, Dec 01, 2000 at 02:12:18PM -0700, Brian Paul wrote: > Does anybody know exactly what gl_ztrick does? I think this is the relevant part of the Q1 source: else if (gl_ztrick.value) { static int trickframe; if (gl_clear.value) glClear (GL_COLOR_BUFFER_BIT); trickframe++; if (trickframe & 1) { gldepthmin = 0; gldepthmax = 0.49999; glDepthFunc (GL_LEQUAL); } else { gldepthmin = 1; gldepthmax = 0.5; glDepthFunc (GL_GEQUAL); } } else { if (gl_clear.value) glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); else glClear (GL_DEPTH_BUFFER_BIT); gldepthmin = 0; gldepthmax = 1; glDepthFunc (GL_LEQUAL); } |
From: Brian P. <br...@va...> - 2000-12-13 21:41:35
Attachments:
gearflip.c.gz
|
Andreas Ehliar wrote: > > On Fri, Dec 01, 2000 at 02:12:18PM -0700, Brian Paul wrote: > > Does anybody know exactly what gl_ztrick does? > > I think this is the relevant part of the Q1 source: > > else if (gl_ztrick.value) > { > static int trickframe; > > if (gl_clear.value) > glClear (GL_COLOR_BUFFER_BIT); > > trickframe++; > if (trickframe & 1) > { > gldepthmin = 0; > gldepthmax = 0.49999; > glDepthFunc (GL_LEQUAL); > } > else > { > gldepthmin = 1; > gldepthmax = 0.5; > glDepthFunc (GL_GEQUAL); > } > } > else > { > if (gl_clear.value) > glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); > else > glClear (GL_DEPTH_BUFFER_BIT); > gldepthmin = 0; > gldepthmax = 1; > glDepthFunc (GL_LEQUAL); > } I've modified gears to use this technique to avoid calling glClear. It works fine for me using s/w Mesa, the DRI trunk w/ Voodoo5 and the DRI tdfx-3-0 branch on Voodoo5. The program is attached. I don't know why this isn't working in Quake. -Brian |