skullernet / q2pro

Enhanced Quake 2 client and server
GNU General Public License v2.0
248 stars 87 forks source link

How to increase the 10hz tickrate ? #177

Open voivodpl opened 5 years ago

voivodpl commented 5 years ago

I'm developing a sp/mp mod that is heavily based on weapon kick angles and pain kick angles. 10hz tickrate makes it quite choppy and kinda unpleasant. Also I would like to make more accurate representation of chaingun, that would require at least 30 tickrate to fire each bullet on different frame instead of 3 bullets in one frame(right now it accelerates to 5 shots per frame haha!). I've already written the code, but was quite dissapointed when discovered it would not work cause of engine limitations. I've added quite long railgun fire delay and it would be constant and not depending on players ping. This is definitely not for purists, but since there aren't many developers and players for quake 2 right now the mod could refresh the player base.

sthalik commented 5 years ago

10hz tickrate makes it quite choppy and kinda unpleasant.

It shouldn't, unless you're using original q2ded. With the new protocol things are way smoother. Most importantly, you probably have a bug somewhere else if it looks choppy.

There's a server capability flag for marking your server as variable fps-capable. For this to be viable, you need to replace hardcoded frame times like baseq2 does. In fact I'd recommend basing your changes on q2pro's baseq2 with many bugfixes.

Instead of making such changes with unknown implications, I recommend you contribute to q2pro, opentdm and the like. It's not hard to jump into either codebase.

voivodpl commented 5 years ago

Well I'll take a look at q2pro. For now I'm on 3.24 by Knightmare(baseq2). Is there a tutorial how to convert hardcoded frame times ? I might release the code so anyone could fix any errors or bugs or merge the mod into their game dll when it's like done. I still have much to do to switch to bug tracking instead of developing :P. I might consider "contributing" when I learn how to properly code :). I would like to include gladiator bots, but I'm having trouble compiling. And addressing to "changes with unknown implications" - I'm all about that. How can you make something new and exciting without experimenting ? :P

sthalik commented 5 years ago

Is there a tutorial how to convert hardcoded frame times ?

There are usages in baseq2 and opentdm. Rebase your changes on that as soon as possible rather than having to do them all over again.

And addressing to "changes with unknown implications" - I'm all about that. How can you make something new and exciting without experimenting ? :P

Depends how you like chasing random bugs with unknown causes.

voivodpl commented 5 years ago

Depends how you like chasing random bugs with unknown causes.

Haha! Well I've already spent like whole day modifying one function. Well yeah, already have one unknown bug, but it's not that important to fix right now. :)))

voivodpl commented 5 years ago

Too bad I didn't know that Q2pro source is superior to 3.24 unofficial ;). So what I need to know to port to the new protocol ? I see that in defines you use the "f" character which propably tells the engine to use variable frame rate. I see the changes when setting the next frame time on entities.

voivodpl commented 5 years ago

I'm having trouble running in "variable fps mode". I'm using official q2pro binaries. I think i searched everywhere for info and all I can tell is propably official builds don't have variable fps flag set because I don't even have sv_fps cvar. I'm really confused.

sthalik commented 5 years ago

You're doing something wrong, given that sv_fps exists even when the game.so library doesn't support variable tickrate.

voivodpl commented 5 years ago

q2demo, 3.20 point release, newest q2pro binaries

No sv_fps cvar when q2pro or q2proded launched.

sthalik commented 5 years ago

The Friendly Manual has details on this. On my end, I'm not providing further assistance.

voivodpl commented 5 years ago

Does anyone test current windows builds from http://skuller.net/q2pro/ ? I ran through manuals and code multiple times. I use gamex86.dll that comes with q2pro, so I'm guessing source doesn't compile with the variable fps option.

skullernet commented 5 years ago

Just to clarify: nightly builds are built without CONFIG_VARIABLE_SERVER_FPS option. Baseq2 game library that comes with Q2PRO has not been converted to variable FPS. Only OpenFFA mod has been converted (and similarly needs CONFIG_VARIABLE_SERVER_FPS option to be enabled at compile time).

Also, primary objective of variable FPS mode is to reduce perceived latency of entity movement. Things like weapon animation, kick angles, etc are still run at 10 Hz even in variable FPS mode. You can't change that without breaking compatibility with older clients that don't support variable server FPS. (If you are developing a standalone mod and compatibility is not a concern, then of course, go ahead).

voivodpl commented 5 years ago

THANKS a lot for clarifying this! I was going nuts over here... Gonna look to OpenFFA for answers. Someone(not busy enough) could write a tutorial how to port mods to variable fps. It(VSFPS) should became a standard. 10 server fps is just absurd. Your start ping(actually latency) is 100+ ms.

Yes I know what higher server fps means. For firing more then 10 shots per second I'm just gonna hook to server frame ;).

Wonder why ID was short sighted and didn't include higher server frame rate in the first place. It's one of those reasons majority of players moved to q3 that had 30(AFAIK) server fps and was much smoother. Maybe that was intented.

adem4ik commented 11 months ago

It seems like they increased tickrate to 40Hz in the rerelease as well as introduced some lag compensation: https://www.youtube.com/watch?v=2ZRngIXCick

https://github.com/stephen-hill/quake2-enhanced : As part of this release, all internal logic in the game DLL has been adjusted to run at 40hz compared to the original 10hz of the original engine. This provides a better gameplay experience, and allows maps and game logic to run at more precise steps than the original 100ms. 40hz was chosen as it is a multiple of the original 10hz, operates at an integral 25ms step, and was the best balance between bandwidth and CPU concerns around the original tech.