From: Joseph C. <kng...@de...> - 2001-03-22 13:19:40
|
On Wed, Mar 21, 2001 at 10:15:17AM -0800, Seth Galbraith wrote: > > Then I must be missing something.. >=20 > I'll bet you aren't the only one. Most of the action is in CVS and on the > openquartz-general mailing list. We haven't even got a real web page up! > We have weaknesses in the web presence and documentation department. Last I heard CVS was dead and I was better off working with the tarball on your website which was far more current. As a result, I went by that, which hasn't seen any updates in 6 months. I'll take a look at the CVS at some point possibly soon. I may be a little less irritable then. ;) > > Low-precision low-framecount vertex models and high-precision skeletal > > models with much more detailed animations.. They don't go together. >=20 > I agree that they don't go together, but I don't see them as contradictory > goals, I see them as seperate goals. >=20 > Open Quartz is not just one game, it's really as many variations as are > required to exploit those new engine features that require new content. = =20 > (Which is currently one, but will be two if you implement high precision > skeletal models.) Fragmentation is a bad thing. I'm a strong believer in doing one thing and doing it right. > The goals are SO seperate that the models could be completely different, > not just different versions of the same model with different levels of > detail - depending on what the artist(s) want to do for a new high > precision skeletal model. That's still an exponential duplication of effort. > > Thirdspace was not trying to be different for the sake of it. =20 > > Thirdspace was trying to provide things that no other free engine > > today does.. Very large maps, lots of clients, and game control very > > changable from one game to another. >=20 > I don't mean that Thirdspace's goals don't require SOME differences. The > impression I got was that the Thirdspace team beleived that it would be > easier to write a new engine from scratch than to implement these > features as individual modifications to QuakeForge (Waiting until the > last possible moment before breaking compatibility when necessary.) The fact is that most of Quake is totally unsuited to what Thirdspace was targetting. I don't think you realize that. Quake's world renderer is a BSP renderer, you can't just swap that for any kind of patch renderer. We were planning on a complete VM to replace the current QuakeC model used by QuakeForge. There were going to be no limits (ie, Descent can't be done in Quake.. Better yet, if you are a Babylon 5 fan, consider the requisite control mechanisms for a Starfury.. In Quake? Impossible.) Thirdspace was supposed to make all of these things possible, if not perhaps the best ideas in some cases. I wish we could do a lot of that in Quake but I just don't see how it's possible if we are going to remain compatible with the existing games. There's a lot Quake can do as long as you're doing Quake (or at least a Doom/Quake/HL/Unreal/whatever game) but if you want something more unique, you're going to have a hard time doing it in Quake simply because it wasn't written for more than that. > This attitude is what made me believe that Thirdspace was just a little > bit too enamored with it's own novelty :-) Of course that's a moot point - Thirdspace is a dead project before it really got started. > I think engine development is very incremental. Yes, the market keeps > changing, but it is not impossible to keep up with incremental > improvements - in fact it is harder to catch up when you start from > scratch. Commercial engines have to build teams, reputation and capital. > Free engines have to build teams, reputation and communities. I don't think so. When Quake3 was written, was Quake2 refitted? No, they did that to get Quake2, but Quake3 was a totally new engine. They just couldn't refit Quake2 to come up with Quake3. Yeah they reuse engines when they can, but for the most part when they do it they have to rewrite a lot of the code anyway. Gone are the days you can just recycle the engine with almost no changes for a new game if you want to make a profit. > The generality which has worked for a few commercial engines like Quake > and Unreal may eventually work for one or more Free engines, but it has to > happen by prolonged evolution that improves the Free engine fast enough to > catch up with and exceed the audience's expectations. If you think that Quake has any kind of generality, you clearly haven't tried to do anything significantly different from Quake with it. You just can't do it with Quake because Quake was designed for Quake. Oh sure you can probably modify the source to do anything you want, but I know for sure that you have=20 --=20 Joseph Carter <kng...@de...> Free software developer <calc> knghtbrd: gnome 2.0 will be out in a few months, not sure how it will compare to kde 2.0 though <knghtbrd> calc: Just as bloated, just as buggy, and every Gnome 2 app will depend on 30 libraries. <Slimer> knghtbrd: so what changes from 1.0 ? |