nesdev.com

Okay, sorry, when you posted, I was still posting, I need to ask you something when I get back from doing something. So just hang on a few minutes.

Okay, I understand the basic concept, but I'm a bit confused about the formula to figure out what tile your sprite is over. So could someone explain that to me again? I remember I think tepples saying:

tilex = (xpos+Xscroll)/8
tiley = (xpos+Yscroll)/8

Huh? why would that be the formula? Can I have a more newbie friendly explanation? I'm not implying that I'm a newbie, I'm just asking for a simpler explanation.

Seriously, draw a picture. Those always help me. Let the formula appear in the picture, rather than trying to find it (since you'd be trying to find something you don't yet understand). The point is to make conditions as favorable as possible for the understanding to come to you naturally. Often it doesn't come to me until I draw a picture and explore it.

You have a table arranged like this (I put random characters in it) :
A X U W O L T
S Z W K Y M Q
S U E U W P E
Q S G E I S L

Now you want to got the P that is in the third row and the sixth column.
You have two indexes, one is 2 (the count starts from zero, so the third row is number 2), and 5 (also start from zero).
The problem is that all the table is stored lineary in your ROM, so there it would be :
A X U W O L T S Z W K Y M Q S U E U W P E Q S G E I S L

The formula to know witch letter is the one you're looking for is :
There is 7 rows so, multiply the row index by 7. Scince the last letter of row 0 is at column 6, the first letter of the second row will be just after it, so effectively it's number 7.
Then, just add the column index to get the final index number.
In that case, 2*7=14; 14+5=19
Looking in the list above, the 20th letter is effectively P. It's number 19, but it's the 20th because the index starts from zero.

_________________
Life is complex: it has both real and imaginary components.

blargg is right. Draw it down on paper. It alway helps me too. Draw the grid of tiles, draw your player over it in different positions and try to find your formula from that. We can't give you the exact formulas, we don't know your game. We don't know the size of your map, the size of your sprites, any of that. We can only help you with the concepts, give you examples and all, but it is up to you to convert to your specific needs.

Oh, that is stupid that when bit 7 is set, the N flag is set. that's confusing, so you have to bmi for when bit 7 is set, and not bpl. I hate how everything in 6502 is like backwards. Okay, I don't mind it that much. But I'm just wondering if it's possible to load the data from a .nam file, because it still holds bytes, it's just a binary file. I think it's funny that you could actually just make a blank file, open it up in hexacute, and change the bytes, and make it into a .nam file, and it would actually show stuff. So could you do me a favor? I'm sorry, there's something I'm still not getting. I know you have to divide x and y coords by 8, but I was still confused about how to make the sprites coords and the map have anything to do with eachother. I could just say this:

collision:
do the whole lsr a thing again with cy
if tile above or below has bit 7 set ; this is the confusing thing
if not go to thing
otherwise collide

do the whole lsr a thing again with cx ; or would it be asl?
same collide routine

thing:
rts

Yeah, I'm just confused about how to say "if the tile above or below". Not even if bit seven is set, I don't know how to compare such a thing as tiles and sprite cords. There, that's it. I don't know how to compare tiles and sprite coords. Sorry, any other examples?

OK, Celius. We told you could find the formulas yourself if you drew the stuff down. But you don't seem to want that. So I'll draw it for you, only because I like to talk about this subject.

But don't just forget everything I told you before! You'll have to use this together with what I told you in past posts.

EDIT: Before we begin, I'd like you to remember how we do things: always move the player, even if there is a wall. You check for the collision AFTER you moved the player. And if there was any collision, we CORRECT the player position, so that it looks like the wall stoped him (wich is what the person playing the game sees).

Here is the notation i'll be using:


And this is what we might have at the top left corner of our game screen, at a given time:

The player is just standing there. The red point represents the player's coordinates. Now, let's do some math. From this drawing, the players coordinates are something close to (19, 11). Your background tile size is 8x8, so we divide these coordinates by 8. The result will be (2, 1) - we totally disregard fractions. Those are the exact coordinates of the block where that point is! That is enough to check for collisions. Now that you have the block coordinates, you do the math I showed you before (past posts) and when you check your map, you'll see the tile is clear.

There is only one problem. Lets try to move the player to the left:

The new coordinates are something close to (11, 11). When we divide by 8, we get the map coords (1, 1), where there is no solid block. Wich would mean the player movement was successful, but this is wrong. The player just went through a wall!!!

What do we do? Add more collision points:

Now, after moving the player, just check all 3 points as I described earlier. If all 3 points are clear, there was no collision, but if any of them are solid, there is no need to keep checking, you know there was a collision.

