It is currently Mon Nov 12, 2018 7:14 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 108 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author Message
 Post subject:
PostPosted: Sat Sep 10, 2005 11:46 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2005 12:56 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2005 1:10 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2005 1:16 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7563
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2005 2:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10959
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 8:09 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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? :(


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 9:31 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10959
Location: Rio de Janeiro - Brazil
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:
Image

And this is what we might have at the top left corner of our game screen, at a given time:
Image
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:
Image
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:
Image
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.
Image
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:
Image
Image
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:
Image
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.


Last edited by tokumaru on Fri Sep 16, 2005 10:01 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 9:51 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10959
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 10:35 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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. :(


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 11:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10959
Location: Rio de Janeiro - Brazil
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:
Code:
if (Map[pointX div 8, pointY div 8]) > 127 then playX := pointX and $F8 + 8;

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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 7:38 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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:

Code:
collision:
      ;the collision stuff which I already understand pretty much
     
      lda (map_add), y
      sta stuff

      lda stuff
      bpl nocol

      lda #$01
      sta lfcol
      ;I would have it storing 1 in rtcol, upcol, and dncol, but that would mean I can't move anywhere once there's a collision.
nocol:
      lda #$00
      sta lfcol
      sta rtcol
      sta upcol
      sta dncol



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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 9:06 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10959
Location: Rio de Janeiro - Brazil
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:
Code:
      lda (map_add), y
      sta stuff

      lda stuff
      bpl nocol


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:
Code:
      lda (map_add), y
      bpl nocol

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.

Quote:
One is, that the collision areas act as collision columns, so I collide in the columns that the tiles are in.

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.

Quote:
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.

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:
Code:
moved_left:
   ;Set the first point.
   LDA playX
   STA pointX
   LDA playY
   STA pointY

   ;Check the first point.
   JSR check_collision

   ;Jump if collision happened.
   BMI left_collision

   ;Set the second point.
   LDA playY
   CLC
   ADC #$08
   STA pointY

   ;Check the second point
   JSR check_collision

   ;Jump if collision happened.
   BMI left_collision

   ;Set the third point.
   LDA playY
   CLC
   ADC #$0F
   STA pointY

   ;Check the third point
   JSR check_collision

   ;Jump if collision happened.
   BMI left_collision

   ;If you get here, no collision
   ;happened, so, skip the position
   ;correction step.
   JMP end_left_collision

left_collision:
   ;Here we fix the player's Y position.
   LDA playY
   ;Clear the lower 3 bits
   AND #$F8
   ;Add 8 to place it to the right of the solid tile.
   CLC
   ADC #$08
   STA playY
end_left_collision:
   ;If you make the checking of each direction
   ;as subroutines, you can just return now.
   RTS

check_collision:
   ;do all that collision crap I
   ;explained befor in here. But
   ;use "pointX" and "pointY"
   ;instead, so you have a generic
   ;function that can check any
   ;points you want it to.
   .
   .
   .
   LDA (map_add), Y
   ;OK, if it was a solid block,
   ;the N flag is set.
   ;Return from the routine, having
   ;the N flag to indicate a collision.
   RTS

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!
Code:
moved_down:
   ;Set the first point.
   LDA playX
   STA pointX
   LDA playY
   CLC
   ADC #$0F
   STA pointY

   ;Check the first point.
   JSR check_collision

   ;Jump if collision happened.
   BMI bottom_collision

   ;Set the second point.
   LDA playX
   CLC
   ADC #$08
   STA pointX

   ;Check the second point
   JSR check_collision

   ;Jump if collision happened.
   BMI bottom_collision

   ;Set the third point.
   LDA playX
   CLC
   ADC #$0F
   STA pointX

   ;Check the third point
   JSR check_collision

   ;Jump if collision happened.
   BMI bottom_collision

   ;If you get here, no collision
   ;happened, so, skip the position
   ;correction step.
   JMP skip_bottom_collision

bottom_collision:
   ;Here we fix the player's X position.
   LDA playX
   ;Just clearing the 3 bits will
   ;do the trick this time.
   AND #$F8
   STA playX
skip_bottom_collision:
   RTS

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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 10:51 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 25, 2005 6:01 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2150
Location: Minneapolis, Minnesota, United States
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:
Code:
collision:
   lda #HIGH(bg1)
   sta turd
   lda #LOW(bg1)
   sta turd1
   lda cy
   lsr a
   lsr a
   lsr a
   sta tiley
   lda cx
   lsr a
   lsr a
   lsr a
   sta tilex
   lda tiley
   asl a
   asl a
   asl a
   asl a
   asl a
   sta vara
   lda tilex
   adc vara
   sta turd1
   ldy #$00
   lda (turd),y
   bpl nocol
   lda #$01
   sta colflag
   rts

nocol:
   lda #$00
   sta colflag
   rts



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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 26, 2005 9:21 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7563
Location: Chexbres, VD, Switzerland
I just saw two problems.
The first one :
Code:
   lda #HIGH(bg1)
   sta turd
   lda #LOW(bg1)
   sta turd1

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 :
Code:
lda (turd),y

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 108 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group