i'm too paranoid to install an outside program for something that already works (afaik) in tf2

if you're used to tf2s raw input, why change?

Some people seem think it works better.

One such some person from the thread:

Interesting wording, I feel this often " this tends to make mouse movement feel 'disconnected' in a strange way
with what you are seeing on screen"

sounds like bs

I was actually looking into this yesterday. people have been saying raw input has issues (particularly in csgo but also other source games). some say its fine.

from what I saw the scarce evidence says raw input is implemented okay.
on the other side many people say raw input 1 feels odd and disconnected in source games

all I know is m_rawinput 1, 0, and RInput certainly feel different.
as for which one is better, who knows? its somewhat preference.
I would assume RInput is the best as there is no buffering.

The problem with RInput is injecting it. its a pain to do it everytime you start the game, makes people uncomfortable, might be banned at lan. This program helps somewhat I guess (already had a batch file for this so its not that special)

its kind of like back in the day where you could use CPL mousefix or you could use anir's fix which was slightly better but also invasive and banned at many lans.

you might as well put it in but let people make their own choice I guess
(personally I use accel driver so I can't use raw input anyways..)

placebo

I took a look at the source for RInput here: https://github.com/abort/Rinput-Library

What this code does is make sure the game has the most up to date cursor coordinate values that windows sends it. Depending on how mouse input is implemented in Source, and your fps, you may notice a different feel to your game, but this isn't how mouse input should be implemented in general.

In general, mouse input should be implemented in the way that's described in this post: http://www.gamedev.net/topic/641102-frame-independent-movement-and-slowdowns/#entry5049391
That method takes into account computers with variable fps and lag spikes on the whole spectrum.

For the specific case of having a high fps with no lag, sure, use RInput.

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.

I've been using it since I saw the thread. I like it, it certainly feels more consistent to me.

@wareya
You're incorrect in saying that mouse/cursor input is independent of time sampling.
As an example, during regular play, say you have a one second freeze, where the game appears to be frozen and not updating graphically. During this freeze, you could move your mouse left, click shoot, and move right back to the original position.

In an incorrect input implementation (possibly what Source does), those input events would all be processed in the next frame after the freeze is over. This would internally result in your position not moving because of the left and right movements cancelling out, and your shot firing in the original position, because to the game, your cursor didn't move.

In a correct input implementation, which is what that post describes, those input events would be spread over the virtual frame updates that were delayed due to the freeze, taking into account the timestamp of the frame being processed and the timestamp of each input event. After the game catches up, this would result in your cursor moving left, shooting, and moving back to the right, no matter if any of that is displayed graphically or not.

I'm not sure what you're saying about threaded networking and how it relates to this.

i remember i did a ton of research on this and I ended up making the conclusion that it's not worth using and the whole myth about raw input in csgo being broken is just that, a myth

can't remember the actual reasons though so don't count my opinion over some who actually knows what they're doing

edit: so I gave it a try and i changed my mind, it definitely feels much more consistent, might just be playing well tonight but I'd recommend you give it a go and decide for yourself

@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.

wareya why u so nerd

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

because he doesnt know what hes talking about
if you think the source engine is so perfect you have another thing coming boy

You're insufferable. Wareya is correct, tf2 already does what calamari's article is talking about because the server receives your input regardless of what is being drawn to your screen.

downpour's just still salty about how badly he got shit on by wareya.

"tf2_scientist"

Started playing this yesterday, with kind of bad fps and generaly shit hardware .
Feels different idk If its better though . Give it a try

wareya and setsul are my fav people on these forums

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).

dl link for the latest version?

Sorry, I hate registering for sites if I don't have to.

i input it raw, all the time

https://www.dropbox.com/sh/l4u5iiy9gkg17g7/AADECyGkVXX6TCCUgNXjd4r0a?dl=0

edit: the signup for that website took about 30 seconds and i don't get any emails from them

Still waiting on someone to chime in using words us dumb people can understand, does it feel better or not for hitreg ^_^?

assuming you're using this you set in game rawinput to 0?

^ does that mean a high fps that fluctuates? or is the no lag part meaning cap your frames to 289 and you don't drop below that kind of like mouseexcel.

For instance i don't cap my frames because of stutter issues, so I'm anywhere from 600 to 340 typically, 50-60ping no choke or loss.

Find something you like using.

Rawinput is purely preference for most people.
If your settings feel good to you, use them.