Pixel-movement: Scrapping the 32x32 generalization

ID:151617
 
Dec 24 2009, 3:42 am
Alright, I was testing my game, with the pixel-movement nearing completion, however, I noticed that if I put a block in there which is larger/smaller than 32x32 it goes screwy. So I figured... what if I made a new x and y that increased/decreased when the pixel_x/y were above/below 8/-8(lol to the slashes)

For instance:
//PX, being the new pixel_x, as you cannot use the real one, or else it will never reset when it reaches 32
if(src.PX >= 8)
 src.EY++
 src.PX-=8/*what this does is set the BRAND SPANKIN' ~*NEW*~ y when the PX is above 8*/


atom/movable/proc/Position(atom/movable/O)
    if(src.y == O.y)
        if(src.pixel_x+(src.px-src.width/4) >= O.px-O.width/4||src.pixel_x+(src.px-src.width/4) >= O.px-O.width/4)
            src:client.pixel_x=O.width/2
            src.px -= O.width/2
            src.pixel_x -= O.width/2
            return

That's the Position proc(if you can read), it basically just positions you on the objects you've just landed on, or bumped into(landed on for the other half of it) that way you cannot float above/fall through dense objects.

However, things go screwy. For instance, it will bump me if I'm pixels, and pixels, and pixels above it(about 128 of them to be exact).

Would(at this point, this question makes me think this should go into how-to, I can't tell, it has both of the criterion of Design Philosophy and Developer How-To met)
using a y which is based off of 8x8 tiles be more efficient than a y based off of 32x32 ones. If so, how would I implement it?

Dec 24 2009, 4:10 am
I think 128 is the maximum pixel_x/y offset you can have currently =/
Dec 24 2009, 6:11 am
In response to Rushnut
Actually it's now like 30000 or something to that effect.
Dec 24 2009, 1:37 pm
In response to Fugsnarf
Even if you're now able to assign the vars to such values, just like before, it won't do you any good, as pixel-offset graphics once again won't appear if their source object is out of the client's range.
Version 459.1051 Release Notes:
Use of gigantic pixel offsets could cause the server to send huge map sections to the client that were too big to handle properly. Objects that are more than 4 tiles outside of the regular view will no longer appear even if they have pixel offsets that would otherwise make them visible.
Dec 27 2009, 6:52 pm
In response to Kaioken
Would you consider it to be conicidence that 32x4 = 128? ;)
Dec 28 2009, 9:19 am
In response to Rushnut
Almost so. I'm afraid that you were certainly wrong when saying that the limit for pixel-offsets is 128, for 2 reasons:
1) The actual range of numbers that you can set the vars to is currently -32767 to 32767. -128 to 128 is an old limit.
2) The maximum range in which pixel offsets remain functional is 4 tiles, which in pixels is a dynamic number, since it's based on a non-constant.
Dec 28 2009, 5:17 pm
In response to Kaioken
Wasn't the actual old limit -127 to 127?
Dec 28 2009, 5:23 pm
In response to Haywire
Yeah, the old limit was not a perfect set of 32x32 squares. I remember making a Megaman styled explosion by setting pixel offsets awhile back and they didn't go out to a perfect 4 tiles.