A last question! is there any way that I could use the patern tables tiles in a image format?

I mean, now I fully understand this tutorial, but to proove myself that I really understand it, I want to make a custom background with the tiles of Mario Bros background pattern table/tiles. As a visual support I would like to do something that I see to be accurate. Does some one understand what I mean?

I'm not sure if I express really well what I want but I hope some one will.

Hi, thanks again for all the answer, they were really helpful!

I got a very last question. I finally menage to understand very well this tutorial. But as a challenge to myself, I want to make a background out of my imagination with the background tiles of the Mario bros. file.

My question is, Is there a way that I could use the tiles/background patern table from the Mario bros file, and make a visual support with it. The goal is to make a visal reference that help me to be more accurate, like a image(jpeg or something like that). I know its a lot of trouble but I think it could be very helpful to me.

Gosh sorry for double post, I thaught it didn't appear so I make another post. sorry again

What do you mean by visual support?  What are you trying to be more accurate in/with or what exactly are you having trouble with? What are you trying to accomplish overall with this?

The way I understand your question, the program YY-chr does what I think you are asking about.

I mean, instead of memories every tiles number, I'll make a complete picture (like a puzzle) of what I would like my background to look alike. Best exemple of what I'm looking for is Pyxel Edit  http://pyxeledit.com/images/tileE...

^___ I'm not too sure I understood you question, and my English is rather poor; however I try (@all if my answer is not good, just correct it with the correct answer, there is no need to mock me, I'm just trying to help):

- if you will make a background of 16x16px areas (ie. 2x2 tiles) then you might be interested in the MRN article on metatiles, look for it in the sticky thread of The Brewery.

- I don't think the tool you ask for exists (by the way: IMO jpg would definitely be a wrong format, since it is not loseless compression: bmp, gif or png would be definitely more correct), but Shiru made a tool you can found in NESDev forum (I think it must be a great tool, but I have hard time to fully understand how it work exactly, so I basically used it once to see how many tiles a third party image which was given to me to include in a game would take, and I used something like Tile Layer Pro to actually import the image in the CHR).

- If you make the background of 8x8px areas, this is a way you can do it without using other tools: make a big data table of the background on your file to load, like:

00 00 00 00 00 00 00 00 00 00 00 ...

long 32 tiles repeated x 30 lines. This are the 960 Bytes to load your background. Then you edit it tile by tile, or row by row, reassemble the code, and verify in an emulator that it looks correct so far; you can take screen shots of the previous "version", to help you editing the file for the next version. It is quickly boring and highly time consuming, however, it works I guess.

Again, I'm not even sure I understood the question. I'm confident other members will provide you better feedback.

Cheers!

Download NES Screen Tool, found here:

https://shiru.untergrund.net/file...

Open the CHR file you want to use and then click on the tile you want to use, then click on the position you'd like to use it. When you're done, you can export the nametable and attribute data and import them into your assembly file with the use of ".incbin "filename".

Which explains why I hardly feel the need for such features, and brings an interesting question:

How many NES homebrewers actually save a full nametable in the ROM for each background in the game?

I mean, in my ROMs I describe the nametables, I don't save them Byte by Byte.

For instance, let say a game has the backgrounds sharing few identical lines. In this case I store a compressed array of bytes (fi. 32 00 for an empty line, if the whole 00 tile is "transparent color") and give each line an ID number (fi. 00), then describe the background as a compressed array of 30 lines IDs (fi. 30 00 for an all empty background made of 30 all "transparent color" lines made each of 32 "transparent color" tiles). If instead the backgrounds share areas different than lines, then I code a compressing / decompressing routine handling these "screen areas" instead of lines. And so on. And this also for attributes, of course. This also because often little portions of the backgrounds change during game.

I never find myself storing a whole nametable in a ROMs, and I never used in different games the same compressing / decompressing routine to describe backgrounds. I always adapt the compression method to the game structure and needs, with the goal of avoiding redundancy in the ROM and to save space. The method used depends on the game.

@all
So now I wonder: it is this common, or it is just me to prefer store the backgrounds data in some fractioned and compressed way rather than have, for each single background, a full nametable of 960 Bytes + attributes Bytes?

I'm really curious on the subject now!

Cheers!

I store everything as full backgrounds, using what I learned in MRN's compression tutorials (though I took out the repeat function since the costs outweighed the benefits at this time; meaning I like to see all of the tiles at once). Except for the status bar, which is loaded separately, and therefore saves six (three compressed) lines of data in memory per room. However, for the 64 rooms that I have up and running it only took a couple of days to program them in, and I enjoyed having the level of control that I did. But that's just me, and I'm sure things will change in the future as I continue to learn.

