Unfreeze FPS cap

[Sl33p3r]

Hi guys i have been playing on the unfreeze server for a week and i have a little problem. I played on the server with my normal Q3 and i had no problem, then i decided to download the unfreeze mod ioq3v6-unfreeze-client. I put my pak0 file in in it and it works perfectly.
The problem is i cant have it work at 200fps since im on a laptop and overheats it i need it to be lower like 125
i5 6198 GEFORCE 940mx
Im trying to lower it to 125 max fps with com_maxfps command but its not working. I tried changing it in the config but i dont think the ioq3v6-unfreeze-client even recognizes my cfg in base3 folder because i had to copy paste it from my Q3 because when i started quake from the unfreeze mod it never made a new cfg file.
Anyone have any ideas thx in advance.

[adminless]

hello and welcome to the forum

well, that's a good question, currently the unfreeze client, yes, it's hard locked at 200 fps as you noted. that was done to prevent at the least the people that use it to mess around with the client fps that only brought problems. so basically at the moment you're out of luck about changing the fps on the unfreeze client. it's possible may be that on the future I publish the lowend build at 100 fps instead, that could be a good idea, or just something else like that.

anyways by now all I can suggest you if you struggle real bad at getting 200 fps by lowering settings and so is to activate the vsync of your graphic driver, that will hard lock the game fps to that of your monitor that unfortunately are likely going to be just 60 fps but at least that should be very constant. the client command for the vsync is "\r_swapinterval 1" although it working is very dependent on the operative system as well as graphic card and driver. the best bet to turn off/on vsync is always by the graphic driver itself.

in addition if you struggle with overheat/power consumption I'd also recommend you to activate some sort of power saving plan on your operative system or limit it's cpu/gpu usage.

hope that helps

[Sl33p3r]

Ok i will try the Vsync, thx for the quick answer.

Edit : Yes it worked its locked now at 60 fps, but i dont really mind it i dont see much of a difference anyways.

[adminless]

ok, I don't know if you're still around but as I see that this is a common topic (people struggling to hit the fps) I finally carried on my intention to bring some sort of frame limiting to the mod and I pushed new update files you can get here. you don't need the whole thing just to get the fps limiting, you only need the ioq3v6 binaries corresponding to your system (either linux or windows). ok, in short I basically added two different frame limiters, they are accessed with the com_framelimiter client variable. I finally locked the lowend build at 100 fps (as I had initially mentioned) which made sense as a default for the usual average laptop with integrated graphics although it still permits to be limited even more to 67 fps with the command "\com_framelimiter 1" and additionally for those a bit more powerfull but may be not enough for smooth 200 fps you can get to 167 fps with the command "\com_framelimiter -1". the regular build defaults at 200 fps which is actually the recommended on most circumstances even if you can't consistently hit them 100% of the time (but are most of the time in the +170 range), no changes here, and optionally for those with a bit lower hardware it allows to be locked at 167 fps with the command "\com_framelimiter 1". no other combinations in between are possible beyond those, the only other option to get a frame rate in between is, as mentioned, via the vsync feature of your graphic card driver (real case example someone with a 144hz 4k monitor).

check it out and let me know if it finally helped your hardware to run some better.

[tar]

@adminless:

You provided new sources but the files are not included in a new version packed zip. I am not sure which files I should combine.

Furthermore, in my version (from end of January 2019) I am not able to get 125 or 111 FPS. Instead, with GSync ON & VSync ON it is flickering(!) around 97-100 FPS but I am using 120 Hz which is rather confusing. Did you also restrict the FPS in older versions already (to 100 FPS)?

I just changed my monitor refresh rate to 100 Hz, set com_maxfps = cl_maxpackets = r_refreshrate = "100" and still the FPS are flickering and not stable @ 100 FPS. I even set the meaningless r_swapinterval to "1" which had no effect. I remember having this issue long ago with my old monitor... I get headaches...

[adminless]

hello

I was going to make a thread about this small update around today probably but well as you ask me now, I'll break it shortly for you. it's nothing really huge, that's why I didn't package it and so, it only consist mostly in a few things as well as this fps limiting issue on lowend hardware. the pk3 files as well as the qagame files added support for the green armor (which is not gonna be used at UnFreeZe but it at least allow people to play cpma a-like maps, notably hub3aeroq3, on single player) which was missing as well as automatically remove the lagometer when playing a demo and automatically draw the timer when the server has a timelimit set (which again is not the case at UnFreeZe). the ioq3v6 binaries just have the fps variation (with the inclusion of the new com_framelimiter variable) I described here as well as a minor fix for taking levelshots. as you can see nothing really mainstream beyond the fps thing that apparently it was hitting a couple of guys here but at least it sets the foundation for future updates/maintenance.

