Screenspace and tracking locations and stuff

As I'm building my game to emulate the NES's capabilities, it occurs to me that it may be more reasonable to track my objects from their corner, rather than their center. I suspect this is how NES games did it anyway. It's simple logic, really. Positions and things need to be whole integers, and if an object is eight pixels wide, and you tracked its position according to the center, they would be half a pixel off in either direction. But if the object is tracked from the corner, eight pixels wide just means seven pixel over. Nice and even whole pixel increments.

So as I am building things, the question is: which corner? Off the top of my head I can't see any *real* advantage to any corner, so I'm curious how things were handled on the NES. Because learning is fun, and maybe there are some distinct effects that would be easier to duplicate if I track my objects the same way.

I would *assume* that the hardware draws the screen so that any pixel on the screen is counted from the upper-left corner; x pixels to the right, y pixels down. (I'm pretty sure sprites are drawn from the left side of the screen, since they can't be drawn partially visible on that edge, so that edge is zero. And I'm really just assuming they count from the top down because that is how TVs draw the scanlines.)
And I also suspect that because of how the hardware works, pretty much all games follow that same standard, and have to track an object's position in game-space according to the same standards used in screen-space. But hey correct me if I'm wrong.

So when a sprite is drawn, it is drawn from is the upper-left corner. And it just makes sense to track whole objects that way. All positions relative to an object are offset from that corner; each sprite is placed so-far to the right, and so-far down; when they check for collision, it checks points that are so-far to the right, and so-far down.

Just as I was writing this though, I thought of a legitimate reason to not track objects from that corner: changing height. When a character crouches, the top of them basically disappears. It sounds a bit more reasonable to track from the bottom-left corner then, so that changing the size of a character just means dropping a couple values. But is the character were tracked from their upper corner, when they crouch they would have this awkward gap that has to be ignored. All sprites would be eight or more pixels away, collision would be ignored for a small gap...

Well I guess it isn't exactly unreasonable to do that. But I still wonder how games tracked objects and stuff. Could a game even track an object's position freely according to how the game was coded? Or does the hardware restrict it to use the same way the system is drawing everything? And how do games commonly (or absolutely) track an object's position?

The number of games I've personally debugged isn't very significant, but I've never seen any games where objects were tracked by their corners... it was always the center.


That's correct.


Object coordinates are usually in level space, and have to be converted to screen space for drawing purposes. Since there's usually a conversion involved, the coordinates can be manipulated as needed, from a system that's good for physics and collisions to another that's good for displaying, without them necessarily having anything in common.


It's not uncommon for games to move positions to accommodate state changes. There are games that will instantaneously move the object's position a few pixels down when crouching, while also modifying its bounding box.


There are no hardware restrictions at all. This is all just math... The game world is modeled a certain way, more convenient for physics and collisions, and this information has to be converted to another format that will allow you to represent the game objects on screen. This final format is imposed by the hardware, but how you're gonna get to that format is entirely up to you.


Most games I've personally debugged track their objects by the absolute center, both vertically and horizontally. There might be some games out there that use corners, but I've never seen it happen.

Haunted: Halloween '85 uses the bottom center, as that's the most salient point for floor collision.

I really like the idea of using the bottom center, because that's the best point to attach to surfaces, even when there are slopes, half-pipes, loops and the like. All you have to do is rotate the object and its bounding box around that point to match the angle of the surface it's attached to. Crouching is also more intuitive, since you can simply reduce the height of the object's bounding box.

Unfortunately, old consoles in general are not good with rotations, so smoothly rotating sprites and bounding boxes around the bottom center point is out of the question. When there are few sprite angles available, a rotation based on the center of the object looks infinitely better. Rotations are literally the only reason I'm currently using the center of the objects, instead of the bottom center.

Okay, but if the object is tracked from the center, how does a NES game handle the logical offset of using values in whole numbers?
If a character is 16 units (pixels) wide, then the character's exact center is in-between the eighth and ninth pixel.

The logical bounding box is nearly always smaller than the sprite, so collisions don't feel unfair to the player. There's nothing wrong in having the dimensions of the bounding boxes be odd numbers, so the hotspot can be in the center. As for the sprites, you can simply offset them one pixel in the direction they're facing.

There are many ways to go about this really. If you want the bounding box dimensions to be even, you can define it using an odd value on the left (7) and an even value on the right (8), so the final width is 16. And when flipping sprites, adjust their coordinates by -8. The reference point will be slightly off center, but still close enough.

I thought I'd chime in with a visual representation. This is assuming your object is 16x16, which is made up of 4 sprites. The main difference is the location of your origin point.



As tokumaru stated, it is useful to choose one that fits the game you are developing. The bottom center origin is great for platformer collision calculations and the center origin is useful for top-down games.

I've seen the top-left alignment used fairly often with hardware accelerated sprites (using OpenGL/DirectX). The advantage is that you always have positive values. To "draw" the sprite you place the first row, move down 8 pixels, and place the next row.

Honestly it comes down to preference. You could even change the origin point for different calculations if you want to get fancy, but make a note in your code so you don't forget why you did it.

I've coded dozens of games and I've always used "top left of the bounding box". It feels natural to me, not because it's natural, but maybe because I've been using that approach for more than 20 years.

Maybe it's because the fact that I taught myself and I reinvented several wheels in the process :-/

Well, it works, especially if there are no rotations involved. It's just not the norm in the industry, it seems.

In general, coordinates based on the center of something makes object-object collision detection easier if objects have different sizes. For example, if you have one object 14 pixels across and another 4 pixels across, they overlap if their centers are within (14 + 4)/2 = 9 pixels of each other. With top left, the collision happens if the distance is between -14 and 4 pixels, which makes it easier to get the sign wrong.

Plus there's a reason why objects have a center of mass, not a top-left of mass.

I had started programing it to where the object's coordinates are the top left, because I find it easier to visualize because you can't really have something like the center be in the center if the object's height and width aren't odd numbers. I don't know if this effects anything, but it's just weird to me.

Except for FHBG, all of my games have used the top left corner, since it simplifies sprite drawing and background collision detection where I need the corners. This way, I already have the X of the top left and bottom left, and the Y of the top left and top right without needing to do any math, so it's only two adds rather than two adds plus two subtracts.

Now I'm really not sure how I want to proceed...

I'm in the process of rebuilding a lot of the basics for my game. For one, I'm forcing it to move objects in whole-pixel increments. For this to work properly, I'm also building my own collision system, which honestly is going better than I had thought it would.

At the moment my objects are tracked from the center, but I am starting to think I should track from the bottom-left. If I track from the middle, I need to devise a way to offset position and collision so that everything lines up with whole-pixel precision.
But if I track from a corner, I need to revise how characters flip the way they are facing. Currently I just flip their scale in x.
Then again, I guess I'd still need a new method if I use the center but offset measurements a little, because it still is moving one pixel in the other direction.

I guess there are no easy answers.

I just thought of another drawback of using the top left corner (or any corner, for that matter): poor handling of flipped asymmetrical bounding boxes. Say you have an object that has actions that require its bounding box to extend in one direction only, like punching or kicking. This is fine as long as the object is facing right, but if the object turns around, the top left corner you had before is meaningless. You'd need to awkwardly move the coordinates back to accommodate the new bounding box, and revert this when the action is done. And you'd need to do this repeatedly as the object turned around and/or started/stopped these actions. If the reference point was at the center, you could just modify that particular side of the bounding box (1 value).

I'm not saying to never use the top left corner for positioning game objects, I'm just saying that's it's not a very accurate model of how objects are positioned in the real world, and because of that there might be limitations on how they interact with the rest of the game world. If the worlds are completely made of blocks (no slopes or loops) and the bounding boxes don't need to be frequently modified, then the top left corner is as good a choice as any.

I always thought of just using the point as a reference point more than anything, in that bounding boxes and whatever would have a value that asks where relative to the point you want the box to be and another thing to say how wide it is. Same with flipping the visual representation of objects. Now that I think about it, I think I'm making it overly flexible... I still don't know how you can have the point in the middle if there's an even number though, and if you were to flip the object, you'd have to make sure the object is in the right spot, as in if you were flipping a 16x16 object with the "center" being the bottom right corner of the top left block, you'd need to make sure that the "center" stays the "center" in that it doesn't get pushed over an extra pixel or something in that the new "center" would be the bottom left corner of the top right block.

I won't be defending my approach as I don't have real claims for it and I understand why other approach are more convenient, but I'd like to pinpoint a couple of advantages (if bounding boxes won't change [much] during gameplay).

- To get the coordinates of the bounding box, you only have to add width and height for the bottom and rightmost borders, as he left and top borders will equal X and Y. Using the center, you have to perform calculations for all 4 boundaries.
- For collision, it has mentioned that you only have to check if the coordinates from both objects are within a abs(w1-w2)/2 range. I find it easier a x1 >= x2-w1 && x1 <= x2+w2. You can avoid the potential negative numbers playing around with the inequation: just do a x1+w1 >= x2 && x1 <= x2+w2.
- Translation between world coordinates to screen coordinates will be, in most cases, more direct.

Of course there are many other situations where you need to calculate the center (I do!). That's why I won't be defending my option (as it was, in the beginning, purely arbitrary).

You know, I just realized that tracking from the center isn't going to have the offset problems I was thinking of.
If, that is, that I make sure all objects use even numbers in their dimensions. (Or all odd, but it makes more sense to use even, since the tiles are all 8x8.)
Yes, the object's center may be between two pixels, but this exact same thing is going to happen to the map, and all other objects. Everything will still be displayed properly.

The only difference is that when I check any arbitrary point, I need to look half a unit higher or lower, so that I can check the relative center of a displayed pixel. Otherwise I'm going to be checking a point in between two pixels.

I heard that in games like Sonic that have a lot of slopes, that when a character is running up a slope, it checks wall collision several pixels higher in order to not get stuck in a wall that is under their feet. Do any games cut corners (quite literally, ha ha) by always checking walls several pixels higher, even while air bound, and snap the player up to the platform if they jump close enough to the top of a wall?