Why is the pixel so popular as the metric unit of a game?

Question

I keep seeing everywhere people using pixels for resolving collisions, angles, distances. I wonder if using the pixel as the metric unit for a game is a good solution, first because you're tying your game logic with implementation, in this case squares in your monitor, second handling more elaborated effects like zoom, rotation becomes more difficult, etc. Isn't adopting integer numbers as your smallest metric unit more flexible and letting the renderer do the pixel operations?

Why the pixel unit is so much popular than integer units? Which are the benefits and drawbacks for each strategy?

Answer 1

It is absolutely business-as-usual to decouple physics (and related ops like ray-based picking) from display values. Two common examples (I welcome any others as comments):

1. OpenGL uses the float range 0.0->1.0 in x and y, thus abstracting display code from resolution (and thus, pixels).
2. Box2D is also built for such decoupling.

But having said that, it's not always necessary, which is why you see some people simply using 1:1 ratios. OpenGL and Box2D are libraries (write-once-use-many-times), so they need to be applicable in a range of circumstances. As such, they wisely do not tie the user into implementation specifics of this sort, since your choice may be totally different from that of another user of the library.

There is nothing to say that an engine may not do perfectly well, if for example the physics are specifically built to work at 1:1 scaling -- or any other fixed scaling, for that matter. You typically still use floating point to deal with fractional values in your physics. (Another alternative is a custom-built fixed-point implementation, if you are running on older hardware -- but that is still a non-integer.)

(Disclaimer: In the particular case of Box2D, Erin Catto has stated that his engine is optimal at a 10:1, physics units to display units ratio. This is based on floating point precision limitations which meant that some optimal ranges had to be chosen for the physics ops to be less "granular" while still supporting relatively high velocities. You can choose your own ratio however. It just provides a smoother experience at 10:1 or higher.)

For 2D games, I normally first consider level size in metres or feet, then consider viewport size such that you know what percentage of the level you want to see at a default (1.0) level of zoom, then decide on the supported screen resolution, and then finally use that inform your decision of what your sprites' pixel dimensions need to be.

(Thanks @JoshPetrie, @NicolBolas, @e-MEE for getting us this far on the OP's question.)

Answer 2

Don't know if "everywhere" is true these days, but in good old days (on C64, PC and consoles like NES) the games ran in relatively low resolution (around 300x200 pixels), possibly with special hardware for tiled graphics and sprites.

Back then, it made perfect sense to measure distances and sizes in pixels, as everything was "solid" and there were relatively small amount of pixels available.

Today, even if you're doing a 2d game, you'll probably render it through OpenGL or similar, and can keep your camera dynamic, which in turn decouples pixels from your actual game "physics" entirely.

Of course it may still make sense to think of your visible world in some pixel resolution and do the math that way, if it makes it easier to think about, but there's no longer any actual need.