My guess without being able to see the code would be a variable issue (writing beyond the one you want). Check the hex viewer to see, and then double check your Y or X variables. Is one of them being increased? Is there an extra ___, Y when there shouldn't be? That type of thing. I've done both of those a lot, especially when adapting MRN's code. Come to think of it, check your +1 pointers too. Sometimes he (or someone, MetalSlime?) will use +1, and other times an INY to achieve the same thing, but it you accidentally use them both you get a lot of fun errors.

Thank you for the insights guys. I will check that stuff for sure. Just didn't really know where to start. I thought that i may have mixed up player variable with a playershot variable and that was causing it, but no such luck. I will check the hex viewer for sure.

It's been a bagillion years since I looked at this, but, if I had to guess, I'd say something like your variables aren't INCing properly, like Solegoose said. Basically, with meta spites you have to go up by 4, one for each sprite, and for weapons, you go up by 1. IF you forget to do both X and Y, you'll get some creative errors. Sometimes it's easier to write a routine for the meta sprites and one for the basic sprites. At least until you get it working and see how they are similar/different. Memory is cheap, as the man says.

Or, just say the hell with it and burn 3 extra sprites for the weapons. That way everything has a 16x16 sprite reserved for it and you just don't use the extras or leave them blank.

I'd imagine you're even more confused now. Haha.

What year is this?!?!?

 

Actually the adding blank sprites crossed my mind lol! I actually figured it out. It was due to the fact that this is a platformer, so my main character (only character I have right now) goes through the horizontal and vertical hit detection separately. After my character updates the shot updates run. When I came back to the player and calculate its horizontal collision the vertical sprite values from the shot were being used in the players hit detection. So after I finish the shot detection and transfer the values back to the sprite, I clear out the sprite_vertical and sprite horizontal, setting them to zero before the next frame hits and the players collision detection is calculated again.

Im not sure if I explained that well enough but at least it is working now.
...And now to break it again, most likely lol.

Thanks guys!

Ah, so you're using the same temporary variables to figure both the characters and the projectiles, makes sense to me.

I just got to thinking about the original question a minute ago, for whatever reason, and if you ever do suspect that you're over running your variables in some way a quick way to check is to just throw in a bunch of variables where you think that it might be occurring. Kind of a cheating way to do things (real programmers frown I'm sure   ), but it is quick! I usually throw thirty bytes of Nothing and that lets me pinpoint what might be causing the issue pretty quick. That'll also let you clearly see which of the Nothing bytes are affected if you open the hex editor. If it is over running the fourth then it is easier to see since nothing else will be modifying it.

Yes, I probably should make seperate variables but I thought, "well they will never be used at the same time so nothing bad can happen, right?" I should have known that any statement ending in ",right?" is going to end badly lol.

I have been using extra variables here and there. Never in that way, so I will use that trick for sure. I usually just put in a byte here and there to make sure that the code I think is getting hit, is getting hit. Its weird that Im used to .Net so debugging is something I have never really had an issue with. This stuff is super tricky to debug, but Im getting better at it. At the very least, I know I am enjoying myself when it takes me almost a week to find 1 issue.

Now imagine debugging for two years and never knowing how to read the hex editor  . A different story for a different day...

Re-using variables isn't bad by any means, you just have to be careful. I made separate variables for everything in Spook-o'-tron and ran out of RAM pretty quick since I was afraid to re-use anything just in case it broke things unexpectedly, but with the next project I set it up from the beginning to use a temp system. The same 25 or so variables get used for all calculations and the final result usually ends up only being a byte or two. I like it a lot better so far, but it does mean that I have to be 100% certain that the routine is not going to get interrupted, and that the routines as a whole are in the right order.

I am using fceux. I am getting the hex editor down, but the rest of the debug stuff, I have no clue. I dont even know if it is useful. But as long as I have enough to get by and start creating I am usually ok.

Wow, I finally figured out my issues and issues from those issues. I did manage to learn the fceux debugger a bit. I didn't realize it was literally my code without the named variables, just the address of the named variables. I wish we could add a data table to the debugger to put in the variable names for the addresses. Anyway, not why I am here.

If anyone has any knowledge of the meta sprite routines you may be able to help. It seems as though this tutorial is set up for 2x2 meta sprites. I have background collision working with those, very well actually. But my enemy that I am testing with is 2x3 (2 wide, 3 tall) and its vertical collision with the background works... but the enemy hops up and down while he does this. When I set up the transfer for bg collision I have tried many things but none of them seem to fix. So I guess my question is, do I need to heavily modify this routine for use with meta sprites larger than 2x2?

When you say jumps "up and down", I'm assuming its moving into the bg object and then back out? I'm not familiar with this routine at all but from what you are describing, it almost sounds like you are moving into the object and then the next frame undoing that move back before the collision. How many pixels are you moving per frame? If you are moving 2 or 3 pixel per frame, you could be overshooting your collision point and causing odd issues. These 2 seems to be fairly common issues when learning bg collision or writing a new bg routine.

Thank you, I believe the vertical speed is the same as the player character, which is a 2x2 sprite and doesn't have the up down from the collision as we are seeing.  The funny thing is if I set the vertical transfer of the 2x2 sprite to the 2x3 sprite the 2x3 doesn't have the up down motion but, of course, the enemy is 8 pixels into the floor.  Im going to make sure on the vertical speed though.  Thanks for the idea

EDIT: 2x2 not 4x4