Link->Jump not as documented.

The documentation for Link->Jump reads as follows:

Code:

---

Link's upward velocity, in pixels. If negative, Link will fall.
        * The downward acceleration of Gravity (in Init Data) modifies this value every frame.

---

Note here, it says, in pixels; and it also briefly mentions that the internal constants modify this. I would not expect that gravity would increase the height in pixels by 16, if over 2...

I find pixels to be untrue... If the value is considerably low ( 1, or 2 ), then it is indeed in pixels; however, anything much higher than '3' is in tiles.

Is this intended? Is it a bug? Is the relationship of constants something that must be modified for the value to always be in pixels?

That meaning, is there some relationship between this, and the internal gravity and velocity constants, to force a strict x = pixels relationship; or is the zscript.txt documentation just wrong here?

If so, what equation is used, to calculate the effects?

This isn't a high-priority thing, as I'm not doing any side-scrolling stuff meself, but in advising a few people on the matter, it's come to my attention on more than one occasion.

P.S. The documentation for Link->Jump on the wiki is also incompatible with that of both zscript.txt, and the behaviour of the variable in use:

'Link's upward velocity, in 1/20ths of a Roc's Feather jump. Undefined for values outside of -20 <= Jump <= 20. '

With gravity set to 0.16 and velocity set at 3.20, the defaults, setting Link->Jump to 1 gave about 1 tile, setting it to 2 gave about 26 pixels of jumping, setting it to 3 gave me about a 54 or so pixel jump, setting it to 4 gave me about 6 and a half tiles (about 104 pixels) of jumping, and setting it to 5 gave me 8, possibly more, tiles of jumping. I am using ZQ/Zc 2.50 Build 28. Not sure if I have 2.50.1 or one of the RC's, though.

It's supposed to be pixels, but the math's not working out somehow. Probably an issue with underflow in the format conversion. Fixed now.

IMHO Link->Jump should be a float.

Quote:

---

Originally Posted by Tamamo

IMHO Link->Jump should be a float.

---

Internally, it is already a float; then it's floored for use with the actual mathematics so that you don;t end up with partial pixel coordinates, or, at least it is supposed to be floored. I suspect that it isn't, because the math for its conversion is extremely wrong, and the returned value is still a float at all times if you Trace it. You may be able to write a floating value to it as-is, given that it Treace()s as a float.

@Saffith . Thank you. I look forward to testing the updated/fixed versions.

P.S. Does this affect extant quests, or does it only store an ASM value during compilation? (i.e. Is the new value mechanic internal, or is it calculated during compilation and stored in the ZASM code?)

If the value is stored in the ZASM code, then it shouldn't affect anything made in the past, but if it's an internal math problem, well, some people may need to update things. I'm not sure how long this has been broken.

No it ain't it's a fixed point number "it's an allegro thing" but that's neither here here or there. If it whe're a true float it would make things a hell of a lot easier.

Quote:

---

Originally Posted by Tamamo

No it ain't it's a fixed point number "it's an allegro thing" but that's neither here here or there. If it whe're a true float it would make things a hell of a lot easier.

---

Well, you're a dev, so break it until it obeys. :p

Update: While Link->Jump now returns the correct values, it still does not work as documented, and is inconsistent within its own value ranges. Setting Link->Jump = 10 for one frame, for instance, moves Link far more than 10 pixels.

@ZoriaRPG
Do me a favor and set it to -10 as well, it should defunct to terminal velocity. if not @Saffith broke something else trying to fix this.
But that's a given when it comes to ZC. Change one thing, Break another.

This is me saffith and gleeok right now. Which one is Picard I have no idea.
http://hotnerdgirl.com/wp-content/up...e-facepalm.jpg

Jump isn't a single frame thing; it drops gradually as gravity slows him down. Setting Link->Jump to 10 moves Link upward 10 pixels per frame, then 9, then 8...

Oh right, not a bug. Marking this as fixed then.

Quote:

---

Originally Posted by Saffith

Jump isn't a single frame thing; it drops gradually as gravity slows him down. Setting Link->Jump to 10 moves Link upward 10 pixels per frame, then 9, then 8...

---

I set Link->Jump = 10, followed by Link->Jump = 0 ... :(


I'm going to need to test it with frame-advance, to confirm what's happening.

I should note that what I perceive to be buggy-ness is for sideview-gravity, which is inherently broken in many aspects.

It would be so nice if this was a floating point value.

Quote:

---

Originally Posted by Tamamo

http://hotnerdgirl.com/wp-content/up...e-facepalm.jpg

---

Ignoring the photoshopped-in-person, my mind is burning trying to remember from what TNG episode that frame was taken. I know that scene, but I can't place it. It looks like a typical day, around here.

it is, internally.

Quote:

---

Originally Posted by Tamamo

it is, internally.

---

Unfortunately, on the lexer end, it's classified as an integer. It really should be converted into a floating point scale, and adapted to a fixed, like ffc coordinates. In fact, most of the ffc coordinate code could be reapplied to the Link coordinates, I think.

This shouldn't break anything, or at least, not in an important way.

they all are
keeps things simple