Can somebody show me code for jumping/velocity?

[rainwarrior]

I wonder if the OP will come back or if we've scared them off with our bickering. ;(

[Drew Sebastino]

I don't know, but there's a surprising number of people on this forum who only post once or twice and are never heard from again. There are even quite a number of people who have several year old accounts and have never posted once. Why even make an account? You know, someday, you might as well just delete those.

[thefox]

Why even make an account? You know, someday, you might as well just delete those.

I don't think deleting all non-posting accounts would send a good signal. There are other uses to having an account other than just posting. For example, if you have an account, the forum software will keep track of unread posts in threads.

[tomaitheous]

Well, if he doesn't come back.. then we could just take over this thread and talk about different ways people implement jump physics and related stuffs.

I knew of the constant gravity method, but I always chose not to use it. I always used conditional states specifically to tweak control aspects of the player/character.

[Sogona]

Bumping this because it's already here.
It seems like a lot of platform games have the object hotspots at the bottom center to make it easier to land against the ground, but I've already designed my object system around having the hotspot in the top-left corner, and would have to re-write it, so I'd like to avoid that if possible.

I've done some simple work with subpixels, and it looks like they're pretty much a necessity for making a jump look like...well...what you think of when a sprite jumps. Right now, I just have an 8-bit value representing the Y position of my objects. Assuming I want each object to have gravity, should I change them to be 16-bit so they can have sub-pixels?

It looks like the common way to do jumping (Like Rainwarrior described) is to set the vertical speed to a large negative value, causing the object to jump, and then increase the vertical speed until it eventually becomes positive, causing the object to fall.

How I'm currently going about jumping is still pretty buggy; gravity only works when the object is actually jumping, and the object usually gets either slightly stuck in the floor, or hovers slightly above it. My theory is that this in part due to the vertical speed being the wrong sign when a map collision happens, as the vertical speed is what I'm using as the value to eject the object.

Here's what I currently have, implemented from Rainwarrior's algo. Just to clarify I am using ASM, I just like to write in pseudocode to get stuff across.

Code: Select all

if (obj_action[object] != JUMPING) {
	obj_y[object] += obj_vspeed[object];
	obj_hb_y[object] += obj_vspeed[object];

	//Background collision
	//Don't have code for checking collision with the ceiling yet
	//Check collision with the floor
	if (collision happened for the left corner, right corner, or midpoint) {
		obj_y[object] -= obj_vspeed[object];
		obj_hb_y[object] -= obj_vspeed[object];
		obj_action[object] = STANDING;
	}
	else
		obj_vspeed[object]++;
}
else if (buttons_pressed == A) {
	obj_action[object] = JUMPING;
	obj_vspeed[object] = -12;        //An arbitrary starting value
}

[tokumaru]

should I change them to be 16-bit so they can have sub-pixels?

Definitely.

It looks like the common way to do jumping (Like Rainwarrior described) is to set the vertical speed to a large negative value, causing the object to jump, and then increase the vertical speed until it eventually becomes positive, causing the object to fall.

That's the general idea.

gravity only works when the object is actually jumping

I actually advocate the use of gravity only when the object is in the air (jumping or falling), because I find it a waste of CPU to add the gravity even when you know the object is on the ground just to eject it back.

and the object usually gets either slightly stuck in the floor, or hovers slightly above it.

That sounds like improper ejection. As soon as you detect that the object is below the floor, you should "snap" it exactly to the floor level, making it impossible for it to be slightly off.

the vertical speed is what I'm using as the value to eject the object.

That's not right. You shouldn't just "undo" the whole movement, because part of it was valid, only the amount that went into the ground has to be undone.

[dougeff]

Can I jump in with a similar question about 16-bit X movements...

Because, when just using the upper byte (upper byte for pixel, lower byte for subpixel, but position needs to be reduced to 8-bit)...essentially is a round down, and you notice pretty quickly that positive and negative X movements are uneven...

Some website suggested for converting float to INT that you should add 0.5 before the conversion to int (which is similar to this situation)...I suppose that would be like adding $80 to the lower byte before using the upper byte as X movement...

But, I haven't seen any code that does this sort of thing for 6502...am I thinking about this issue correctly?

Or perhaps, I should be using the full 16-bits for speed and position, rather than just the upper 8-bits. ?



(On a side note, the Ninja game does a completely different and weird method that avoids 16bit math altogether, but I'm aiming to improve the core code with better physics).

[tokumaru]

Because, when just using the upper byte...essentially is a round down, and you notice pretty quickly that positive and negative X movements are uneven...

I think the difference is pretty negligible.

I suppose that would be like adding $80 to the lower byte before using the upper byte as X movement...

Or just do this:

Code: Select all

	lda fraction
	asl
	lda integer
	adc #$00

This would be done only for drawing the sprites though, not for the movement.

[dougeff]

Thanks, that helps.

And, I do think it's noticeable...(rounding down)

Scenario 1...acceleration of $0020...
Going right will take several frames before you get 1 pixel of movement right...
0020, 0060, 00c0, 0140 (16bit X position)

Going left, you get a pixel movement on the first frame...
ffe0

[thefox]

But, I haven't seen any code that does this sort of thing for 6502...am I thinking about this issue correctly?

Yeah, by rounding to nearest you can minimize the amount of error, but you have to consider whether it's worth the performance hit. I'm sure many games/apps on 6502 round down without thinking twice about it.

[Sogona]

That's not right. You shouldn't just "undo" the whole movement, because part of it was valid, only the amount that went into the ground has to be undone.

Hmmm...how would I go about calculating this? As a first project, I know I'm not gonna attempt slopes, so I think it's safe to assume that pretty much everything would be aligned to a 16x16 pixel grid, so would the eject value be 16 - whatever the vertical speed was?

[tokumaru]

Speed has nothing to do with this. The speed is not aligned to the block grid in any way, so it definitely can't be used to snap to blocks. It's the vertical coordinate of the collision point that you have to use.

To detect collisions, you generally get rid of the pixel bits in the coordinates and use only the higher bits to find blocks in the map, right? Well, now you need the lower bits, because they'll tell how far the into the block the object went. If blocks are 16 pixels tall, their top is always at row 0, and the bottom is always at row 15.

If PointY AND $0f is 0, the point is 1 pixel inside the block. If it's 15, the point is 16 pixels inside the block. So, simply get the Y coordinate of the point you used to collide with the floor (usually that's 1 pixel below the object) and do this: EjectY = (CollisionY AND $0f) + 1

Now just subtract EjectY from the object's position and it'll be perfectly aligned with the floor.

[Sogona]

EjectY = (CollisionY AND $0f) + 1

That works perfectly.

I'll probably just re-write my jumping code rather than trying to inject subpixels and gravity when falling into it. I'll get back after that.

EDIT: This actually wasn't as difficult as I thought it would be. The player can now jump, fall, and collide correctly, and I also added variable jump height.