From ntoronto at cs.byu.edu Sat Jan 6 02:09:34 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Sat, 06 Jan 2007 00:09:34 -0700 Subject: PyQuake3 on SourceForge Message-ID: <459F4B2E.3040507@cs.byu.edu> A few items: 1) Florian Ludwig (dino4k) has joined this previously one-person project as a developer and source control admin (since I suck at such things). I still retain the title of Benevolent Dictator For Life. He brings with him significant development experience (especially in Python) and a lot of interest. 2) We're forking. (Sorry!) We decided it would be a major version-control PITA to maintain this project as a patch. However, since we don't expect very many changes in ioquake3 to affect us at all (ours is mostly new files and a few hundred scattered lines of glue code in areas nobody likes to touch), we'll roll in ioquake3 deltas whenever you fine people make a stable release. Our project is hosted here: http://sourceforge.net/projects/pyquake3 3) The client game renders everything properly and plays all sounds. It's only missing the HUD and scoreboard. If you want to try it out, do it this way: svn co https://pyquake3.svn.sourceforge.net/svnroot/pyquake3/trunk pyquake3 -r 7 We expect not-inconsequential changes in directory structure, so things may break. You're safe with revision 7. In addition to the normal ioquake3 prerequisites (X11 dev, SDL, OpenAL dev, etc.) you'll need python2.4-dev, python-profiler, and possibly python-pyrex. (Those are the Debian and Ubuntu package names.) I'm afraid it only compiles properly on Linux, but that will change. To play the Python cgame, you'll need to set sv_pure 1 and vm_cgame 3. If you don't see a HUD, you're running it. 4) I've run some timedemos to compare QVM client performance with the Python client performance. On four.dm_68 (eight players, q3dm6) on my junky Intel-card laptop, I get 62 FPS for the QVM and 49 FPS for Python. Not bad at all. Neil From daniellord at mac.com Sat Jan 6 02:35:59 2007 From: daniellord at mac.com (Daniel Lord) Date: Fri, 5 Jan 2007 23:35:59 -0800 Subject: [quake3] PyQuake3 on SourceForge In-Reply-To: <459F4B2E.3040507@cs.byu.edu> References: <459F4B2E.3040507@cs.byu.edu> Message-ID: Neil, Congratulations. You and your new team member pulled it off. Kudos. I'll bet once I buy that quad-Xeon Mac Pro I hope to get this year, the Python version will exceed the FPS of the regular version on my Macbook Pro ;-). Yum! Daniel On Jan 5, 2007, at 23:09, Neil Toronto wrote: > A few items: > > 1) Florian Ludwig (dino4k) has joined this previously one-person > project as a developer and source control admin (since I suck at > such things). I still retain the title of Benevolent Dictator For > Life. He brings with him significant development experience > (especially in Python) and a lot of interest. > > 2) We're forking. (Sorry!) We decided it would be a major version- > control PITA to maintain this project as a patch. However, since we > don't expect very many changes in ioquake3 to affect us at all > (ours is mostly new files and a few hundred scattered lines of glue > code in areas nobody likes to touch), we'll roll in ioquake3 deltas > whenever you fine people make a stable release. Our project is > hosted here: > > http://sourceforge.net/projects/pyquake3 > > 3) The client game renders everything properly and plays all > sounds. It's only missing the HUD and scoreboard. If you want to > try it out, do it this way: > > svn co https://pyquake3.svn.sourceforge.net/svnroot/pyquake3/trunk > pyquake3 -r 7 > > We expect not-inconsequential changes in directory structure, so > things may break. You're safe with revision 7. In addition to the > normal ioquake3 prerequisites (X11 dev, SDL, OpenAL dev, etc.) > you'll need python2.4-dev, python-profiler, and possibly python- > pyrex. (Those are the Debian and Ubuntu package names.) I'm afraid > it only compiles properly on Linux, but that will change. > > To play the Python cgame, you'll need to set sv_pure 1 and vm_cgame > 3. If you don't see a HUD, you're running it. > > 4) I've run some timedemos to compare QVM client performance with > the Python client performance. On four.dm_68 (eight players, q3dm6) > on my junky Intel-card laptop, I get 62 FPS for the QVM and 49 FPS > for Python. Not bad at all. > > Neil > From ntoronto at cs.byu.edu Fri Jan 19 15:44:08 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Fri, 19 Jan 2007 13:44:08 -0700 Subject: John Carmack on ASM code Message-ID: <45B12D98.3070708@cs.byu.edu> I like to browse through Carmack's Slashdot posts every once in a while. I found this today: "Anyone working on the Q3 codebase today should just delete all the asm code and use the C implementations. Making a commercial game with fairly high end requirements go 10% faster is sometimes worth writing some asm code, but years later when the frame rate pressure is essentially gone, the asm code should just be dumped in the name of maintainability. All the comments in the world wouldn't change this decision a bit." http://slashdot.org/comments.pl?sid=159570&cid=13365387 Something to think about. Neil From ewetoo at gmail.com Fri Jan 19 16:09:19 2007 From: ewetoo at gmail.com (ewe2) Date: Sat, 20 Jan 2007 08:09:19 +1100 Subject: [quake3] John Carmack on ASM code In-Reply-To: <45B12D98.3070708@cs.byu.edu> References: <45B12D98.3070708@cs.byu.edu> Message-ID: <91d14f320701191309x2534918eh8a709122e2b97f92@mail.gmail.com> On 1/20/07, Neil Toronto wrote: > I like to browse through Carmack's Slashdot posts every once in a while. > I found this today: > > "Anyone working on the Q3 codebase today should just delete all the asm > code and use the C implementations. Making a commercial game with fairly > high end requirements go 10% faster is sometimes worth writing some asm > code, but years later when the frame rate pressure is essentially gone, > the asm code should just be dumped in the name of maintainability. All > the comments in the world wouldn't change this decision a bit." and then the code rots and noone can port the game to a new platform that needs that efficiency? Sometimes that's just as important as easily-maintained code. -- Emacs vs. Vi flamewars are a pointless waste of time. Vi is the best From lmsmercykiller at gmail.com Fri Jan 19 20:06:29 2007 From: lmsmercykiller at gmail.com (Stephen Youts) Date: Fri, 19 Jan 2007 19:06:29 -0600 Subject: [quake3] John Carmack on ASM code In-Reply-To: <91d14f320701191309x2534918eh8a709122e2b97f92@mail.gmail.com> References: <45B12D98.3070708@cs.byu.edu> <91d14f320701191309x2534918eh8a709122e2b97f92@mail.gmail.com> Message-ID: I think that porting to a new hardware platform would imply a rewrite of the relevant asm code anyway. On 1/19/07, ewe2 wrote: > > On 1/20/07, Neil Toronto wrote: > > I like to browse through Carmack's Slashdot posts every once in a while. > > I found this today: > > > > "Anyone working on the Q3 codebase today should just delete all the asm > > code and use the C implementations. Making a commercial game with fairly > > high end requirements go 10% faster is sometimes worth writing some asm > > code, but years later when the frame rate pressure is essentially gone, > > the asm code should just be dumped in the name of maintainability. All > > the comments in the world wouldn't change this decision a bit." > > and then the code rots and noone can port the game to a new platform > that needs that efficiency? Sometimes that's just as important as > easily-maintained code. > > -- > Emacs vs. Vi flamewars are a pointless waste of time. Vi is the best > -- -MercyKiller ================ http://lms.d3files.com http://www.debian.org -------------- next part -------------- An HTML attachment was scrubbed... URL: