Counting pixels?

[Jambutters]

Yello, newbie here.

My short story: I've been (re)watching tutorial series on web development and programming for.... about 4 years...I end up quitting due to distraction/preoccupation with other games, then find myself grinding tutorials when I have the urge to re learn(which is once a month or so). 

Now, since I'm out of school and no longer addicted to any particular games, I've been getting some hands on experience for the past couple days(FINALLY). I still struggle with wondering what to write but that's not the point. 

-End of story-

Something I've always struggled with is counting/drawing/placing/calculating pixels in sprites/images whether it would be trying to design/positioning a webpage using css or drawing/calculating x&y of movement and sprite drawing.

What do I mean by counting/drawing/placing/calculating pixels? 

Pixels are really/extremely small.. I don't understand how developers can estimate/count/place them. Saying things like "hmmm, 30 pixels down and 100px right should be right about here(pointing with their cursors)", knowing a relatively close position of where their image is going to be placed. How is this possible? I really really can't imagine counting 30 pixels across and 100 down... I'd probably end up being off by a lot...

(From a tutorial video) Another example is moving a sprite 5 pixels right when a player press the right arrow key.(I know how the function works)  but..... what does 5px left, look like? How do developers know what 5px left looks like?  Again, I can't imagine counting 5px to the left... I don't think I could keep track of counting 5 pixes (microdots) to the left...

Anyways, you get the point. I'm not asking for a specific answer of " Well, 5px left or 100px down is about (x) inches" . 

I'm asking, How do I count pixels? 

 

Sorry if this is somewhat confusing.

 

 

 

[P.Uri.Tanner]

Great question – especially with the rise of high density displays in all gaming arenas pixel counting sucks now more than ever.

1. Knowing your devices by heart helps significantly. Lucky for developers and designers most of the pixels-sizes are divisible by multiples of 2. So you can remember how large 50%, 25% 12.5% of your screen-axis are and will nearly always have to deal with beautiful, integers. 

You already know those: 2, 4, 8 16, 32, 64, 128, 256, 512, 1024, 2048, 
Also easy to remember: 5, 10, 20, 40, 80, 160, 320, 640, 1280, 2560

2. Have a medium DPI device or use zooming to easy recognize a "pixel perfect" design. Pixels on modern 300+ DPI devices are too small to easily discern.

3. Use a grid! Some of your early art assets should contain a grid. 

Sometimes i just overlay the canvas with a CSS grid set to "pointer-events:none;"

http://codepen.io/puritanner/full/JGrewg

 

4. Use conventions and abstract pixels right from the start. This is another byproduct of not using "magic numbers" and removes a lot of the guesswork and pixel counting.

// 10 Meters to the right!
entity.x += 10 * METER

// 120 WHAT? This will be more difficult to work with later on
entity.x += 120 

 

[chg]

5 hours ago, Jambutters said:

(From a tutorial video) Another example is moving a sprite 5 pixels right when a player press the right arrow key.

Even if a designer knows what 5 pixels looks like (for some resolution or virtual resolution), now you are referring to 5 pixels per "frame" (or similar fractional unit of a second). Now maybe there are a few individuals that can intuitively understand that speed, but I think most probably just guess and play test, it sounds like the worst super power ever anyway so I wouldn't be too envious of anyone that can actually translate such a speed into these units.

You only have problems if you are several orders of magnitude off - ie. you guess pixel values that are way off screen, or speeds which either don't move visibly or shoot offscreen so fast as to never be seen moving... as such mistakes are by nature harder to see. Thus, basic maths guestimation skills can help (eg. you guess it should take the player a few seconds to go from one side of the screen to the other, what is a reasonable guess for the speed in pixels per fraction of a second that you can tweak/play test later)

[mattstyles]

It's just experience and its definitely not something I'd pursue.

You'll get a feel for how far things are (on a regular screen, whatever that is these days) just by building stuff although with the range of pixel densities on devices and screen sizes it's not really important anymore (was it ever?).

If you're still learning the ropes you have enough on your plate without being about to intuitively know if a circle is 20 pixels or 40 pixels across.

No one is going to hire you because you have laser-like precision in judging 50 pixels by eye on every device on the market, but they might hire you if you can work out how far an object should move each frame if it has 512 pixels to travel and 3 seconds to get there.

[Jambutters]

10 hours ago, mattstyles said:

You'll get a feel for how far things are (on a regular screen, whatever that is these days)

The clients screen resolution effects the movement/calculation/placement of pixels? 

10 hours ago, mattstyles said:

If you're still learning the ropes you have enough on your plate

Indeederino but I'm somewhat of a little "perfectionist" and I want to get into writing code with "professional/good" habits asap.

19 hours ago, chg said:

now you are referring to 5 pixels per "frame" (or similar fractional unit of a second).

What is a frame if I may ask(I'll google it if you don't want to answer, its fine)(P.S I have social anxiety) ? Come to think of it, I really don't know how/what to deal with frames per second are. I mean I do know the higher the fps, the higher the quality of how things looks are but 

 

19 hours ago, P.Uri.Tanner said:

3. Use a grid! Some of your early art assets should contain a grid. 

 

Yessir! 

19 hours ago, P.Uri.Tanner said:

Great question – especially with the rise of high density displays in all gaming arenas pixel counting sucks now more than ever.

 

Thank you, I thought it was somewhat of a dumb question because I feel like I'm the only one struggling with it.... Glad to see professional/experienced developers find this somewhat of a difficult subject too.

[mattstyles]

Quote

