[ioquake3] Modular Rendering System
matthias.bentrup at googlemail.com
Mon Feb 7 02:58:14 PST 2011
sorry for bringing back this old discussion, but there is a patch
contributed by use.less01 to separate the renderer into a dll on Bugzilla
(Ticket 4790). The patch does not add or remove any functionality from the
current renderer, so most of the issues on the wiki are not addressed, but I
think issues like automatically choosing the best renderer, backward
compatibility etc. can only be sorted out when there actually are more than
one renderer to choose from.
I wonder what is necessary (testing, code review, etc.) to get this patch
commited to the ioquake sources, because I have been working on replacing
deprecated GL functionality in the ioquake3 renderer with more modern
functions, but I find working with OpenGL 2.x + extensions to be very
painful, as hardware support is varying a lot and the renderer has to check
/ provide alternatives for missing functionality. (E.g. vertex texture fetch
is a required feature for GL 2.1, but drivers for DX9 class ATI cards do not
support it, so they announce GL2.1 compatibility, but return
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 0, so you cannot use the feature. NVidia
announces support for float textures for GeForce 6 and 7 cards, but in fact
it supports them only in vertex shaders - using them in a fragment shader
causes no error, but the renderer will run in software mode with ~1fps.)
So I would like to move to OpenGL 3.x, which has a reasonable set of
features that every vendor has to support in hardware, but as OpenGL 3.x
(corresponds to DX10) support is not granted today, I'd need to keep the old
renderer for those who still have only OpenGL 1 or 2 support. This should be
ok, because the fixed pipeline has been removed only in OpenGL 3.1.
2010/4/30 <monk at rq3.com>
> Well, I don't have to expound on how much I wish that ioq3 updated its
> 10-year-old rendering tech to, say, 7-year-old rendering tech, so I'll
> keep this short. I decided that for there to be any movement on this at
> all from any interested parties, there had to be a starting point for
> commenting. With that in mind, I present:
> You can scroll to the bottom for the quick-and-dirty summary. Please bear
> in mind that this is written from someone without a working knowledge of
> the quake 3 codebase. In fact, I would extremely love to have people with
> that knowledge take a look at see what parts seem feasible or practical or
> even possible! And at the very least this will be a reference point for
> others to look at and say "ok this idea has merit" or "what was he smoking
> when he came up with THAT?"
> And hell, if this gets hashed out well enough, even if there are no
> interested parties at present who want to implement it, it should make any
> future attempts at implementation easier for whoever wants to try tackling
> So please, constructive comments, discussion, etc. This is pretty much as
> far as my skillset will allow me to contribute to this idea/effort so
> instead of lamenting the lack of these features I figured I'd at least do
> what I could to make implementation easier for others.
> Thanks for your time!
> ioquake3 mailing list
> ioquake3 at lists.ioquake.org
> By sending this message I agree to love ioquake3 and libsdl.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ioquake3