The compression method you're describing is definitely the better way to go, and I use this method for gameplay background data and other areas.  But for things like Title screens, credit screens, etc, I use the method I described.  It's super easy to go back, open the nametable in NES Screen Tool, make a change, and export the new background.  Then I never even have to go into my code to update it.  It's already changed automatically.

And it makes a lot more sense to try to explain this method to a beginner.  Someone who is just trying to figure things out would have a hard time trying to grasp background compression.  That's something that is adapted later.

The nice thing about NES Screen Tool is that it actually supports RLE compression out of the box. Create the nametable as you normally would, but when saving it select "RLE packed" from the file type list. This will produce a .RLE file, which you can .incbin in to your project, and use the routine from rle.asm (also included with NES Screen Tool) to decompress the data. RLE compression gets rid of most of the redundancy in a nametable.

The .RLE files can also be opened in NES Screen Tool as nametables just like normal uncompressed nametables.

user: You have to weigh whether making a custom compression/decompression routine for each scenario is beneficial. It may make your data smaller than e.g. RLE could, but by how much, and is it worth the extra time it takes to develop the data format and the algorithm (and possibly to layout the compressed data by hand)?

If you are not targetting cart production, then ROM space is completely free so I don't bother with compression.

If you are targetting carts, then I only use compression to hit important ROM sizes like 128KB and 512KB.  The same chip is used for 80KB and 128KB so smaller data frequently doesn't matter.  I have done compression for CHR (8KB->3-5KB) and RLE for dragon warrior type maps, but I don't think I have done it for nametables.

@Kevin, bunnyboy, Kalle, Beau
Thank you, really interesting reading from some more experienced homebrewers. Exactly what I was looking for as answers to that questions. I consider myself way more talented as a game designer (game concepts, mechanics, and such things) rather than as a good programmer (I learned to program because is needed to develop an idea I have for a game), so when more experienced programmers talk, I am always interested into it, no matter that I'm already skilled enough to understand, or I still need to chew on what I am explained a bit more to fully understand what I am told.

So, thank you for your detailed opinions and proposed alternatives, I'll surely care about read them more then once and understand further the advantages/disadvantages of each.

Nice to know that anyways there is not a "correct way": it seems, from these first replies, that it is more like "it depends" on various factors, as often is in many creative fields.

@Kevin
""" And it makes a lot more sense to try to explain this method to a beginner. Someone who is just trying to figure things out would have a hard time trying to grasp background compression. That's something that is adapted later. """

Indeed. I was talking now on a right next level, for my own interest, giving as done that your previous link fully solved Bullseye needs (which is what I guess).

Thanks All!

- Jack

I use a home made RLE compression routine to compress my screens. I use it in all my games.

@KHANS games @USER thanks to both of you! I'm very pleased by all the supports I get here! Thanks again!

I am using the code in these tutorials to load a full screen background. It works nicely, now I wan to load another "room", (i.e. load the tiles again into the nametable). I repurposed the routine into a subrotine, but the second time I call it, the new "room" won't load properly, instead I get a garbage version of the room;

LoadBackground:

  LDA $2002             ; read PPU status to reset the high/low latch
  LDA #$20
  STA $2006             ; write the high byte of $2000 address
  LDA #$00
  STA $2006             ; write the low byte of $2000 address

  ;LDX room_number       ; grab the actual room pointer
 
  LDA #$00
  STA pointerLo       ; put the low byte of the address of background into pointer
  LDA #HIGH(Room1)
  STA pointerHi       ; put the high byte of the address into pointer
 
  LDX #$00            ; start at pointer + 0
  LDY #$00
OutsideLoop:
 
InsideLoop:
  LDA [pointerLo], y  ; copy one background byte from address in pointer plus Y
  STA $2007           ; this runs 256 * 4 times
 
  INY                 ; inside loop counter
  CPY #$00
  BNE InsideLoop      ; run the inside loop 256 times before continuing down
 
  INC pointerHi       ; low byte went 0 to 256, so high byte needs to be changed now
 
  INX
  CPX #$04
  BNE OutsideLoop     ; run the outside loop 256 times before continuing down       

  LDA #%10010000   ; enable NMI, sprites from Pattern Table 0, background from Pattern Table 1
  STA $2000

  LDA #%00011110   ; enable sprites, enable background, no clipping on left side
  STA $2001
 
  RTS

Can this code be used to re-load the background or I am missing something?

Also can anyone point me to a tutorial on how to show a main screen, and the load the game level, as it should be the same concept I am trying to get working.

Let your NMI enable your PPU. Don't do this in the main code. Doing it in the main code will make it look like garbage (what you are seeing).
   LDA #%00011110   ; enable sprites, enable background, no clipping on left side
   STA $2001

Here is what my NMI looks like:
LDA #%10010000                    ; enable NMI, sprites from Pattern Table 0, background from Pattern Table 1
 STA $2000
 
