It is currently Wed Aug 16, 2017 8:33 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Mon Feb 06, 2017 12:20 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1293
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.

Code:

y = y + dy
dy = dy + ddy

dy = (button held) ? (strong gravity) : (weak gravity)

if (button pressed once) then
    dy = JUMP_STR_CONST



Top
 Profile  
 
PostPosted: Mon Feb 06, 2017 12:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18790
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Feb 06, 2017 1:46 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
Interesting.

The jumping mechanism is as follows:

- 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:

Code:
// gravity
if (pvy < PLAYER_VY_FALLING_MAX) pvy += PLAYER_G; else pvy = PLAYER_VY_FALLING_MAX;

// Move
py = py + pvy;

// Collision check (vertical) goes here, ommited.

// Jumping logic.
// pjb: cheap "button pressed" flag.
// pj: jump is on
// pcjt: jump frame counter
if (pad & PAD_A) {
   if (!pjb) {
      pjb = 1;
      if (!pj) {
         if (pgotten || ppossee || phit) {
            pj = 1; pctj = 0;
            pvy = -PLAYER_VY_JUMP_INITIAL;
            sfx_play (SFX_JUMP, SC_PLAYER);
         }
      }
   }
   
   if (pj) {
      pvy -= PLAYER_AY_JUMP - (pctj >> 2) - (pctj >> 3);
      if (pvy < -PLAYER_VY_JUMP_MAX) pvy = -PLAYER_VY_JUMP_MAX;
      pctj ++; if (pctj == PLAYER_VY_JUMP_A_STEPS) pj = 0;
   }
} else {
   pjb = 0; pj = 0;
}


Also constants seem to be the same:

Code:
#define PLAYER_VY_FALLING_MAX   64
#define PLAYER_G            4
#define PLAYER_VY_JUMP_INITIAL   16
#define PLAYER_VY_JUMP_MAX      64
#define PLAYER_AY_JUMP          8   
#define PLAYER_VY_JUMP_A_STEPS      16


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

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 :)

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon Feb 06, 2017 4:11 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 773
Location: Gothenburg, Sweden
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
mojon-twins--wo-xiang-niao-niao.png [ 3.37 KiB | Viewed 474 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. :shock: :twisted:

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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Feb 06, 2017 9:09 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 274
na_th_an wrote:
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. :roll:


Top
 Profile  
 
PostPosted: Mon Feb 06, 2017 10:03 pm 
Offline
User avatar

Joined: Sun Nov 20, 2016 10:43 pm
Posts: 11
Location: Osaka, Japan
Am I the only one who enjoyed the floaty jump mechanic? :?

I think the games are really great as they are and the 'problem' of the games being too similar is a bit surprising to me considering they all come from the same developer.

_________________
tempus edax rerum


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 12:31 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 1:39 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
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.

Any thoughts?


Attachments:
goddess--alternate-jump--a.nes [64.02 KiB]
Downloaded 30 times

_________________
http://www.mojontwins.com
Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 3:42 am 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 274
I think it feels much better.


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 3:53 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 773
Location: Gothenburg, Sweden
I like the change - the jump feels reliable and direct. :)

Another thing i found:
I noticed looking at the map resets enemy and moving platform positions. It has gotten me killed a few times, and i've also used it to cheat.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 4:05 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
Oops - I didn't take that in account! Thanks for pinpointing that issue, I'll try and find a solution.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 4:49 am 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 274
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. :|


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 5:40 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
I'll look into it, thanks.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 6:54 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5535
Location: Canada
na_th_an wrote:
- 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
broken_parabolic_jump_chart.png [ 26.02 KiB | Viewed 385 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.


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 7:49 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 773
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group