My game relies on small differences in movement speed and I was wondering if there was a way to implement decimal step-sizes, rather than increasing the overall speed of the game, because as it stands, step-sizes are relatively close together, I could scale them all up so that decimals are a rarity, but if I don't have to do that, I'd rather not.
| |
Short answer, there's no unit between two pixels...
Long answer: Increase your world.icon-size from 32 to 64, then change your map's icon-size to 32 (so it looks the same as it was before)... double the size of all your graphics and you will have gained half a pixel within the appearance of a single pixel. In other words, it will be possible to "stand" in between pixels. This is easier said than done, but if you do it, you gain a lot of advantages. Your map text can be rendered at twice the resolution than your game graphics, and you can make movement look a lot smoother. | |
That's what I figured I would have to do. I already actually did that (but I could double it again, its no biggy)
I made a small icon utility that doubles the size of icon files automatically so i'll try that EDIT: I had only pondered this because forum_account's pixel_movement used to be able to do this, technically there was a unit between two pixels, just not graphically. So if your speed was 1.1, and you moved 10 times, you would actually move 11 pixels instead of 10. It's a gradual difference but it allowed for lots of different speeds | |
I've brought this up a lot before. People don't appear to understand why you would want to "move less than a pixel" or "what that would look like," when the thing they're not getting is that it's not about what it looks like to move less than a pixel. It's simply a part of numbers that needs to be conserved for high framerate + low speeds.
Here's a nice post full of those kinds of people: http://www.byond.com/forum/?post=151264 I've tried out the method Forum_account uses in his libraries (which use native pixel movement, by the way). My current implementation seems simplest to me, but it's probably not the fastest. I haven't had any efficiency problems with it, though. Basically, you have a vector containing your internal position, decimals and all. When you want to move a certain displacement, add it to your internal position. You can easily find your external pixel coordinate, which is just tile_width * (x - 1) + bound_x + step_x. Then, you round the internal position and subtract it by your external position. With that integer difference, you can move with Move(). I have yet to figure out how to allow movers to use this system and slide along walls. The built-in super-accurate collision only works with one big Move(). The usual way to slide along walls that I use is to have two separate Move()s in the two axes, but then moves won't be a accurate. Meh. I'll figure it out. | |
EDIT: But I have tried using fractions