NES Screen Tool

muffins · Post by **muffins** » Mon Feb 13, 2012 9:19 am

Would someone be willing to walk me through how to include this in a .asm file to show up as say, a title screen, once I've designed one using this application?

Dan

3gengames · Post by **3gengames** » Mon Feb 13, 2012 11:39 am

Read more nerdy nights over and over until you understand at least PPU interaction, because you should be able to pretty much do that once you get to there. Don't look too far ahead.

NESHomebrew · Post by **NESHomebrew** » Mon Feb 13, 2012 11:56 am

muffins wrote:Would someone be willing to walk me through how to include this in a .asm file to show up as say, a title screen, once I've designed one using this application?

Dan

Save the CHR data to a file. Then there is an option in one of the menus to save the nametable, attribute, and palette data to clipboard. Then using your own code, or borrowing some from existing tutorials (aka nerdy nights) replace the background and attribute data with the data copied from nesst.

Nerdy Nights 6 deals with backgrounds, but I agree with 3Gen, you should really go through all the others first just to get a basic understanding. Week six has already dealt with reading controllers, displaying sprites, palettes, and a lot of really important stuff you need to know before continuing on.

muffins · Post by **muffins** » Mon Feb 13, 2012 12:21 pm

Thanks guys! I guess I should have been a little more specific with what I was having trouble with. I have been through those tutorials a few times and have created a functional pong game (without audio or title screen...that's the stuff I'm working on now

) but what I was curious about was how to dump the information from the Screen Tool to a file, and then access it in the PRG ROM. I've written a loop that can fill a screen with tiles (32 x 30) to create a background if I have explicitly written out the data, for example:

Code: Select all

.db $25, $25, $26, $25, $27 ; and so on...

but I didn't want to go through the painful process of designing a title screen in NES Screen Tool, then go tile by tile and hand code each of those tile numbers in myself, but rather have the program dump that data into a file that I could access via a loop. I see the "Save nametable and attributes" option that you mentioned, WhatULive4, but I don't know how to access the data in a .nam file because the Nerdy Nights tutorials give no background on that type of stuff.

tokumaru · Post by **tokumaru** » Mon Feb 13, 2012 12:44 pm

Put the files generated by NES Screen Tool in the same folder as your source code, and replace the .db statements with .incbin (some assemblers do it differently, but it's usually .incbin "file.nam"). This includes a binary file at that point in the ROM, which is the same as if you typed a bunch of .db statements.

muffins · Post by **muffins** » Mon Feb 13, 2012 12:46 pm

Just what I was looking for. Thanks Tokumaru!

NESHomebrew · Post by **NESHomebrew** » Mon Feb 13, 2012 12:46 pm

You'll want to select the whole image or just part of the image if you want using the shift key. Then in the nametable menu, select the "copy block to clipboard" option.

Bananmos · Post by **Bananmos** » Sat Feb 18, 2012 9:03 am

One feature I'd love to see is for attributes to be properly calculated when importing a .bmp, as it is a bit tedious that you have to correct the attributes manually even if the .bmp has been drawn with this in mind. Of course, that presents a problem that if the rules of the attributes are not enforced in the bmp data, but I think just getting the color from the upper-left 16x16 block would be sufficient, and just let the user deal with the case where (s)he neglected the attribute rules in the original file.

Also, it'd be nice if there was some sort of "project" file for saving loading all of your data at once, instead of having to save nametable, tiles, and palette separately. I guess just saving all of this into one .zip/.tar archive (which is what OpenOffice's format or the Android .APK format really is) might be the simplest way to implement this.

Shiru · Post by **Shiru** » Sat Feb 18, 2012 9:43 am

'Save all' is may be useful, but I certainly don't want to make zip/tar thing. Why there is no 'Save all' yet: it wasn't really needed in (many) actual projects, since they tend to have one tileset, few palettes, and many nametables. I.e. situation 'one tileset-one palette-one nametable' is not common.

Shiru · Post by **Shiru** » Sun Feb 19, 2012 1:35 am

Added colors and attributes import. It consider colors 0..3 as related to palette 0, 4..7 to palette 1 etc, checks the most often used colors in an attribute position and sets corresponding attribute. So it is able to import back previously exported BMPs with colors and attributes, or another image that was created considering this limitiations.

There is also primitive Save all function now, it calls all the save dialogs (Save CHR, Nametable with attributes, Palette).

Bananmos · Post by **Bananmos** » Sun Feb 19, 2012 3:39 pm

Shiru wrote:Added colors and attributes import. It consider colors 0..3 as related to palette 0, 4..7 to palette 1 etc, checks the most often used colors in an attribute position and sets corresponding attribute. So it is able to import back previously exported BMPs with colors and attributes, or another image that was created considering this limitiations.

Thanks! This one is really helpful! :)

There is also primitive Save all function now, it calls all the save dialogs (Save CHR, Nametable with attributes, Palette).

Hmm... this one currently requires you to type in the filename separately for each type of data it is about to save... so it's only slightly less teious than having to go through it manually :P

I do understand your arguments against a "save everything"-feature, but I see it more as a "save your current state for working on it later" function. Even if your final data you'll use in a game will most likely be carefully sorted into different .chr, nametables, palettes etc, without a simple 1-1 relation, the common case while playing around in the tool will be to want to save everything you're currently working on easily for later reloading, which is where I think this feature would be very convenient.

Shiru · Post by **Shiru** » Sun Feb 19, 2012 3:58 pm

If 'Save all' will put first entered filename (CHR) into two next save dialogs (nametable, palette), would this help?

I'll think about 'save state' thing, I guess it not only needs to save all currently loaded data, but also current paths and state of buttons (grid etc).

jayminer · Post by **jayminer** » Sun Mar 18, 2012 11:49 am

I think I found a bug. Don't know if it has been reported earlier since I didn't have the patience to read through the entire thread!

I was splitting some of my CHR-banks into smaller chunks, and I usually do this by selecting 1kB of data and using "Save selection", but if I did this when I had selected data in bank B it saved the corresponding data from bank A instead.

Shiru · Post by **Shiru** » Tue Mar 20, 2012 4:08 am

Yes, it was a bug.

The program is updated, added the requested 'save states', also tile 90 degree fliiping, few small bugs fixed, and documentation is improved.

infiniteneslives · Post by **infiniteneslives** » Thu May 17, 2012 2:19 am

Loving this tool Shiru!

Minor feature change requests for your next release:

-Is there some way to see what name table mode I'm in visually? I always just end up assuming I'm in select mode and undo the undesired modifications if I'm wrong. Kind of annoying. I avoid looking at my keyboard like the plague so the caps lock light doesn't help.

-Could the draw/select nametable hotkey be switched to something besides caps lock? Tab perhaps, or hold spacebar while selecting? This becomes excessively annoying especially when using a man's text editor like Vim as a neighboring dev tool. I start destroying my code if I forget I left the caps lock on from my last nametable modification.

As a discussion:
I see there is talk of larger than NROM support. I'm no where close to being able to make use of this with a game. But I imagine it would be a huge benefit to supporting bank switching for animations and such. I guess you can do similar effects by just using A and B nametables back and going back and forth. Then just manually stitch your banks together properly. Wouldn't work so great for more than two banks of animation. Down the road once I set up some hardware with swappable attribute and name tables I may request support for more than one attribute table or different attribute table limitations. But now I'm really getting ahead of myself