Re: [Dri-devel] Bug in compilation?
John S. Chalice wrote: I am attempting to recompile DRI on my newly configured Mandrake 9.0 system.. but it cuts out with an error on line 14282 or so of my log file.. with an error in a gcc line.. it's the only place it tries to use the Xpm library "-lXpm" and for some reason, it says it can't find it. Any ideas? Could you send the specific compiler output? You don't have to send the whole output from make, just the part that shows the error.- rm -f xf86cfggcc -m32 -o xf86cfg -march=i686 -O3 -pipe -ansi -Wno-return-type -w -pipe -g -L../../../../../exports/lib -L/usr/X11R6/lib accessx.ocards.oconfig.ocard-cfg.oexpert.ohelp.ointerface.okeyboard-cfg.olibc_wrapper.o loader.o loadmod.o monitor-cfg.omouse-cfg.ooptions.oscreen-cfg.oscreen.ostartx.ostubs.otext-mode.ovidmode.oxf86config.o -lxkbui -lxkbfile -lxf86config -lXxf86misc -lXxf86vm -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXpm -L../loader -lxloader -L../dummylib -ldummy -rdynamic -ldl -lXext -lX11 -lncurses -lm -Wl,-rpath-link,../../../../../exports/lib/usr/bin/ld: cannot find -lXpmcollect2: ld returned 1 exit statusmake[6]: *** [xf86cfg] Error 1make[6]: Target `all' not remade because of errors. --- There 'tis :) Thanks for any help. :) -- John S. Chalice
[Dri-devel] UT2003
FYI, With the latest patch to UT2003 (2186), and drivers from the texmem branch as of this morning (for a Radeon 8500), ut2003 segfaults: Backtrace: [ 1] ./Core.so [0x409f635a] [ 2] /lib/libpthread.so.0 [0x40d7275a] [ 3] /lib/libc.so.6 [0x40b9f898] [ 4] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74419] [ 5] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74966] [ 6] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e7498a] [ 7] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e59521] [ 8] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e70614] [ 9] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e309e8] [10] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e24301] [11] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43dbf587] [12] /usr/local/games/ut2003/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRender Interface14EPrimitiveType+0x348) [0x42f49ac0] [13] ./Engine.so(Flush__11FCanvasUtil+0x1dc) [0x4035206c] [14] ./Engine.so(_._11FCanvasUtil+0x28) [0x40351dac] [15] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x97a) [0x403434 96] [16] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x840) [0x4027b304] [17] /usr/local/games/ut2003/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0 x42f0a93b] [18] /usr/local/games/ut2003/System/SDLDrv.so(Tick__10USDLClient+0x85) [0x42f09 365] [19] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x40282111] [20] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] [21] ./ut2003-bin(main+0x328c) [0x8058b2c] [22] /lib/libc.so.6(__libc_start_main+0xdd) [0x40b8e9f1] [23] ./ut2003-bin(ValidateCDKey__Fv+0x4d) [0x80512d1] Signal: SIGSEGV [segmentation fault] Prior to this patch, the game would load, levels would load (of course, they'd render completely wrong), and my machine would lock up eventually. I'm not sure if I should consider this an improvement :-) Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Problems with RTCW in 16bit resolution
Hi, when playing RTCW in 16bit screen resolution, the color of fog effects (panzerfaust smoke, clouds in the sky, fog on the ground) are funny. This effect is visible even in the main screen. To be more specific: - panzerfaust smoke from the panzerfaust tube dropped after shooting is sometimes dark magenta, sometimes dark green. Should be white - clouds in the sky on first level are dark a with funny colors, should be white and sky blue. - fog on the ground in some dungeons incl. the first level is dark, should be white This problems occur with both TCL enabled and disabled. Using XFree86 4.2.99.4. When I use 24bit resulution for X server, all seems to be fine and the above problems do not occur. I am using Radeon AIW (QD) with 32MB SDRAM on Linux 2.4.21pre4. There is also a reproducible lockup in the Rocket base mission - when taking the lift to the missile launching room and when you look up, my machine locks hard (not even kernel magic keys work). This is easily reproducible. The workaround is not to look up on the lift :-) This lockup occurs in 16bit, I am not sure about other color depth and does not occur anywhere else in the game. Thanks for otherwise great drivers. I am especially looking forward to texmem branch, it should help those having only 32MB on-card memory, right? :-) Michal Bukovjan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] !--#rotate Random word of digits with length 1 to 17 884187885552226
mariea, MelmaptarolimfTieaepoaheesiunN¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ >.)îÅj+Ô¨ëax6I硶Úÿ 0½«(~Üç(:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
On 2003.02.02 04:24 Keith Whitwell wrote: Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. Pawel, Can you try using the pre-september kernel module with the current driver? I have a guess that it may be related to changes made in the radeon.o module about that time. I tried v 1.5.0 [drm] Initialized radeon 1.5.0 20020611 on minor 0 as in dri CVS on 2002-08-31 but the delays are still there. Should I try another version? -pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switchingproblems in wolfenstein.
Pawel Salek wrote: On 2003.02.02 04:24 Keith Whitwell wrote: Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. Pawel, Can you try using the pre-september kernel module with the current driver? I have a guess that it may be related to changes made in the radeon.o module about that time. I tried v 1.5.0 [drm] Initialized radeon 1.5.0 20020611 on minor 0 as in dri CVS on 2002-08-31 but the delays are still there. Should I try another version? No. Probably the most helpful thing you can do is binary search to try find the change which introduced your problem. So try a date half-way between now september, check out that version see if the problem is there, etc. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. Sorry for my ignorance, are these compression methods supported in any way by DRI now? Which apps would benefit of them? Regards, -- Sergey signature.asc Description: This is a digitally signed message part
[Dri-devel] Married and flirting ! 8616-4
Check outmarriedbutyetalone] Married But Lonely Married But Lonely is an exclusive site of lonely women looking for sex dates with you! We have thousands of married women listed nationwide and in over 10 countries! Plus, you get an adult cyberpass which automatically and instantaneously makes you a member of over 300,000 of the Internet's finest premium X-rated adult sites. Push here enter now! Check outmarriedbutyetalone Check outmarriedbutyetalone Check outmarriedbutyetalone Check outmarriedbutyetalone Check outmarriedbutyetalone Check outmarriedbutyetalone Can't wait to hook up? Talk with a live, HOT lady RIGHT NOW ! 1-800-463-CUMM credit card required, from only $1.99/minute I bought a list of single men, if this isn't you just email [EMAIL PROTECTED] and I'll get you off :) 5277VEhK4-038zjGC137l19 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Bug in compilation?
/usr/bin/ld: cannot find -lXpm collect2: ld returned 1 exit status make[6]: *** [xf86cfg] Error 1 make[6]: Target `all' not remade because of errors. check for existance of files ./lib/libXpm/libXpm.so* and ./exports/lib/libXpm.so* I assume those were not built or were cleaned up unintentional. If you will not see a Makefile and have not other clue, then please start over with a make world from the xc-base directory. -Alex. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Bug in compilation?
On Son, 2003-02-02 at 23:38, Alexander Stohr wrote: /usr/bin/ld: cannot find -lXpm collect2: ld returned 1 exit status make[6]: *** [xf86cfg] Error 1 make[6]: Target `all' not remade because of errors. check for existance of files ./lib/libXpm/libXpm.so* and ./exports/lib/libXpm.so* I assume those were not built or were cleaned up unintentional. If you will not see a Makefile and have not other clue, then please start over with a make world from the xc-base directory. The DRI tree no longer contains all the X stuff it needs (hasn't for a long time, actually) to build but instead relies on it to be installed on the system. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
On 2 Feb 2003, Sergey V. Oudaltsov wrote: According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. Sorry for my ignorance, are these compression methods supported in any way by DRI now? Which apps would benefit of them? No they aren't supported in DRI. For existing apps, they would probably only be useful for apps supplying uncompressed textures and requesting generic compression through ARB_texture_compression. The textures would have to be compressed in software and then passed to the card to de-compress as it applies the textures. There is no GL extension (vendor-specific or otherwise) that I know of for these formats, so it would require a new extension spec. and a software implementation of compression/de-compression as well as the support for hardware de-compression (that's the easy part). Since there's no existing extension, there wouldn't be any existing apps supplying pre-compressed textures to the GL in this format, and afaik, very few existing apps would ask for generic compressed formats either. This limits the utility of implementing it, as VQ compression is much more time consuming than S3TC/DXTC compression, as I understand it. It's better for offline compression and real-time de-compression (de-compression could be faster than with S3TC). So it would require detailed specs on the compression format as implemented in the hardware (e.g. block and codebook sizes) to write the spec. and software support, or some trial and error reverse engineering. Quite frankly, it seems like it's probably more trouble than it's worth. Does anyone know if these formats were ever supported in ATI's drivers? I'm assuming it would have to have been in the DX drivers, since I can't find any GL extension supporting them. But I can't find any reference to DX supporting VQ except for the WinCE DirectX SDK for the Sega Dreamcast. I think Microsoft made DX 5 and 6.1 sdks for the dreamcast, and DXTC/S3TC was introduced in the PC version of DX6. According to ATI's site, later Rage 128 chips (Rage Fury Pro, Rage Mobility) support DX6 texture compression, which I assume means S3TC, but I don't see any relevant register defines in the headers and I don't have specs for Rage 128. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
