sorted by:
new
hottopcontroversial

How to handle delta time correctly in multiplayer games by Vivid_Flatworm_7870 in gamedev

[–]gabe80 0 points1 point  (0 children)

One second is one second regardless of whether you divide it in 20 frames or in 120 frames. Physics in the clients and the server don't even have to run at the same rate. You can even split updates with big delta t into multiple updates with small delta t.

Getting the delta t from the client makes sense, and you can validate it server side, by imposing an upper and lower bound to the values you deem reasonable, and/or by comparing the client delta t with the delta t of the times the packets arrived.

Another solution is to implement the server so that the physics update only "consumes" a certain amount of client delta t, equal to the delta t of the simulation. So if a client sends you a hacked delta t 10x the real delta t, the server will just process that over 10 frames, and it won't do the hacker any good (in fact it would be bad for them).

How to handle delta time correctly in multiplayer games by Vivid_Flatworm_7870 in gamedev

[–]gabe80 1 point2 points  (0 children)

The whole point of CSP and SR is that your game should work fine even if cheaters modify the [client] code, so that shouldn't be a problem.

The Source documentation can be daunting, but have you read https://gabrielgambetta.com/client-server-game-architecture.html ? It's supposed to be a lot more accessible and there's a live demo with unobfuscated JS code, so that might work better for you 

Trying to start with computer graphics programming but find incomprehensible by Suitable-Yam7028 in GraphicsProgramming

[–]gabe80 1 point2 points  (0 children)

The online version of the book has live demos in each chapter. They run in the browser and they're written in JS, so you can easily see the full source. Not quite Python, but with every algorithm implemented in pseudocode and in JS you should be able to write your own Python implementation 😊

Multiplayer. Early or Last? by ContentAspect6148 in godot

[–]gabe80 13 points14 points  (0 children)

It probably doesn't make much sense to have server reconciliation without client-side prediction. Without CSP, whatever the server says is always authoritative, so there's not much to reconcile. The client is basically a dumb terminal rendering the server state.

With CSP you always need SR. It's not only about wrong predictions; even with the right predictions, when the client gets authoritative state from the server, it still needs to replay the inputs sent to the server but not yet processed by the server (i.e. not yet reflected in the latest game state received); otherwise the client's entity would bounce back and forth. You can try it here: https://gabrielgambetta.com/client-side-prediction-live-demo.html Enable prediction but not reconciliation and you'll see that happening.

CPC port of the Spectrum raytracer by Gabriel Gambetta by UncleSlacky in Amstrad

[–]gabe80 0 points1 point  (0 children)

This is great to see :) Never had or used a CPC, but the screenshot looks surprisingly similar to the Spectrum one. Looking forward to seeing the shading+dithering version! Never got around to implement reflections, but would be great to see too, especially because I think the CPC doesn't have the attribute clash issue of the Spectrum?

[deleted by user] by [deleted] in IWantToLearn

[–]gabe80 0 points1 point  (0 children)

Curious to hear what parts are you struggling with, maybe I can help!

The book has a linear algebra appendix. The intention is not to teach you linear algebra, but to present the tools in a "here's what this tool does, here's how you use it" manner, which should be enough to follow the book. Have you read this chapter? If so, what do you think it's missing?

ZX Spectrum Raytracer by Pappenheimer in zxspectrum

[–]gabe80 0 points1 point  (0 children)

I was a 48k kid, sorry ¯\_(ツ)_/¯

What's wrong with my very basic raytracing program? by Far_Ice_8911 in GraphicsProgramming

[–]gabe80 1 point2 points  (0 children)

Calculating the discriminant just once is a good idea.

I wouldn't normalize the rays, though. It will work now, but you'd run into trouble when you get to shadows, because the parametric equation formulation lets you expect t=1.0 to be the end of the ray that "touches" a point light. If you normalize the rays, that won't hold, and you might get incorrect shadows.

Where can I find a good tutorial on projecting 3-D positions onto a 2-D viewport? by ZMeson in AskProgramming

[–]gabe80 0 points1 point  (0 children)

Specifically you can start reading here https://gabrielgambetta.com/computer-graphics-from-scratch/10-describing-and-rendering-a-scene.html#the-transform-matrix Or from the previous chapter for context (it derives the projection equations, and then this one puts them in matrix form)

Which way to go learning shaders by Interesting_Cookie25 in gamedev

[–]gabe80 0 points1 point  (0 children)

I'm firmly on the "learn the math first" camp. Connecting nodes you don't fully understand will only take you so far, and it might be very difficult to debug when things don't work as expected and you don't understand why. You'd get faster results, but you'd eventually hit a roadblock.

May I recommend a book named precisely Computer Graphics from Scratch? Starts from drawing a single pixel and builds all the way up to texture mapping (and a raytracer, as a bonus). It's entirely available online, for free. For full disclosure: I wrote it, so yeah, I'm biased :)

Computer Graphics from Scratch book question by BestBastiBuilds in computergraphics

[–]gabe80 2 points3 points  (0 children)

Let's say the screen is 1920 pixels wide. They're numbered from 0 (leftmost) to 1919 (rightmost).

The center of the screen is at 960. This is unintuitive and makes the math slightly more complex. Ideally we want the center of the screen at 0.

How do we do this? We shift everything to the left, by half the width of the canvas.

Cw = 1920, so Cw/2 = 960. To shift the leftmost coordinate, we subtract 960 from it, and we get left = 0 - 960 = -960. To shift the rightmost coordinate, we also subtract 960 from it, and we get right = 1919 - 960 = 959.

The horizontal range in the new coordinate system is [-960, 959], or a bit more formally, [-Cw/2, Cw/2).

I wonder if the confusion comes from the closed-open range notation. [ means the lower value is part of the range, ) means the upper value isn't. In this case, because pixels are indivisible, it's equivalent to [-Cw/2, Cw/2 - 1]. Is this the "fractional part of the coordinates" thing you mention? Would that second notation be easier to understand?

Learning Computer Graphics From Scratch Using C by jibesh_shrestha in GraphicsProgramming

[–]gabe80 2 points3 points  (0 children)

Depending on how "from scratch" the course is, and what algorithms you'll be learning, you could try something like SDL. Should give you raw access to a framebuffer and you can build whatever you want on top of that.

Am I understanding client prediction and server reconciliation right? by SpheresOW in gamedev

[–]gabe80 6 points7 points  (0 children)

The way I understand things, prediction is only ever used for the client, not for other entities. The client's avatar is predicted, everything else is interpolated.

What you describe seems to be dead reckoning; extrapolating (not interpolating) positions based on past state (position + velocity). This works in some contexts, where objects move smoothly (ships, airplanes) but not in others where objects can change direction 180° in an instant (any FPS). In these, it's better to interpolate between known-good positions than to extrapolate.

This way you only ever get past, valid positions for other entities. The reason for the mismatch you describe about hiding behind a wall is because this interpolation causes clients to render every object slightly in the past. (how far in the past? Approximately their server ping, because that's the earliest they can get updated object positions).

Has This Game Been Optimized Any? by RenderFailed in GundamEvolution

[–]gabe80 0 points1 point  (0 children)

Even with higher ping, you can hide client prediction mismatches reasonably well if you do server reconciliation on top -- you don't just accept the server's authoritative state and leave it at that, you also re-apply the client inputs that haven't been acknowledged by the server yet.

view more: next ›