8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

tokumaru wrote:
unregistered wrote:Would column 0 of nametable 0 be the start of the third screen?
Yes.
Thank you tokumaru. :)

---

Code: Select all

0C1CA                           camera_aim:
0C1CA                           
0C1CA                             ;determines how much to move based on the players position
0C1CA A5 03                       lda oX+0 ;players position
0C1CC 38                          sec
0C1CD E9 04                       sbc #$04
0C1CF 85 1F                       sta CameraX+0 ;camera's position
0C1D1                             
0C1D1 A5 04                       lda oX+1
0C1D3 E9 00                       sbc #$00
0C1D5 85 20                       sta CameraX+1
0C1D7                             
0C1D7 60                        rts ;end of camera_aim
So here is my initial try at a camera moving based on players position. I'm trying to subtract 4 from the player's position and so the camera should always be on the player. This doesn't happen... she eventually reaches the otherside of the screen.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

unregistered wrote:she eventually reaches the otherside of the screen.
So oX is the object's coordinate within the level, right? How are you calculating the sprite coordinate then? You can't simply take oX and use that for the sprites, unchanged.

You have to keep in mind that when you're dealing with scrolling games, you have 2 coordinate systems to care about: level coordinates and screen coordinates. Level coordinates are absolute, they indicate where in the level the objects are, and this doesn't change, no matter where the camera is. Screen coordinates, however, are relative to the camera, so before displaying objects on the screen you have to convert level coordinates into screen coordinates. Since the left edge of the camera represents the left edge of the screen, you have to subtract the camera's coordinate from the coordinate you're converting: SpriteX = oX - CameraX.

You may take shortcuts, but generally speaking, you have to convert between coordinate systems for everything you'll display on the screen, since the relative position of everything changes as the camera moves. For example, if you want to render a metatile column at the right side of the screen, you have to convert the column number from screen coordinates into level coordinates so that you know which column to read from the level map. You may have taken shortcuts here, but conceptually, this is what's happening (or should be!).
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

So, to convert from screen coordinates to level coordinates... you would add CameraX right? :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

Yes, but I can't think of many cases where that would be necessary. Things often happen in the level, and you need to translate that to the screen so that the player can see what's happening, but the opposite should be very rare. In a device with a touch screen you'd do that to check what parts of the level are being touched, but this is obviously not the case of the NES. Would you mind telling us why you need this conversion?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples »

Zapper provides a Y coordinate (more or less), Vaus provides an X coordinate, and Oeka Kids tablet provides both. These need to be translated to world space coords.

Super Mario World spawns a stored item into the level from a fixed place on the screen.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

tepples wrote:Zapper provides a Y coordinate (more or less), Vaus provides an X coordinate, and Oeka Kids tablet provides both. These need to be translated to world space coords.
Yeah, input devices are usually the ones responsible for the need to convert screen coordinates into world coordinates, but I don't think unregistered is using any of those special controllers.
Super Mario World spawns a stored item into the level from a fixed place on the screen.
This is indeed a legitimate reason that's not related to input.

In the message where I first talked about coordinate conversion I used the example of rendering metatiles to the right side of the screen, which would require coordinates to be converted from screen space to level space. This wasn't such a good example though, since you could achieve the same effect by rendering metatiles at the right side of the camera (not the screen!), and using coordinate conversion to find their final position on the screen.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

tokumaru wrote:Would you mind telling us why you need this conversion?
yes... you were talking about doing that and so I was wondering...
tokumaru wrote:For example, if you want to render a metatile column at the right side of the screen, you have to convert the column number from screen coordinates into level coordinates so that you know which column to read from the level map.
tokumaru wrote:In the message where I first talked about coordinate conversion I used the example of rendering metatiles to the right side of the screen, which would require coordinates to be converted from screen space to level space. This wasn't such a good example though, since you could achieve the same effect by rendering metatiles at the right side of the camera (not the screen!), and using coordinate conversion to find their final position on the screen.
I don't understand. Sorry. :( .. well I do understand that you are talking about what you were talking about before. I'm confused now. :?
tepples wrote:Super Mario World spawns a stored item into the level from a fixed place on the screen.
... I remember that from the New Super Mario Brothers DS game. :) Was pretty neat battling little browser with a Mega Mushroom from above!

edit.
Last edited by unregistered on Wed Apr 24, 2013 2:45 pm, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

unregistered wrote:
tokumaru wrote:For example, if you want to render a metatile column at the right side of the screen, you have to convert the column number from screen coordinates into level coordinates so that you know which column to read from the level map.
tokumaru wrote:used the example of rendering metatiles to the right side of the screen, which would require coordinates to be converted from screen space to level space. This wasn't such a good example though, since you could achieve the same effect by rendering metatiles at the right side of the camera (not the screen!), and using coordinate conversion to find their final position on the screen.
I don't understand. Sorry. :( .. well I do understand that you are talking about what you were talking about before. I'm confused now. :?
I just meant that I think it's best to start at the source (level map) and then calculate the target (screen) when rendering scrolling backgrounds, but my first comment suggested the opposite (calculate the source from the target). Both work, I just happen to find one method more appropriate than the other.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

^ :)

---
On the screen it looks like the first column is repeated every 8 pixels.

Code: Select all

Instead of this

\000
0\00
00\0

there's this

\\\\
0000
0000
It redraws the same four columns of tiles over and over as the screen scrolls. I just want one copy of those four columns of tiles. And then I would like a different four columns... and then another different four columns. So the background looks like it's scrolling by. Do you understand? :) Could you write some psudocode to give me an idea of what to do?
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

Continuing from this:
If cameraposition/8 - oldcameraposition/8 is not equal to 0, we moved at least one tile and need to update the nametables.
columntoupdate = cameraposition / 8.

Edit: Well, when scrolling left anyway. When scrolling right, columntoupdate = (cameraposition+256)/8

Decode and pass that column to whatever you're using to draw columns instead of always the same one, like it sounds like you're doing now. I can't really give more detail than that without a refresher on how your level is actually stored.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:Continuing from this:
If cameraposition/8 - oldcameraposition/8 is not equal to 0, we moved at least one tile and need to update the nametables.
columntoupdate = cameraposition / 8.

Edit: Well, when scrolling left anyway. When scrolling right, columntoupdate = (cameraposition+256)/8

Decode and pass that column to whatever you're using to draw columns instead of always the same one, like it sounds like you're doing now.
Thank you so very much Kasumi! :D That passing of the column... that was what I needed to understand. Now it is almost working... it draws a 32 wide column... and then skips a 32 wide column... and draws the third 32 bit wide column... and then skips again... and draws then skips again. So in one screen it draws every other 32 bit wide column twice. And also it starts in the wrong nametable... it should take a break at the beginning while our girl travels across nametable 0 and nametable 1... now it starts drawing the columns on nametable 1. It's almost working!! :mrgreen: :D
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

... well, I tried to get every column to display... instead of every other 32 bit wide column. That involved creating an ATTENTIONflag variable and it was lousy. So I deleted all of that code and decided to try to make it wait until our character reaches nametable 1 to start drawing columns... but I'm lost. Here is my scrolling the screen code. What have you done to make the code wait until your character reaches nametable 1?
no, I going to try this myself.

(edit) added.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:Later in the code, you decide to move the camera based on where she is. Like... if her position is greater than half the screen, the camera moves to her position - 128 (half the screen).

So... cameraposition = ladyposition - 128.
If cameraposition > levellength -256, cameraposition = levellength-256.
If cameraposition < 0, cameraposition = 0.
I want to ask you a question about your last line right there. How and why does this need to be one of the checks? If cameraposition < 0, cameraposition = 0. For me this means that cameraposition cant ever be greater than 127... if we have to check if it is less than zero. Right now there is one thing I notice that's wrong... cameraposition can be greater than 127 because the levellength+1 is = to 4. So would that mean that the negative value would span two bytes? I'm so confused. :? 2^15 = 32768... would be a two byte negative value I think.

edit: So after finding the fast way of writing 2s compliment video...
first I write the positive 16bit binary number... 1000 0000 0000 0001. That's equal to 32769.
Then I invert all the digits after passing the first "1" going from right to left.
I get 0111 1111 1111 1111. Um so that's odd it starts with a 0.... but it's negative... hmmm... :?


last edit: ahh maybe -32769 isnt possible for 16 bits.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

I want to ask you a question about your last line right there. How and why does this need to be one of the checks? If cameraposition < 0, cameraposition = 0
Let's say lady position is 0.
cameraposition = ladyposition - 128.
cameraposition = 0 - 128.
cameraposition = -128.

That's why you do that check. The camera shouldn't be negative.

As for how, just subtract the numbers and check for a clear carry which tells you you went below zero. If that happens set camera position to zero. It makes no difference if you're using 8bit, 16bit or 24bit numbers. (But if you want to actually scroll, you want a range greater than 8 bits will provide)

Think in unsigned bytes for this.

Edit:
Right now there is one thing I notice that's wrong... cameraposition can be greater than 127 because the levellength+1 is = to 4. So would that mean that the negative value would span two bytes
Huh? Let's say your level is 256 pixels long. Your lady is at 256. This puts the camera at 128. (Because cameraposition = ladyposition - 128) Except the cameraposition is the leftmost point of a 256 pixel box. 128+256 = 384. You're showing 128 past the right edge of the level.

So if cameraposition is greater than levellength - 256, you set it to levellength - 256.

This works for any value of levellength that is equal to or greater than 256 pixels.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
I want to ask you a question about your last line right there. How and why does this need to be one of the checks? If cameraposition < 0, cameraposition = 0
Let's say lady position is 0.
cameraposition = ladyposition - 128.
cameraposition = 0 - 128.
cameraposition = -128.

That's why you do that check. The camera shouldn't be negative.

As for how, just subtract the numbers and check for a clear carry which tells you you went below zero. If that happens set camera position to zero. It makes no difference if you're using 8bit, 16bit or 24bit numbers. (But if you want to actually scroll, you want a range greater than 8 bits will provide)

Think in unsigned bytes for this.
Brilliant! Thank you Kasumi! :D ...I remember that cmp would work because it acts just like subtraction only it discards the answer... and that would be fine... the carry would still be cleared.
Kasumi wrote:
Edit:
Right now there is one thing I notice that's wrong... cameraposition can be greater than 127 because the levellength+1 is = to 4. So would that mean that the negative value would span two bytes
Huh?
levellength+1 is 4... so cameraposition would have to be big enough to reach 768... my logic doesn't work well right now.
Kasumi wrote: Let's say your level is 256 pixels long. Your lady is at 256. This puts the camera at 128. (Because cameraposition = ladyposition - 128) Except the cameraposition is the leftmost point of a 256 pixel box. 128+256 = 384. You're showing 128 past the right edge of the level.

So if cameraposition is greater than levellength - 256, you set it to levellength - 256.

This works for any value of levellength that is equal to or greater than 256 pixels.
Thank you so much for stepping through both of your ideas! :D

edit.
Post Reply