A few notes here.

You want com_maxfps 125 if you're going to take advantage of Q3's physics rounding behavior. You can test this on a map called Ultimate2 by Immortal. Go into the portal room, select the jump room, and see how many levels you can clear. If you can't make the top level then you're not getting maximum air.

r_displayrefresh is only forcing the display driver's screen refresh rate, not the game's logic. r_displayrefresh has to be set to a HZ value your monitor supports. If not, you'll either get kicked back to 60Hz or your screen will go black until you exit the game (depending on your video driver). If you want the game to run faster internal frames you need to set sv_fps higher. This only works server-side to change the game's internal clock. The default for Q3 is 20 Hz, which gives an 8 msec server frame time. Just keep in mind that if you're hosting a server it also speeds up the snapshots being generated so it WILL increase network overhead if the client requests snapshots at a higher rate.

Speaking of, you can set "snaps" to a higher value to reflect what the server is running. A snaps of "40" will request snapshots at 40 FPS instead of 20 FPS. If you want buttery smooth play on a local game do sv_fps 125 and snaps 125. If you play online you will be limited to the server's sv_fps so additional snaps will be wasted. Playing with a snaps of 40 online is recommended. (You'll also want to up cl_maxpackets to a value like "100" to prevent your movement from being choppy to other players. Some servers will kick you for "cheating" for using too low a value).

Setting r_swapinterval to "0" will disable vsync, but the problem is setting Sync Every Frame in the menu only sets r_finish to "1". This just tells the GL handler to finish it's functions before rendering a new frame. It will NOT prevent screen tearing on a monitor that is not using Freesync or Gsync. Freesync and Gsync can prevent screen tearing but if you want to use black frame insertion to reduce blurring you may not be able to use both at the same time.

Changing overbright bits is still a bit of a workaround. The problem in Q3's code is with a line in win_gamma.c that does this:

"if ( vinfo.dwMajorVersion == 5 && vinfo.dwPlatformId == VER_PLATFORM_WIN32_NT ) {"

That locks the gamma ramping in Windows 7 an later. The "==" needs to be changed to ">=", which can only be done with a source port.

OK. Couple things:

Although I appreciate the advice of some things that I didn't mention in the video, there's a lot of things in your post that implies that I said some incorrect stuff...even though I actually didn't say that stuff in the video.

- I never said that r_displayrefresh affects game logic. I said it affects the monitor's refresh rate.
- or that r_swapinterval will offer vsync even on a Freesync or Gsync display. I only said that r_swapinterval is another way to disable vsync in-game without having to always exit and change vsync settings in your driver's settings.
- I also never said that "Sync Every Frame" will prevent screen tearing. I said it will reduce lag, which it does.

I don't mind some of the other stuff you brought up, but sv_fps, cl_maxpackets, and using source ports is beyond the scale of this video. It's simply a tutorial to get the original Quake 3 executable to run properly on modern systems as close as possible to how it did 20 years ago.

I still disagree with a few things. And that is I still believe there's no difference between setting com_maxfps to 120 or to 125. Both will be rounded off to 125 except when you enable vsync, that is unless you thought I was talking about any number that isn't 120.

And no, changing overbrightBits is not a workaround. r_Ignorehwgamma and r_intensity messes with the look of how the engine handles lighting, like how some shadows are not any darker than a texture that is not in shadow. OverbrightBits when combined with MapOverbrightBits only effects the brightness and contrast of the image as a whole, rather than only affect some of the elements.

Αναρτήθηκε αρχικά από lllDash:

- I never said that r_displayrefresh affects game logic. I said it affects the monitor's refresh rate.

What you said in the video was that it makes the game "run slower". To me, "running slower" means a literal slowdown. I misinterpreted what you said as logic vs refresh. Sorry about that.

- I also never said that "Sync Every Frame" will prevent screen tearing. I said it will reduce lag, which it does.

I understand that. I was simply pointing out some of the issues with disabling r_swapinterval and enabling gsync or freesync on a monitor. I have to use black frame insertion or I cannot look at an LCD screen due to the blurring effect, even at high FPS. Others may have that issue, so that's why I brought that up.

I still disagree with a few things. And that is I still believe there's no difference between setting com_maxfps to 120 or to 125. Both will be rounded off to 125 except when you enable vsync, that is unless you thought I was talking about any number that isn't 120.

I have to speak with authority on this as I've been all inside the engine and physics code. I worked alongside a fellow named puma to improve on Haste's pmove_accurate code, which sought to address the framerate-dependent movement physics in Q3. I'll explain.

The problem with the physics behavior is this line in pmove_single:

trap_SnapVector( pm->ps->velocity );

trap_SnapVector rounds the float array up or down to save on bandwidth, which was important since dial-up modems were still a very real thing when Q3A was released. Depending on the frame rate this rounding causes jump height to vary, which in turn affects the transition from PM_Airmove to PM_StepSlideMove when encountering a ledge. At 125FPS you can step onto certain ledges that you cannot at any other frame rate. You can load up charonq2dm1 (Return to the Edge) and try jumping directly onto the large crates in the megahealth room and you will never get up on them with r_swapinterval "1", r_displayrefresh "120", and com_maxfps "120". If you set com_maxfps "125" and r_swapinterval "0" you can jump onto the crates fairly regularly. That 5 fps makes a huge difference in physics. Removing the trap_SnapVector statement removes the rounding and makes the physics the same at any frame rate, but it does not allow for the "sweet spot" that 125 FPS did with the snap present. What puma and I did was to work out how the rounding errors were stacking in order to replicate the 125 FPS Z stacking at any frame rate higher than 20FPS. I have incorporated this physics correction into Generations Arena's current internal build, so please understand - I mean no disrespect, I am simply 100% certain of how this works because I and other users have tested this behavior to death, and data is data.

And no, changing overbrightBits is not a workaround. r_Ignorehwgamma and r_intensity messes with the look of how the engine handles lighting, like how some shadows are not any darker than a texture that is not in shadow. OverbrightBits when combined with MapOverbrightBits only effects the brightness and contrast of the image as a whole, rather than only affect some of the elements.

Actually that's somewhat incorrect. r_mapoverbrightbits and r_overbrightbits specifically affect vertex lighting calculations, lightmap, and lightgrid calculations. This is done when RE_LoadWorldMap parses all the shaders. This is called exactly once by CG_Init after a level change or subsystem restart (vid_restart). It is not called on the fly by the renderer. The only way to affect the scene as a whole is to render a single quad from the existing framebuffer and execute a shader command on that quad. Again, I've done this for a greyscale, color inversion effects, and for view blends, and I know that changing any overbright settings messes with the dynamic lighting as I've been all over the dynamic lighting code as well. If you load Q3DM1 and fire a rocket into the torches with a source port that corrects the gamma ramping OS version check you'll see a difference between that and changing r_overbrightbits and r_mapoverbrightbits and then raising r_gamma. This might not be a big difference to some users, but it is a difference. Will most players care for vanilla Q3? Maybe, maybe not, but if you're running a mod that heavily uses dynamic lights that's going to be noticeable.

Look I'm not trying to dismiss your attempting to help fix Q3. It's just that I have been working to fix a lot of these same annoyances in my own source port and game logic, such as the view weapon lowering at higher FOV's, Q3's stupid "add to texture" dlight behavior that makes bright textures brighter and doesn't light dark areas, the broken gamma ramping in the 1.32b code as well as the fps-dependent movement physics. I simply have experience in these matters and wish to share what I know about how the game works under the hood.

Does the physics rounding happen at higher numbers to? Modem PC can run this in 4k@999 fps so would make sense to pick a higher number than 125 these days esp since monitors refresh rates are much higher than that too.

I noticed that fps 250 locks at 250 but if you set it to 251 then max fps shoots up to 333. Just tested the mega health jump on q3dm13 and I can seemingly do it so easily now it feels like cheating. At 125 I only made it up half the time and only if I was strafing when I jumped.

Also gotta say sv_fps 40 made a huuuuge difference. Feels like a thousand % better esp at higher frame rates when it used to just get more jittery the higher the fps for some reason.

Increasing it 125 actually made unlocked 1000fps being smooth af (wich it jumps to if you set maxfps to 501 lol) but also made me feel heavy somehow. Like with lower snaps/sv_fps at 1000 i could somehow get more air time.

Increasing sv_fps cuts the snapshot time down so there's less interpolation going on. Q3's default sv_fps of 20 means a snapshot gets generated every 50 milliseconds. At 40 that generates one every 25 milliseconds. At 125 the server generates a snapshot every 8 milliseconds. Just be sure to set your "snaps" setting to the same as the sv_fps so that the client is pulling snapshots at the same rate the server generates them. This is more important for online play as opposed to a local game, but if you do a dedicated server and connect in to it, that will make a difference.

Setting com_maxfps to a very high number will end up capping the physics rounding since it's predicting the movement on the client with only a 1 or 2 millisecond gap per client frame. That's also why it shoots from 501 to 1000 since 500 would be 2 milliseconds, 1000 is 1 millisecond, but 501 would be 1.996007984, which doesn't work since milliseconds in Q3 is an integer, so it gets truncated to 1 millisecond.

That's the same thing going on with the com_maxfps 251 jumping to 333. 1000 divided by 250 is 4, a nice round number Q3 likes. 251 divides out to 3.984063745. Q3 truncates that to 3 milliseconds per frame, which would be 333.3(repeating), but the decimal again gets discarded.

So I don't know why but my original copy of Quake 3 Arena stand alone seems to run better than the steam version. Even custom maps and models load better.

I even see a51 and crom ctf
and excessiveplus server

to bad most of them wont allow vpn

:p

best game tho

good to see servers still going