so, as I know that you like to get the whole thing, the whole thing should be replace your qagame.dll something files inside your unfreeze directory by the ones on that ftp folder as well as place the new unfreeze1-dev-client.pk3 file next to your unfreeze1-client.pk3 file and then for the engine binaries, replace your current one at the top of the installation path by those provided there. I don't think, I'll package it for the reason I'm telling you they don't really bring enough as to go for a "release" they are just the typical development version to get going and address this kind of things.

if you get stuck or want to clear up something let me know, ah and no, the last files I provided here (the ones on the main thread and the ones you got) doesn't have any lock besides the 200 fps cap (both the normal, the intel as well as even the lowend) which is what accordingly to the real end users hardware feedback I ended up adding now.

edit: may be give a try to the lowend build and disable any sort of sync on your setup (graphic driver as well as monitor osd), my best bet, it gives 100 fps locked here.

[tar]

As those changes are not very important, I will leave it as it is without any new files.

I tested a bit further with local maps and observed this behaviour (all driver settings) @ 120 Hz:

q3 tests.png

As you can see: I could not recognize heavy differences between GSync ON or OFF but I needed to adjust my monitor game mode settings to "FPS profile" in order to get rid of 97-100 FPS flickering at 120 Hz (with VSync ON) and instead got a 117-121 FPS flickering (guess, the GSync module is overclocked by that). After I switched it back to "Player 1 profile" it stayed at the 120 FPS range (with VSync ON).

[adminless]

mmmm thanks for good feedback mate, awesome job yes, that's what I was talking about, it was just a quick update mostly pushed to target this, it's probably worth checking but that's all about it. then what I understand from your experience seems consistent with my general recommendation that probably the best shot is to leave the sync options alone (unless for the gsync in your case that seems to improve the things to some extend). as for the tearing I never suffered that much (that I noticed at least, I tend to notice the most stutter/choppy game and unresponsive/laggy input) although probably it's not the same a regular 1080p screen than a full size 1440p ultra wide screen. probably you could try disabling the smp code, "\r_smp 1", may be that helps on your specific situation, also the files I posted today may give a slightly more stable frame rate so it may be worth checking (for your case this one for a 100hz lock or this one for the full 200hz thing, no need to deal with the other files for you). anyways it's just a suggestion and it's not that much of a difference overall I guess, I hope on future versions I'll try to workout things a little better. thanks for report.

[tar]

I just noticed that r_smp was activated again - by switching it off some (heavy) stuttering effects went away and as far as I have researched, most stuttering issues could occur due to my Intel Xeon 1245v3 Quadcore from 2013 and corresponding CPU security patches.

Nevertheless, I still cannot understand why you skip the availability of:
- com_maxfps = 125
- cl_maxpackets = 125

Which is widely known as the perfect setting for Quake 3 and in Fernandinhos and my case would fit better to our monitors which run with 120 Hz (his old CRT and my modern UWQHD).

[fernandinho1337]

I just noticed that r_smp was activated again - by switching it off some (heavy) stuttering effects went away and as far as I have researched, most stuttering issues could occur due to my Intel Xeon 1245v3 Quadcore from 2013 and corresponding CPU security patches.

Nevertheless, I still cannot understand why you skip the availability of:
- com_maxfps = 125
- cl_maxpackets = 125

Which is widely known as the perfect setting for Quake 3 and in Fernandinhos and my case would fit better to our monitors which run with 120 Hz (his old CRT and my modern UWQHD).

i dont use CRT anymore switched last year

[tar]

i dont use CRT anymore switched last year

Oh, but still 120 Hz

[adminless]

ok, great news, I think I've already made that r_smp suggestion various times and as I'm starting to differentiate a bit more the lowend release I think that probably it will be better to default it to on for the lowend build (where it's needed the most, gain 10 or more frames over 90 definitively matters even if it's not 100% in sync) and to off for the rest (where it will probably might introduce more issues than benefits, gain 50 frames over 500 does not really matter particularly when the game tops at 200). thanks for feedback again.

I think we discussed the 125 fps thing several times already, in short it doesn't quite sync with the way the server is particularly configured and 200 fps are better. but anyways at this point I don't think that have a bunch of good old school clients doing 125 at the server (which there will always be btw) is gonna be such a big issue and it can also be interesting for the single player (which was included on the last release) as well as it may be interesting in the event I ended setting up a custom tournament server (I'm not committing to that but it's a possibility, I mean, last changes where on that direction of me doing more things with the UnFreeZe mod than just play at the "mainstream" servers). so I updated now the files again (only the ioq3v6 binaries, well, and I also added a funny four.pk3 file to test the fps) with a new special parameter, now "\com_framelimiter vq3", should give 125 fps on any of the binaries. in addition I also "unlocked" the local/single player server so now the single player/local server should feel definitively very improved. check it out and let me know (I think you already know, get ioq3v6-lowend.exe and ioq3v6-intel.exe and then replace on your local installation).

[fernandinho1337]

i dont use CRT anymore switched last year

Oh, but still 120 Hz

it is the sweet spot

[tar]

Your "four.pk3" did not work. I've tested it with an own demo (about 28000 frames) and the results are the same on both new binaries: 1225.6 FPS.

Settings:

Code: Select all

seta r_smp				"0"				// enables the use of multi processor acceleration code (0: off, 1: on)

// === display ====================================================================================

seta r_swapinterval			"0"				// vsync but no no in-game effect! use your graphics driver settings to activate vsync!
seta r_displayrefresh			"120"				// monitor refresh rate but no in-game effect! use com_maxfps instead if you have vsync enabled
seta r_refreshrate			"120"				// monitor refresh rate (no effect)
seta r_mode				"-1"				// resolution (see /modelist in console, -2 (ioq3): uses desktop resolution, -1: custom used with r_customheight and r_customwidth, 3: default)
seta r_custompixelaspect		"1"				// toggle the use of custom screen resolution/sizes (0: off, 1: on)
seta r_customwidth			"3440"				// resolution custom width
seta r_customheight			"1440"				// resolution custom height
seta r_fullscreen			"1"				// application window mode (0: window, 1: fullscreen)
seta r_picmip				"16"				// general level of detail, used with cg_nomip (0: highest, 16: lowest)

// === brightness =================================================================================

seta r_mapoverbrightbits		"2"				// brightness rendering of texture pixels (lower: darker, higher: brighter)
seta r_overbrightbits			"0"				// intense of r_mapoverbrightbits, r_fullscreen must be enabled (lower: darker, higher: brighter)
seta r_ignorehwgamma			"0"				// use directx gamma correction instead of video driver gamma correction (0: off, 1: on)
seta r_gamma				"1.4"				// brightness, only useable if r_ignorehwgamma is disabled (lower: darker, higher: brighter)
seta r_intensity			"1.7"				// intensity of texture colors (lower: darker, higher: brighter)

// === fps ========================================================================================

seta cl_maxpackets			"125"				// unfreeze: not changeable, automatically tries to send as much packets as possible

seta com_framelimiter			"vq3"
seta com_maxfps				"125"				// unfreeze: not changeable, use vsync to reduce frames per second
seta com_maxfpsminimized		"0"				// maximum frames per second when minimized
seta com_maxfpsunfocused		"0"				// maximum frames per second when unfocused

// === custom =====================================================================================

seta cg_autoswitch			"0"				// auto-switch weapons on pick-up (0: off, 1: on)
seta cg_drawfps				"1"				// frames per second display (0: off, 1: on)
seta cg_viewsize			"100"				// view port size (30 to 100)
seta cg_fov				"115"				// field of view (default: 90, lower: better frontal vision, higher: better peripheral vision)

seta cg_footsteps			"1"				// enables footstep sounds
seta cg_notaunt				"1"				// disables the ability to hear voice taunts (0: off, 1: on)
seta cg_nomapsounds			"1"				// unfreeze: disables ambient map sounds (0: off, 1: on)
seta s_musicvolume			"-1"				// sets volume level of music while in-game (unfreeze -1: deactivates also every map ambient sound, 0: off, 1: loudest)
seta s_volume				"0.06"				// sets volume level of sound effects while in-game (0: off, 1: loudest)


// === movement configuration =====================================================================

seta cg_bobup				"0"				// set amount player view bobs up/down while moving
seta cg_bobpitch			"0"				// set amount player view bobs forward/back while moving
seta cg_runpitch			"0"				// set amount player view bobs up/down while running
seta cg_bobroll				"0"				// set amount player view rolls side to side while moving
seta cg_runroll				"0"				// set amount player view rolls side to side while running
seta cg_bob				"0"				// unfreeze: dizziness when moving, replaced cg_bobpitch, cg_bobroll and cg_bobup (0: off, 1: on)
seta cg_kickscale			"0"				// unfreeze: dizziness when getting hit, replaced cg_damagekick and cg_fallkick (0: off, 1: on)

