User panel stuff on forum
  14 posts on 1 page  1
Client Talk
2011-01-02, 18:15
Member
150 posts

Registered:
Nov 2006
Just found out this one.
Causes 1ms delay just like g_weapons.pak

If anyone knows about some issue that causes extreme fps drops in a non-normal way can add to this list.

Most of the issues have been around for years, thing is just noone really bothered to test things deeply.

This should be reported as bugs, but at least people can avoid huge fps drops until problems get solved (maybe never).

1 - g_weapons.pak
2 - gl_nailtrail 1
2011-01-02, 20:12
Administrator
886 posts

Registered:
Jan 2006
Is g_weapons.pak the file containing remodeled weapons? didn't know I had this file, but I do.
Hopefully one can live without it, if it saves delay.
Join us on discord.quake.world
2011-01-03, 13:37
Administrator
1864 posts

Registered:
Feb 2006
Did you report it then?
2011-01-03, 15:16
Member
485 posts

Registered:
Feb 2006
"1ms delay"?

g_weapons.pak has models and skins.

I don't see anything abnormal with the nail trails. FPS just drops cause there's a lot of fancy smoke. It drops with similar rocket and grenade trails too.
2011-01-03, 16:04
Member
347 posts

Registered:
Feb 2006
500 FPS is the same as 2ms delay. If you add 1ms to that your FPS will drop to 1000/(2+1) ~= 333. Of course it gets worse the higher your FPS become. At 2000 FPS adding 1ms means you drop to 1000/1.5 ~= 666 FPS.
2011-01-03, 18:50
Member
150 posts

Registered:
Nov 2006
Kalma wrote:
"1ms delay"?

g_weapons.pak has models and skins.

I don't see anything abnormal with the nail trails. FPS just drops cause there's a lot of fancy smoke. It drops with similar rocket and grenade trails too.

It tends to happen more when using "special effects", RL Trail without particles is fine. Quad Glow is fine.quad glow, etc, etc, the list goes on...

Use r_speeds 1 so you know what i'm talking about.

I forgot to mention it happens when you fire nails of course.
Try map ZTRICKS2, teleport n1, fire nails, i get like 300 fps drop.

Zalon wrote:
Did you report it then?

No, simply because i believe "they" won't bother...
2011-01-04, 10:01
Administrator
1864 posts

Registered:
Feb 2006
MatriX wrote:
No, simply because i believe "they" won't bother...

Like you won't bother to report it? :/
2011-01-04, 19:21
Member
11 posts

Registered:
Oct 2010
g_weapons.pak

Probably not low-poly models. But VERY high polymodels.

RL
About 100 vertices , original
About 1000+ vertices , the other...
I would say.

There is more to compute , more to draw.

But that isn't a bug.
Nicer models , actually a feature :]
If ones puter can handle it.
2011-01-04, 22:00
Member
347 posts

Registered:
Feb 2006
1000 vertices is NOTHING by today's standards though. 100 or 1000 vertices should not render at significantly different framerates.
2011-01-04, 22:27
Moderator
1329 posts

Registered:
Apr 2006
Does ezQuake support hardware T&L like Q3 does? Also, does ezQuake support LOD for distant objects? What's the OpenGL render path ezQuake uses? Does ezQuake use CPU or GPU for rendering particles?

It's funny how you think you can use any ancient engine, add features to it and think it could run million fps by just doing that. Sure, gfxcards (and even CPUs) are very powerful today, but if you do not support something on hardware level, it will definitely cut down the fps by a large amount, so "nothing" will become a burden.

If you want to accelerate polygon (vertex) rendering, you are going to want to implement hardware T&L support. If you want to go faster than that, implement tesselation support (OpenGL 4.0 feature). If you want to accelerate particle effects, you probably need to go multithreading.

I wonder if optimizing would make things different, however if you want to add stuff as you wish to ezQuake's renderer, you probably have to rewrite it completely to support newer OpenGL paths.
Servers: Troopers
2011-01-04, 23:58
Member
347 posts

Registered:
Feb 2006
Renzo wrote:
Does ezQuake support hardware T&L like Q3 does?

As I understand hardware T&L is automatic. Unless you do something extremely silly as transforming your own vertices instead of just using the OpenGL API you'll get hardware T&L.

Renzo wrote:
Also, does ezQuake support LOD for distant objects?

To my knowledge, no, but with the amount of triangles on screen at any time in your typical QW map, it does't make much (any?) sense.

Renzo wrote:
What's the OpenGL render path ezQuake uses?

The fixed function pipeline. Shouldn't make any difference though, since it's probably just implemented as a fixed shader anyway.

Renzo wrote:
Does ezQuake use CPU or GPU for rendering particles?

To render them it (obviously) uses the GPU. I am guessing it uses quads. The simulation uses the CPU though. A GPU implementation could likely speed things up.

Renzo wrote:
It's funny how you think you can use any ancient engine, add features to it and think it could run million fps by just doing that. Sure, gfxcards (and even CPUs) are very powerful today, but if you do not support something on hardware level, it will definitely cut down the fps by a large amount, so "nothing" will become a burden.

