> If art assets are very bound to the renderer type, doesn't this become > a bit impractical in the real world? If a dev team is going to use > only a specific renderer for their art assets and that dev team has > the control of the client that their users will receive, doesn't this > whole operation becomes a bit of a futile endeavor? i.e. e.g. can't > they just use Xreal to begin with? Can't they just keep using Q3 GPL > base to begin with? etc.
What is impractical in the real world is having to choose between multiple versions of Q3 for specific features and then have to try to reimplement them when they are missing from the specific version that's the "best" fit. I view ioq3 as an engine project and the renderer as an integral part of the engine. Dev teams should be able to utilize the engine and actually program the GAME they want, not rewrite engine-level stuff. Why reinvent the wheel all the time? Or why keep switching to other random engines for one or two specific features? ioq3 should be the one-stop shop for most projects starting off. How many offshoots will keep rewriting the renderer? And how many will die off and never get their work committed upstream? XreaL hasn't been updated since sometime in 2009? So while XreaL may languish, ioq3 might get live webcam feeds in-game. How cool is that! And do I need to give that and other ioq3-specific features up for a better renderer? How many source trees will I have to get updates from when I pull features from all over? In an ideal world, you'd just need to synch with ioq3. Yes, we can start over from Q3 GPL but that's insanely impractical since we'd have to reimplement so many YEARS of fixes and updates. Add that to actually coding the game we want? So much wasted, duplicated effort. I'd even go so far as to say that ioq3 is perfect for our game engine needs and we'd never bother to look at ANY other projects if only it had a more modern renderer and model support. The fact that we're thinking of dumping ioq3 because of that is the most tragic part. We've investigated XreaL and it means that a bunch of our existing content won't work (no longer have the .map files to recompile) and it'll be nontrivial to try to adapt our code to work with it. The fact that this is a serious consideration is such a horrible decision to have to make. You want impractical? 8 years of content we're thinking of dumping. I know that's not really breaking anyone's heart but this is the type of decision that people who WANT to use ioq3 are forced to make. I haven't been lamenting about this stuff for the last 4 years because I just like shiny things. ;) I've been trying for 4 years to attract content creators to help finish off our mod/game and have been running into the same issues re: not worth the effort because it won't help them develop skills. For existing teams with a dedicated crew, no big deal, but most of our guys have moved on. This is an actual problem in the real world I've been faced with and this seems to be the best fit solution, in my mind. Contributors seem dead-set against improving the renderer and leave that to offshoot projects. Everything else gets revamped and fixed up. It's odd and seems like it is holding ioq3 back from being a modern general game engine. I just think that if people can work on the renderer at will as a plugin, then the contributors who don't have an interest can safely continue to ignore it and let other people dink with it. But without a framework in place, the only way people can do that is by forking again and again and again. Impractical! I can go in more detail if you want off-list. This was already too long, sorry blokes. Monk. _______________________________________________ ioquake3 mailing list [email protected] http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
