From: Joseph C. <kng...@de...> - 2001-04-23 15:50:57
|
First my preemtpive response that you are out of your mind and once you really start getting into the engine hacking you'll understand just how crazy you are. Don't say I didn't warn you when the men in white coats show up at your doorstep. =3D) On Mon, Apr 23, 2001 at 04:09:39PM +0100, Mathieu Olivier wrote: [..] > We have a double approach. First, we want to make a > total conversion that will transform Quake and > QuakeWorld into clones of Blood. So far so good. > Then, we want to work > on the engine to have one single binary which will be > a NQ/QW merge (a kind of NQ with the QW network > engine, mainly). We don't mind the NQ/QW > compatibility, for the network protocol and for the > data formats. We allow ourselves to make any change > that will beneficial to our game. QuakeForge is now on its second attempt at such a merge. It's a hell of a lot harder than you think it is to merge, of that I'm certain. > I have followed your progress since several months > now, downloading and compiling source code, submitting > bug reports, reading the mails on the quake-devel > mailing list, ... You have done a lot of very good > things (portability, stability, ...), and your project > counts several talented people, obviously. However, I > must admit that I think you have failed on the > renderer: I have little gaps between some polygones in > OpenGL, the software version misses regularly parts of > the visible polygones, and QuakeForge GL is slower > than Q3Arena on my computer. We know it's slow. Believe me, there are half a dozen people that remind us at least once a week that it's slow. We also are in the midst of a major rewrite of the entire codebase, renderer included. And you can bet that the new renderer will NOT be slow. > On the other hand, I also follow TomazQuake > (http://tomaz.quakesrc.org/) and I must say that I'm > really impressed by the general quality of its > graphics. There are several very annoying points for > the qBlood project though, including the network > protocol (Quake), the OpenGL-only renderer, and the > non-portability of a part of the code. Tomaz has not shown much interest in portability. A lot of the things he's done are things we intended to do in a non-hardcoded manner or they would be implemented already. QuakeForge is about more than just adding shiny new graphics to the codebase, it's about making it the best it can be, and that takes time when you only have a few hours a day to devote to it if you're lucky. IMO his engine suffers where most Quake projects have, fluff over substance. It _DOES_ look nice, that's not even in question. But what's under the hood? > So, my questions are: > 1) Do you have any plan to fix your rendering code > (especially the software renderer) ? =2E..especially the software renderer?! Most of the people who USE our software renderer would have your head and ours if we did anything to it which cut their framerate by even 1fps because that's the difference between the next rocket putting you in slomo or not. > 2) Do you want to keep the Quake/QW compatibility ? Of course, that was the one request John made of us: Make sure the original game and mission packs still work. > 3) Do you plan to merge NQ and QW (maybe with a > modular network part) ? Do you think it's possible ? Uh, that was the very FIRST thing we tried to do and it failed outright. We then went to work on a QW tree which was needed fast, and now are trying the merge again. Is it possible? Yes. Are you going to pull it off without very intimate knowledge of the codebase? Possibly, but being realistic, it's more likely going to turn into a nightmare. > 4) Do you think that we should use QuakeForge or > TomazQuake ? (Tricky one, isn't it ? :) I know that > Tomas Jakobsson suscribes to this mailing list; his > opinion is welcome, of course. I think you should work on your TC first and then consider just what you need from the engine and make that happen. Maybe it's easier to get from one engine, maybe from another. You're going to find QW's network code a PITA for sure. That's why most projects are NQ only. We're looking at new directions to go in designing QuakeForge's network code for things that are not backward compatible with older engines, but these are all still on the drawing board. > 5) Any suggestions ? Pad the walls and dispose safely of any sharp objects within reach. It's a monumental task you've set out for yourself and I suspect you don't know just how big it is yet. But you will. =3D) You'll either learn very fast or your project will lose momentum and stall. I rather enjoyed Blood, so if you can get permission to distribute the artwork and such to people who don't already have the game (I no longer do), I'd love to see the result, even if you only go as far as a TC slightly enhanced for newer Quake engines.. --=20 Joseph Carter <kng...@de...> Free software developer <joeyh> netgod: er, are these 2.2.0 packages 2.0.0pre9 or do you have a direct line with the gods? <netgod> joeyh: i have the direct line |