It is currently Sun Jan 20, 2019 8:38 pm

 All times are UTC - 7 hours

 Page 66 of 97 [ 1452 posts ] Go to page Previous  1 ... 63, 64, 65, 66, 67, 68, 69 ... 97  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Apr 17, 2013 10:27 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
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.

Top

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

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

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
So, to convert from screen coordinates to level coordinates... you would add CameraX right?

Top

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

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

Top

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

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21004
Location: NE Indiana, USA (NTSC)
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.

Top

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

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

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
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.

Last edited by unregistered on Wed Apr 24, 2013 2:45 pm, edited 1 time in total.

Top

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

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

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
^

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

Code:

\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?

Top

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

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1268
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.

_________________
https://kasumi.itch.io/indivisible

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
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! 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!!

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
... 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.

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
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.

Top

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

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1268
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 = 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.

_________________
https://kasumi.itch.io/indivisible

Top

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

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 951
Location: cypress, texas
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 = 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! ...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!

edit.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 66 of 97 [ 1452 posts ] Go to page Previous  1 ... 63, 64, 65, 66, 67, 68, 69 ... 97  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 0 guests

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

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki