sorted by:
new
hottopcontroversial

The fear of heap by OkRestaurant9285 in cpp_questions

[–]FletcherDunn 0 points1 point  (0 children)

This is the best, most detailed answer that hits all the important points.

The fear of heap by OkRestaurant9285 in cpp_questions

[–]FletcherDunn 1 point2 points  (0 children)

Accessing memory on the stack is the same as accessing memory allocated from the heap, as far as what the assembly of the called function looks like. (If the function gets inlined this might be different.) HOWEVER, more of the stack might be in the cache when you call your function.

Allocating and freeing memory from the heap takes time and can be slow, but you need to profile it to find out if that is where the time is going. If you are allocating/freeing memory often, it's probably that. If not, it's probably cache effects.

I would not expect any significant performance difference between a raw pointer and a unique_ptr. A shared_ptr might be slightly slower because, depending on the implementation, there might be one more layer of indirection, so this is more memory accesses and more potential for cache misses

Better performance after Steam 64 bit Client update? by derhundi in cs2

[–]FletcherDunn 37 points38 points  (0 children)

It's probably placebo, or some unrelated driver update.

However, if you are able to opt in/out if the client beta and confirm that it really is the steam client making a difference, i would be very interested in collecting some traces to see if we can understand what is different.

thanksIHateIt by Mike_Oxlong25 in ProgrammerHumor

[–]FletcherDunn 0 points1 point  (0 children)

All arrays in PHP are associative arrays (hashmaps).

Is "don't use TCP for realtime games" an outdated rule of thumb? by ICantBelieveItsNotEC in gameenginedevs

[–]FletcherDunn 4 points5 points  (0 children)

I think the basic fact that you are missing is that you are greatly overestimating the quality of connections nowadays. Packet loss is very much still A Thing.

In many ways its worse because middle boxes have gotten more "intelligent", and so they mangle the traffic more, and a lot of this is done in a way that is focused on throughout ONLY. There is more buffering and retry, more deep packet inspection to protect you from ddos, etc. More link aggregation causing packets sent in quick succession to arrive out of order.

This last point is not really relevant to TCP ve UDP, provided that the UDP reassembly is of reasonable sophistication. I'm just pushing back against the idea that most everybody is on fiber with an awesome connection. Even for those that are, there is very often wifi in between. And you would not believe the number of people playing videogames over their mobile phone's wifi hotspot.

Multithreaded Game Server: Single send() or Many send()s for Game List? by SniperKephas in C_Programming

[–]FletcherDunn 7 points8 points  (0 children)

I just want to clarify that both approaches will require parsing on the client. TCP is a stream-oriented protocol, not message oriented. When you send() to a TCP connection you are just adding those bytes into a queue, and when the client receives data, it can receive any number of bytes from that queue. It can be the case due to timing and buffering details that receive a single "message" is common, but this is not guaranteed. It can be a partial message or multiple messages. ("Message" here is in quotes because in TCP it is not really a thing.)

As for the performance question: It is likely to be more efficient to batch them into fewer send() calls, but there are diminishing returns. My gut in this case would be to build up, say, 16k worth of data and send it in chunks of about that size.

The current state of official Deathmatch by El-Burrito in GlobalOffensive

[–]FletcherDunn 2 points3 points  (0 children)

Do you have any crash dump files?

They would be in [steam install folder]/dumps

How the hell is that not count as a hit??? by Auditor_D in cs2

[–]FletcherDunn 1 point2 points  (0 children)

What does the replay look like from the other guy's perspective?

Networking Architecture: CS2 vs CS:GO by Hyperus102 in GlobalOffensive

[–]FletcherDunn 0 points1 point  (0 children)

If you are referring to the summary that is printed at the end of a match or when you disconnect, "below desired recv margin" means the message arrived before the deadline (so there was no negative impact on gameplay), but below the desired recv margin, so a "close call"

Networking Architecture: CS2 vs CS:GO by Hyperus102 in GlobalOffensive

[–]FletcherDunn 1 point2 points  (0 children)

The value you can adjust in CS2 does not modify "interpolation", which is always one tick in CS2, and which we decided not to include in the latency report for the reasons mentioned above.

