ProQuake 4.90 Beta

[Baker]

ProQuake 4.90 Beta is available with a newly re-focused mission of what ProQuake is best at and how it is used. Download Link: ProQuake 4.90 Beta. Improvements include:

- Colored dead bodies support
- Stays connected while map downloads
- Single-pass video startup
- Particle optimizations for smoother fps during battles.
- DX8 renderer version enhancement/fixes

ProQuake is oriented towards NetQuake multi-player and looks like the original GLQuake with no modern graphical features, it offers a 1996 style deathmatch experience and is fast and stable. Source available, of course.

Note: I get performance from dxpro490 exceeding glpro490 by a huge margin on a new machine (it trails glpro on older machines by 10%-20%), and MH made the Direct 3D 8 Wrapper that makes the dx8 build possible.

[Syluxguy28O3]

cant wait to try it out!

[Baker]

cant wait to try it out!

And I can tell R00k anything he needs to know for Qrackization of anything he would wish. R00k is a large part of the reason we have really nice stuff to play on the servers.

[usernames]

Hey bro no hate bro, but this version runs slower on my PC than 4.51. Start up is faster though.

Edit;

Not that it makes a difference anyway since I limit my FPS to 400. Just FYI.

[Baker]

Hey bro no hate bro, but this version runs slower on my PC than 4.51. Start up is faster though.

Edit;

Not that it makes a difference anyway since I limit my FPS to 400. Just FYI.

On topic: I compiled it on a new setup. So that could be why. I'm not happy with the compiler optimizations or actually the file size. For version 4.91, I'm going to compile on my (obsolete) old machine. Still, since like yourself, most of us easily hit the fps cap, I thought getting this version out to be tested was a priority. I have several more improvements coming along, as I find the time.

[monoz]

will the engine be available for linux servers?

[Baker]

will the engine be available for linux servers?

For now, while I work on the stats system, the server engine I've been working on is going to be private while I add more features to it. Many reasons for this, including if you are going to evolve a stats system, you have to be able to change it at will until you get to support everything you want, and the stats thing needs live testing.

Which, of course it will be getting soon enough.

[MH]

Oddly, the GL version runs about 3 times as fast as the DX8 version for me. That's semi-expected as I get the same kind of performance with D3D9 on this machine (10 and 11 absolutely fly though).

[Baker]

Oddly, the GL version runs about 3 times as fast as the DX8 version for me. That's semi-expected as I get the same kind of performance with D3D9 on this machine (10 and 11 absolutely fly though).

On thiis laptop, the fps glpro490 hovers between 250 and 600 fps, the dx8 fps is between 400 and 900 fps. It's an ATI Mobility.

[monoz]

more than welcome to use my dedicated server to test it. I would love to have stats for my ctf (and soon to be cax server).

[MH]

OK, I switched over to my wee netbook with an ATI in and it's DX8 180 versus GL 170. That's at 800x600 windowed which is roundabout as good as it gets on this machine.

For comparison DirectQ gets almost 240 and Fitz (with fast lightmap modifications) gets 140. DirectQ is actually down from about 260 since last time I tried it on this machine since lately I've been trading performance for functionality and flexibility a little.

I believe that one of the reasons why Fitz was so much lower is because you're still using GL_LUMINANCE lightmaps, which should be faster to update (being both a GPU-native format and having less data). I see also that you've reverted to GL_SGIS_multitexture which this machine is not picking up, whereas Fitz is picking up GL_ARB_multitexture. That works in your favour because PQ is not going through the godawful R_DrawSequentialPolygon path whereas Fitz is (for brushmodels) and that's killing it on state and texture changes. Fitz frustum-culls per-surface so it gets tighter culling but it's not able to do the fast accept/reject tests that culling in R_RecursiveWorldNode each frame can get you (i.e this node is outside the frustum - great! - can automatically reject all of it's child nodes now; same applies for accept although GLQuake doesn't do that (software Quake does)).

I think that if you add a properly sorted GL_ARB_multitexture path for all model types you'll be pretty close to the limit of what you can achieve with traditional glBegin/glEnd code. There will likely still be software-side optimizations you can make, but in terms of the GPU you're not going to get much more than low percentages. I'd be interested in seeing what a vertex arrays version of your GL code can do - if you're willing to burn a little extra memory you should be able to setup MDLs so that they never actually need to have their verts updated at runtime (because you're not doing frame lerping) - just set array pointers and draw. Brush models would pull slightly ahead with ID1 content and more and more ahead as things got more complex.

If memory serves the DX8 code is already set up to work this way, although it's not as optimal as a native version would be, of course.

If you're also willing to trade a couple of percent performance I'd suggest going to GL_LUMINANCE16 lightmaps with 4x overbrighting for a nicer dynamic range and no loss of bits of precision. They should work on all GL1.2 hardware as well.

In theory you don't need that DX8 build at all. One you get rid of the old crap that makes Intels choke, a few nips and tucks (like that vertex array version I mentioned) will get it going like a train on almost any hardware. Only having one renderer to maintain would mean that you wouldn't have to worry about doing anything that might break compatibility with the other, which is nice.

[Baker]

OK, I switched over to my wee netbook with an ATI in and it's DX8 180 versus GL 170.

Kinda funny, is it not? I agree with all the client performance observations you've made.

We've got a more than adequate selection of clients that get the job done, but the server-side part of the equation is the weakness of this community. It is like having a strong left bicep and a neglected right bicep.

So many servers, yet so few stats and servers that facilitate action. Quite a few that setup in such a way to facilitate talking and sitting around arguing over teams and who plays and who doesn't .... which is the opposite of playing.

[@Monoz a time will come when this stuff is mature enough and road-tested enough to get installed on multiple servers, but gotta walk before you can run and it hasn't even had a day or live testing or tweaking yet. I appreciate the offer and I'll keep it mind as this evolves.]

[MH]

I've just got my obsession with client performance.

I'm suspecting that either NVIDIA have nerfed their drivers for GeForce (again!) or I've got some weird system bug (possibly interaction with something else I have installed) that's only manifesting in DX9 or below. It's interesting that there should be such a performance difference though, and it's got me curious as to the cause.

[Baker]

I've just got my obsession with client performance.

Well your whole wrapper deal means that both myself and any ProQuake using players don't have to get to worried about the quality of OpenGL drivers OpenGL drivers suck or don't work? Just dx8pro it.

It's better than stupid threads that go like "Uh do you have the latest drivers? No that one is bad uninstall it ..." Who wants that?

[Panix]

When you get stats going, you gotta talk Slot Zero into upgrading Shmack. I wanna laugh at Scoffer and SaToon's shitty stats.