Linux locks and a kinder, gentler Linus
-
@LaoC said in Linux locks and a kinder, gentler Linus:
@acrow said in Linux locks and a kinder, gentler Linus:
@LaoC said in Linux locks and a kinder, gentler Linus:
If you have an input signal with 1 V of amplitude, a 16-bit ADC has to be precise to doable¹ 15 µV. To get 24 usable bits it would have to be <60 nV, which is completely ridiculous
True, but only if you're trying to do the whole 24 bits with one microphone and amp-chain. Try 2 chains side-by-side, with different sensitivity, synchronized so that you can switch between them on a sample-by-sample basis in post-production.
I've never heard of that one. How would you decide which sample to use?
When the more sensitive (higher gain) one is about to go out of scale, you switch to the less sensitive one. You'll want to pick a value that has a near match between the chains (after the gain difference is taken into account), to use as the switch-over point. Continue to use the lower gain one until the sound drops under the switch-over for a time again (not just a zero-crossing).
-
@Groaner said in Linux locks and a kinder, gentler Linus:
Plus lead time for movement, if it's projectile instead of hitscan. And, naturally, lead time is going to be a function of latency. I've played shooters that do both, and it really screws with you to play one that does it one way and then play another.
Can you give examples of the projectile variety, with distances that matter? Just curiosity; what I've played lately was either so close-quarters shooting that flight times would not have mattered (in reality anyway). Or using hitscan (apparently?), and I kept thinking that the shots I was making would have been impossible in reality due to flight time.
So I'd like to see one where I actually have to lead the target, again.I assume this is what latency-compensation algorithms are for. Such spikes, uncompensated, lead to lower game sales.
You can never get it 100%. Unless the game is client-authoritative garbage, what you see on your end is a creative illusion built from dead reckoning of old positional data, carefully tuned with heuristics applied to arrive at something that looks "good enough." I say this as someone who's been down that particular road.
I've been wondering about something: In the current crop of online games, when the dead reckoning is reconciled with actual server state, does it take into account shots that would have hit the illusion? And does it take into account whether both the actual position and the "illusionary" position would have actually been visible to the shooter at that moment?
-
@Groaner said in Linux locks and a kinder, gentler Linus:
client-authoritative garbage
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
-
@acrow said in Linux locks and a kinder, gentler Linus:
@LaoC said in Linux locks and a kinder, gentler Linus:
@acrow said in Linux locks and a kinder, gentler Linus:
@LaoC said in Linux locks and a kinder, gentler Linus:
If you have an input signal with 1 V of amplitude, a 16-bit ADC has to be precise to doable¹ 15 µV. To get 24 usable bits it would have to be <60 nV, which is completely ridiculous
True, but only if you're trying to do the whole 24 bits with one microphone and amp-chain. Try 2 chains side-by-side, with different sensitivity, synchronized so that you can switch between them on a sample-by-sample basis in post-production.
I've never heard of that one. How would you decide which sample to use?
When the more sensitive (higher gain) one is about to go out of scale, you switch to the less sensitive one. You'll want to pick a value that has a near match between the chains (after the gain difference is taken into account), to use as the switch-over point. Continue to use the lower gain one until the sound drops under the switch-over for a time again (not just a zero-crossing).
How would that help with stuff like thermal noise? Even if your ADC is perfectly precise down to 60 nV, a noise floor of 260 nV makes sure your LSBs are garbage. And usually your noise floor is significantly higher.
-
@acrow said in Linux locks and a kinder, gentler Linus:
Can you give examples of the projectile variety, with distances that matter? Just curiosity; what I've played lately was either so close-quarters shooting that flight times would not have mattered (in reality anyway). Or using hitscan (apparently?), and I kept thinking that the shots I was making would have been impossible in reality due to flight time.
So I'd like to see one where I actually have to lead the target, again.Off the top of my head, shotgun-like weapons tend to exhibit this behavior (especially things like the Flak Cannon in the original UT, where you can see the actual pellets traveling), as well as rockets and grenade launchers, obviously.
I've been wondering about something: In the current crop of online games, when the dead reckoning is reconciled with actual server state,
It depends on the architecture, but generally, it isn't. The server sends out updates at 30Hz, 60Hz or whatever to all connected clients that amount to "HEY EVERYBODY! THIS IS YOUR CURRENT POSITION AND VELOCITY!" Then, clients will either attempt to replay a "view" of the past, or optimistically extrapolate entity positions via dead reckoning and perhaps even perform physics simulations to arrive at a better solution. If entity positions are further away from their "correct" server values by more than some threshold value, they are typically snapped into place.
does it take into account shots that would have hit the illusion?
If it's a server-authoritative architecture, what the client sees matters not. I've heard of some implementations that try to mix what client and server see for a better view, but generally, I wouldn't trust any client-reported data as that opens the door to hackers.
And does it take into account whether both the actual position and the "illusionary" position would have actually been visible to the shooter at that moment?
Probably not. Keeping track on the server of what each client should see is a computationally expensive problem. In theory, you could traverse the scene graph for each player (I believe that'd be O(n2 log n) complexity with an efficient partitioning algorithm like an octree), and then maintain a visibility matrix, and that would actually give a couple benefits. First, you could pare down the amount of replicated positional data by ignoring invisible actors to each player, at the cost of your serialization layer being more complex and computationally expensive. Second, by not sending positional updates for invisible actors, you make it harder to implement a maphack. However, I think most industry developers, who are likely 22 years old and working 80 hour weeks, will opt for the simpler solution.
This guy has a bunch of articles to get you started on the topic. Traditionally, this was how client-side prediction was done, and here, he goes deeper into how interpolation and extrapolation can work.
-
@Jaloopa said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
client-authoritative garbage
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
Oh, client-authoritative is good UX for sure, until a hacker shows up and starts teleporting all over the place since all the other connected peers will consider his self-reported position to be gospel.
-
@LaoC said in Linux locks and a kinder, gentler Linus:
And usually your noise floor is significantly higher.
Definitely. I'm glad I was on the top floor when I lived in my apartment, as there was nobody living above me to toss bowling balls around their apartment while I was trying to sleep.
-
@LaoC said in Linux locks and a kinder, gentler Linus:
@acrow said in Linux locks and a kinder, gentler Linus:
@LaoC said in Linux locks and a kinder, gentler Linus:
@acrow said in Linux locks and a kinder, gentler Linus:
@LaoC said in Linux locks and a kinder, gentler Linus:
If you have an input signal with 1 V of amplitude, a 16-bit ADC has to be precise to doable¹ 15 µV. To get 24 usable bits it would have to be <60 nV, which is completely ridiculous
True, but only if you're trying to do the whole 24 bits with one microphone and amp-chain. Try 2 chains side-by-side, with different sensitivity, synchronized so that you can switch between them on a sample-by-sample basis in post-production.
I've never heard of that one. How would you decide which sample to use?
When the more sensitive (higher gain) one is about to go out of scale, you switch to the less sensitive one. You'll want to pick a value that has a near match between the chains (after the gain difference is taken into account), to use as the switch-over point. Continue to use the lower gain one until the sound drops under the switch-over for a time again (not just a zero-crossing).
How would that help with stuff like thermal noise? Even if your ADC is perfectly precise down to 60 nV, a noise floor of 260 nV makes sure your LSBs are garbage. And usually your noise floor is significantly higher.
It helps by keeping the voltages above the noise floor, while making use of the 24bit range. That is, records from whisper to jet-engine. With just one 16bit recording chain, it'd either cut the jet-engine or lose the whisper in the thermal noise.
But when you have 2x 16bit chains, with one microphone 64x more sensitive than the other, you can make a 24bit recording.
-
@Groaner said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
client-authoritative garbage
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
Oh, client-authoritative is good UX for sure, until a hacker shows up and starts teleporting all over the place since all the other connected peers will consider his self-reported position to be gospel.
While client-authoritative is bad for PvP, wouldn't it make sense for NPC hits, kills and exp to be client-authoritative?
-
@acrow said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
client-authoritative garbage
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
Oh, client-authoritative is good UX for sure, until a hacker shows up and starts teleporting all over the place since all the other connected peers will consider his self-reported position to be gospel.
While client-authoritative is bad for PvP, wouldn't it make sense for NPC hits, kills and exp to be client-authoritative?
Makes it easy to automate grinding when you can tell the server what happened.
Not that I'd mind. Grinding is lazy and should not be a thing in games.
-
@acrow said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
@Groaner said in Linux locks and a kinder, gentler Linus:
client-authoritative garbage
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
Oh, client-authoritative is good UX for sure, until a hacker shows up and starts teleporting all over the place since all the other connected peers will consider his self-reported position to be gospel.
While client-authoritative is bad for PvP, wouldn't it make sense for NPC hits, kills and exp to be client-authoritative?
It depends on the game. In my project, all that stuff is server-authoritative and is replicated (with delta compression, of course, so the entire world state isn't needlessly spewed out over the network 30 times a second). Occasionally, things might get slightly out of sync, but due to replication, they self-correct pretty quickly.
Performing those checks on the client can present some advantages; the question is, what damage can an untrustworthy client inflict? Is it a problem if one client says, "Hey guys, I totally just got 4294967295 EXP from that last kill [of a monster that normally yields, say 100 EXP]," or "Oh, those last 100 NPC attacks missed?"
For example, a game that I'm alpha-testing is effectively a single-player game, but it has worldwide player rankings. Naturally, that's led to some people using exploits to boost their stats artificially high, and the dev team has temporarily disabled some game features while they ponder a more ironclad solution. From my own experience, if you want a multiplayer game, you really have to build that into your design from day one, as replication, authority, and security affect most of the design choices from then on.
-
@Carnage said in Linux locks and a kinder, gentler Linus:
Grinding is lazy and should not be a thing in games.
Well, yeah, but the problem is that it takes me as a developer hundreds of man-hours of work to build one man-hour of content for the end user. Any methods to drag that out, reprehensible as they may be, are tempting.
About thirty years ago, we used to combat this problem by ramping up the difficulty, but games journalists have been whining about how games were too hard, so....
-
@Groaner said in Linux locks and a kinder, gentler Linus:
@Carnage said in Linux locks and a kinder, gentler Linus:
Grinding is lazy and should not be a thing in games.
Well, yeah, but the problem is that it takes me as a developer hundreds of man-hours of work to build one man-hour of content for the end user. Any methods to drag that out, reprehensible as they may be, are tempting.
About thirty years ago, we used to combat this problem by ramping up the difficulty, but games journalists have been whining about how games were too hard, so....
Yeah, I understand the why. But I prefer a shorter game than padding with grinding.
I've been toying with ideas on how to extend MMO style games by crowd sourcing content generation, but most of it would crash and burn.
-
@levicki said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
You can't disagree with his "client authoritative" argument -- it is garbage and it leads to rampant cheating.
Why do you care if people cheat in single player?
-
@topspin said in Linux locks and a kinder, gentler Linus:
@levicki said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
As someone who was annoyed at lag while playing diablo 3 single player, I disagree with your premise
You can't disagree with his "client authoritative" argument -- it is garbage and it leads to rampant cheating.
Why do you care if people cheat in single player?
In Diablo 3 specifically, I presume that the single player character can be used in multiplayer. So, it would cheat people out of grinding.
In general; leaderboards, achievements and rankings. Or, in other words, meaningless cruft that you could very well do without, in single-player games.
The proper way to deal with this would be to have the possibility to opt-out for the online stuff until next fresh character creation, and be client-authoritative until then. But that'd be extra work that only benefits the enthusiasts, so
.
-
@levicki said in Linux locks and a kinder, gentler Linus:
You can't disagree with his "client authoritative" argument -- it is garbage and it leads to rampant cheating.
I can disagree with whatever I want. I'm not playing with other people so there's no need for some server on the other side of the world to slow things down by synching me with me
-
@levicki said in Linux locks and a kinder, gentler Linus:
@Jaloopa said in Linux locks and a kinder, gentler Linus:
I can disagree with whatever I want.
Of course you can if you don't mind sounding stupid.
and you know all about that, don't you?
-
@Jaloopa said in Linux locks and a kinder, gentler Linus:
@levicki said in Linux locks and a kinder, gentler Linus:
You can't disagree with his "client authoritative" argument -- it is garbage and it leads to rampant cheating.
I can disagree with whatever I want. I'm not playing with other people so there's no need for some server on the other side of the world to slow things down by synching me with me
I had similar thoughts regarding Orcs Must Die 2. I'd finally found a game my wife could play and kinda liked, and which had multiplayer.
Except. It couldn't multiplayer directly on LAN. It had to do a round-trip through a remote server, which caused too much network jitter and latency. So, no game for us.
-
@levicki said in Linux locks and a kinder, gentler Linus:
Then play a game which has a local server
I agree I should have done the research before buying the game, but I saw no reason at the time why I should have jitter and lag while playing in an entirely single player way, especially considering that the previous two games in the series had completely separate single player and multi player environments
-
Is Linus back?
Linus Torvalds flames Google kernel contributor
Kernel 6.8-rc2 debuts after very robust discussion about 'inodes'
"And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap."
You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE.
AGAIN.
-
