In my opinion pixel movement provides cleaner movement, and it looks better, it would also improve certain features of my game--but it would totally destroy the bulk of the combat system, which is based on using locations in relation to the player.

a datum.
This particular datum would store info about an atoms pixel location. Or more specifically a point.

#define tile_width  32
#define tile_height 32

atom
  proc/width()  return tile_width
  proc/height() return tile_height

  proc/px(p) return loc && tile_width  * (x - 1) + p * width()
  proc/py(p) return loc && tile_height * (y - 1) + p * height()

  movable
    width()  return bound_width
    height() return bound_height
    px(p) return loc && ..() + bound_x + step_x
    py(p) return loc && ..() + bound_y + step_y

Choosing a pixel, then extending outwards a bounding box 16 pixels in each cardinal direction *N,S,E,W* would then give you a "tile", 32x32 pixels in width and height that would function as an origin for a location that you may wish to use.

Anyway, my point in this post would be to see if you guys would be interested in taking this approach to setting up better handling of locations for the pixel moment,

which I believe would vastly improve it's usability and solve a lot of the problems like accounting for positioning using pixel projectiles,

or "get_step" issues when using pixel movement since the above method could be used to create a "tile" based on the position of a mob or object using pixel movement.

It would also potentially solve some problems with mobs/objs sharing "multiple" locations.

mob
    verb/punch()
//  Tile movement:
        //  get_step(src, dir) returns the turf ahead of src
        //  loop through that turf's contents for mobs to punch
        for(var/mob/m in get_step(src, dir))
            m.die(src)

//  Pixel movement:
        // bounds_step(src, dir) returns a list of atoms ahead of src
        // loop through that list for mobs to punch
        for(var/mob/m in bounds_step(src, dir))
            m.die(src)

//  Alternate (but equivalent) forms:
//  Tile movement:
        var turf/ahead = get_step(src, dir)  //  a turf
//  Pixel movement:
        var ahead[] = bounds_step(src, dir)  //  a list
//  Both:
        for(var/mob/m in ahead)
            m.die(src)

I think you misunderstood what I meant, you can use this method to fix the problem you'd normally get from using get_step.(in theory)

if it works it would be a pixel-movement equivalent of get_step rather than just using obounds or bounds, you would end up with a "tile" of your size and choosing to use as an origin point.

It differs in the way that you are thinking about it I suppose. You are thinking about using a bounding box during combat.

I'm thinking about fixing the issue with locations so that you don't have to use a bounding box for everything.

Bounds tells you everything that is within a box.

A pixel location is a 32x32 location independent of the tiles, so in essence it's something that accomodates pixel movement.

I think it's best to supply a visual.
Your idea of combat and mine are a bit different.
Yours is limited to bounding boxes,

mine is more reliant on the location of the player and surrounding tiles.

When i do it that way, i need to have a reliable location, not exist in 2-3 different places.

I'm saying that what I'm talking about is creating a "tile" based on a pixel point, expanding outward from that pixel point, then creating other tiles in relation to the first one.

A better question is, if it's so simple to set up why isn't it just made an update so everyone can use it?

I'm tired of trying to be productive and in the end getting treated like i don't know what I'm talking about or that I'm an idiot.

I can't really explain it any better than I already have. My purpose isn't to make a get step proc.

This particular datum would store info about an atoms pixel location. Or more specifically a point.

Choosing a pixel, then extending outwards a bounding box 16 pixels in each cardinal direction *N,S,E,W* would then give you a "tile", 32x32 pixels in width and height that would function as an origin for a location that you may wish to use.

Choosing a pixel,

then extending outwards a bounding box

16 pixels in each cardinal direction *N,S,E,W* would then give you a "tile", 32x32 pixels in width and height

that would function as an origin for a location that you may wish to use.