Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
A pixel is a whole-numbered value (an integer), usually. Right now your question reads "why are integer units more popular than integer units?" Were you intending to refer to sub-pixel measurements and/or measurements using floating- or fixed-point values? –  Josh Petrie Dec 14 '11 at 23:04
    
@Josh Petrie I'm referring to the 1 to 1 translation of the graphical pixel and the "game metric" pixel. What if I want to go from zoom 1x to zoom 0.95x? If I'm using other metric I can pass the job of recalculating which pixel goes where to the renderer –  User123 Dec 14 '11 at 23:15
2  
I could understand this question if you had referred to floating point numbers. But integer units... just doesn't make any sense, as @JoshPetrie is saying. Particularly as the example you give (0.95) is a float. –  Nick Wiggill Dec 14 '11 at 23:18
    
@Nick Wiggill think this way, one entity can be on (100,100) and have size of (10,10). If you're using pixels you're tied to render the entity as 10 pixels in size every time, but if your game and renderer use different metrics, the entity can still be on (100,100) with size (10,10) but being rendered at a 0.95x zoom on (95,95) with size (9,9). I really don't know if that's how it works but I suspect you can have one metric behind the scenes and let openGL for instance handle resizing –  User123 Dec 14 '11 at 23:31
1  
if you have a game in 800x600, you see 480000 pixels everywhere in the game, if you zoom in or not, if you are looking at a big world, or just a black screen, there are 480000 pixels. From your question I think you don't understand rendering. –  e-MEE Dec 15 '11 at 7:14

2 Answers 2

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.)

share|improve this answer
    
You can setup OpenGL glOrtho2D view to have range in pixels, e.g. 1024x768. So thats definitely an option. –  Krom Stern Dec 15 '11 at 18:18

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.

share|improve this answer
    
Also, back then your processor usually didn't come with an FPU... –  bummzack Dec 15 '11 at 22:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.