Since this was a collision to the left, we push the player back to the right, placing it as close to the solid tile as we can. Just set the sprite's X position to the X position of the tile you hit * 8 + 8.

In this case, the tile hit was at (1, 2). Take the X coord (1), multiply by 8 and add 8. You'll get 16, wich is the correct place for the player to be.

Seems pretty simple now, doesn't it? Just do it for all directions. Check the appropriate points for each direction you move.

Keep in mind that in this example, I used 3 points per face. This is due to the size of the player and the size of the blocks. But the general rule is: The points can't be more spaced than the block size, or you might miss a block. Like this:


Another VERY important rule is to never move the player more than the size of a block. If the blocks are 8x8, the most the player can walk in one frame is 8 pixels. If you do more, you may also miss a block.

And here are other player sizes (and their collision points) we could have in a game with 8x8 blocks:

The second example shows that you may even occupy only part of the tiles you're using, just by rearranging the collision points.

This method is very good, I've been using it for a while now. I hope you understood it better now. If not, please read carefully until you do. This is all you need for collision against the background. Collision between objects is a whole other story. You'll need to use the concept of bounding boxes, and see if the boxes around different objects overlap. If they do, there was a collision. In a game, you'll tipically loop through your objects, checking if they collided with the player, since collision between enemies or items isn't much used, only to the player.

There is one more thing I have to tell you.

The method I described above, is good for games where the player has a lot of freedom: a platformer, an adventure, etc. But you said before you were doing a pac-man styled game. Maybe, in this case, you may want to choose a simpler method of collision.

Just move the player a full block at a time. This way the collision will never happen at the middle of a block, and you just need to check (still in the suposition of moving to the left) the two exact spaces to the left of the player, before he moves.

"8 pixels at a time? You're crazy, that will look terrible!" you might say. But, what if logically you move it 8 pixels at a time, but do a little animation, instead of just skiping a full tile? Something like this: The player pressed up. You check the 2 tiles that are above the player: one is at (PlayX div 8, PlayY div 8 - 1) and the other is at (PlayX div 8 + 1, PlayY div 8 - 1), as you like formulas so much. But there may be better ways of doing this, such as keeping the player coordinates in the same scale as the background ones, and scaling up (times 8) only for displaying. If the tiles above are clear, start a little counter with the value 8. So, in the next 8 frames, you subtract 1 from the player's Y position every frame. This will give the impression of smooth movement.

Most RPG's do it like this, I think. You should do what feels most confortable and seems right for the game. The first method I described is much more verstile as it can be used for almost any game. The second method is very limited (you can't walk diagonally and can't have any acceleration, for example), and only a few types of games look OK with it, but it is much simpler to implement and will run a little faster. Not that the other method is specially slow. It is only so if you use it with many objects, but you most likely only want it for the player, and for other (simpler) objects you can use the second method.

But I still don't get how to compare tile numbers with sprite coords. I really don't mean to frustrate you, because it's just as frustrating to me. So you have to divide sprx and y by 8, so you can get it in line with tiles. but I don't know how you tell the code what tile you're over. I know how to figure out which tile the character's over, but I don't know how to tell the code what tile the character's over. Do you know what I mean? I really would appriciate if I could say this:
anotherlable:
lda xpos
lsr a
lsr a
lsr a
sta stuff

somelable:
load (stuff+1)
if stuff+1 is over a tile that has bit 7 set
then collide

I just don't know how to say that second part of somelable. Do you know how? or could you explain it to me? I'm sorry, I just don't really understand this concept, and right now, I don't feel like bieng too shy about retarded questions. Sorry. Thanks.

But I explained it already, with code and all! Here it is: http://nesdev.com/bbs/viewtopic.php?p=4429#4429

The second piece of code has everything you need to check a point in the map. (PlayX, PlayY) is the point you want to check. You just have to repeat that piece of code for every point you want to check (the 3 points I showed you with pictures).

You must understand how a map works. A map is not a magic .NAM file that you .incbin in your code! There is no magic. Nothing can distinguish a map from a music or a porn movie, for example, except you. The program YOU code. A map is just a series of bytes, as any other piece of data or code that has ever existed. What tells them all apart is how the code you write handles that data.

Memory is linear. Address $0006 comes after $0005 and it goes like that until the end. But the map is 2-dimensional. How can you represent a 2-D map in a 1-D space? You just place row after row linearly.

Let's think decimal for a while, OK? Your map starts at address 0 (don't ever do that on the NES, I'm just abstracting here). So, address 0 contains the first tile, first column and the first row (coordinates 0, 0). The next address (1) contains the tile in the second column, first row (coordinates 1, 0) and so on, until the end of the first row.

