Find the Exit - K2KYJCS This one has jumping. Have you looked through Smile Basic Source for Keys?

Sprite Animation example code. The important part is the data statements. The first number is the number of animation frames. Then for each frame you have a pair of numbers. The duration in frames then the definition id of the image to show. When calling spanim the false or 0 on the end says to loop the animation. The "I" says to do frame animation.

CALLIDX is filled with the id/handle of the sprite you are updating in the function you set up with SPFUNC. In the attached example I have many sprites and they all use the same function. Also note the use of SPVAR and the output version of SPOFS to get information on the sprite it is updating.

Part 2, hope that helps. SPANIM and the data statements you will want to look at closely.

Animated walking sprite part 1

Excellent job. Your drawings are always impressive.

Very impressive, I like it.

Congrats and have fun.

Calling the function. If you have custom bg tiles load those first. You are still in charge of game physics. You decide if sprites can move places and how they move. It isn't much more than a background image.

Char to num function referenced by the previous code.

Map loading code part 2.

Map loading code part 1 see attached.

How about tic tac toe/naughts and crosses. No graphics required you can do it all in text mode. Or maybe hangman.

CALL SPRITE is built into SmileBasic. You can actually use CALL to call most any function passed as a string. Anyway, you set up what function to call or line to jump to with SPFUNC. Then CALL SPRITE will look at every sprite. If it has a SPFUNC value it will set CALLIDX to the sprite's handle and call the function. If you set it up right, the sprites move around on their own.

Glad to hear you got things working Person D©

The regular sprite collision functions should work. Just make sure you turned on collision detection on both the player/target and bullets when you set up the sprites. Although if you are scaling and rotating the sprites things may not work as well as expected. You will have to keep track of sprite id/handles when checking collisions too.

Wow! Very impressive, puts my entry to shame.

Wow! Looks like I lost the contest. Very impressive.

There are a couple things xscreen may be doing. The first is are you setting up the number of sprites and background layers for each screen correctly? If you half them between screens you would get 256 sprites and 2 bg layers each. The second thing is I assume that xscreen acts like an ACLS. So I would make sure you only call it one time at the top of your code before you load in graphics.

old version to compare against.