Storing and writing a full room's background

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
ericandrewlewis
Posts: 17
Joined: Wed Jan 16, 2019 9:13 pm
Location: Lower East Side
Contact:

Storing and writing a full room's background

Post by ericandrewlewis » Wed Jan 30, 2019 7:16 am

I've made an example of writing the background of an entire room. Here's the relevant code and nes file which doesn't do anything other than display the background:

Image

If you were making a game that consists of rooms like this, is this a good way of storing and writing backgrounds?

Do folks write backgrounds in different ways? Maybe for different layouts, like side-scrollers?

Thanks to rainwarrior for the starter code!
Last edited by ericandrewlewis on Thu Jan 31, 2019 7:23 am, edited 1 time in total.

User avatar
dougeff
Posts: 2627
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Storing and writing a full room's background

Post by dougeff » Wed Jan 30, 2019 9:09 am

This is ok for a very small game. A larger game would prefer some kind of compression.

I have an issue with your palette code. The universal background color has mirrors, so writing to (for example) 3f10 would change it.

So the simple fix would be to do a 33rd write, just after you palette code, which would be 3f20, another mirror for the BG color.

LDA palette ;get the 0th color
STA $2007
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
ericandrewlewis
Posts: 17
Joined: Wed Jan 16, 2019 9:13 pm
Location: Lower East Side
Contact:

Re: Storing and writing a full room's background

Post by ericandrewlewis » Wed Jan 30, 2019 6:40 pm

dougeff wrote:This is ok for a very small game. A larger game would prefer some kind of compression.
Yeah, this is data is heavy at 960 bytes. Seems like run-length encoding could bring this down significantly.
dougeff wrote:I have an issue with your palette code. The universal background color has mirrors, so writing to (for example) 3f10 would change it.

So the simple fix would be to do a 33rd write, just after you palette code, which would be 3f20, another mirror for the BG color.

LDA palette ;get the 0th color
STA $2007
The palette loop writes the palette definition into the PPU at $3f00-$3f1f. The definition includes duplicate values ($0f) for the background memory address $3f00 as well as each of its mirror addresses. So $0f is written to $3f00 as well as $3f04, $3f08, $3f0c, $3f10, $3f14, $3f18, and $3f1c.

Is this bad? What would the affect of writing this value to $3f20 be, if the original and mirrors have all been written to the same?

I do notice this in the PPU palettes wiki page:
Le Wiki wrote:A symptom of not having implemented this correctly in an emulator is the sky being black in Super Mario Bros., which writes the backdrop color through $3F10.
but I'm not sure I understand what that means. Is writing to $3f10, $3f14, $3f18, and $3f1c dangerous even if it's the same universal background color?

Thanks for taking a look!

tepples
Posts: 21809
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Storing and writing a full room's background

Post by tepples » Wed Jan 30, 2019 7:23 pm

Writes to $3F14, $3F18, and $3F1C have no effect under normal display conditions. Writes to $3F10 will overwrite $3F00, so if you write both, the one written last takes precedence.

Post Reply