Indeederino but I'm somewhat of a little "perfectionist" and I want to get into writing code with "professional/good" habits asap.

Knowing what you can ignore and what you should pay attention to is being professional. Coding is hard and programs quickly become non-trivial (even if you are superb at modularising etc etc) so you can't hold everything in your head at one time, you have to be able to shift your focus and ignore stuff that is, for the time being, non-important. In short, dont be a perfectionist, you'll never get anything done (this does not mean that you shouldnt aim for perfection, merely that you have to accept bending the rules).

Quote

 

What is a frame?

In this context a frame is the frequency of the updates to your rendering i.e. how quickly you try to perform renders. Often this means setting up a 'tick', you can use a browser method called `requestAnimationFrame` to tie this to the refresh rate of the monitor, ordinarily this is roughly 60 frames per second (some monitors will go faster) i.e. every 16.66ms or so the monitor will refresh its contents, ideally you want the latest state of your application in there, so, we use `requestAnimationFrame` to tie our rendering into the refresh rate of the monitor which, very generally, means animations are smooth.

If your game runs at a solid 60 FPS (it wont, there will be small fluctuations) and you want to move 512 pixels in 1 second then you have roughly 1000/60 frames (16.66) to account for. Very roughly this means that if you move your character 512/16.666 (just over 30 px) per frame then you'll have moved the desired amount in 1 second. To complicate matters further you might want to move exact amounts, i.e. if your characters ends up at 514 you'll want to move them to 512. Another complication is that each frame will not be 16.66ms, there will be fluctuations. This all sounds very complicated, because it is, but thats programming for you! Most physics libraries take care of this for you and dont really concern themselves with the pixel ratios, you tend to assign speed or acceleration (speed is a funky one, which I wont go in to).

A simpler method of movement is just to update the position of the sprite whenever a key is pressed and getting a good rate of movement (speed) for each game is a fairly unique thing and depends on your world scale. Use trial and error (and get other people to test your game for you too), as chg mentioned, the only problem is when you are way way off so that the sprite either hardly moves or moves way to much.

And yes, Google animation frames and character/sprite movement in games. Its a large topic with many different ways.

And FPS is not always tied to things looking better, it can smooth out animations in most circumstances, but not all. Take a game where characters move, say, 32 pixels at a time (i.e. for square to square, such as many old-school roguelike games) they only need to refresh on user interaction, or, when something moves, so, technically the FPS could be tiny, it certainly is not a concern. Some games can run at 30FPS and be fine because movement is interpolated between frames, this decouples the relative movement of each body from the frame rate i.e. they will always move that 512 pixels in 1 second, the only difference is whether you render them 60 times in that second or 30, in which case, usually, the higher frame rate will make them appear smoother.

[Jambutters]

19 hours ago, mattstyles said:

Knowing what you can ignore and what you should pay attention to is being professional. Coding is hard and programs quickly become non-trivial (even if you are superb at modularising etc etc) so you can't hold everything in your head at one time, you have to be able to shift your focus and ignore stuff that is, for the time being, non-important. In short, dont be a perfectionist, you'll never get anything done (this does not mean that you shouldnt aim for perfection, merely that you have to accept bending the rules).

Quote

 Yes, I understand. But isn't it a good thing to quickly develop and close out noobie coding styles? Like using global variables too often or repeating code too often rather than writing a function. Nevertheless though, I'll loosen up a bit.

19 hours ago, mattstyles said:

If your game runs at a solid 60 FPS (it wont, there will be small fluctuations) and you want to move 512 pixels in 1 second then you have roughly 1000/60 frames (16.66) to account for. Very roughly this means that if you move your character 512/16.666 (just over 30 px) per frame then you'll have moved the desired amount in 1 second. To complicate matters further you might want to move exact amounts, i.e. if your characters ends up at 514 you'll want to move them to 512. Another complication is that each frame will not be 16.66ms, there will be fluctuations.

Extremely sorry but I don't understand where you pulled the numbers from. Bleh, I'll grasp it when the time comes, thank you for responding. 

[chg]

40 minutes ago, Jambutters said:

 Yes, I understand. But isn't it a good thing to quickly develop and close out noobie coding styles? Like using global variables too often or repeating code too often rather than writing a function.

The important point all answers have been gently stating this skill isn't associated with programming/coding - if it belongs under any hat it's game design / balancing (yes in small projects people where many hats and there is often overlap).

 

48 minutes ago, Jambutters said:

 Extremely sorry but I don't understand where you pulled the numbers from. Bleh, I'll grasp it when the time comes, thank you for responding. 

I feel like some of my original point has been missed, tying logic to frames per second rivals tying it to pixel size in terms of arbitrariness. The original example you cited sounds like it made assumptions about both. Matt's answer details better practices, and as per understanding how one might approach updating a game character's position is a better jumping off point.

Unless you are designing your game for an 80s or early 90s game console (or putting in some effort to pretend that you are) you assumptions about pixel sizes or refresh rates don't work so well in modern games.

[mattstyles]

Quote

Extremely sorry but I don't understand where you pulled the numbers from. Bleh, I'll grasp it when the time comes, thank you for responding. 

My fault, chg is right, dont worry about pixels and resolution and stuff, I went in to too much detail whilst trying to be brief.

Just work out how to update position at first then move forward, there are lots of good resources for this and when you have a smaller, more concrete, issue then posting here (or other similar forums) will help you.

Experience is key in my opinion, just get coding things. Some will be good, some will be bad, the important point is that you learn why some things are good and why some are bad. Be prepared to be learning for a very long time, there is plenty to be learned.