ProQuake 4.36 (way higher FPS)

[Baker]

Download: ProQuake 4.36 - 1.5 MB (Source)

Far Higher Frames Per Second

If you are using glpro without using -gamma command line parameter or using dx8pro, you will get a huge FPS gain in this version.

In fact, the fps gain is high enough that I don't think there is a good reason to use the -gamma command line parameter.

The short version goes like this: I re-did the bonus flashes, pain flashes and so forth to NOT use hardware gamma (which is SLOOW) and instead do it the old fashioned glquake way. This means that you can have the benefit of the being able to adjust the brightness and contrast (type contrast 2 in the console) and not have the liability of slow screen flashes.

Other Changes

- WQPRO now has a contrast command (type contrast 2 or 3 in the console, 1 is normal) allowing enhanced brightness control. glpro and dx8pro have had this for a long time.
- Water blends work when not using -gamma. Gunter reported this problem.
- You can switch gl_texturemode on the fly; I broke this on accident a couple of versions ago ... typing "gl_texturemode GL_NEAREST" in the console makes glpro look WinQuakey.
- The overbright feature isn't present in this version, it will be back in a future version. Well, it is actually in the dx8pro version even in this release.
- Disconnects shut stop all ambient sounds, music and eliminate view blends. Historical annoying Quake bugs.
- gl_nearwater_fix 1 works. Accidentally disabled it in 4.34
- Multimap demo playback works. Again, accidentally disabled in 4.34 I think.

Combined with the mouse issue fix in 4.34 (re: Enhanced Pointer Precision), this is a very high quality build.

I believe it is free of any bugs, but if you find something let me know as I have made several modifications in the last few versions and it can be hard to check everything.

[Bruce]

Thanks!

[Polarite]

Good job on the update again Baker !
I get no fps boost , infact I lose 9,6 fps.
Not that it matters

Did some glpro testing on one of my pc's here :



Used this FF6 round1 demo : http://users.telenet.be/polarite/round1.zip

People who play on fov 90 will get more fps ofcourse glpro436 = 415,6 fps
Glpro400 seems to do well when using -gamma to the commandline.
U clearly see here that Bakers work on glpro payed off, good fps boost compared with the old version glpro350.


Baker dumbs up !

[Baker]

Might be something about your config (gl_polyblend 0?)

The brightness flashes when picking up a weapon, firing or a monster attack plus the damage flashes when not using -gamma use video card hardware gamma to flash the screen. A lot of people have complained that the fps really drops in those situations and I've experienced it myself.

On my desktop the fps gain doing timedemo 1 in glpro434 versus glpro436 was 300% (!).

I went from 91 frames per second to 274 frames per second on "timedemo demo1". Likewise, a few people had complained that dx8pro really slowed down during those flashes and that's gone too.

I'll probably end up doing some fps comparisons on a few different machines.

[MH]

I'll second the speed gain - 436 runs at about 4 times the speed as 435 did for me (and also seems a lot smoother with dynamic light updates too!)

It's also nice to not have my entire desktop flash when I run in a windowed mode.

[Baker]

Add: my laptop ... my FPS nearly doubled with glpro436.exe. timedemo demo1 went from 80 fps to 140fps.

I'll second the speed gain - 436 runs at about 4 times the speed as 435 did for me (and also seems a lot smoother with dynamic light updates too!)

It's also nice to not have my entire desktop flash when I run in a windowed mode.

That too.

Note: When I finally build a texture manager for my engine, I'm going to add the option to not use hardware gamma at all That option will apply gamma and contrast to the actual textures and upload them and such an option will eliminate the bizarre situation when using -window where if you want brightness and contrast it affects your desktop too.

[MH]

