The Dink Network

I stumbled upon some weird behavior recently. Apparently when you try to measure Dink's x and y coordinates in the main procedure of some script that runs straightaway when Dink enters the screen you actually get the x and y coordinates Dink had on the previous screen. Take for example this script and attach it to a sprite on the screen or to the screen itself:

void main(void)
{
int &dx = sp_x(1,-1);
int &dy = sp_y(1,-1);
say("X: &dx Y: &dy",&current_sprite);
}

Now Dink will say the coordinates he had on the previous screen.

A possible solution would be to rewrite this script as:

void main(void)
{
wait(0);
int &dx = sp_x(1,-1);
int &dy = sp_y(1,-1);
say("X: &dx Y: &dy",&current_sprite);
}

However Dink actually moves during this wait(0); command. This is a bad thing for a script I need because there I need to determine whether Dink enters from the left or from the bottom of the screen so I can't use large margins of error. This error is about 6 pixels in the x-direction on my computer using normal Dink speed or 12 pixels using herb boots. But I imagine that this is dependent on things like computer speed and the amount of scripts on a screen as well.

There is actually a similar error in the first script: It gives a typical value of x = 17 when I move from right to left using normal dink speed and x = 14 using herb boots. However this doesn't contribute to the 6 pixel error in the second script as freezing Dink during the wait(0); makes Dink appear at exactly the expected location.

Now I was wondering if I could actually use this strange behaviour to determine the direction Dink is coming from. (So a high x value means Dink comes from the left.)How reliable do you reckon this behaviour is?

EDIT: Actually I found that freezing Dink during a wait(0); command doesn't really influence the smoothness of Dink's movement noticeably. So I'll just use that and hope people will play my DMOD on a sufficiently fast computer. Still, my question remains interesting.

I don't see any reason why it wouldn't work. It should be quite reliable. But then again, I suck at DinkC.

Is there a particular thing you're trying to set up for when Dink enters from a particular point or something? Surely there are workarounds.

It's not that weird. The screen script executes before the sprites are created, so it makes sense because Dink has't been placed on the new screen yet. Anyway, the thing that bothers me the most is what if Dink enters via the left near the bottom, or via the bottom near the left? How do you know where he came then?

You can check sp_x/y before and after a wait to deal with this and you won't need the freeze. A big change in y means Dink came from the bottom, a big change in x means Dink came from the left. Much more elegant solution.

The screen script executes before the sprites are created, so it makes sense because Dink has't been placed on the new screen yet.

That's what I thought too initially. However as Dink has sprite number 1, I assumed that Dink was the first to be placed on the new screen. So attaching the script to another sprite (which has to have a sprite number above 1) would solve the problem. However attaching it to another sprite does the exact same thing as attaching it to the screen. So it isn't that straightforward from my point of view...

Anyway, the thing that bothers me the most is what if Dink enters via the left near the bottom, or via the bottom near the left? How do you know where he came then?

I placed a small patch of hardness in every corner. It might not be the prettiest solution, but it does the trick... That's also where my small tolerance for error came from.

You can check sp_x/y before and after a wait to deal with this and you won't need the freeze. A big change in y means Dink came from the bottom, a big change in x means Dink came from the left. Much more elegant solution.

Indeed

Going to use that.

EDIT: Also, I can't use a workaround such as storing the previous value for &player_map into a global as I do screen changes without physically changing screens, so the value for &player_map would be highly deceiving... So unfortunately those hardness patches are there to stay.

Someone: Anyway, the thing that bothers me the most is what if Dink enters via the left near the bottom, or via the bottom near the left? How do you know where he came then?

Meta: I placed a small patch of hardness in every corner. It might not be the prettiest solution, but it does the trick... That's also where my small tolerance for error came from.

Shouldn't you be able to check that with the x and y as well? I.E. if Dink walked right, X > 619, left X < 20, down Y > 399, up Y < 0.

EDIT: I see you pretty much said as much in the first post. =) Seems perfectly reliable to me, much more so than using waits since there's always some variation with those on different computers. (Whereas the base script undoubtedly always runs before the XY resets)

Meta: However attaching it to another sprite does the exact same thing as attaching it to the screen. So it isn't that straightforward from my point of view...

Yeah you're right, I overlooked that. I guess Dink is placed on the screen last.

Scratcher: Seems perfectly reliable to me, much more so than using waits since there's always some variation with those on different computers.

If the wait is only 0 or 1 there shouldn't be variation depending on the speed of the computer. The order things are executed in should usually be independent on processing speed. So it shouldn't matter for my solution. Besides, since the change in x or y is so dramatic on changing screens there is huge tolerance for error. A 6 pixel error isn't going to mask a change of 400 pixels as Dink moves from the screen on the left.

Just so in case it is not clear

void main void)
{
int &x = sp_x 1,-1);
wait 0);
&x -= sp_x 1,-1);
if &x > 300)
{
//came from the left
}
}

forgive my lack of opening parenthesis..

Can't you just use sp_dir?

If the wait is only 0 or 1 there shouldn't be variation depending on the speed of the computer. The order things are executed in should usually be independent on processing speed.

Yeah, I agree it's not really unreliable in this case, I was thinking more about what Meta said in the first post and the whole hard corner thing: However, there doesn't seem to be a need to go as far as checking the coordinates after a wait. IE, when you check the XY at first, it comes up as something like 621 0, 20 405, or whatever. So the only thing needed to determine where Dink came from is to check which screen border he went over.

Test script:

void main(void)
{
int &dx = sp_x(1,-1);
int &dy = sp_y(1,-1);
say_xy("X: &dx Y: &dy",0,0)
if (&dx > 619)
say("I came from left!",1)
if (&dx < 20)
say("I came from right!",1)
if (&dy < 0)
say("I came from down!",1)
if (&dy > 399)
say("I came from up!",1)

wait()

int &dx = sp_x(1,-1);
int &dy = sp_y(1,-1);
say_xy("`%X: &dx Y: &dy",0,20)
}

EDIT: Nevermind, you can screw it by walking diagonally at a corner, so that it displays something like 625 -4. Eguurgh.

Can't you just use sp_dir?

I think the diagonal dirs would screw that up, e.g. you can go left by walking southwest, or go down by walking southwest.