Quantcast
Channel: GameDev.net
Viewing all articles
Browse latest Browse all 17825

Pitfalls of pixels as unit in game

$
0
0
So I've been trying to develop my own little c++, 2d fighting game from scratch and I'm hung up on what exactly I'm suppose to use as 'units' for my game. Currently, as suggested here on another game dev site, my game screen is thought of as a 160x90 grid. So if my game is being run at 1080p screen resolution, that would equal exactly 12 pixels per 1 grid unit (which I call a world unit). For example, I will have code in my game where I will tell my sprite to move 10.0 units/sec in the positive x direction. This means at 1080p my sprite will move 120 pixels/sec when run (12 pixels/unit * 10 units). Recently though, I've started trying to add some collision detection to my game and I've run into a bit of an issue with when to convert my world units into pixels and getting my collisions to work properly. While I'm sure I can fix this after some time, this got me thinking what exactly are the problems with just assuming a certain screen resolution and working strictly with pixels in my game? So instead of saying 'move my sprite 10 game units/sec' just say 'move my sprite 100pixels/sec', avoiding and unit conversion techniques. Then, if I want to, I can come up with some way just to upscale to higher res images or whatever for denser screen resolutions. The reason I ask is on a lot of forums people seem to be against using pixels as units when it comes to collision and physics, even for 2d games.

Viewing all articles
Browse latest Browse all 17825

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>