Another way to do variable height jumps is to do it in the style of Joust, where whether or not the Flap (or in a general case, Jump) button is held modifies some coefficient to be applied to acceleration due to gravity.

That's similar to how Haunted: Halloween '85 and The Curse of Possum Hollow work. The move subroutine for walking actors (player and others) adds a constant GRAVITY to the actor's velocity every frame. But if the actor's move routine is passing the "fast fall" flag in the control word, the walking subroutine instead adds 4 * GRAVITY. The player's move routine passes "fast fall" while in a jump frame and velocity is upward and A is not held.

- Every frame, vy is added to y. - G is added to vy.- When A is pressed, jumping starts. vy gets a negative boost. Such boost is applied to vy in a decreasing manner as long as time passes during a maximum of 16 frames.

It doesn't have to do with your vx at all - well, partially. Inertia is inertia and you'll get horizontally farther if you are running faster.

What strikes me the most is that you claim they seem different - as, in this case, I'm using the same code in the Y axis in the three games:

My games have always been praised for their jumping mechanics so I thought I had got it right

I have plotted a simulation of the curve and it looks like there is something weird happenning during the first 3 frames and maybe that's what's disturbing the curve. It looks almost like 3 but it is definitely slightly 2 during the first frames.

Thank you for taking your time. I will work in my jumping curves further

Playing wo xiang again; you must be right and my memory was wrong. The curve feels the same as in cheril. It has different implications, though, due to the different core premise, connection to other mechanics, go to the right progression, and level layout.I feel it is off/odd the same way i remember it, though; probably the thing you detected while plotting.

Setting emulation speed at 50% helps showing where the slight velocity change happens. A frame by frame advance + calculating and sending the velocity (compare pixel+subpixel position of previous frame to current) value to an observable place in ZP and watching RAM might help pinpoint it? I'm sorry, i'm terrible at code analysis.

Speaking of layout, this area here:

Attachment:

mojon-twins--wo-xiang-niao-niao.png [ 3.37 KiB | Viewed 2657 times ]

It's a functional passage, but i wonder what it is suposed to be? A house or ruin? A heap? A tunnel?Looking at PPU viewer in FCEUX, it is tight, but there seems to be room for one more 16x16 block since i can identify 8 characters that look the same. Could it perhaps be used to give the non-solid background some visual cues? Or perhaps another already existing block in another palette set could help do the same?

A technical "issue" in the same scene: if you have clothes on and run into that sneaky person running in the middle corridor while she is moving towards you, you get slammed multiple times against the ceiling. It might be a quirk, but it was also awesomely brutal.

Playing a bit more... On non-autoscrolling levels, maybe the camera could be corrected with a shorter delay? I noticed this time that i wait around for the camera to be adjusted to the right.

Another note: if bumping went faster (not just turning the momentum around faster like suggested before; but also when falling), you'd be able to catch fish on their way down. Right now they have the same speed as the player character falling. It's a slight change of game rules, but i think it just might be slightly for the better.

Quote:

your vx

. This got me confused a bit. Was there something in my previous post which had with horizontal movement to do? I must've written something poorly.

Such boost is applied to vy in a decreasing manner as long as time passes during a maximum of 16 frames.

This what makes your jumps 'floaty'. They should have a single large velocity impulse.

My preferred method of ascension control is to make releasing the jump button clip VY: if the player is moving upward faster than a certain threshold, fix VY to that threshold. Exactly what threshold to use takes a bit of tweaking, but it should still be an upward movement. Because it applies the moment the player releases the jump button, it feels 'responsive'.

Another alternative is to lower gravity while the jump button is still held. This is not an upward acceleration, but rather a reduction in downward acceleration. Releasing still has an immediate effect, but since it changes acceleration and not velocity, it's more subtle. This is the method used in the Mario games, and I honestly hate it, but millions of people would disagree with me, and it's heaps better than what you're doing now.

Another tip for better platforming: slightly slower horizontal acceleration. A single tap from my clumsy old thumb is enough to overshoot a one-block platform. Either slow down or stop forcing me to land on such small targets, especially across screen boundaries. Make sure you don't decrease deceleration as well! You should always stop more quickly than you start.

Yet another suggestion: use a single upward collision point, rather than two. Let the top corners of the player's bounding box, especially the trailing one, stick into the ceiling slightly, and push them out sideways instead of downwards. This obviously depends on how your collision code is set up, but it's a big frustration-reducer for jumping in tight spaces.

I'm going to shut up now or I'll end up writing an entire essay on platformer physics.

Thanks for the insight, I will study the possibilities. I taught this stuff myself via discovery, so I may have some points wrong. In my way to job I was thinking about the gravity reduction possibility, precisely, so I might apply that.

It's interesting how people who come from different gaming backgrounds have rather opposite preferences: in my country, most children played to home computers rather than consoles in the 80s, and faster acceleration times are prefered. Whenever I use lower values, the feedback is that controls are slippery, even though deceleration is usually twice the acceleration, even more. I think I should tally the values depending to the game. Fast action in autoscrolling levels in Wo Xiang Niao Niao surely do benefit from the faster horizontal acceleration.

@rikami: thanks for your words. That was part of my own thinking, at least art-wise: of course graphics and music are simmiliar as they are made by the same people Glad you enjoyed the games.

I've changed the jump physics in Cheril the Goddess applying the techniques described here:

- Once you press jump, the "jumping" state takes 16 frames, maximum.- When you press jump, an initial instant boost is given to the vy in the negative direction (upwards).- If you depress jump before the 16 frames have passed, vy is clipped to a lower, fixed value.- During the jumping state, gravity is for times less.

It may be the placebo factor, but I find it quite controllable and visually the curves are more bell-like.

I found a weird bug at the extreme right edge of the map, just past a recharge point with a green bat right next to it, where a statue and two solid blocks got replaced by glitched tiles. I flew up and got stuck on the screen above, where there's one-way platforms with no way out above them.

I didn't think to take a screenshot, and when I came back later everything was normal.

- Once you press jump, the "jumping" state takes 16 frames, maximum.- When you press jump, an initial instant boost is given to the vy in the negative direction (upwards).- If you depress jump before the 16 frames have passed, vy is clipped to a lower, fixed value.- During the jumping state, gravity is for times less.

Any thoughts?

Aside from the gravity alteration, that's pretty close to what I do in my current project.

Start of jump sets an immediate upward velocity.

Gravity is added to velocity each frame, velocity is added to position each frame.

Releasing jump clamps upward velocity to a lower value.

The result is a normal parabolic arc for a full jump, and a "broken" two-piece parabolic arc if the jump button is released before the clamp threshold is reached.

Attachment:

broken_parabolic_jump_chart.png [ 26.02 KiB | Viewed 2568 times ]

I am not entirely sure how your lessened gravity applies, but I'm guessing it makes for a slower ascent and an additional continuity change in the parabola where it switches off.

If* you would want the breaking off to be less sharp, you could perhaps gradually 'roll down' to the clamping value over the course of a couple few frames, maybe four or six? It's a very minute change few will notice on a conscious/cognitive plane, given the short time span, but it might be felt. Ie current_clamp = TARGET_CLAMP + n, and decrease n by 1 or 2 or something until 0. the const TARGET_CLAMP may need to get adjusted a little bit to compensate for the rolling off for the short jump to not lengthen itself.

*maybe being sharp is a good thing, principially or in some environments.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum