Could someone give me a code example?

[Brick Nash]

Hey folks,

Could someone be so kind as to give me a simple example using Amos Basic or Amal (or both preferably) of how to go from a resting still image on a bob to when the joystick is pushed right so that they go into another image but with an animation (and move obviously)

I'm currently moving the bob with a pre called resting image from within a loop just using -

If Jright(1)=true
X=X+2
Wait VBL

The movement is fine but I just can't get the image to switch or animate and the manual doesn't really give examples for image switching in this way. I've tried using a subroutine & procedure and calling that in the joystick command (within the loop) within the 'If' statement but that only continuously re-calls the subroutine and only shows the first frame (and moves the bob Very slowly). I can't use an Amal command within the loop because it doesn't work so I'm a little stumped.

I have an .abk saved for my bobs resting image and another 6 frame animation for a walking movement.

Thanks, I'm still very sketchy on how the Sprite bank works in terms of how to call images for changes as well as still getting to grips with Amal. I like looking at examples so any help would be great!

Many thanks once again!

[jimwon2016]

If you don't want to use AMAL for animation (and I don't blame you, I don't like it much either) then there's not exactly a simple answer to your question, as it isn't a simple task.

If you do a search for Oubliette on Aminet you'll find my source code which has a 2 frame animation method but it's not really a simple example or probably even the best way to do it, but should give you a start.

[volvo_0ne]

Is the intended animation the same for each movement & direction of the Joystick, or is it (Say) a different set of frames for each direction?

[Brick Nash]

Originally Posted by jimwon2016

If you don't want to use AMAL for animation (and I don't blame you, I don't like it much either) then there's not exactly a simple answer to your question, as it isn't a simple task.

If you do a search for Oubliette on Aminet you'll find my source code which has a 2 frame animation method but it's not really a simple example or probably even the best way to do it, but should give you a start.

Thanks I'll have a look. And I'm quite happy to use Amal, I'm just having trouble figuring out how it's used for things like this. Most games change to an animation when you push the joystick in a direction so I assumed it would be one of the more straightforward things.

Originally Posted by volvo_0ne

Is the intended animation the same for each movement & direction of the Joystick, or is it (Say) a different set of frames for each direction?

It's the same animation for up down left and right but just flipped for left (and left up/down etc). I've got the movement and flipping working beautifully but I just can't seem to get the 'walking' animation to play when I move the joystick.

[volvo_0ne]

Originally Posted by Brick Nash

Thanks I'll have a look!



It's the same animation for up down left and right but just flipped for left (and left up/down etc). I've got the movement and flipping working beautifully but I just can't seem to get the 'walking' animation to play when I move the joystick.

How about ....

EG
If Joyleft(1)
inc Imageframe
bob blah,blah,blah ,Hrev(Imageframe)
Rem:appropriate frame count & reset here
Endif


etc etc.

The main problem with this idea is that you also have to keep track of which way it was flipped last because ALL flipped frames stay flipped until you change them.

So (say) you have 2 frames for left, then you move left twice, in the 2nd move, the bobs will be flipped back to their normal position, this is why I dont like the Rev commands much.

[Brick Nash]

Thanks for all the help folks. I've sort of got it up and running and my bob changes into his animation nicely now on the joystick command.

It's presented another issue in that I'm using subroutines for a resting state and one for a walking state and I'm using the loops within them in order to check for conditions to go to other subroutines but I keep getting the 'out of stack space error'.

It's not mentioned in the subroutine section in the Game maker's manual anywhere so I assume I'm doing something wrong (again!)

It says that a subroutine can only call itself 50 times but I'm assuming there is a way to maybe reset that number or clear the stack?

[jimwon2016]

This doesn't sound good.

Ideally you want your main loop to run a set of subroutines then call a Wait VBL as quickly as it can.

It might be a good idea to post your subroutine for more specific advice on how to proceed.

[idrougge]

Looks like some fundamental problem in your logic if you have a subroutine calling itself so many times in a game. Usually, subroutines are called once every vbl to update something, not calling themselves.

[Samurai_Crow]

It's called infinite recursion. It's a bad bug but the way around it is simple: make one variable hold the state number of where to execute the next subroutine. Then make a jump table at the beginning of your AMAL script using If ... Jump command sequences.

[Brick Nash]

Thanks again for the replies folks. Ok, I think I get the jist of what's happening but I'm not quite sure I understand in Amos terms but I'll post what I have in my two subroutines and maybe someone can tell me where I'm going wrong with this stack space issue.

Bear with me, I'll have to type this out by hand as my winuaeclip doesn't seem to work.

' ** STANCE SUBROUTINE **

STANCE:

If Jleft(1)=false and Jright(1)=false and Jup(1)=false and Jdown(1)=false
Load "dh2:abk/player/player stance.abk
bob 1,X,Y,1
End If

do