Not sure who you are addressing here, but I'll bite. The point of my comment was exactly that -- if ezQuake cannot handle a few more triangles then it can very well be considered a 'bug' and it should be fixed.

Renzo wrote:
If you want to accelerate polygon (vertex) rendering, you are going to want to implement hardware T&L support.

See above.

Renzo wrote:
If you want to go faster than that, implement tesselation support (OpenGL 4.0 feature).

Hardware tessellation is primarily meant to improve image quality (by making the GPU procedurally generate more triangles as you get closer), not to speed up rendering per se. Quake models already have a very low polygon count, so going any lower doesn't make much sense.

Renzo wrote:
If you want to accelerate particle effects, you probably need to go multithreading.

Actually the GPU is pretty darned good at moving particles around.

Renzo wrote:
I wonder if optimizing would make things different, however if you want to add stuff as you wish to ezQuake's renderer, you probably have to rewrite it completely to support newer OpenGL paths.

ezQuake could do with a lot of rewiring for sure. I'm not sure how much time is spent/wasted in the rendering phase though. It would be interesting to see some profiling with a breakdown of where most of the computation time is going.
2011-01-05, 01:35
Member
271 posts

Registered:
Feb 2006
Renzo wrote:
Does ezQuake support hardware T&L like Q3 does? Also, does ezQuake support LOD for distant objects? What's the OpenGL render path ezQuake uses? Does ezQuake use CPU or GPU for rendering particles?

No.
No.
The path that was depricated due to performance issues.
Both. Physics is CPU, actual pixels are GPU.

Quote:
It's funny how you think you can use any ancient engine, add features to it and think it could run million fps by just doing that. Sure, gfxcards (and even CPUs) are very powerful today, but if you do not support something on hardware level, it will definitely cut down the fps by a large amount, so "nothing" will become a burden.

If you want to accelerate polygon (vertex) rendering, you are going to want to implement hardware T&L support. If you want to go faster than that, implement tesselation support (OpenGL 4.0 feature). If you want to accelerate particle effects, you probably need to go multithreading.

Actually, the 'lighting' part of that is useless, as itsgenerally restricted to just 8 or so lights, and its generally ugly and per-vertex. Quake uses lightmaps rather than hardware lighting, which gives significantly better image quality in most scenes.
What you actually want is to not copy everything from system memory to video memory every single frame - to say 'this is the vertex format, draw verticies X through Y', rather than 'this is vertex 0, it it has this colour, this texture coord, this lightmap coord, this world coord, this is vertex 1, blah blah'.

If you want to accelerate particle effects, you would probably want to not change gl state constantly, as doing so causes syrchronisation points (aka: stall points). By that, I mean not using multiple gl*Matrix calls for each and every single friggin particle.
Multithreading particles is pointless, as you still need particles to be drawn at the same time within the frame. Actual particle physics are not the bottleneck.

Quote:
I wonder if optimizing would make things different, however if you want to add stuff as you wish to ezQuake's renderer, you probably have to rewrite it completely to support newer OpenGL paths.

Just using vertex arrays properly would be a significant improvement - its a gl1.1 feature.


as raz0 said, 1000 verticies is nothing for a GPU. I was rendering a million verts on my old geforce2mx card and still getting 77+ fps.
Its only slow if you have bottlenecks between each quad. Modern games use 10k+ verts *per model* - but those verts are batched properly.
Put it this way, an explosion where you check each particle individually will be slower than updating each vertex of each particle directly - anything involving linked lists is hard on a CPU's cache. But changing rendering state after every single individual particle is 50 times slower, and that's a bug in amfquake's particles.
moo
2011-01-05, 02:35
Moderator
1329 posts

Registered:
Apr 2006
raz0 wrote:
Actually the GPU is pretty darned good at moving particles around.

...snip...

It would be interesting to see some profiling with a breakdown of where most of the computation time is going.

I'm actually referring to Valve's source particle system that scales very good on multicore systems (example), if there was a bottleneck.

And yes, I was talking to Qqshka earlier about profiling ezQuake's bottlenecks, so it would be fun to see what's lagging the client down, especially with certain effects enabled.


Spike wrote:
Just using vertex arrays properly would be a significant improvement - its a gl1.1 feature.

Now that you mentioned it, I remember testing vertex array enabled ezQuake some years back. The problem was that the performance was actually worse than it was normally. Maybe a time for revisit then?


EDIT: Tested this using Q3A and r_ext_compiled_vertex_array. The difference is ~640fps (disabled) vs ~900fps (enabled) so there is definitely a difference in favor of using (compiled) vertex array.
Servers: Troopers
2011-01-05, 17:08
Member
150 posts

Registered:
Nov 2006
I don't have deep knowledge to understand how things work, i jus test and comment what i observe.

Thinking in a very basic way:

At the exception of g_weapons, would you confirm that all other .pak together in \qw would require as much "power" as the g_weapons alone ?
And this only occurs with g_weapons.
The particles.png, probably all effects alone or combined cause extreme fps drops, i don't know.

I remember seing a post once saying that if a map is faulty/bugged not properly built with some leak, it would cause extreme fps drop. Maybe that's what happens with g_weapons.
  14 posts on 1 page  1