Now, the next tile is in the second row, the one below. But memory does not know the concept of "below". In memory this is all just one BIG row. If you're following, the last tile in the first row is at address 31. What is the next address? 32! So, the first tile of the second row is at address 32.

That's why we have to multiply our Y index to the map by 32. Each row is composed of 32 bytes, so in order to get something from the 3rd row, we must first skip the first 2, wich take 64 bytes. The 3rd row is index 2 (remember, the 1st one is 0), so we multiply 2 by 32 and we get 64. That's exactly how many bytes we must skip to read something from the 3rd row. Now, we use the X coord as an index, that tells how far in this row is the byte we want.

That's what the code I posted before does. At first, I didn't wan't to give it all to you. But in the end I did. With the stuff other people and I posted in this thread, you can make a very decent collision detection system, it is all here, and I literally mean ALL. Take a good read at the complete thread, from the beginning. The ideas, concepts and even the code is all here. You just have to adapt them to your specific situation.

I fail to see what exactly you don't understand... and you seem to be just ignoring what we say. I write a huge-ass message, explaining it bit by bit, and you come with the same question from 10 messages ago. You are not paying attention, and that's really frustrating, 'cause I really would like you to understand. No one else is replying to this thread anymore, except the 2 of us. Maybe it is because you don't pay attention to what people say.

And if you don't know how a 2-D array is laid out in memory, maybe you shouldn't be programming a game yet. Sometimes it seems as you lack the knowledge of many basic principles needed in game programming. And starting at such a low level as 6502 assembly might not be good.

Note that I'm not saying you don't know asembly, but things that are accomplished easily in high level languages are quite difficult to implement in assembly. and if you don't know them in a higher level, it will be really hard to understand it in low level. I don't mean the language, but the data structures and other logic wich make much more sense in higher levels.

For God's sake, the collision you're having so much trouble with can be done in ONE line of code in higher level languages:

This single line of Pascal code will check if a collision to the left happened at point (pointX, pointY) and put the player back to the right if it did.

And I think it is much simpler to understand the concept like this than in assembly. Maybe you should experiment more, read more. There is a qbasic site, I think, with great links to game programming tutorial, not related with the NES at all, but cover many of the concepts needed in game programming. Maybe you should google for it, I think it is "Pete's QB site" or something.

Sorry if I seem angry or something, I'm just a bit frustrated. I would still like to help you out, but only after you're past this. There is nothing more for me to say about collision, really. When you understand collision, and I believe you can, with all the material in this thread, we can gladly discuss the next problem.

I'm really really sorry, I didn't mean to be a pain. I read through this forum, and I understood a little more, and I really didn't mean to ignore everyone, there was just some things I didn't understand, and I guess I wasn't asking about them clearly enough. Well anyway, I used your example, and guess what! it works! Except I just have two problems. Are you willing to help me just a little more? Please? I would deeply appreciate it. I just have two problems. One is, that the collision areas act as collision columns, so I collide in the columns that the tiles are in. and also, I can't think of a way to make it so it's like when you're on the right side of the object, you can still move right, up and down, but not left. I have my code set up like this:



If you haven't noticed lfcol, rtcol, upcol, and dncol are variables for left collision, right collision, upper collision, and lower collision. I'm not really sure how to fix this. I really hope you'd consider helping me just a little more, because I finally understand the main part. And once again, even if you don't help me, I'm sorry that it took so long for me to understand. I would deeply appreciate it if you just helped me a little more, and then I'd be done with this, and then we could move on. I'll actually read it many times and try to understand. Please help me a little more. Thanks if you do.

I don't mind helping at all if you actually pay attention and figure at least some things out.

There is one thing I'd like to say about one piece of code, though:


There is absolutelly no need to store the byte in "stuff". After you did "lda (map_add), y" the N flag was already altered by the loaded value, so there is no need to store it and load it again. Change to this and it will run just fine:

This is obviously faster. Not that speed is much of a problem for now, but avoiding unnecessary operations can only be a good thing, especially when you work on bigger projects where speed is really important.


I didn't understand this. Maybe you could take a screenshot or something, or explain better what's happening. What are you calling "collision areas"? A solid block? the collision points in the sprite? I didn't understand.


You just have to repeat the code you used for left collision with the other points: 3 in the top, 3 in the right and 3 in the bottom.

I suppose that the player coordinates refer to the top left as in my past examples. So, when you move to the left, there are 3 points to check for collision:
1. playX, playY (the one at the top left of the sprite)
2. playX, playY + 8 (the one in the middle, still in the left)
3. playX, playY + 15 (the bottom one, in the left)

