nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 66 of 97

Author:  unregistered [ Wed Apr 17, 2013 10:27 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

tokumaru wrote:
unregistered wrote:
Would column 0 of nametable 0 be the start of the third screen?

Yes.
Thank you tokumaru. :)

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

Author:  tokumaru [ Wed Apr 17, 2013 11:01 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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!).

Author:  unregistered [ Mon Apr 22, 2013 1:49 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

So, to convert from screen coordinates to level coordinates... you would add CameraX right? :)

Author:  tokumaru [ Mon Apr 22, 2013 4:45 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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?

Author:  tepples [ Mon Apr 22, 2013 6:37 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  tokumaru [ Tue Apr 23, 2013 9:28 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

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

Author:  unregistered [ Wed Apr 24, 2013 1:11 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

tokumaru wrote:
Would you mind telling us why you need this conversion?
yes... you were talking about doing that and so I was wondering...
Quote:
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.

Author:  tokumaru [ Wed Apr 24, 2013 2:44 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

Author:  unregistered [ Wed May 01, 2013 7:06 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

^ :)

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

Code:
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?

Author:  Kasumi [ Wed May 01, 2013 8:03 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Continuing from this:
Quote:
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.

Author:  unregistered [ Tue May 07, 2013 7:00 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Kasumi wrote:
Continuing from this:
Quote:
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

Author:  unregistered [ Fri May 10, 2013 9:52 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

Author:  unregistered [ Mon Jun 03, 2013 10:09 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  Kasumi [ Mon Jun 03, 2013 7:41 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

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

Author:  unregistered [ Tue Jun 04, 2013 9:12 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

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

Page 66 of 97 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/