It's not as flashy but it seems like it is better suited to eventual integration to ioq3 if it maintains 100% compatibility with existing Q3 entity and rendering support. Seems like a solid base to build from; I wish you luck! (no, really, I really really do!)
> 2010/6/22 Evan Goers <[email protected]> > >> >From what I have learned from speaking with Tr3B and other >> graphics-informed people, it's that the deformvertexes and various tcmod >> functions cannot be stored in a VBO, or has other GLSL-related >> implications >> that prevent it from working. They were probably removed because of >> these >> reasons and that UrT probably has no real use for these functions >> anyway, >> besides for water effects or something. >> >> For what it's worth, all these functions are in XreaL(except for >> deformVertexes), probably re-written to make it work. It might be worth >> taking a look into how it's done in XreaL. >> >> >> On Mon, Jun 21, 2010 at 8:14 AM, <[email protected]> wrote: >> >>> We had looked into this as well and there may be more work and testing >>> someone would have to do. From some mappers/coders: >>> >>> "someone(!) should inform him about the non-compatible parts (no tcMod >>> rotate, no deformVertexes, r_overbrightbits is borked etc...)" >>> >>> I unfortunately don't have an extensive list or too many details, but >>> it >>> appears that there are some changes right off the bat that would make >>> this >>> unusable for the main branch. Now I grant that that could be an issue >>> with our implementation, but anyone working on this should make sure >>> that >>> all the base Q3 features are available with the new renderer. >>> >>> I honestly would have just assumed that they were but hey, perhaps they >>> are not! >>> >>> >>> > On Wed, Jun 9, 2010 at 10:21 PM, <[email protected]> wrote: >>> >> It's been around a while but looks like it was updated in the last >>> day >>> >> or >>> >> two. The source isn't directly linked so for those who are curious, >>> >> here >>> >> ya go: >>> > >>> > I ported it to the latest ioquake3 (r1785). There wasn't much work >>> to >>> > do as far as converting to SDL etc. The hard part was sorting out >>> > what changes needed to be included. ioUrbanTerror is mostly based on >>> > a pre-SDL version of ioquake3 but it also has some recent changes >>> > backported. If this would be used upstream and someone can help me >>> > test vanilla quake3, I'd be happy to help merge it. I tried to keep >>> > my diffs as close to 27's source code as I could since it's already a >>> > big diff. If it gets merged upstream, you would want to fix up the >>> > diff so it applies cleaner with respect to removing small UrT changes >>> > (e.g. urtconfig.cfg), newline cleanup, and indenting cleanup. >>> > >>> > I like this bloom filter better than the one in OpenArena. And the >>> > shiny water is very nice. :) >>> > >>> > Here's the one that shows all of the changes that are really >>> > necessary. This won't apply cleanly because it's a diff between my >>> > UrT patches and 27's changes. It is based on r1785 so it should be a >>> > quick fix to merge the changes against the ioquake3 trunk. This >>> > should get you 95% of the way there. >>> > http://pastebin.ca/1885022 >>> > >>> > This one would apply cleanly if pastebin didn't mess up my diff. >>> > There's one reject when you try to apply it. This is a lot messier >>> of >>> > a diff because it includes my UrT changes and 27's bumpy changes. I >>> > would use the first one if you want to move the code upstream. This >>> > gets you 100% of the way there after fiddling with the diff so it >>> > applies cleanly, but it has a lot of UrT changes. I would use the >>> > other diff. >>> > http://pastebin.ca/1885028 >>> > >>> > Note that both diffs need a tiny patch that 27 posted on the forums >>> to >>> > fix a bug with the bumpy code after I made the diffs. You'll also >>> > need the glsl/*.cfg files from the binary version (his other *.rar). >>> > I put them in ~/.q3a/q3ut4/glsl/*.cfg >>> > > > You may also have a look at > http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 > That patch is based on Tremulous, but the sources are almost identical to > ioquake3 (except the directory is called src instead of code, so you'll > have > to mv code src; apply patch; mv src code) > > It doesn't provide many graphical enhancements (yet), but it attempts to > compile the Quake3 shaders into GLSL shaders. The benefit is that even > multi-stage shaders can be rendererd in a single pass and it can always > use > static vertex data from VBOs. > > Unfortunately OpenGL before version 3.3 does not provide the blend modes > required to compile any possible Quake3 shader, so in these cases it falls > back to the original fixed-function multi-stage renderer. > > Otherwise all deform, texgen, texmod and rgbgen instructions in the shader > are computed on the GPU, the world and model vertexes are uploaded into > VBOs > at map loading time and so the CPU just has to handle the sprites, decals > and text output. Also dynamic lights and fog are rendered in separate > fixed-function passes, but I plan to integrate them into the GLSL shaders > in > the future. _______________________________________________ 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.
