ID:151622
 
I've never quite understood the desire for pixel movement. To me, it seems the only effect is that movables can take steps smaller than their body. Perhaps there's a degree of smoothness that my eyes just can't detect, but I think there's also diminishing returns.

I'd rather just use a world icon size that's a fraction of the movables' icon sizes. On the downside, this could make it easier for some to hit the limit of how many tiles can be displayed at a time. However, the step-to-body ratio is smaller and bounding boxes can still be tied to tiles with BYOND's standard movement... albeit more of them.

Updates and boardgame test aside, I'm currently designing a project with map cells of 8x8 pixels and movable sizes that are multiples of that. I went small, but I don't think it's necessary. I'm just aiming for 640x360 pixels to follow the 16:9 format recommended by YouTube.
Don't forget that many projects for which pixel-based movement is considered necessary are those for which you either have 360 degree (or at least a lot) freedom of motion or if the game is a platformer. I suppose smaller tiles could make platformers using the tile based movement more feasible, but even then 8x8 might be too large.

This is a good idea though. More experimenting with this would be a good thing.
I try not to use the term "pixel movement" when possible, preferring to talk about "non-atomic movement" or "non-standard movement" when talking about BYOND. A non-atomic movement system needs to use an abstract system to determine or change position and size. Once this is done it then updates its display system to reflect these changes. Most of the time on BYOND, people choose to go for a 1:1 correspondence between units in the movement system, and units in BYOND's display system, leading to the term "Pixel Movement". This is not strictly necessary, and a lot of the time it isn't even true. For instance, Plunder Gnome uses what has been called a "Pixel Movement" system, but it is not. It uses a floating point value to represent position, and a rounded version of that value to display the object.

You may be wondering why I went through such lengths to make such a minor point. It becomes important when dealing with your suggested method. Your idea is to use small turfs, and multi-tiled mobs. The problem is that you will still need to define your own custom movement and positioning system to handle those larger objects. The basic concepts of such a system are exactly the same as those used in pixel movement (such as bounding boxes, or circles, or what have you). There may be benefits in that you're not using atomic (or client) pixel offsets, but I'm not sure that these out-weight the drawbacks of displaying more tiles on screen, mapping out all those tiny tiles, or generally dealing with a system where each "large pixel" is also an atom.

I thought about this very hard when world.icon_size was first introduced. I think it comes down to a matter of performance, one that will have to be determined by test projects: Does a custom movement system where each unit of movement is an arbitrary piece of data, displayed via pixel offsets, work better than a custom movement system where each unit is a small atom?
I think the problem with simply using smaller turfs and keeping the default system is that with pixel movement you have the possible freedom of creating your very own collision system which can be customizable to do just about anything with any size. You, by using just smaller turfs, are still limited to the size of icon you're using. With a pixel movement system there are no limitations. You just tell it where and when to collide based on your size and your pixel offset. With your method of using smaller turfs, you'd also still want to make movement into a loop at least. Pixel movement using the default repeat for movement does not work very well.

Really I see nothing wrong with your method, but I do see far more possibilities with a custom pixel movement system.
I have been testing technology lately for a new game concept which requires the concurrent movement of many different objects at many different speeds, very rapidly. My technical challenge is getting the movement to look "smooth" on the client end while still being able to pause/freeze the movement at a moment's notice.

I tried using smaller tile sizes as one way to handle the issue, since I could still make use of pixel_step_size on the client end (instead of pixel offsets, which are still slow). The main problem I ran into was network lag - when displaying all the additional tiles (with a world.view of 35 or so) I would run into immense slowdowns across the network when there were lots of active things on the screen. This was lessened when using overlays on single objects wherever possible to achieve the desired graphical effect, but still not eliminated entirely.

The entire pursuit of smooth pixel-based movement has proven to be an immense challenge for me in my latest endeavor. I hope that strides are made in the future to support this better (at least some optional predictive movement algorithms on the client side would be nice).

I wish you luck! I have tried over 13 separate ways of handling my problem and finally chose the lowest hanging fruit and sacrificed some visual glitz for it.


~Polatrite~