If you're using a 3.5 mm audio device with two bands for sound on the plug, you can unplug the cable half way so that sound is played on both speakers.
Even if the rounding didn't happen, seems like there would still be some framerates that would be better than others, for achieving higher jumps. For example, in the graph on the right, at 1:48, the highest orange dot is not at the very top of the "ideal" parabola. But surely at some framerates, the highest orange dot would be closer to the top. Therefore the player's max height would be higher. The truth is, if you want variable framerates, and perfect physics, then you have to perform physics on a fixed timestep, and make your renderer interpolate between the timesteps. (Another option is to intentionally add randomness to your physics. Make your jump have a slightly random initial velocity. That's a pretty big game design change though.)
happens in tremulous too. Different physics numbers, but the medistation-armoury jump is a notable example of this too. In particular its only possible on 333 fps. Weird bugs also occur at 500fps where sound no longer works for the player and other players watching that player, and at 1000 fps client side physics prediction fails altogether but the player still can play, albeit not see what is going on. edit: You answered this bug in the last quarter regaring cl_maxpackets
Just ran through RTCW at 144 (matching monitor). Started a new playthrough and remembered capping at 333 FPS from W:ET. The difference is so huge in game that I had to look it up. Interesting video!
It's worth adding than later there were mods used for competitive play like OSP which introduced server side command called pmove_fixed and with this turned on the physics were no longer fps depended (not entirely sure if this was OSP or one of Quake Point Release patch addition). The same was with CPMA mod which I think was working like that out of the box.
1:08 - first time I ever hear someone say "per second per second" rather than "per second squared" and it sounds so off, but thinking about it, it actually makes more sense
You seriously need to record more stuff like this. I have been looking for the ideal voice to help me get to sleep. I found this interesting, but your soothing voice is the real star of the show here.
This is why you never use first order ODE solver, even for first order ODEs. They drift a lot. Euler method is basically something you should never use. 2nd order methods are easy to implement, and vastly superior. Just use Heun's method or Verlet method, as a better start. The rounding step is just stupid.
You can do network layer rounding since these variables are transmitted for visual purposes, but simulation rounding is an ouchie. Looks like they put it in the wrong spot by mistake.
I was wondering why I've just recently been experiencing bad launch pad trajectories and being able to jump so high! I've been on 333 FPS. Does being able to jump higher impact bunny-hopped forward speed? I swear I feel much more dexterous with this change. I've also been jumping over weapons and stuff, hah! I just started to run my own source so maybe I can put a toggle in, where instead of running everyone at a standard fps on the server (as you mentioned with the existing toggle), it'll just not do the rounding... I was just looking for general nerding out vids on the quake 3 source, and boom, an answer to a curiosity! Very interesting, thank you!
You can get sound on both sides if right click the speaker icon on task bar, go to devices, disable your soundcard, go to a friends house, phone back to your house, have somebody re-enable your soundcard, go back home, play the video and record it on your phone, then playback the recording held up to your left ear, while playing the video on your computer - for added realism turn your head to the left, so you are staring at whatever is on your left, so that your right ear is soaking up the decliious sound from in front of you.
Do you know if CoD 4 uses the same engine or gravity/movement implementation as well? It has the same behaviour with strafing/jumping, fps (125, 250, 333, 500 are used for different porpuses) and even uses the same name for the config variables. Nice video!
Wouldn't it have been a better idea to multiply the floating point number by a multiple of its base (trivial), then round to an integer, send that value, and then have the server do the opposite to "unpack" the package? With a 32-bit integer that should work. Or are you saying quake only used smallints? Assuming there is a large advantage to sending integers, anyways. Also, a floating point number should ideally only require sending two integers and it could be reconstructed directly. I don't see why there is an inherent advantage to doing sending an int.
I believe it very likely does not send the integers directly. You can combine together the data you are sending, effevtively doinh very simple compression, to send it over the internet. Also, representing a 32-bit float with a 32-bit int instead would save no bandwidth. It's both 32 bits. It only matters if you send less bits. Thus you would cut off some of the less significant bits to save bandwidth.
I saw a video once that explains how Quake 2 or maybe all Quake games are designed to pull the player towards the center of each map. Do any of you kno the video I'm referencing or have anything on this? I can't find it anywhere now.
533, then 1600 and with 1601 and over, the rounding causes the velocity to snap right back to the original after decreasing, so you keep flying forever
Cannot imagine the devs would allow that kind of niche advantage at this point in the games lifespan. For the sake of competition, I assume it’s normalized across clients just like he said at the end.
It depends on the server. On servers with pmove_bunnyhop 1, movement is fps dependent. On servers with pmove_bunnyhop 0, movement does not depend on fps. This is one of the side effects of the idiotic changes that were supposed to help beginners but instead just made a total mess of the physics and actually just harm the beginners in the long term. If you don't want to worry about such stuff then just play on classic servers. discord.io/houseofquake
That doesn't work. You can only use numbers that use round integer numbers in milliseconds. Anything that doesn't scale down to a even number does not compute.
Jesus Christ.... guys... guys.... boys.... we all think we know how to program, but John Carmack is out here making frame-based physics and doing memory bit manipulation to make his lighting work. He's the greatest mind in videogame programming history, hands down. Don't at me.
