Tremulous Forum
General => General Discussion => Topic started by: baybal on March 15, 2010, 07:00:10 am
-
I think default tremulous branch should begin merge with tremfusion just by obvious performance reasons:
People still having slide-show when plating atcs and having lots of models in frame i.e. humans jammed in their base.
Load times can be made even smaller
Hack-prooveness from client side, i.e. server can't order clients do rm -rf / by any way.
The main improvements here are SSE2 and use of vbo + reworked smp code, now just renderer thread made off independent, helps realtimeness.
-
Well, as far as I know the VBO code has never been merged into a released version.
If you're interested in testing some beta quality stuff, I can post a patch that uses VBOs, VAOs and GLSL to move most rendering onto the GPU, but it still has some issues (not all quake shaders can be compiled to GLSL, mirrors are not clipped correctly, etc.)
-
If anything, id love to see tremulous ported to the quake 4/doom 3 engine, oiquake4. However, ioq4 hant been publicly released yet so i guess we'll have to wait :).
ORZM GRAFX
(http://pcmedia.gamespy.com/pc/image/article/611/611006/440Building_B_Marines06_1115438005.jpg)
-
This is one of the most obvious troll attempts in a while.
-
Well, as far as I know the VBO code has never been merged into a released version.
If you're interested in testing some beta quality stuff, I can post a patch that uses VBOs, VAOs and GLSL to move most rendering onto the GPU, but it still has some issues (not all quake shaders can be compiled to GLSL, mirrors are not clipped correctly, etc.)
Would be neato with a patched gpp for increased performance.
-
I think default tremulous branch should begin merge with tremfusion just by obvious performance reasons:
Tremfusion to tremulous would make more sense but no.
-
tremfusion is great yes but it does have some bugs that would need to be dealt with before a merge would ever be considered by either dev team IMHO and seeing as the last update to tremfusion code was 4 months ago i doubt any bugfixing will happen for quite a while.
Well, as far as I know the VBO code has never been merged into a released version.
If you're interested in testing some beta quality stuff, I can post a patch that uses VBOs, VAOs and GLSL to move most rendering onto the GPU, but it still has some issues (not all quake shaders can be compiled to GLSL, mirrors are not clipped correctly, etc.)
would be good to have. how about adding it to here: http://patches.mercenariesguild.net/index.php?project=4 (http://patches.mercenariesguild.net/index.php?project=4)
-
If somebody arguing about VBO giving negative performance increase why not just add a cvar to set it on off? And as a whole, merge can be one sided, like just getting some essential patches from tremfusion for 1.2
-
http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 (http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4), use on your own risk.
-
http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 (http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4), use on your own risk.
makes me lag crazybad(my guess is something isn't supported so its falling back to software rendering) and a few graphical defects thanks for the patch ill look through it later and make a custom one trimming off some things that might not be complete/working yet
-
I think when the official 1.2 is done, tremfusion will finish up it's shit. The "trem devs" will never accept it though as anything official so it wont go on the front page, even though it should.
-
http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 (http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4), use on your own risk.
makes me lag crazybad(my guess is something isn't supported so its falling back to software rendering) and a few graphical defects thanks for the patch ill look through it later and make a custom one trimming off some things that might not be complete/working yet
Ouch, on what kind of hardware ?
-
http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 (http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4), use on your own risk.
This completely breaks rendering of pretty much everything for me.
-
http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4 (http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4), use on your own risk.
makes me lag crazybad(my guess is something isn't supported so its falling back to software rendering) and a few graphical defects thanks for the patch ill look through it later and make a custom one trimming off some things that might not be complete/working yet
Ouch, on what kind of hardware ?
gf9600gt it should be able to do most things its not that old running semi-latest nvidia drivers 190.42
i doubt you wanted the other stats but:
Linux Slacker 2.6.30.5 #1 SMP Mon Aug 17 13:33:26 EEST 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux
2GB ram
heres a few pics of graphical glitches i mean
pic1 is of the lighting see the stuff to the left that was just zapped by a mara
pic2 is a dude that has been clipped too much 1/2 of him is missing
pic3 is the chaingun which also makes your fps go down rapidly i got to 2 fps in 1 game
it also broke my console transparency:/
-
Hmm, I run it with normal FPS on a GeForce 6600, NVidia 185 driver. Can you try to disable the extensions r_ext_vertex_shader, r_ext_vertex_buffer_object and r_ext_occlusion_query to find out if it is related to one of them ?
A few graphical glitches are related to color clipping, the q3 engine has to compute colors on the CPU and pass them via OpenGL to the GPU, so they are automatically clipped to [0,1]. When I generate the colors in a shader program, they are not clipped, so color values above 1 or below 0 are possible, you can see this on the booster. The booster shader has a sin rgbGen that goes between -1 and 1, but in the normal game it is clamped at 0, while in the GLSL code it is not, so the color gets darker than normal.
The clipping bug is strange, it looks as if there are some refEntites not rendered.
-
Also, when just using this patch for a certain amount of time, the game segfaults or falls back to the menu complaining of memory allocation problems.
-
But generally it give a performance increase?
-
[deleted]
-
I did VBO testing a while back on my GeForce 5200-FX and it did more to hurt performance than help it. From what it seems like to me, it doesn't help much with older video cards, and Trem has lots of players on old gear.
-
[deleted]
-
So why don't we port those patches and add a cvar to toggle them on/off? I think it will be a quite sane solution. I think that non-accelerated geometry is an only one thing that gives a performance degradation in lots of models + high resolution scenario on new hardware.
-
This is the only patch that adds graphics functionality without messing with the shader system or requiring special opengl extensions. With that in mind it's the only patch that has any remote chance of making it into Tremulous SVN, considering the aforementioned demands it meets.
-
I would say that tremfusion has much more than this. Tremfusion although is pretty much dead now. What we have is a very good patchset just laying in their SVN. It's just a go and take it situation. I don't know why so much of people are objecting to it so much. What I'm proposing is not to impose higher GFX requirements, but to take patches that fix quirks of current tremulous code and add features like freetype support.
-
[deleted]
-
Most open source projects start as a buggy patch set of half baked ideas. Nevertheless, some evolve into something useful.