ID:149522
 
at what BYOND speed dose walking become seemless?
My recent BYONDscape article on player movement includes a method to make it seamless at any movement rate. ( http://www.byondscape.com/scape.dmb/content/000030/ index.html#AT ) Guy even decided to make it free content. ;)
In response to Shadowdarke
so this will make it so when my mob is moving it dose not appear to stop at each tile?
In response to jobe
jobe wrote:
so this will make it so when my mob is moving it dose not appear to stop at each tile?

I figured that's what you meant, though Shadowdarke's code is actually aimed at seamless animation. To get the mob to appear not to stop at each tile, I think what you have to do is play around with pixel_x and pixel_y; otherwise I'm not sure it's so possible to achieve fluid movement.

Lummox JR
In response to jobe
I think the smooth animation takes about 4 ticks to complete, so anything faster than one step per 4 ticks should be fine.
In response to Lummox JR
Lummox JR wrote:
I think what you have to do is play around with pixel_x and pixel_y; otherwise I'm not sure it's so possible to achieve fluid movement.

Adjusting your mob's pixel_x and pixel_y doesn't change the client eye location (unless there is a setting I've missed.) If your client eye is centered on your mob, the mob's icon will wiggle around when you change pixel offsets.
In response to Shadowdarke
Shadowdarke wrote:
Lummox JR wrote:
I think what you have to do is play around with pixel_x and pixel_y; otherwise I'm not sure it's so possible to achieve fluid movement.

Adjusting your mob's pixel_x and pixel_y doesn't change the client eye location (unless there is a setting I've missed.) If your client eye is centered on your mob, the mob's icon will wiggle around when you change pixel offsets.

Ooh, crud. I forgot about that one.

Lummox JR
In response to Shadowdarke
Shadowdarke wrote:
Lummox JR wrote:
I think what you have to do is play around with pixel_x and pixel_y; otherwise I'm not sure it's so possible to achieve fluid movement.

Adjusting your mob's pixel_x and pixel_y doesn't change the client eye location (unless there is a setting I've missed.) If your client eye is centered on your mob, the mob's icon will wiggle around when you change pixel offsets.

Unless your client eye is not attached to the mob. Most games have it attached, but it doesn't have to be.
In response to Skysaw
Skysaw wrote:
Unless your client eye is not attached to the mob. Most games have it attached, but it doesn't have to be.


Indeed. I made a demo that shows how to remove client eye from your mob to another mob, it's located here.
In response to Nadrew
Yes, but I think Skysaw was talking more about moving the eye to fixed objects near the player's mob like in BYOND Home. Moving the eye to a mobile object would make moving your own mob more confusing.
In response to Shadowdarke
Shadowdarke wrote:
Yes, but I think Skysaw was talking more about moving the eye to fixed objects near the player's mob like in BYOND Home. Moving the eye to a mobile object would make moving your own mob more confusing.

Yes, that's what I was talking about. For example, in Murder Most Beautiful, the eye gets fixed to the center of each discreet room that you enter on the map.
In response to Lummox JR
Lummox JR wrote:
Shadowdarke wrote:
Adjusting your mob's pixel_x and pixel_y doesn't change the client eye location (unless there is a setting I've missed.) If your client eye is centered on your mob, the mob's icon will wiggle around when you change pixel offsets.

Ooh, crud. I forgot about that one.

Yeah, I was disappointed when I found out. :( My new project could have greatly benifitted from the pixel offsets, but with the map scale and speeds involved it's not practical to detach the eye from the mob.

I imagine it would be a lot of work in the core of BYOND's code for Dantom to make the client eye capable of pixel offsets too. :(
In response to Shadowdarke
I imagine it would be a lot of work in the core of BYOND's code for Dantom to make the client eye capable of pixel offsets too.

Actually, not really, at least as far as I could guess -- it'd just tell Dream Seeker to draw everything skewed in the window.

The major problem would be forcing the client to load an extra tile's worth of ordinates* in each cardinal direction, since skewing the client eye would require that things that are off the screen be visible on the screen.

Another slight problem would be if people made pixel_x offsets of, say, -127, and then set client.pixel_x to -32. Overflow error.

It's possible, and I definitely request that feature, but those issues might come up. ;-)


* Coordinates would be the more understandable term, but in this context it is unacceptable, since I'm only referring to a single axis at a time.
In response to Shadowdarke
I read that article today, and it gave me the solution that I was looking for (accumulator.) I revamped my speed library using that new idea. Thanks, Shadowdarke!
In response to Spuzzum

Another slight problem would be if people made pixel_x offsets of, say, -127, and then set client.pixel_x to -32. Overflow error.

Just restrict it to the -32 to 32 range.

It's possible, and I definitely request that feature, but those issues might come up. ;-)

Yes. Then I could have an antroids clone that lets the screen move around. Yay!