LDA EnablePPUFlag                   ;Only Enable the PPU when this flag is enabled in the code.
BEQ .SKIP
    LDA #%00011110                   ;enable sprites, enable background, no clipping on left side
    STA $2001
    DEC EnablePPUFlag
  .SKIP:

(This is a Subroutine in my main code. The NMI calls this when I tell it to with the EnablePPUFlag)
EnablePPU:              ;<--------------------***********Subroutine called by the NMI to turn on the PPU
  LDA #%00011110   ; enable sprites, enable background, no clipping on left side
  STA $2001
  RTS


-----------
This is what my code looks like.

LDA #$00        ;<-------------------------**********Turn off the PPU in the Main Code First
STA $2001

  LDA #LOW(PlayingBackground)          ;<-----------------**********Load background routine*************
  STA BackgroundAddr
  LDA #HIGH(PlayingBackground)
  STA BackgroundAddr+1
  JSR LoadBackground
 
  LoadBackground:
  LDA $2002
  LDA #$20
  STA $2006             ; write the high byte of $2000 address
  LDA #$00
  STA $2006             ; write the low byte of $2000 address
 
  LDX #$04              ; Loop X 4 times
  LDY #$00              ; Loop Y 256 times
LoadBackgroundsLoop:
  LDA [BackgroundAddr],y          ;Load background from table in the pointer
  STA $2007                                     ;Write to screen
  INY
  BNE LoadBackgroundsLoop
; Outer loop
  INC BackgroundAddr+1           ; increment high byte of address backg to next 256 byte chunk
  DEX                    ; one chunk done so X = X - 1.
  BNE LoadBackgroundsLoop   ; if X isn't zero, do again
  LoadBackGroundDone:  
  RTS
 
  INC EnablePPUFlag             ;<--------------********This flag will tell the NMI to turn PPU back on*******



---------------------------------------------------------
SIDE NOTE: You don't have to do anything with this code when turning the PPU on and off. That code only belongs in the PPU
  LDA #%10010000   ; enable NMI, sprites from Pattern Table 0, background from Pattern Table 1
  STA $2000



Hope that made sense. Good luck

Thanks, I will work on this

Thanks Mega Mario Man, now I have room switching working. I do get a quick black flash when switching, I know is because I am turning on and off the PPU, just wondering if this is the standard way or if there is a way around this?

Also, if I want to update just some background tiles, like the score for example, can I just update the value in my backgrounds .db(s) directly and that is it? Or does the PPU has to be turned off for this also?

 

Unfortunately, you are going to get the slight moment of black as the PPU is off at that time. When trying to render that many background tiles at one time, you have to disable the PPU.

For shorter lengths, the PPU does not need to be disabled, however, you still have to load the tiles during the NMI. I do this all of the time, especially in my current game I'm writing. These is only 1 8x8 sprite in the game, and its just an arrow to point to who's turn it is.

There is a spot in the game where I write 256 tiles to the background (1/4 of the screen) and I do turn off the PPU for that.

Here is some code from my current game, I never disable the PPU for any of those .db tables:

 LDA #$05
  STA TEXTLENGTH                     ;The length of the text being written to the screen (number of characters being written)
 
  LDA #$0E
  STA TEXTLOWBYTE  
  LDA #$21
  STA TEXTHIGBYTE
 
  LDA #LOW(PauseText)
  STA TextPointer
  LDA #HIGH(PauseText)
  STA TextPointer+1
 
  JSR LoadText
--------------------------------------------------------------------------------------------
LoadText:
  LDA $2002               ; read PPU status to reset the high/low latch
  LDA TEXTHIGBYTE
  STA $2006               ; write the high byte
  LDA TEXTLOWBYTE
  STA $2006               ; write the low byte
  LDY #$00                ; start y out at 0

LoadTextLoop:
  LDA [TextPointer], y     ; load data from address (background + the value in y)
  STA $2007                ; write to PPU
  INY                        ; y = y + 1
  CPY TEXTLENGTH           ; Compare Y to TEXTLENGTH
  BNE LoadTextLoop         ; Branch to LoadTextLoop if compare was Not Equal to zero
  RTS
 
PauseText:
  .db $19,$0A,$1E,$1C,$0E                 ;PAUSE
UnDrawPauseText:
  .db $24,$24,$24,$24,$24,$24,$24,$24     ;Undraw Pause
MissText:
  .db $16,$12,$1C,$1C                      ;MISS
Hit1Text:
  .db $11,$12,$1D,$24,$01                  ;HIT 1
Hit2Text:
  .db $11,$12,$1D,$24,$02                  ;HIT 2
Hit3Text:
  .db $11,$12,$1D,$24,$03                  ;HIT 3