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

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.

Did you report it then?

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

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.

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.


No, simply because i believe "they" won't bother...

Like you won't bother to report it? :/

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.

1000 vertices is NOTHING by today's standards though. 100 or 1000 vertices should not render at significantly different framerates.

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.

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.


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.


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


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.


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.


See above.


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.


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


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.

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


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.


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.

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.



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.

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.