Skip navigation
NintendoAge
Welcome, Guest! Please Login or Join
Loading...

Nerdy Nights week 6 Backgrounds

Oct 28, 2009 at 12:45:32 AM
MetalSlime (0)
avatar
(Thomas Hjelm) < Crack Trooper >
Posts: 140 - Joined: 08/14/2008
Japan
Profile

Whenever you copy some data from one place to another, by definition you have a source and a destination.  In this case, your source is somewhere in ROM and your destination is the PPU (VRAM).  Writes to $2006 will set your destination address, and then you write to the destination with sta $2007.  The PPU takes care of incrementing the addresses for you, so you don't have to do anything.

The source is where you are having some problems.  First, all addresses are 16-bit, which is why we need two variables (1 byte each) to represent one address.  The 6502 is little endian, so addresses need to be stored low-byte first (high-byte last).  So when we make a pointer variable in RAM, the low byte needs to come first, hence the order:

AddrLow .rs 1

AddrHigh .rs 1

Now as you suspected, the magic is in the brackets [].  Putting brackets around a variable Z translates to "the address located at Z and Z+1".  So when we have an instruction like this:

lda [AddrLow], y

it translates into English as "Go to the address stored in AddrLow and AddrLow+1.  Add y to that address.  Read the byte located there and stick it in the Accumulator."

If you look at our variable declarations above, you will see that AddrLow+1 is none other than AddrHigh.  So in our case, the instruction translates to "Go to the address stored in AddrLow and AddrHigh.  Add y to that address.  Read the byte located there and stick it in the Accumulator."

This is the piece you were missing I think.  We only put one variable (AddrLow) in the brackets, but the 6502 extrapolates that to two variables (AddrLow and AddrHigh) and makes a 16-bit address out of them.


-------------------------
MetalSlime runs away

My nesdev blog: http://tummaigames.com/blog...

Oct 28, 2009 at 1:13:11 PM
resynthesize (0)

(brandon t) < Cherub >
Posts: 7 - Joined: 10/19/2009
United States
Profile
Thomas, thanks!  This is exactly what I was looking for and it makes perfect sense now.  My only remaining question is whether this is a universal 6502 asm technique or something specific to NESASM.  I didn't see the brackets listed on this 6502 addressing reference page anywhere: http://www.obelisk.demon.co.uk/65...

-------------------------
 

Oct 28, 2009 at 1:31:16 PM
bunnyboy (81)
avatar
(Funktastic B) < Master Higgins >
Posts: 7704 - Joined: 02/28/2007
California
Profile
It is indirect indexed addressing on that page. Some people use the () notation and some use the brackets. There is no real standard but the mode is in all 6502 processors.

Oct 28, 2009 at 2:41:16 PM
resynthesize (0)

(brandon t) < Cherub >
Posts: 7 - Joined: 10/19/2009
United States
Profile
OK thanks.  I googled 'indirect indexed' to read more info about this since the explanation on the page I linked above wasn't very helpful.  I found this page which explains it better I think:

http://www.atariarchives.org/root...

I now understand what is going on.  It is the declaration of AddrHigh and AddrLow as zero page variables that allows indirect indexing to work.  Thanks everyone again for your help!  

-------------------------
 


Edited: 10/28/2009 at 03:14 PM by resynthesize

