Author Topic: Tremfusion merge (Read 7688 times)

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.

gimhael · « **Reply #1 on:** March 15, 2010, 09:39:24 am »

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.)

3th4n · « **Reply #2 on:** March 15, 2010, 02:46:13 pm »

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

Lava_Croft · « **Reply #3 on:** March 15, 2010, 08:37:37 pm »

This is one of the most obvious troll attempts in a while.

Cadynum · « **Reply #4 on:** March 15, 2010, 09:06:37 pm »

Quote from: gimhael on March 15, 2010, 09:39:24 am

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.

CreatureofHell · « **Reply #5 on:** March 15, 2010, 10:15:43 pm »

Quote from: baybal on March 15, 2010, 07:00:10 am

I think default tremulous branch should begin merge with tremfusion just by obvious performance reasons:

Tremfusion to tremulous would make more sense but no.

SlackerLinux · « **Reply #6 on:** March 16, 2010, 12:38:08 am »

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.

Quote from: gimhael on March 15, 2010, 09:39:24 am

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

baybal · « **Reply #7 on:** March 16, 2010, 06:00:41 am »

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

gimhael · « **Reply #8 on:** March 16, 2010, 07:52:49 am »

http://patches.mercenariesguild.net/index.php?do=details&task_id=231&project=4, use on your own risk.

SlackerLinux · « **Reply #9 on:** March 17, 2010, 03:34:02 am »

Quote from: gimhael on March 16, 2010, 07:52:49 am

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

Silver · « **Reply #10 on:** March 17, 2010, 07:20:52 am »

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.

gimhael · « **Reply #11 on:** March 17, 2010, 08:34:51 am »

Quote from: SlackerLinux on March 17, 2010, 03:34:02 am

Quote from: gimhael on March 16, 2010, 07:52:49 am
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 ?

Odin · « **Reply #12 on:** March 17, 2010, 08:52:46 am »

Quote from: gimhael on March 16, 2010, 07:52:49 am

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.

SlackerLinux · « **Reply #13 on:** March 17, 2010, 10:24:07 am »

Quote from: gimhael on March 17, 2010, 08:34:51 am

Quote from: SlackerLinux on March 17, 2010, 03:34:02 am
Quote from: gimhael on March 16, 2010, 07:52:49 am
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:/

gimhael · « **Reply #14 on:** March 18, 2010, 07:24:55 am »

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.

Odin · « **Reply #15 on:** March 18, 2010, 07:45:15 am »

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.

baybal · « **Reply #16 on:** July 24, 2010, 07:51:00 am »

But generally it give a performance increase?

Crava_Loft · « **Reply #17 on:** July 24, 2010, 01:09:32 pm »

[deleted]

Aelita · « **Reply #18 on:** July 25, 2010, 01:31:17 pm »

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.

Crava_Loft · « **Reply #19 on:** July 25, 2010, 10:54:28 pm »

[deleted]

baybal · « **Reply #20 on:** July 29, 2010, 09:53:23 pm »

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.

Odin · « **Reply #21 on:** July 30, 2010, 03:35:23 am »

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.

baybal · « **Reply #22 on:** August 03, 2010, 06:11:11 am »

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.

Crava_Loft · « **Reply #23 on:** August 03, 2010, 08:42:33 am »

[deleted]

gimhael · « **Reply #24 on:** August 03, 2010, 03:55:42 pm »

Most open source projects start as a buggy patch set of half baked ideas. Nevertheless, some evolve into something useful.

News:

Author Topic: Tremfusion merge (Read 7688 times)

Crava_Loft

Crava_Loft

Crava_Loft