Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
This is just a handful of convenience vars I ended up defining while cobbling together my pixel movement system. They're nothing fancy but it would be nice if DM provided them by default. My naming conventions probably aren't the best but they should get the idea across at least.

pixel_maxx: world.maxx but in pixels (world.maxx * TILE_WIDTH)
pixel_maxy: world.maxy but in pixels (world.maxy * TILE_HEIGHT)

Currently these have to be global vars in my implementation. It would be nice if in an official implementation these were world vars instead to keep syntax consistent with world.maxx and world.maxy.

movable.map_x: movable.x but in pixels (1 + (x - 1) * TILE_WIDTH + step_x)
movable.map_y: movable.y but in pixels (1 + (y - 1) * TILE_HEIGHT + step_y)

movable.pixel_bound_x: movable.bound_x but in pixels (map_x + bound_x)
movable.pixel_bound_y: movable.bound_y but in pixels (map_y + bound_y)
movable.pixel_bound_maxx: (pixel_bound_x + bound_width)
movable.pixel_bound_maxy: (pixel_bound_y + bound_height)

These last two just give quick access to the coordinates of the top right corner of the bounding box.
DM's coordinate convention is to be 1 at minimum, so the pixel coordinate of the left side of a movable's bounding box, when pressed against the left map edge, is this:
1 + (x - 1) * TILE_WIDTH + step_x + bound_x
(and similar for y)

It would also be useful for these pixel coordinates to be defined on turfs instead of just movables.

I use the coordinates of the centers of bounding boxes much more often than the lower left or upper right corner of the bounding box, so convenience vars for that would also be nice.

You can see my implementations of pixel movement-related functions (and more) in my KaioCode library.
In response to Kaiochao
Ah whoops thanks, my variables account for the one as well. That's what I get for posting without checking my code. Updated the post with the correct formula.

Login to reply.