Re: [Dri-devel] hw cursor in mach64
Hi all It seems people are actively testing mach64 branch. So I have a couple of questions: 1. Could anyone please periodically make binary snapshots including only X server, necessary libs and little (~10 lines) readme? 2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend on some 4.2 APIs? Unfortunately I cannot afford take the whole XFree branch and build it on my machine, but I would really like to play in testing dri/mach64. Thanks a lot, Sergey V. Udaltsov ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. Regards, Jose Fonseca On Mon, 2001-12-03 at 15:11, Sergey V. Udaltsov wrote: Hi all It seems people are actively testing mach64 branch. So I have a couple of questions: 1. Could anyone please periodically make binary snapshots including only X server, necessary libs and little (~10 lines) readme? 2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend on some 4.2 APIs? Unfortunately I cannot afford take the whole XFree branch and build it on my machine, but I would really like to play in testing dri/mach64. Thanks a lot, Sergey V. Udaltsov ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. AFAIR there is a way to build kernel modules without precise kernel version dependance (correct me if I am wrong) - as long as all external symbols as resolved, the module will be loaded. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. :) If I only had this machine:) There are only 2 machines in the company with Linux: my laptop and server. Nobody is going to let me build something on the server (and it does make sense:). If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. In sources? :( I am not sure it will help me (see above). BTW, what would be the size of the archive (because traffic is an issue for me)? So, the question is: whether there is a way to build kernel modules for generic 2.4.x? Will this cause trouble? Also, my second question is still remaining: will the server and libs be compatible with XFree 4.1.0 from RH7.2 distro? Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? --Leif On 3 Dec 2001, Jose Fonseca wrote: I've been testing the mach64-0-02-branch on my laptop (ATI Mobility 4Mb) and in Unreal a semi-transparent garbled sprite appears on the middle of the screen - it's the hw cursor that wasn't properly erased because this behavior disappears when the X server is started with the 'sw_cursor'. This appears during game and menus - it seems that Unreal draws itself the cursor by software regardless of the availability of hardware acceleration. Any ideas? Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
On Mon, 3 Dec 2001, Otto E Solares wrote: On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? i had exactly the same problem in quake3 and rtcw with the white walls until i disable gl extensions on options and problem gone, but the problem with a rectangle on center on the screen is boring me, will try disabling hw cursor. Well, I tried lightmap with gl extensions disabled and the lighting definitely looks better, but it runs slower (compiled vertex arrays are also disabled). I noticed that with extensions/multitexturing on, I see GL_MAX_ACTIVE_TEXTURES_ARB: 2 on the console. Maybe quake needs 3 textures: wall + lightmap + damage? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? Try disabling multitexture, if you have the Q1 gamedata then I would not mind hearing if it works with twilight with a few different settings. Zephaniah E. Hull. --Leif -- 1024D/E65A7801 Zephaniah E. Hull [EMAIL PROTECTED] 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery msg02012/pgp0.pgp Description: PGP signature
Re: [Dri-devel] hw cursor in mach64
Leif, I've managed to solve that same problem by leaving NoLighting=False and changing UseMultiTexture=0. Fortunatly we can get the source for the OpenGLDrv at http://openut.sourceforge.net . I'm sure that that will help us find the source of these problems... Regards, Jose Fonseca On 2001.12.03 20:09 Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? --Leif On 3 Dec 2001, Jose Fonseca wrote: I've been testing the mach64-0-02-branch on my laptop (ATI Mobility 4Mb) and in Unreal a semi-transparent garbled sprite appears on the middle of the screen - it's the hw cursor that wasn't properly erased because this behavior disappears when the X server is started with the 'sw_cursor'. This appears during game and menus - it seems that Unreal draws itself the cursor by software regardless of the availability of hardware acceleration. Any ideas? Regards, Jose Fonseca -- Leif Delgass http://www.retinalburn.net Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel