Thank you. If you think that game is an adictive time waister, try Zombie Horde.

@ramstrong when I try p1m it says "undefined label". Is there another way?

Please don't thank me. I'd rather you read the Tutorial Thread before you ask an already answered question to the group.

Yes, but you don't need to. I'm not even going to bother answering that question. I need to start working on my blog since it's almost February. I don't believe that you have less time than me. I don't even get 1 hour per day.

I think that if you can't even frame the question properly, that's a sign that you bit off more than you can chew. How about working on a simpler, easier project to start? Pong is a good start. Rock-paper-scissors is another. CYOA is fine, too.

@ramstrong ..... thank you anyway for your other advice. I guess I will have to find the answer myself. Thank you again. You have made it easier to do this.

hey morphtroid. please make more games they are just awesom and i also could use some help with sprite,read,and data commands. you are just a boss at those commands so please

You want one of these right?

I just need some feedback. Plus mainly it is a Petit computer journal.

I'm slowly working on that Thank you.

About Sprite, Read and Data, I have written something about them in the tutorials thread. It's somewhere in my long post.

ok didnt know

I need some help with my program. I'm trying to have a blast sprite collide with a skeleton sprite and destroy it. When I use SPHITSP(1,2) (skeleton and blast sprite, respectively) I get an Illegal Function Call. I am sure this is due to the blast sprite not being created when the code is reached, as the player needs to press the a button to create it. So, I tried putting it inside the blast sprite's gosub, but it seems to ignore it entirely. Here's a basic version of what I'm trying to do:
When the player presses A:
@BLASTUP
SPSET 2,236,8,0,0,0
SPANGLE 2,270,0,1
SPANIM 2,4,5,1
SPOFS 2,X,Y,0
BEEP 1
IF SPHITSP(1,2)==TRUE THEN GOSUB @SDED: 'Skeleton death animation
WAIT 20
SPCLR 2
RETURN

Why don't you try to have the explosion sprite created from the very begining of the program and hide it from the player's view (outside the screen).
Then you can move it back and forth from it's hiding place when it's needed instead of resetting it every time.

I actually have thought of that Morphtroid, and I remember it not working, but I'll try and implement it again and if it works then I'll post the code I made for that.
Also, good work on Petit Farm. Looking at your code for it has helped me through some other errors I had.

Alright, I've figured it out! Unfortunately, it only causes more problems.
Anyway, what I've come to see is that I don't even need to have the blast hidden, or even created from the start. When I put the command SPHITSP(1,2) in the blast gosub, I wasn't seeing any reactions. This is because I have the blast sprite rotated 270 degrees so it animates upwards, and thus the collision detection coordinates for that sprite are at the bottom left of it. I had already set up the player's collision with the skeleton (which blew up the player and set it back to the starting coordinates), so I couldn't have gotten close enough to have known that the blast's collision was where it was. I turned off the player collision and tried again, and the skeleton blew up. So I guess I need to set a collision box around the blast sprite, instead of only having the lower left pixel affect anything.

However, now that the skeleton blows up (and then clears it's existence) I get another error stating that the skeleton doesn't exist (such as when the program goes back to the loop and then tries to animate it.) My temporary solution to this is to move the skeleton offscreen after its death animation instead of clearing it. I'm sure that if I move some gosubs around, it will work as normal.

Thank you about your previous comment

I was gonna to comment about the collision area before too, but I figured you would be using a normal 16*16 unrotated sprite Well, I'm glad you sorted that part out! About that other bit...
Never understimate the power of hiding things from the player instead of destroying them.
If you're gonna use it again, then why bother clearing it at all?

The sprite I'm using is a standard sprite (Numbers 236 -239 for animation.) I had to rotate the sprite because that particular sprite faces and animates to the right, and depending on which way the player faces is which way the sprite faces.

The only problem I could see with hiding sprites is slowdown, but maybe that's only when there are a ton of sprites being displayed on screen.

@swordx If you are still checking this thread when do think you will be finished with dungeon adventure,i really can not wait for it.

@Hairmanban19 Check the QR code thread for your answer. Thanks for the support, I really appreciate it!

Well, I fixed another one of my program's problems! A word of advice for everyone: beware of rotating your sprites!
When I first tried to set the collision detection box on my blast sprite, it wasn't working. I tried doing this:
@BLASTUP
SPSET 2,236,8,0,0,0
SPANGLE 2,270,0,1
SPANIM 2,4,5,1
SPOFS 2,X,Y,0
SPCOL 2,0,0,16,16,0
IF SPHITSP(1,2) THEN SPCLR 2:GOSUB @SDED
(leaving some code out)

This didn't work because the sprite was rotated, and so the coordinates I set in SPCOL would be correct, except it ended up setting a box made of 16x16 pixels BELOW where the sprite is, starting from the bottom left corner of the sprite. So I set the starting coordinates to this:
SPCOL 2,-16,-16,16,16,0
And it works fine now.

The reason is because the sprite's point of origin (also point of rotation) is at the default (0,0) of the sprite, or top-left corner. When you rotates by 270 degrees clockwise, it rotated on that point, so you're left with the sprite on it's side, but 16 pixels above the original position (sprites set without using optional width/height at defaulted to 16x16). This also means that the collision box you set will also be 16 pixels below the sprite. There is a fix to this.

SPHOME control_number (0~99), x, y

This will change the point of origin, and will also change the sprite's point of rotation to match. In your example, try using...

SPHOME 2,8,8

...which should now center on your sprite, and any rotations you make will not left it drift off by the corner anymore. Just to note, it will also offset your sprite by the negative of the values you set, so if you had your 16x16 sprite set with (8,8) with SPHOME, it will shift your sprite to the left by 8 and up by 8. Since it shifts the entire sprite, you'll also have to compensate with SPCOL by that much, negatively.

Now, that is how you ask a question! Very clear question. I see that Morphtroid and Discostew has answered your questions. Also take a look at my Asteroid program to see sprites in action. In my experience, 99 sprites doesn't slow you down at all. It can take a while for you to process them all, though, but absolutely no problem displaying them. Also, although hiding the sprites is the recommended method, you actually can create sprites on the fly. You just have to keep track of it manually.

'Create sprite
SPSET 2,236,8,0,0,0
SP[2]=1

'Check sprite
IF SP[2]==1 THEN IF SPHITSP(1,2)==TRUE THEN GOSUB @SDED: 'Skeleton death animation

'Destroy sprite
SP[2]=0
SPCLR 2

@credible what kind of game are you making? So far this is mysteriously sounding like something from my battlewood game... Oh yeah and welcome to nintendo life and this forum. Unless of course you had a previous account . It is very nice to meet yet another person who appreciates programming and Petit computer. Good to see you.