An easier way to convert to pixel movement wouldn't be a bad idea, kind of how isometric works.
When I post the update to my pixel movement library I'll also be posting a video to show how you can convert to pixel movement just by checking the box to include the library. If I have time I might add examples of how tile-based features can still work even after you include the library.
Falacy wrote:
There is no possible way that pixel movement could be LESS flexible than tile movement.
What we're saying is that pixel movement can work many different ways, so it's unlikely that the default behavior would be sufficient. I expect that very few games use the default tile-based movement, most people need to override some movement procs to make the game work how they want.
then theres loads of changes to be made anyways if you already have a game using tile movementI've been over that multiple times in this topic alone, there really isn't.
There really is. A lot of assumptions can be made when you use tile-based movement. For example, you can do this to limit movement speed:
mob
var
locked = 0
Move()
if(locked) return 0
locked = 1
.= ..()
spawn(3) locked = 0
But things like this don't transfer over to pixel movement. There is also the assumption that the mob is standing in the center of a single tile. What should view() return if you're standing partially between two tiles? If the behavior of these procs changes when you enable pixel movement, what do you do if you want to access their tile-based behavior? Also, when you assume that a move takes you from the center of one tile to the center of another, it's obvious when Exit, Enter, Exited, and Entered should be called. When you can move pixels at a time, when precisely do you enter or exit a turf?
Edit: another issue: when you set an object's loc you are only being precise to the tile. When you're using tile-based movement that's fine, but when you have pixel based movement it's not. Suppose you want to move an item from the player's inventory to the ground at their feet, just setting the item's loc to be the mob's loc wouldn't cut it. What if you wanted to swap the positions of two mobs - you can't just swap their locs. There's no way for old code to work exactly how you'd want it to.
I don't see why you and/or Lummox thinks this. There is no possible way that pixel movement could be LESS flexible than tile movement. In fact, you should logically have to build pixel movement into tile movement (not vice versa) - it would be rather easy, by simply looping a few steps. If BYOND properly handled some type of pixel_step_size setting on movable atoms, then it could probably be as easy as changing that variable to 32. I'm not sure what type of flexibility issues you're referring to...
I provided a decent amount of suggestions. If they need more information, they can feel free to ask. As I said in the request, its very common for new issues to arise while developing, regardless of how well you have things planned out. And when/if pixel movement is actually implemented, I'm sure it will lead to a hoard of new issues & requests.
I've been over that multiple times in this topic alone, there really isn't.
New icons surely wouldn't be required, though you may be able to improve upon them nonetheless. Turning shouldn't be effected at all by pixel movement vs tile movement...