These were the coordinates of the 3 points you have to check for collisions to the left. If you think a bit, the tree points to check for collisions ABOVE the player are:
1. playX, playY (same as the one we use for the left)
2. playX + 8, playY (the one in the middle, still in the top)
3. playX + 15, playY (the one to the right, stil in the top)

For the RIGHT:
1. playX + 15, playY (the one at the top right corner)
2. playX + 15, playY + 8 (the one below it)
3. playX + 15, playY + 15 (the one at the bottom)

For BELOW:
1. playX, playY + 15 (the one at the bottom left corner)
2. playX + 8, playY + 15 (the one next to it)
3. playX + 15, playY + 15 (the one at the bottom right corner)

These are all the points you have to check for each direction the player moves. No need to chack them all at once! Only check for right collisions if the player moved right. There is no way you'll collide in the left when moving right, so there is no need to check it. You'll at most check 2 collisions, if the player can move diagonally, wich means it can move in both axis at once.

I don't think you need lfcol, rtcol, upcol and dncol at all. The only thing you have to do after a collision is move the player back. You don't need to create a flag for that, just move the player back right when you detect the collision.

I suggest you do it like this:

That's it. Just do it to the other 3 directions (up, right down). I'll show you ONE more collision, but you have to find out how to do the rest of them!

These functions are just clones of each other, with minor changes. you have to set the 3 correct points (the ones I listed before), and correct the position of the player accordingly. The 2 routines I posted should be more than enough for you to figure out the rest.

Now, I can't say this code will work for sure, as I have not tested it, and I just typed it all down. There may be errors. So don't just go and copy it and paste into your game. Read it carefully and try to understand what I'm doing here.

EDIT: Just to make it clear: The code I posted here should be run AFTER you moved the player. I'm assuming you already read the joypads AND already incremented the player coordinates accordingly. In fact, it wold be even better, in my opinion, if you include the "coord increment" step INSIDE the function that checks for collision (the ones I just posted). Just do it in the very beginning of each function. I see no reason to do it OUTSIDE the functions if you're going to jump to them right after updating the coords.

I believe you are explaining this with a 16x16 sprite in mind, which is okay, because I am going to use a 16x16 sprite in a game that I am going to make in the future, but right now, I'm starting out simple with a crappy looking 8x8 sprite. That is what you were explaining right? okay. And by the way, I don't really copy/paste too much, I look at the code and type it in, making modifications that will fit my code as I go. And I just realized my map was loaded incorrectly. I don't know why, I load it like a normal map. Like, you know how you load a text message, like for instance, .db "hello world" would be loaded like this:

ldx #0
ldy #11

loadtext:
lda text, x
sta $2007
inx
dey
bne loadtext


yeah, I load the map at $C000 like that, and it screws up, and doesn't work at all. I have it just loading 255 in y, and doing that method. And I have exactly 255 values in the map, and it loads incorrectly. There's a bunch of mishmash on the NT. Sorry, I don't mean to have the main problem that this thread is discussing branch out a thousand times into other dumb problems. But this is probably a leading cause of the collision problem. any suggestions?

AHHHHHHHHH!!!!!!!!!!!!!!!!!! THIS IS SO STUPID!!!!!!!!!!! Okay, I know that no body wants to talk about his anymore ever again, but I was just wondering what is wrong with my code. Okay, I tried to make my own collision code, and I cannot figure out what was wrong! I need your help. Okay, here is my code:


Do you see anything there that is easily spotted wrong? And I tried using code that you guys supplied, that didn't work. I'm angry! What happens is it is constantly making my player collide. Even when I'm on Tile #$00. What's going on here? How can I fix this? Please, help, and be kind. Thanks.

-Celius

I just saw two problems.
The first one :

I don't know what you call turd1, but if it is turd plus one, then it's wrong because 6502 opears in little endian mode, meaning that the low byte should be befor the high byte. But if you make it the way that turd1 is one byte befor turd, it's allright. In that case :

Should be replaced by "lda (turd-1),y"

The other problem comes when you're adding tilex to 32*tiley, you store the result in var1, and you don't load your adress proprely. I mean :
If the result of this addition is only 8-bit, then just load Y with the result of the addition (this is probably not the case here).
If the result is 9-bit, you should increase the high pointer after the addition if the carry is set. Then, load Y with the result would be simpler, but if you want to do it the way you're doing there, you should add the content of the low pointer to the result, then once again increment the high pointer under a carry condition.

_________________
Life is complex: it has both real and imaginary components.