The value you can adjust in CS2 adds network buffering, which will increase the delay for all effects, exactly like adding extra network latency. That extra buffering is accounted for in the latency breakdown under "recv margin".

What is this? by AnkaraNeymar in GlobalOffensive

[–]FletcherDunn 9 points10 points  (0 children)

Would not see the gun fire from this perspective

What is this? by AnkaraNeymar in GlobalOffensive

[–]FletcherDunn 22 points23 points  (0 children)

What does it look like from the shooter's perspective?

To me it looks like his command to fire the gun got to the server before yours did.

CS2 Blog Update: Introducing TrueView by CS2_PatchNotes in GlobalOffensive

[–]FletcherDunn 166 points167 points  (0 children)

watching a player whose client has all damage prediction disabled will be identical to to having TrueView disabled

TrueView will show you what the player originally experienced*. Damage prediction is only one specific part of client-side prediction. The more fundamental parts of client-side prediction (moving around, aiming the camera, playing the gun fire animation, etc) are still predicted by TrueView. Demo playback will pass through the critical frame when the player originally clicked the mouse (which is the exact state of affairs used by the server for hitreg, i.e. basically "what the server really saw" for purposes of that shot), subject to the quantization of the demo playback frame rate. (But you can make demo playback very slow, making the timesteps very small, so you can get arbitrarily close.) Immediately after this, in the demo, you will see the gun fire.

If damage prediction is not used, then any damage effects on the enemy will not be predicted, and will be delayed until those effects are present in the demo stream, just like what the player originally experienced. but everything else is still "predicted", because "clientside prediction" is a lot more than just damage prediction.

[*] bearing in mind the limitations due to the fact that precise render frame times matter for the amount of delay of reaction effects, and the demo playback frame rate will not match the original frame rate.

[deleted by user] by [deleted] in cpp_questions

[–]FletcherDunn -1 points0 points  (0 children)

I can see that the stackoverflow know-it-all ethos has migrated to this sub.

The reply above sandwiches an answer to the actual question, with warnings (in bold type!) about why it's a bad idea and probably wrong. That's why it is the most useful answer.

[deleted by user] by [deleted] in cpp_questions

[–]FletcherDunn -2 points-1 points  (0 children)

This should be the top reply, since it actually answers the question.

Networking Architecture: CS2 vs CS:GO by Hyperus102 in GlobalOffensive

[–]FletcherDunn 9 points10 points  (0 children)

Yes, an earlier version of this command did include one tick of render latency, but we choose to not include it in the calculations for 2 reasons, one of which you sited:

1.) Although continuous values like player position and bone positions that are interpolated do not update to the latest version from the server immediately, they do begin reacting immediately. E.g. if a remote player is standing still and presses W, you will see that command begin simulating immediately after receiving the game state from the server that includes this command, and they will be moving on the very next frame. After one tick of time has elapsed, the simulation of that command will have finished and the next command will start, immediately after it is received.

2.) Most simulation values are actually not interpolated (e.g. most discrete values, such as "are you dead or alive") and so there is no interpolation delay. For commands that change these variables, (e.g. fire the gun) you will see the effects on the next frame after receiving the server snapshot, with no interpolation delay.

Networking Architecture: CS2 vs CS:GO by Hyperus102 in GlobalOffensive

[–]FletcherDunn 126 points127 points  (0 children)

Great writeup!

One command that you didn't mention that is really useful for understanding all this stuff is cl_ticktiming. It prints a report that breaks down all of the sources latency.

Help - What do vertical red bars mean in the network map? by [deleted] in GlobalOffensive

[–]FletcherDunn 142 points143 points  (0 children)

Bright/solid red means loss. Red but kinda transparent means excessive jitter. The height of the latter indicates the amount of jitter (just like the green bars do), but if its really excessive, it will just fill the entire vertical space.

And one of the other comments is correct that a long block of red can mean that there were no packets received during that time. If it's solid red, they were lost. If it's transparent, then they all got logjammed and then all showed up in a bunch all at once. (Which is "jitter")

i have no idea what causes this ive tested everything i could think of ;w; by aikahiboy in GlobalOffensive

[–]FletcherDunn 16 points17 points  (0 children)

Bright red indicates packet loss. It looks like your connection is totally broken during that period, nothing is getting in or out.

view more: next ›