First off, I want to say that I am sorry for not well contributing to this website. I feel that if I had a better understanding of how to make and SNES game, I could actually write something decent. The purpose of this page is to inform me (and other beginners possibly) how to do game programming basics such as collision detection and map updating. I don't care if you link a page, or if you try and explain something yourself, but I am just going to say that I tried to go on line and look up some simple things on how to make a game using asm, but ultimately, I had no luck. I know that what I am about to write is not limited to the SNES, but it is the only thing I have ever worked with. Now I am going to start a list of things that are essential to a game, but I do not understand to pull off.
1. Collision Detection.
This is something that has never been very well explained that I see. I know that most video games use hit boxes, but I do not know how to set something like that up. It be easy if there were greater than and less than functions, as you could see if any part of an object was in a position greater than the left side, but less than the right side, (same with up and down respectively) but unfortunately, I know that the only kind of comparisons are equal or not equal. (you could do collision detection pixel by pixel by checking each individual pixel of the sprite with BEQ, but it would by VERY slow) By the way, like I said, I have looked over other people code for collision detection, but usually I get something that is nearly impossible to read like this...
2. Level Maps.
I don't get this either, because say if you had 50 characters that would appear throughout the level, you have to check 50 different spots every frame to see if you were in any of them. The way you would check to see if anything was in the right place or not, I would assume that every time the screen moved, you would add to the BG scrolling registers, but you would also use another register to see where you are in the level vertically and horizontally, as these could be a 16 bit value large enough to hold an entire level. Something like this would be much easier on an auto-scrolling shooter, as you could just set a "timer" for everything to happen, as you can't actually change the direction of the screen in game.
1. Collision Detection.
This is something that has never been very well explained that I see. I know that most video games use hit boxes, but I do not know how to set something like that up. It be easy if there were greater than and less than functions, as you could see if any part of an object was in a position greater than the left side, but less than the right side, (same with up and down respectively) but unfortunately, I know that the only kind of comparisons are equal or not equal. (you could do collision detection pixel by pixel by checking each individual pixel of the sprite with BEQ, but it would by VERY slow) By the way, like I said, I have looked over other people code for collision detection, but usually I get something that is nearly impossible to read like this...
Attachment:
2. Level Maps.
I don't get this either, because say if you had 50 characters that would appear throughout the level, you have to check 50 different spots every frame to see if you were in any of them. The way you would check to see if anything was in the right place or not, I would assume that every time the screen moved, you would add to the BG scrolling registers, but you would also use another register to see where you are in the level vertically and horizontally, as these could be a 16 bit value large enough to hold an entire level. Something like this would be much easier on an auto-scrolling shooter, as you could just set a "timer" for everything to happen, as you can't actually change the direction of the screen in game.