Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Micahsa on 2008-03-03, 10:57:34 PM
-
So, went through the whole tutorial, everything works fine, I add gravity and all, make a few custom sprites, etc.
But I want to add jumping. For the life of me I can't get the right setup.
Taking an example from the SHFL demo project, I have:
If IsInputPressed
SpriteBase.InputBits.Button2
Inital only = true
then: Do = -10 (output to dy)
I get my sprite to jump, but he jumps a tiny hop and falls back down and I can't figure out how to change the jump height.
Also, he can jump mid fall so he keeps going up and up if I keep pressing fast enough.
Is there something more complicated to basic jumping?
-
well you've done it well so far, but it's just a little bit of changing numbers.
then: Do = -10 (output to dy)
make that 10 bigger will make the jump more powerful.
or you could lower the gravity.
-
Also use the IsBlocked function to determine if the player is standing on solid ground before allowing it to jump. The sample game should demonstrate this.
-
Sorry for the delay, but thanks for the help. Got it working and the isBlocked is nice, missed that one.
Another issue now however. I started a new project from scratch, making all the basic componants and such, but my solid tiles are only solid from the top and bottom. My sprite can jump onto them and when he tries to jump from underneath a floating one, he is blocked (which I want). But he is not blocked from running horizontally through the tiles from either side.
I pulled out the tutorial and have been reading through it checking my work but can't find any steps I missed or anyplace that I'm able to distinguish between fully solid or partially solid.
Thanks and sorry if its a simple thing (which I'm sure it is :whistle:)
-
What shape did you assign to the tiles (in the "Solidity")? If they are "TopSolid" then the player will only be blocked from falling down through the tiles; every other direction the player will be free to walk/jump through the tiles.
-
Solidity is set to SolidTileShape.
The only difference I can find between mine and the tutorial (aside from the graphical differences and such) is that I have two graphical sets, one for world graphics, one for sprite graphics. I also have two framesets, again, one for world graphics, one for sprite graphics.
I have one tileset with all of them in there and one tile category of "solids".
My sprite solidity rule is: Do ReactToSolid and it comes right after my left, right and jump rules, before anything else.
-
The only other thing I can think of is, where did you put MoveByVelocity? If there's anything between ReactToSolid and MoveByVelocity, or if MoveByVelocity is before ReactToSolid, it's possible that you're moving the sprites without taking the correct solid reactions into account.
-
That was it.
I had React to Solid, snap to ground, limit velocity, accelerate, gravity, move, then inertia.
I pulled Move up right after react to solid and works like a charm now.
Order of operations always hated me :)
Thanks!
-
I think what you want to do is drag Move DOWN one MORE from where it was (after inertia), and pull React to Solid DOWN to right before it (after inertia). The way you have it currently set up, you're doing the calculations for Snap,Limit,Accelerate,Gravity,and Inertia for the NEXT frame DURING this one. The way you had it before, you were doing calculations for inertia for the next frame.
In general, you should do all the things that figure out WHERE the sprite should be, and then MOVE them there.
-
this should really be mentioned in the help files. it sounds a little bit strange, because i thought all the time it would make no difference. but okay, i understand the logics behind that.
-
I think it really doesn't make a difference. There's no code that really cares whether your sprite's velocity indicates how it got to where it is now or where it's going to go on the next frame, unless you write some code that cares. There's no SGDK2-intrinsic code that executes on sprites between frames except to delete inactive dynamic sprites. It does seem a little odd to me that you would move the sprite and *then* calculate where to move, but when I think about it, it doesn't really matter enough to tell someone to do it one way or another if my way doesn't make sense to *them*.
-
Well, if they don't quite have a way, and if they're trying to debug something, it would be easier for others to help if there was a "normal" way to do things, much the way many places have standards for how to format code, and why it's harder to understand obfuscated code, etc.
-
I get the logic and was also wondering about why it actually mattered from a code point of view. But standard practice certainly helps with debugging, so thanks for the recommendation.