From owner-freebsd-multimedia Mon Sep 22 19:21:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08745 for multimedia-outgoing; Mon, 22 Sep 1997 19:21:31 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08709 for ; Mon, 22 Sep 1997 19:21:10 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id TAA00283 for ; Mon, 22 Sep 1997 19:21:08 -0700 (PDT) Message-Id: <199709230221.TAA00283@rah.star-gate.com> To: multimedia@freebsd.org Subject: [game] Any Care to Lend A Hand for GLQuake? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 19:21:08 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: http://threewave.planetquake.com/linux/glquake.html [snip] As many people know, I'm working on the Unix ports for id software. I'm working on GLQuake for Linux, now that Linux GLIDE is available. I have gotten it running using MesaGL on top of Linux GLIDE. There are a number of issues that I need to address and I was looking for some input. - Right now, texture management with MesaGL over GLIDE isn't very nice. In fact, you can't even load a level in GLQuake without cutting the textures down pretty severely with gl_picmip. Also, after two or three levels you still run out of texture memory anyway (since GLQuake never frees textures, it just shares them between levels) and it bombs out. Is there any work to improve texture handling in MesaGL in the near future? Ideally, it should just be like the 3DFX opengl32.dll miniport in that it automatically handles moving textures in and out of the card based on the demands of the current rendering scene. Until this is fixed, GLQuake under Linux really isn't usuable. Quake2 doesn't have this problem, as it frees textures between levels, but the current fxMesa implementation never 'frees' textures out of the card, so you still run out of texture memory. - Keyboard and mouse handling are an issue. After looking at this, looks like the best way is to use X11 for both inputs. Keyboard is pretty standard under X (just create a window and start reading keyboard events), but mouse is rather ugly. Essentially, you keep having to warp the pointer to the middle of the window after reading its position change. I'm wondering if there's a better way. Ideally, I'd want to steal the mouse from X entirely and read it directly to get precise inputs from the mouse itself. I've considering ripping the code out from gpm/svgalib to do this. Any one have thoughts on this? Is there a mode in X11 where I can just grab the pointer and read it's changes directly? This also gets ugly if you have window managers that change focus based on mouse position. If you whip the mouse fast enough before GLQuake has a chance to warp it back to the middle of the window, you can end up changing focus to another application and all hell breaks lose. - Performance under MesaGL over GLIDE is pretty slow. I get around 12fps at 640x480 with a "timedemo demo2", and that's even after mipping down all the textures. This is much less than the Win32 opengl32.dll miniport where I get around 24fps with standard settings (no funky tweaks). I'm not sure where the performance is lost. I'll have to do some more testing and profiling to find out where. Just for your info, I'm using my bottom of the line Pentium 100 for testing which explains the rather low numbers. I'd like input on these issues and hope to provide a working GLQuake for Linux as soon as its feasible. /// Zoid. zoid@idsoftware.com The Glide 2.4 rasterization library for Linux has been released by 3Dfx for users of the Voodoo chipset. The library can be obtained from 3Dfx. Things are really starting to fall into place quite nicely now. I'm not sure what lies in our future... a miniport of GLQuake or a full blown (read slow) port of OpenGL Quake. I'll let ya all know as soon as I hear anything.