Last I checked it's also unhealthy to stand still too much, make sure to get your five minute sits in!

The input thing calamari is talking about is actually important and could totally be applied to source engine if they wanted to waste a bunch of bandwidth. It would make input prediction feel a lot better and probably eliminate some of the 66tick hitreg issues.

The hard part is synchronizing this crazy input model with mouse location without making things feel weird. The right solution would probably look similar to some of the crazier forms of lag compensation.

The only straightforward and well-understood way to really eliminate input lag is to crank everything's tickrate/framerate/pollingrate up the whazoo, and always use all the input information available to the program in whatever way is most appropriate, never ignoring new inputs for any reason and always doing things in the right place in the engine code (don't sample input before you run your framerate limiter pls).

http://i.imgur.com/CnHGxly.png

Good luck.

@calamari
Mouse/cursor location IS independent of time sampling. Time sampling for input is only useful when you care about WHEN the thing happens. You want the absolute minimum latency possible for mouse/cursor location, you should ALWAYS use the most recent location and consume all mouse input events.

The reason for the input model in the post you linked is that some game engines have a hard time handling stutter, so they may drop actions or put them onto the wrong frame, making someone jump on a different frame than they hit the button in a platformer and causing them to die. Source uses a threaded networking model where only the server's view of the world actually matters, so this isn't important at all. I don't even have to get into how "virtual frames" is being misused here. The entire concept is totally irrelevant to the way source does input networking, it doesn't care. Input to the server is done x times per second no matter what, and if it's not, you have HUGE problems that this WON'T fix.

Sure, you want the mouse cursor input to be in sync with when you click your mouse buttons, but the threaded input command model already does that. In the worst case scenario, the command model will use a slightly later mouse location input than the renderer does, but that's still preferable to having the renderer have mouse input lag.

To be honest I expect way better of you than this.

mouse input has nothing to do with the scaling problems that post describes calamari, those are related to how moving left and right and such are functions that happen over a period of time etc wheras mouse input and cursor position is independent of time sampling as long as you're not using ingame accel. It has an effect on movement but the way fps games are networked it's only important at the moment it sends it out. source already has a threaded network command model in tf2 (and cs:go) so it's not an issue.

EDIT: phrasing etc.

Updated again, somewhat minor. Fixed site widths (which are only hardcoded because I'm really bad with javascript) and made the article titles on the front page width-aware:

http://i.imgur.com/rotv1qw.png

Alternate themes should be left to stylish sheets. Do one thing right and all that.

Also the brightness is the same as before but the text is also lighter so it's harder on the eyes. I think enigma should make the text closer to what it used to be. Not sure how far back the darker text was though.

Updated.

not upgrading until the window manager vsync fiasco is legitimately resolved

Yep, we need fixed stair stepping now. Being able to jump twice within 30ms is the only way I've been able to bunnyhop up stairs effectively.

In VQ3 and CPMA, stair code still works even if you're in the air. The problem is that the stair code indiscriminately maps you and your momentum to the surface of the stair, requiring you to have another jump queued if you want to keep bunnyhopping.

Reflex's movement code is so incredibly faithful that I'm going to assume the stair jumping problems I've been having are from the same cause.

This is desirable behavior to basically noone, especially since the stair code doesn't apply to tall ledges. They should prevent stair climbing from mapping your momentum to the stair surface if you didn't start out in the air.

The only thing I can see it damaging is the stair jump to RA on aerowalk... Which you could still allow to be done with some workaround.

What is CSPI

Fake sugars are actually really bad for your metabolism.

try removing it from /tf/maps again

corner clipping was glitchy because it was just a missed collision check, it's only mostly gone because they upped the server framerate which will result in everything else being better. if there were some non-glitch way to introduce it I'm sure they'd consider it.

What they should really do is make you stick to stairs when you run down them 8)
Then when they add crouching you can use that to clip down stairs for airstrafing like VQ3 players are obsessed with