﻿ Link->Jump not as documented. [Archive] - Armageddon Games Forums

PDA

View Full Version : Link->Jump not as documented.

ZoriaRPG
05-29-2015, 10:21 AM

* 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. '

coolgamer012345
05-29-2015, 01:46 PM
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.

Saffith
05-29-2015, 04:51 PM
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.

Tamamo
05-29-2015, 05:23 PM
IMHO Link->Jump should be a float.

ZoriaRPG
05-29-2015, 06:58 PM
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.

Tamamo
05-30-2015, 01:34 AM
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.

ZoriaRPG
05-30-2015, 08:26 AM
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

ZoriaRPG
01-20-2016, 07:18 AM
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.

Tamamo
01-20-2016, 10:57 AM
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.

Saffith
01-20-2016, 11:09 AM
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...

Tamamo
01-20-2016, 03:13 PM
Oh right, not a bug. Marking this as fixed then.

ZoriaRPG
01-21-2016, 05:30 AM
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.

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.

Tamamo
01-21-2016, 06:51 AM
it is, internally.

ZoriaRPG
01-24-2016, 12:34 PM
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.

Tamamo
01-26-2016, 10:32 AM
they all are
keeps things simple