Usually when making a game you're going to decide between either Pixel movement, or no pixel movement. If you're going with no pixel movement, then there's a lot of extra variables and memory being used on redundant things.
It'd be nice if they weren't even included unless something forced them to be.
ID:1983703
 Nov 16 2015, 2:34 pm
|
|||||||
Not Feasible
| |||||||
|
Nov 16 2015, 2:47 pm
|
|
Kaiochao
  |
The only variables that are pixel movement-only are step_x and step_y.
|
Kaiochao wrote:
The only variables that are pixel movement-only are step_x and step_y. step_size, and the associated useless procs (when using tile based movement) Plus it's the general point that if someone writes a bunch of stuff that isn't meant for tile based movement, it'll break everything else in your project. It makes sense, but it's not particularly friendly. | |
When step_size is set to a multiple of world.icon_size, you move multiple tiles at once. Not pixel movement.
When bounds (bound_width, _height, _x, _y) are set to multiples of world.icon_size, you occupy multiple tiles. Not pixel movement. However, I can see a use for this to modify the args of Move() so that you can add arguments without having to skip over step_x and step_y. Of course, this might make it very difficult to convert your project to pixel movement if you wanted to, but that's probably to be expected. Enabling pixel movement might also un-define tile-movement-only variables like glide_size and animate_movement. I can also see a use for a more general "syntax version" filter to completely get rid of actual deprecated stuff like lentext(), addtext(), findText(), pixel_step_size, maybe goto. | |
Kaiochao wrote:
I can also see a use for a more general "syntax version" filter to completely get rid of actual deprecated stuff like lentext(), addtext(), findText(), pixel_step_size, maybe goto. findText() generates a warning, so there's that. goto is not and will never be deprecated. | |
Lummox JR resolved issue (Not Feasible)
| |