If Jright(1)=true
Gosub WALKRIGHT
X=X+2
End If

Loop
Return

'** WALK SUBROUTINE **

WALKRIGHT:

Load "dh2:abk/player/player walk.abk
Channel 1 to Bob 1
Bob 1,X,Y,1
AMAL 1,"Anim 0,(1,8)(2,8)(3,8)(4,8)(5,8)(6,8)"
Amal on
Wait vbl

Do
if Jright(1)=false
Amal off
Gosub STance
End If
Loop

Return

I'm also calling the stance subroutine beforehand just after all my variables as a sort of 'initialiser' if you get my drift so that the player appears on screen in his stance and ready to go.

As I say, this does what I want it to do (sort of, the player doesn't actually move) but it's certainly a problem that will be a valuable lesson.

Once again many thanks!

[jimwon2016]

Programs should consist of a single Do Loop statement block called the Main loop. Subroutines should be positioned after the main loop and execute a list of instructions as quickly as possible then return to main loop. They should not contain Do Loop statements.

At the moment your program will do nothing else except handle the player. You will be unable to execute other instructions to handle playfield or collisions or enemys because your program will be stuck executing the infinte Do Loop statements. In addition, your joystick handling logic is not extensible and you will run into problems when trying to add other directions.

When it comes to images, you want every object for your game in the same bank. Loading up differant banks is perhaps something you might do between levels not in the middle of a joystick handling routine. You can easily add new images to your first bank using the object editor in AMOS.

I'm aware that I'm pointing out problems without solutions but my advice to you is forget about animation and flashy stuff for now. Write a simple game with a single screen tile based background and static images so that you can get to grips with program control and flow. Here's how that program code should roughly kind of look:

Declare and globalise variables

Do
Run subroutines or procedures
Loop

Subroutines or procedures

[Brick Nash]

Originally Posted by jimwon2016

When it comes to images, you want every object for your game in the same bank. Loading up differant banks is perhaps something you might do between levels not in the middle of a joystick handling routine. You can easily add new images to your first bank using the object editor in AMOS.

I'm aware that I'm pointing out problems without solutions but my advice to you is forget about animation and flashy stuff for now. Write a simple game with a single screen tile based background and static images so that you can get to grips with program control and flow. Here's how that program code should roughly kind of look:

Declare and globalise variables

Do
Run subroutines or procedures
Loop

Subroutines or procedures

Ok thanks, I'll switch to that structure, I was just trying stuff out and that appeared to work.

I've always been a bit confused at image switching and how the sprite bank works though. Do you mean I should have all my player graphics saved in a single .abk file? And should I set my screens up before or in the main loop?

[Samurai_Crow]

All the setup code should be before the main loop.

[idrougge]

Load banks
Screen setup
Setup bobs
Do
If JRight Then Gosub Walkright Else Gosub Stance
Update bobs
Wait Vbl
Loop
End
Stance
Walkright

[jimwon2016]

I mean you shoud have ALL your graphics saved in a single .abk. Not just your player graphics.

If, for example, you had the type of game where there is a theme change in between levels, say, a pirate level, then a snow level, then a forest level, it's possible you would have multiple .abks that need loading in between. For more simple games, you should have have a single .abk with everything included.

[Brick Nash]

Amazing info as always folks. Thanks for taking the time to help me!

Did a bit of shifting about and it seems to be doing pretty much the same thing within the new structure now sans the Stack Space issue.

Originally Posted by jimwon2016

I mean you shoud have ALL your graphics saved in a single .abk. Not just your player graphics.

If, for example, you had the type of game where there is a theme change in between levels, say, a pirate level, then a snow level, then a forest level, it's possible you would have multiple .abks that need loading in between. For more simple games, you should have have a single .abk with everything included.

That's a lot of images to keep track of isn't it if they're just assigned a number? Or am I missing something again? If so I guess I'll need to write down what image or series of images relates to which number in the bank.

[jimwon2016]

Yep. It is. And you should absolutely write down the number for each image.

[Brick Nash]

Originally Posted by jimwon2016

Yep. It is. And you should absolutely write down the number for each image.

If that's the way it's done then that's totally cool and I'm down with it. It's little unspoken techniques like that which tend to go over my head so thanks!

[jimwon2016]

Writing computer programs is a lot of work and requires a lot of thought and planning. I plan out graphic banks before I even start drawing anything, then draw everything I need even if it's just a rough sketch and grab it into a bank.

I also write all code as pseudocode in pen and ink before writing a subroutine.

[Brick Nash]

Originally Posted by jimwon2016

Writing computer programs is a lot of work and requires a lot of thought and planning. I plan out graphic banks before I even start drawing anything, then draw everything I need even if it's just a rough sketch and grab it into a bank.

I also write all code as pseudocode in pen and ink before writing a subroutine.

That's all fine I don't mind it being hard work, I just wasn't sure of the options I had.