# r/l/b/t parameters in orthographic projection?

I am trying to implement following:

What are the l r b t units? I understood that r-l= is just screen_width, however is not clear: is it for ex: l=-400 and r=+400 for a screen width 800 pixels? I believe so, because that's what we see on the picture below (origin is in the middle):

However, plugging l=-400 and r=+400 into ortho matrix provided above, we have zero: r+l = 0. Same obivously goes for t+b when t=+400 and b=-400.

Am I taking wrong numbers, or is it just zero and that's it?

So let's say you've set up your game where 1 world unit = 1 meter, and you have a level that's 5m tall, and you want to fit the whole level vertically into however many pixels there are along the height of your screen/window. Then t = 2.5 and b = -2.5 so that t - b = 5, covering the full height you want, and t + b = 0 - no vertical shift, so the part of the scene directly in front of the camera stays in the center of the screen.
Once you've transformed your objects into view space, an object at the very top of the camera's view will be at y = 2.5 - multiplying it by this orthographic projection matrix gets you y' = 1. Similarly, an object at the very bottom will be at y = -2.5, and after multiplying by the projection matrix you get y' = -1. This transformed position is in normalized device coordinates: a coordinate system that ranges from -1 to +1 from left to right/bottom to top across the window's bounds, and from the near plane to the far plane depth. The standard -1/+1 bounds make it easy to do clipping math in the next stage of the graphics pipeline.
Because pixel values don't occur anywhere in this formula, you can run the same projection code for a window or viewport of any size, and the rasterization will automatically scale the view of the scene to fit the output. You do need to match the aspect ratio of your (r-l)/(t-b) to the aspect ratio of the destination to avoid squashing though. And this automatic scaling works fine for mesh geometry, but does not do anything clever for textures, so if you want "pixel perfect" sprites and UI images, you need to take extra steps to adjust their positions/sizes/contents depending on the output resolution.