Pixel_x and Pixel_y

ID:134736
 
Nov 7 2005, 8:43 am
I know this has been brought up before, but it seemed to be dismissed as unecessary. I, however, would have quite a use for raising the limit of pixel_x and pixel_y, just at least as far as BYOND's view size limits allow. When using pixel_x and pixel_y for overlay offsets, I'm limited on how large I can make my "large" icons. It doesn't seem like THAT much of a cost to store the extra information needed to extend the limit, but I may be wrong. I can live with 128x128 icons, but it'd be neat to have some really massive dragons and things in Maeva. :)
Nov 7 2005, 9:22 am
There are easy workarounds for that. Just use more objects, or use images instead of offsetted overlays.
Nov 7 2005, 11:51 am
Or, you could do when the pixlel_(x or y) gets to 127 just increase it's X+1.
Nov 7 2005, 11:53 am
In response to PirateHead
PirateHead wrote:
There are easy workarounds for that.

Sure there are, but this is one of those things where it just makes sense to extend the limit anyway. Hopefully it will have full range in version 4.
Nov 7 2005, 11:54 am
In response to Sniper Joe
Sniper Joe wrote:
Or, you could do when the pixlel_(x or y) gets to 127 just increase it's X+1.

Not really. He is talking about the offset of image objects, not just a single arbitrary object on the map. You can't just relocate them.
Nov 19 2005, 10:41 pm (Edited on Nov 19 2005, 10:52 pm)
In response to Loduwijk
Now, I have become very partial to using more than one object. there are a few simple reasons: 1) when the object leaves the view, so do its overlays. Therefore, a 128x128 object will leave the viewport when its base tile leaves the viewport, making invisible dragons able to appear out of nowhere. 2) Density, need I say more?

As for the downsides to multiple objects: Often, in online games, the clients will see the object break up, even if the host cannot. It really sucks, and ruins the effect.

Can't really win either way.

I'd like to see BYOND have the ability to have "object maps", or an atom that is like a container of objects. It can have more than one location, and acts like a single object when referenced:

objectmap
 var
  list/map
  list/contents
  x
  y
  z
 proc
  getDensity(x,y,z)
   var/atom/movable/M = src.map["[abs(src.x-x)],[abs(src.y-y)],[abs(src.z-z)]"]
   if(M)
    return M.density
   else
    return 0
  Add(var/atom/movable/M)
   src.map += "[abs(src.x-M.x)],[abs(src.y-M.y)],[abs(src.z-M.z(M.z)]"
   src.map["[M.x],[M.y],[M.z]"] = M
   var/atom/O = locate(M.x,M.y,M.z)
   O += src


Essentially, the objectmap is inside of the turf, and the turf grabs the object out of the map list by locating it via absolute value from the objectmap's origin location.

I'm going to start a thread for this kind of thing built into BYOND. Surely, by having this behaviour built in, this kind of thing can be more useful and much more presentable as an end-result.
Nov 21 2005, 5:17 am
In response to Ter13
That's what SYNC_STEPS is for. They'll never see it break up.
Nov 21 2005, 1:53 pm
In response to PirateHead
WRONG. Across slower host-networks, breakup on synch_step objects is very common.