> So, IMHO, there are some points that have to be decided: > > - pluggable renderer or not: putting the renderer in a DLL/so should be > possible with medium effort, the engine calls into the renderer only via > the > refexport_t, but the renderer doesn't always use the corresponding > refimport_t. > - update the old renderer or create a new one: without renderer plugins > the question is moot, but if there is a plugin structure should the > original > renderer be kept as is ? > > - what is the target of the new renderer ? The current renderer targets > OpenGL 1.1, with some extensions. A new renderer could target 2.1 > (~DirectX9), 3.4 (~DirectX10) or 4.0 (~DirectX11). Other possible targets > would be DirectX9/10/11 or OpenGL ES 2.0. > > - how do you want to handle features that require new data ? should it be > possible to run a new map on an old client (without the new features ofc), > or is it ok if old clients fail on a new map ? > > - do you want to preserve qvm/shader/bsp compatibility ? some features > will > require new qvms, others only new shaders or a new bsp format.
I think the fear is that a new renderer won't work on the traditional hardware that Q3 supported like SGI and Sun machines. A modular renderer would at least (in theory) let the legacy renderer remain in some form so that those machines would always have a way to play ioq3 regardless of what graphic tomfoolery is added. This would also let people dink with the renderer to their hearts' content and not affect some of the legacy hardware platforms. If there is a modular architecture then you could have multiple targets. DX9? OpenGL 4? Whichever you wish! Someone like Tr3B could go balls-to-the-wall and support only the latest hardware while someone else could look for a middle ground and support DX9 and later hardware. The renderers that will be popular will be the ones with the toolchain that supports them. If someone designed a renderer with support for lots of bells and whistles, it won't matter unless the mapping tools supported the features to let the mappers use them. I think it is unrealistic to expect new content created explicitly to take advantage of a new renderer to be backward compatible with the vanilla Q3 client. If it can be done, neat, but I don't think that's a must-have. I was thinking more along the lines of how to block that content or have it gracefully tell the player to upgrade to ioq3; however, if that effort is basically the same as making the content work for older clients anyway, then so be it. QVM/BSP/Shader compatibility, same thing. I think it's an expectation that a game project that wants to take advantage of the new abilities will realize that they won't magically work with old Q3 servers and clients. Just because the capability is there in the engine doesn't mean the player or dev team needs to be forced to use it. The point is that no one has that option at present. Take for example our mod that wants to turn standalone. We have no need to keep Q3 QVM compatibility as we intend to make a "reaction.exe" and have that only run our mod/game. In that case we could use the new content allowed by a new renderer and not worry about backward compatibility. I think it'd be nice to enable eyecandy on legacy content as much as possible, yes. But I also realize that for some of the really neat stuff, new content will be needed and might not work on a regular Q3 client. Thank you for your in-depth breakdown of some of the issues. These are just my opinions on the matter so again the reality of actual coding issues may invalidate some (or all) of what I'm advocating. But hey, unless someone says "that's stupid and here's why," I'll never know better! :D 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.