seta cl_freelook			"1"				// use of freelook with the mouse (ability to look up and down)
seta cl_mouseaccel			"0.12"				// the mouse speeds up or becomes more sensitive as it continues in one direction
seta cl_pitchspeed			"140"				// set the pitch rate when +lookup and/or +lookdown are active
seta cl_yawspeed			"140"				// set the yaw rate when +left and/or +right are active
seta cl_run				"1"				// set running mode (0: off, 1: always running)

seta sensitivity			"3.5"				// mouse sensitivity (depends on mouse, dpi, sample rate, etc.)
seta m_filter				"0"				// turn on mouse interpolation which makes mouse movement smoother, adds latency (0 to 33)
seta m_forward				"0.25"				// set the back and forth movement distance of the player in relation to how much the mouse moves
seta m_side				"0.25"				// set the strafe movement distance of the player in relation to how much the mouse moves
seta m_pitch				"-0.022"			// set the up and down movement distance of the player in relation to how much the mouse moves (negative numbers result in inversed mouse)
seta m_yaw				"0.022"				// set the speed at which the players screen moves left and right while using the mouse

exec _cfg/scripts.cfg		// scripts
exec _cfg/bindings.cfg		// bindings
bind f9					"give all; god"

nVidia driver: GSsync ON & VSync OFF

125 FPS are stable but with both binaries sometimes +attack is hanging after a rocket jump and bridge-to-rail still does not work.

[adminless]

mmmm that's rare I tried now deleting it and re-downloading it and the usual timedemo demo four thing just worked right away. that sounds to me like you probably miss-installed it or something, my best bet is that you put the four.pk3 in the baseq3 instead of the unfreeze sub-folder or somewhere else where your game didn't find it. just to be safe could you please try by deleting it and re-downloading it again (four.pk3) and placing at the unfreeze subfolder of your installation? don't worry that if this continues like this is very likely that on "some time" I end up making that temporal development package once we progress some further.

1225.6 FPS?!?!?! hahahaha ok ok that's quite good then, that shows off that the timedemo unlock fix worked and that's what I meant by the r_smp thing is not gonna add anything meaningful to you but probably the opposite. just for the sake of knowledge, could you please test that same demo with r_smp on (requires vid_restart) and see what value you get? my best guess is probably near 1400 fps (the problem with that is that the smp code runs asynchronously mostly, it's just not as consistent).

yes, the bridge to rail thing and those sort of specific 125 fps frame dependent physics tricks I remember we also discussed them long here. the thing with that is that, precisely as noted, those physics are dependent on the client frame rate and the problem we face here (and precisely on this thread that lead to the patch) is that not all people can hit the fps or consistently hit them, meaning that on regular vq3 physics they are at a clear unfair technical disadvantage (they can not move the same regardless of the skill, in fact, they move slower, jump less and so on just for that fact). and we also have the other situation, the people that prefer (or needs, 144-200 hz and even more monitors are common nowadays) to run the game at higher fps, as noted by miro once here then what we do with those guys? on regular vq3 those guys will move faster, will jump higher and so. this is because on regular vq3 various physics vectors are rounded to integers before being transmit, apparently in order to save the precious bandwidth of the internet modem era. and unfortunately the client frame rate determines at what time this rounding takes place this way effectively producing different results. I'm fully aware of the pmove physics that instead force every rounding to take place at the same time as I'm also fully aware of the problems that it causes to anyone that is not doing exactly 125 fps all the time. the only real solution to this problem is to simply transmit the full float vectors instead of a round up however that has the side effect to slightly differ from the "canonical" vq3 movement (regardless of the compensations that I'm also fully aware of). therefore on the "mainstream" servers those are the physics that I run and I will keep running and I'm not gonna change them because as can be clearly seen the server has to deal with a whole range of hardware/players not only ideal advanced players doing exact 125 fps all the time (in fact, I'd call those the minority probably) and make it fair for everybody. plain vq3 physics are probably the way to go for the local server, a lan party with your friends or just a top players side tournament not for a public server.

so that being said now that you bring the topic I think I could probably make that for the local server/single player at some point, sounds like a reasonable idea (a fitting scenery for those physics) and it may even could come in handy for a later event. as for the input issue that's more complicated, what is a new issue that you found on this specific build or it comes from before? I would have to dig it but stuff to try there is "\in_mouse -1" and see if you still experience the same issue.

ok, thanks for report.