Feb 17, 2010 at 11:24:55 AM
bigjt_2 (17)
avatar
(Yeah, I'm a fat bastard.) < Meka Chicken >
Posts: 707 - Joined: 02/17/2010
Indiana
Profile
Originally posted by: bunnyboy

You can see there are 8 grid squares horizontally, so there will be 8 attribute bytes horizontally.  Then each one of those grid squares is split up into 2x2 tile sections to generate the attribute byte:


No 16x16 area can use more than 4 colors, so the question mark and the block cannot use the greens from the palette.

Hey bunnyboy,

I'm a noob at NES homebrew and am in the process of pulling things apart to see how they work.  I've really been enjoying your tutorials since finding them online a few days ago.

I was looking at different games just to verify the "no more than 4 colors per attribute tile" rule highlighted above, and got confused when I looked at this one from the character select screen on SMB2.  (I'm fairly certain my selection is an actual 16x16 attribute tile, but could be wrong.  I might have over dragged by a few pixels when I was capturing, as well.)


Now I know it's probably something I'm looking at wrong and/or misunderstanding, but I'm counting at least five colors being used in this area: red, blue, white, dark red, yellow.  Any idea what I'm not getting?


-------------------------
Every thread on this forum is very offensive.  Please lock every last goddammed one of them!

"Tell him you'll break his A button pusher."
                                                  --Otto Hanson
"Unlike the Sega Genesis, which will give you cancer."
                                                  --Randy the Astonishing

Feb 17, 2010 at 11:26:55 AM
Mario's Right Nut (352)
avatar
(Cunt Punch) < Bowser >
Posts: 6634 - Joined: 11/21/2008
Texas
Profile

^^ That's a 32x32 tile.

i.e. 2x2 each, 16x16 tiles.

Top left is using white, dark red, and light red.

Bottom left is blue, dark blue, and white.

Top right is using dark and light red.

Bottom right is using black, light red, dark red, and yellowish.


-------------------------

This is my shiny thing, and if you try to take it off me, I may have to eat you.

Check out my dev blog.



Edited: 02/17/2010 at 11:30 AM by Mario's Right Nut

Feb 17, 2010 at 11:31:43 AM
bigjt_2 (17)
avatar
(Yeah, I'm a fat bastard.) < Meka Chicken >
Posts: 707 - Joined: 02/17/2010
Indiana
Profile
Ah, I see now.  My math was way screwed up there.  Thanks for the help!  

-------------------------
Every thread on this forum is very offensive.  Please lock every last goddammed one of them!

"Tell him you'll break his A button pusher."
                                                  --Otto Hanson
"Unlike the Sega Genesis, which will give you cancer."
                                                  --Randy the Astonishing

Jun 21, 2010 at 8:04:08 AM
Horv (0)

(Tamas Horvath) < Cherub >
Posts: 3 - Joined: 06/21/2010
Hungary
Profile
Hi all! Thanks for the tut! Its helped! But I'm having trouble with the background, 'cause it made its limit. :S
Here's this picture:



This don't want to display more lines.

Here's the code about the tiles:
loadbg:
          lda background,x
         sta $2007
          inx
         cmx #208
        bne loadbg
background:

  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
  .db $00,$01,$02,$03,$04,$05,$06,$07,$08,$09,$24,$24,$24,$24,$24,$24  ;;row 1
Thanks! Horv

-------------------------
 


Edited: 06/21/2010 at 08:41 AM by Horv

Jun 21, 2010 at 10:25:28 AM
Dwedit (0)
avatar
(Dan Weiss) < Crack Trooper >
Posts: 130 - Joined: 05/25/2010
Illinois
Profile
Of course it doesn't want to display any more lines, you're only copying 208 tiles. (6.5 rows, or less depending on what X is initialized to)

Jun 21, 2010 at 11:17:48 AM
bunnyboy (81)
avatar
(Funktastic B) < Master Higgins >
Posts: 7704 - Joined: 02/28/2007
California
Profile
Originally posted by: Horv

         cmx #208

typo!

Jun 21, 2010 at 11:23:17 AM
Horv (0)

(Tamas Horvath) < Cherub >
Posts: 3 - Joined: 06/21/2010
Hungary
Profile
Oh, 'Cause I want to start the background at 80. Y. Is that possible?

Originally posted by: Dwedit

Of course it doesn't want to display any more lines, you're only copying 208 tiles. (6.5 rows, or less depending on what X is initialized to)


But the complier says error to me :S

-------------------------
 


Edited: 06/21/2010 at 12:22 PM by Horv

Jun 22, 2010 at 3:06:16 PM
Horv (0)

(Tamas Horvath) < Cherub >
Posts: 3 - Joined: 06/21/2010
Hungary
Profile
I made it! YEAH YEAH!

-------------------------
 

Jan 4, 2011 at 2:44:44 PM
thebmxeur (0)

(Simon Anciaux) < Cherub >
Posts: 5 - Joined: 01/04/2011
Belgium
Profile
Hi, I'm new to NES programming and this tutorial really helps a lot.

But I've got a few question : when I set a color in the first byte of the sprites palette, the fist bytes of each "group" of background palette changes. I tried with both the file I was working on and the file provided and it does the same. I'm missing something ?

Also can someone explain a little the DMA part when loading sprites ? I'm not sure why we don't use 2 STA $2003 (one with #$00 and one with #$02) and then "call" STA $4014. And is it ok to have that part (the DMA transfer) before checking the controllers states and moving the sprites (will the sprites move during the current or the next frame ?) ?

A last question : in the first part of the tutorial (making a bluish background), during the clrmen: part you put #$FE at $0300 ($03xx). Why ?

I hope I didn't ask too much question ^^
Thanks in advance
Bye



-------------------------


Feb 2, 2011 at 4:39:21 AM
Herbalist (139)
avatar
(Bill Brasky) < King Solomon >
Posts: 4208 - Joined: 08/19/2008
Wisconsin
Profile
I downloaded the attached background2.zip and I noticed that after the attribute line of code there is a previous line of sky data repeated.

I dont think it belongs does it?
Why is it there? Filler Data?


[ QUOTE ]

attribute:
.db %00000000, %00010000, %01010000, %00010000, %00000000, %00000000, %00000000, %00110000

.db $24,$24,$24,$24, $47,$47,$24,$24 ,$47,$47,$47,$47, $47,$47,$24,$24 ,$24,$24,$24,$24 ,$24,$24,$24,$24, $24,$24,$24,$24, $55,$56,$24,$24 ;;brick bottoms



.org $FFFA ;first of the three vectors starts here
.dw NMI ;when an NMI happens (once per frame if enabled) the
;processor will jump to the label NMI:
.dw RESET ;when the processor first turns on or is reset, it will jump
;to the label RESET:
.dw 0 ;external interrupt IRQ is not used in this tutorial


[ END QUOTE ]



-------------------------



Edited: 02/03/2011 at 05:22 AM by Herbalist

Apr 26, 2011 at 4:12:19 PM
JC-Dragon (0)
avatar
(JC Childs) < Eggplant Wizard >
Posts: 388 - Joined: 04/24/2011
United States
Profile
I seem to be having trouble with this. for some reason my code displays 4 pink blocks on a black background while BunnyBoy's will display mario with bricks and sky and whatnot. can someone point out to me where in my code it is incorrect. I'm not asking for exact reason just where the problem is occurring in the code.

[Edit]

 deleted all the code on the page since it was just taking up space on the thread.


[EDIT]
  I forgot to put this in the code which kept the sprites from loading. lol

   .bank 2
  .org $0000
  .incbin "mario.chr"

I spent nearly 4 hours going over my code to realize that I was missing this little piece. lol

-------------------------
You can't depend on your eyes when your imagination is out of focus
- Mark Twain


Edited: 04/27/2011 at 03:03 PM by JC-Dragon

Apr 26, 2011 at 4:30:14 PM
Mario's Right Nut (352)
avatar
(Cunt Punch) < Bowser >
Posts: 6634 - Joined: 11/21/2008
Texas
Profile
Is this your whole program? Do you ever include the CHR data?

-------------------------

This is my shiny thing, and if you try to take it off me, I may have to eat you.

Check out my dev blog.


May 14, 2011 at 1:37:58 PM
LucasWeatherby (42)
avatar
(Lucas Weatherby) < El Ripper >
Posts: 1284 - Joined: 03/18/2011
Florida
Profile
ok i need some help... when i use fceuxd and open the ppu viewer, i can see that the '? box' begins and lotcast $53. and goes thru $56. however, if i open up the mario.chr file with yy-chr it says the '? box' begins at C3. how can you know that address gets changed?

May 14, 2011 at 2:20:01 PM
removed04092017 (0)
This user has been banned -- click for more information.
< Bowser >
Posts: 7316 - Joined: 12/04/2010
Other
Profile
It's at $53-$56. My CHR file from this zip is at the same place. Maybe download it again? Or you're not going all the way to the bottom when you scroll with the red bar on the left side.

May 14, 2011 at 4:36:50 PM
LucasWeatherby (42)
avatar
(Lucas Weatherby) < El Ripper >
Posts: 1284 - Joined: 03/18/2011
Florida
Profile
ohh i see, you have to scroll all the way to the bottom to make it $53-$56(which also makes the numbers the first things on the screen in yy-chr). So I guess the numbers are where the background tiles knows to start. And i guess the assembler just knows this when it loads the background. Im still kind of confused on what i would do if i wanted more tiles then this mario.chr has tho. then how would it know where the background started?

May 15, 2011 at 9:31:11 AM
removed04092017 (0)
This user has been banned -- click for more information.
< Bowser >
Posts: 7316 - Joined: 12/04/2010
Other
Profile
Well you can only have 8KB of tiles in total. 4K for the front and 4K for the back. To get more you use a mapper, you can mostly only use a 8KB bank at a time. Then basically you can just make each file 8KB and include them all in the program. But you'll have to have your game switch them to utilize them.

To make a new file of the size you want (it should be an even number like 8K,16K,32K,64K,128K,256K etc.) and then start making the graphics. If you need the program to create a blank file, I have one just PM me. With eath 8KB bank, you can select which ones go on the background and which goes to the sprites.

And the assembler doesn't care what the background grahics are, the games program does and "knows" all it needs to know. The assembler just shoves the graphics in after the program, it doesn't do anything to them. It doesn't need to know which tile is what, it just assembles your ROM.

Nov 2, 2011 at 6:09:56 AM
oleSchool (0)
avatar
(Jonathon Wright) < Little Mac >
Posts: 72 - Joined: 11/02/2011
Hawaii
Profile
New guy here, thought after 2 months of reading this stuff and doing well in the tutorials that I would make it all the way through to the last topic, but got stuck on a question I'm not getting. So joined up the NA site so I could post my question and start participating.

Anyway, I'm having difficulty determining what should be a "sprite", and what should be in the "background". Or what the real difference is anyway.

For example, in SMB, the clouds and bricks are both background (Pattern Table 1) correct? But Mario interacts (collision) with some background tiles like the bricks and some other background tiles not at all, like the clouds. So I'm trying to see if there is a good definition for a sprite vs background tiles. The only thing I can tell really is that sprites have 4 attributes, only 2 of which differ it from a background tile (such as flipping it). Color palette and location are both set, etc....

Just trying to think ahead for certain situations like:
1. I may have more sprites than I can fit onto 1 Pattern Table of 1 .chr file. (Just make more chr files a solution?)
2. I may not have a background at all, so I would want both Pattern Tables for sprites (maybe Pac Man or Galaga has no background?)

Just thoughts, maybe I'm way off, any kind words are welcome as this is my first post =)

OS


-------------------------
"It's Dangerous to go alone. Take This!"
The Old Man

https://www.youtube.com/channel/U...


Edited: 11/02/2011 at 06:12 AM by oleSchool

Nov 2, 2011 at 6:33:04 AM
Zzap (47)
avatar
(James ) < King Solomon >
Posts: 3301 - Joined: 05/01/2007
Australia
Profile
The sprites can all move independently, and have pixel accuracy. You can have up to 64 8x8 or 8x16 sprites (max 8 per scanline).

The background can only move as one whole background, while it is possible to update tiles in the background each frame, there is a limit to how many tiles you can replace per frame.

-------------------------

Chunkout for iPhone, iPad and iTouch out now!
Chunkout Games: FaceBook | Web

Nov 2, 2011 at 12:22:52 PM
removed04092017 (0)
This user has been banned -- click for more information.
< Bowser >
Posts: 7316 - Joined: 12/04/2010
Other
Profile
Extending on what Zzap said: If it's one object like an item in the game that you can pick up, I'd make it sprites. If it's an object often in the game, I'd recommend making it a background tile. Animate it by taking it off the background is probably the best idea if you have the time to implement it. Super Mario Bros. 3 does this, look at FCEUX's nametable viewer and jump and hit a coin box and slow it down to see what it does. It'll remove it from the background and animate it via a sprite, and then put it back when it's done so that you can have many blocks in a row and still have animation to them when hit.


As for no background, I dunno. A game simply done with all sprites would probably not be very good to look at, even if it played well, and if there's some decent amount of stuff on the screen, you may have to flicked a decent amount.

And then the NES usually does 8x8 pixel sprites. You can also do 8x16 sprites, which are actually 2 sprites built into one. You can use both the background graphics and sprite graphics for the whole graphics for the sprites in that mode. The background can only use the background sprites assigned to it even in that mode though, as it only does 8x8 graphics per tile on the background. If you have lots of characters in your game that are four 8x8 sprites made into a 16x16 object, I'd use 8x16 spites so you can get more of them on the screen myself. You need to plan all this out before you start working on big projects. Although you're just learning, I'd mess with both. Make a program that works with 8x8 sprites, and then use 8x16 and see the difference first hand. If you need help quick just PM me and I'll help you, I'm always on line if I'm at my house and will help you.


Edited: 11/02/2011 at 12:41 PM by removed04092017

Nov 3, 2011 at 4:32:09 AM
oleSchool (0)
avatar
(Jonathon Wright) < Little Mac >
Posts: 72 - Joined: 11/02/2011
Hawaii
Profile
Did I mention that this site rocks because of the people here. I can tell this is definitely visited by true enthusiasts, and that alone is very exciting. Both of you seem pretty seasoned in this stuff, so thanks for the time to make the replies for us new guys. =)

Zzap, that makes sense, Guess I just needed to talk it out and hear it.

3GenGames, First sentence, got it. So if Mario hits the block (part of the background), it "produces" a sprite such as the mushroom via some code. Which is probably why the mushroom is in the sprite pattern table. Also, what I meant by no background was no attribute / colors just flat black $0F (like Galaga). The other reason I was asking and you already addressed with SMB3 comment. I'm just thinking "is it easier to have collision detection between a sprite and background, or sprite and sprite?" So when Mario hits a block (background) there is collision detection obviously. And if a mushroom sprite is produced, and Mario grabs it, there is also collision detection. So which is easier sprite-to-sprite collision detection or sprite-to-background...or does it matter, they are the same?

Just planning ahead, as to which one I want to make. The bricks are obviously already part of the background, so its the more "standard" way of doing it. I just like to think outside the box and see what other options are there, and maybe understand a bit more on the "why" it is the standard.

Hope that makes sense.
Thanks for the PM offer, I'll probably take you up on it when I'm "stuck" on an actual line of code, haha. Right now, I just have background of some SMB tiles and mario sprite that I can move around.

Still getting the feet wet. =)

OS

-------------------------
"It's Dangerous to go alone. Take This!"
The Old Man

https://www.youtube.com/channel/U...


Edited: 11/03/2011 at 04:35 AM by oleSchool

Nov 3, 2011 at 7:17:22 AM
removed04092017 (0)
This user has been banned -- click for more information.
< Bowser >
Posts: 7316 - Joined: 12/04/2010
Other
Profile
Ha, okay man. But sprite on sprite background detection is pretty easy, I'd say the background is little harder, especially if you edit it at all. But I mean it's a good idea to me just not to mess with that out of the gate unless your project needs it, you can always work up to it later in the project or with another game.


Edited: 11/03/2011 at 07:18 AM by removed04092017