My pseudo 3D jump code

[Brick Nash]

Hi folks,

Just wanted to stop and ask if I'm heading in the right direction with my current task and perhaps any suggestions for better efficiency.

I'm trying to write a 'jump' code for a pseudo 3D type game like Double Dragon. From what I learned from doing this in Game Maker the jump requires an additional fake Z axis as the 'Y' is used for walking back 'into' the screen.


I have however managed to do it just using the Y axis and 2 For/To/Next loops nested inside one another, one which makes the player travel upward at a certain rate and the other which gradually reduces the number that the player travels by 1 until it becomes a negative and starts to go back down again. Then it was just a case of playing with the numbers to get the launch/land position right. I assumed I'd have to somehow store the current Y co-ordinate (hot spot at feet) at the point of launch as a reference but this works pretty well and is customisationable to directions/added left or right travel. The only issue is that it's a little fast on the travel but it's not a big deal.

I've not quite got to collisions yet but I was worried that this method may somehow cause problems with it. I don't know if it's possible but I was thinking invisible boxes that could be placed over arms/legs etc or separately around the screen if need be.

Anyway, just wanted an opinion to see if there maybe could be any improvements made or better/easier ways to do it.

Thanks! The basic code is below -

N=12
For J=1 to 13
      FRM=24 REM Jump Frame
      Bob 1,X,Y,FRM
      Y=Y-N REM Jump Up
          
      For J2=1 to 2
            N=N-1 REM Reduce and bring down
            Wait VBL
            Next J2
Next J

[S0ulA55a551n]

what if the person is moving back into screen and or fwd at time of jump, surely they could be moving on all three axis at same time.

not sure about collisions, in q platform game u just a rectangle hotbox that is slightly smaller than your character sprite

[Brick Nash]

Originally Posted by S0ulA55a551n

what if the person is moving back into screen and or fwd at time of jump, surely they could be moving on all three axis at same time.

not sure about collisions, in q platform game u just a rectangle hotbox that is slightly smaller than your character sprite

Thanks for the reply.

Yes that's the concern as I'm using Y for both moving back into the screen and the pseudo 3D jump.

I'm thinking I could solve it by storing whatever the real Y axis value is at the time that the player leaves the ground then put that in a custom variable and have that as a reference for enemies so that I could set up a Y comparison test and they'd have to be in a certain range of that number either way to attack but I'm not quite sure how to do that. I can't just put Y=Ground as both the values would still change.

Is there a way to take a snapshot of a value like a co-ordinate and hold it until conditions are met?

Sorry I'm still a bit new to coding. I think I know how to go about something but putting it into code is the tough part!

[jimwon2016]

Something to think about here is once your player triggers the jump routine your game will pause to complete it. Ideally, you need to have a single Wait VBL command in your main loop so all movement and collision detection routines will run each frame.

[Brick Nash]

Originally Posted by jimwon2016

Something to think about here is once your player triggers the jump routine your game will pause to complete it. Ideally, you need to have a single Wait VBL command in your main loop so all movement and collision detection routines will run each frame.

I never even thought of that as it's just my player on the screen right now so thanks. I think I have one in the main loop anyway but I'll certainly include one now!

[jimwon2016]

So to take that thought forward, your movement routines should not try to complete an entire movement in one go. They should complete one step in the movement (such as altering X or Y position of Bob by 1 or 2 pixels) then return to the main loop so you can run other routines.

You must check and update every game object and state over one pass of the main loop then call a Wait VBL to update it all. So only one Wait VBL in your entire code, except for when you have a routine in which to intend to pause execution of other code, such as a cut scene or title screen.

[Brick Nash]

Originally Posted by jimwon2016

So to take that thought forward, your movement routines should not try to complete an entire movement in one go. They should complete one step in the movement (such as altering X or Y position of Bob by 1 or 2 pixels) then return to the main loop so you can run other routines.

You must check and update every game object and state over one pass of the main loop then call a Wait VBL to update it all. So only one Wait VBL in your entire code, except for when you have a routine in which to intend to pause execution of other code, such as a cut scene or title screen.

Ahh ok, maybe I'm off down the wrong path then. When I activate my jump it's going to a jump subroutine and the For loops are being run there which I assume it will probably keep it out the main loop even longer. I am including a wait VBL there as well though but maybe that's not the right way.

[jimwon2016]

I would suggest you go through your code and look for any subroutine with a loop of any kind (Do, While, For etc) with a Wait VBL. All of those will cause a stuttering effect in your game. A great test would be to put something else onscreen that you can move with the second joystick and test that both objects can move at the same time.