The only downside to that is needing to reload your textures if the user changes brightness or contrast while running a map. I just decided to live with the changed desktop gamma in windowed modes (it would be different if the D3D gamma functions actually worked as documented - or at all even, for that matter - and if the documentation could make up it's mind on what way they were supposed to work.)

[Polarite]

Updated

Ok i tested again with gl_polyblend set to 1 and no -gamma on the commandline.
Used this FF6 round1 demo : http://users.telenet.be/polarite/round1.zip
Glpro400 = 213,2 fps (with -gamma on the commandline its 374fps)
Glpro436 = 385,9 fps (with -gamma on the commandline its 384fps)

Clearly a bigg boost of 172,7 fps !

Test with timedemo demo1 :

Glpro400 = 182,5 fps (with -gamma on the commandline its 756,3fps)
Glpro436 = 741,8 fps (with -gamma on the commandline its 765,2fps)

Clearly a bigg boost of 559,3 fps but I don't think demo1 is a good value for testing this...

So gl_polyblend 0 or 1 doesn't matter much for glpro436
Good job Baker.

[Baker]

General notes:

1. I find it annoying that playing a demo or doing timedemo triggers the demo loop. I really don't like demo1 and such playing after playing a demo. Will have those commands clear the demo queue.

2. I notice in Quake that the next demo doesn't play if the menu is up. But does if the console is up. I'm going to make sure there isn't a good reason for that and if not, I'm going to see if I can fix that.


DX8 Build notes (Uses MH's Direct3D 8 wrapper to use "DirectX" instead of OpenGL):

1. d3d8 wrapper doesn't support setting the display frequency. I need to rework the video options menu a little so that a user isn't thinking they are actually able to set it.

2. At least my implementation of the d3d8 wrapper doesn't support vid_vsync and strange enough when full screen the FPS actually gets capped to the display frequency (vsync!) but when in windowed mode (no vsync!). So you can get higher fps in -window mode.

3. -fullwindow with the dx8 build effectively results in fullscreen mode rather than windowed mode that happens to be fullscreen. If you have dual monitors, the difference is that if you switch to an application on monitor #2 and Quake is windowed, you still see Quake. But if Quake is fullscreen, Quake disappears upon loosing focus.

4. Need to play with glPolygon offset because I get e1m1 quad secret area flickering (a bit of it) due to zfighting in dx8pro.

5. As indicated, I accidentally ported overbright lighting into the dx8 build upon implementation of the wrapper. I need to "unport" that so I can "re-port" that as a cvar.

Other stuff

1. Gunter has some "interpolation-friendly" weapon models. I need to upload them here and link them for anyone interested in using them. In particular, a well known interpolation issue is the nailgun where the animation looks a bit weird as the flash interpolates to the middle of the nailgun.

[Baker]

Homeworks ...

2. At least my implementation of the d3d8 wrapper doesn't support vid_vsync and strange enough when full screen the FPS actually gets capped to the display frequency (vsync!) but when in windowed mode (no vsync!). So you can get higher fps in -window mode.

The dx8 wrapper doesn't report vsync as an extension. Need to unravel the wrapper and compare versus d3dquake's just a curiousity to see why we have vsync off in fullscreen in d3dquake and vsync on in fullscreen in dx8 wrapper.

3. -fullwindow with the dx8 build effectively results in fullscreen mode rather than windowed mode that happens to be fullscreen. If you have dual monitors, the difference is that if you switch to an application on monitor #2 and Quake is windowed, you still see Quake. But if Quake is fullscreen, Quake disappears upon loosing focus.

Ah! Ok I made this work. Apparently the wrapper has some stuff that I'd normally expect to find in vid_wgl.c aka gl_vidnt.c

[Baker]

Test with timedemo demo1 :

Glpro400 = 182,5 fps (with -gamma on the commandline its 756,3fps)
Glpro436 = 741,8 fps (with -gamma on the commandline its 765,2fps)

Clearly a bigg boost of 559,3 fps but I don't think demo1 is a good value for testing this...

So gl_polyblend 0 or 1 doesn't matter much for glpro436
Good job Baker.

Maybe demo1 is an ideal test, but gaining 559 frames-per-second is nothing trivial

[MH]

I never implemented vsync; it's a bit messy as it requires a device reset, which needs careful planning/etc.

This will disable vsync in fullscreen modes:

	// popup windows are fullscreen always
	if (windowed)
	{
		// defaults for windowed mode - also need to store out clientrect.right and clientrect.bottom
		// (d3d_BPP is only used for fullscreen modes and is retrieved from our CDS override)
		d3d_CurrentMode.Format = d3d_DesktopMode.Format;
		d3d_CurrentMode.Width = width;
		d3d_CurrentMode.Height = height;
		d3d_CurrentMode.RefreshRate = 0;

		// required for windowed mode
		d3d_PresentParams.FullScreen_PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT;
	}
	else
	{
		// also fills in d3d_CurrentMode
		D3DFORMAT fmt = D3D_GetAdapterModeFormat (width, height, d3d_BPP);

		// ensure that we got a good format
		if (fmt == D3DFMT_UNKNOWN)
			Sys_Error ("failed to get fullscreen mode");

		// vsync off
		d3d_PresentParams.FullScreen_PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
	}

(you should be able to figure out where it goes. )

demo1 by the way isn't a bad test. I find it useful for benchmarking particle system performance (of the ID1 demos it's the particle monster). A demo that just stresses everything is fine for an overall benchmark, but doesn't give you any useful info beyond that.

That round1 demo looks useful to me too - I think I'm able to reproduce one of the crashes with it!

[Baker]

This will disable vsync in fullscreen modes:

Hello fake vsync

You know ... because like it somehow vsyncs in fullscreen but your code will make it not ... so like you haven't implemented vsync on|off but like this code will make it not vsync like the vsync that is what it is doing now ...

/End corny joke

[Panix]

I tried out ProQuake 4.36 on Shmack last night. It looks like WinQuake again which is cool but I had finally got use to the old GL Look so it took some getting use to. The speed thing is nuts though. I kinda felt like I had to relearn playing some because I felt like I was literally flying sometimes grappling around. I think I like it though because I feel like I'm camping if I'm not moving around constantly.

[lennox]

just now tried the new version, have to say, the fps issues i was having in win7 with older versions of proquake have been fixed without a doubt, i was getting around 180 fps before, now im well over 600 fps.