[Brick Nash]

Hmm I don't really have any stuttering going on. Some things don't feel like they move quite right though so I'll do as you say as it's likely that is the cause.

Some things like walking are done by checking in the main loop if the joystick is activated in any direction in with the fire button off and then going to a "Controls" subroutine where it then checks which direction is being pushed via a variable and then individual code for action. I had some wait vbl's in all of them but I'll just sift through everything and chop it out!

[jimwon2016]

Thats not what I mean by stuttering. Visualise Streets Of Rage, what would the game look like if all the enemies and screen movement and background animation stopped whenever Player 1 moved? That is what I mean by stuttering and you don't see that in your own program because you don't have those things yet.

Stripping out all the other Wait VBLs is only part of the problem, you need to rewrite the code to strip out any loops from your subroutines too if you still have them.

[Brick Nash]

Ah ok. I guess I have some work to do! Thought I was on to something but all part of learning!

Thanks for the help!

[Mrs Beanbag]

i would write something like

bob 1,X+Y,Y+Z,FRM

or depending on which way your axes point, change one or both of the +'s into -'s.
(the above graphics example looks like the Y axis should point up and left, rather than up and right, then again i vaguely remember this sort of game not paying all that much attention to consistency with the background graphics)

to do jumping in my own code, i tend to maintain an upwards velocity variable, call it DZ, then in your game loop do something like

Z=Z+DZ
DZ=DZ-1
if Z<0
   Z=0
   DZ=0
end if
if Jup(1) AND Z=0 then DZ = 20

you can experiment with the numbers obviously

[Brick Nash]

Originally Posted by Mrs Beanbag

i would write something like

bob 1,X+Y,Y+Z,FRM

or depending on which way your axes point, change one or both of the +'s into -'s.
(the above graphics example looks like the Y axis should point up and left, rather than up and right, then again i vaguely remember this sort of game not paying all that much attention to consistency with the background graphics)

to do jumping in my own code, i tend to maintain an upwards velocity variable, call it DZ, then in your game loop do something like

Z=Z+DZ
DZ=DZ-1
if Z<0
   Z=0
   DZ=0
end if
if Jup(1) AND Z=0 then DZ = 20

you can experiment with the numbers obviously

Excellent I'll give this an experiment today. Forgive my rather simple illustration, the Y arrow was meant to represent the player walking back 'In to' the screen and the Z was for the player jumping. The arrow could have pointed up left as well and directly up for that matter if it were behind the player. I think the way the pavement is slanted is confusing but that's my fault.

Thank you for the examples!

[Samurai_Crow]

Also, don't forget the shadows. It helps line up the position of the characters like in the bonus stage in the arcade version of the Final Fight with the ice blocks.

[Brick Nash]

Originally Posted by Samurai_Crow

Also, don't forget the shadows. It helps line up the position of the characters like in the bonus stage in the arcade version of the Final Fight with the ice blocks.

That's a good point, thanks for that!

Thank you too to Mrs Beanbag for the code example. I've been tweaking and experimenting with it all day and managed to get a nice semi working routine going and had quite good fun doing it too. All within the main loop as well and not taking up too much space.

The jump itself is going up and down is very fast though but I'll work on that!

[idrougge]

Just make DY smaller.

[Brick Nash]

Originally Posted by idrougge

Just make DY smaller.

DY? But there is no DY. There is only DZ and that appears to control the height of the jump not the speed.

[idrougge]

Ah, I meant DZ.

Try to change DZ=DZ-1 to DZ=DZ-0.5. You might need to redeclare DZ as floating point, I think it's DZ# in AMOS.

[Brick Nash]

Originally Posted by idrougge

Ah, I meant DZ.

Try to change DZ=DZ-1 to DZ=DZ-0.5. You might need to redeclare DZ as floating point, I think it's DZ# in AMOS.

That works nicely, thank you.

I actually tried using floating point values before which didn't work but I just realised that I needed to set ALL the DZ variables to DZ#.

It's working nice and smoothly now. Many thanks everyone!

[Mrs Beanbag]

DZ controls the speed AND the height! well literally it is the speed the player is moving upwards, if you jump faster you'll go higher, that's basic physics.

i generally stay away from floating point variables because they are very slow without an FPU. fixed point is easy to do, just divide Z by some power of two when you set the bob's position:

bob 1,X,Y-Z/8,FRM

for instance...