This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

What do you guys use to create nametables and attrib tables?

What do you guys use to create nametables and attrib tables?
by on (#53385)
I just wanted to know if you guys used any programs to make your nametables and attribute tables or do you do it all by hand?

by on (#53386)
I've never had a real need for setting up complex Name Tables, because most of my programs generate the Name Table contents gradually (such as scrolling game that decodes the level map to the screen a column/row at a time). And I use my own tools for the level maps.

There will be a time when I'll have to make title screens and such, but I guess I never though about it much. I will probably use someone else's program to create the screens, but will probably use a custom compression scheme on the data.

If the screens are really simple, use mostly contiguous tiles and simple attribute patterns, it might be simpler/quicker/smaller to draw them with a few loops.

by on (#53388)
tokumaru wrote:
I've never had a real need for setting up complex Name Tables, because most of my programs generate the Name Table contents gradually (such as scrolling game that decodes the level map to the screen a column/row at a time). And I use my own tools for the level maps.

There will be a time when I'll have to make title screens and such, but I guess I never though about it much. I will probably use someone else's program to create the screens, but will probably use a custom compression scheme on the data.

If the screens are really simple, use mostly contiguous tiles and simple attribute patterns, it might be simpler/quicker/smaller to draw them with a few loops.


Oh right. How does scrolling work in the nametable sense is something else I've been wondering, how does Zelda II for example, handle scrolling and nametables.

by on (#53393)
The nametable can be thought of as an endless plane, and the screen is a 32x30-tile sliding window on that. Whenever the leading edge of the sliding window crosses a new row or column of tiles, update that row or column. To find what you need to update, keep track of a "camera" position in world space, and update the nametable whenever that crosses an 8-pixel boundary. In general, you prepare an update transaction in main RAM while the PPU is displaying a frame, and then you "commit" it during vertical blanking by making the copy to VRAM. You might learn something from tokumaru's illustration.

For nametables on static screens, I first used NSA (a DOS-based nametable editor). When I upgraded from Windows ME to Windows 2000, I felt the need to clone it for Windows using the Allegro library; 8name was the result. But lately, because of compatibility issues between Allegro and two of my computers (a Mac mini running Snow Leopard and an Eee PC running Ubuntu 9.10), I rewrote it in Python.

by on (#53406)
Doogie wrote:
How does scrolling work in the nametable sense is something else I've been wondering

I learned a lot from looking at how commercial games work. Open a game that scrolls in FCEUXD and open the Name table Viewer. I just looked at the game Layla for example. As you walk forward or backwards you can see how new columns of tiles are drawn.

Some game do it a bit differently. Castlevania, for example, updates larger squares one at a time from the top of the screen to the bottom. The advantage of working with squares of that size is that they match exactly the are covered by an Attribute Table byte, so this makes the handling of attributes easier.

Those are 2 simple examples, because they only scroll horizontally. Pick a game that scrolls vertically as well and you can see how it has to update rows and columns of tiles and attributes in order to display the correct portion of the level. This process is a litle complex, specially because you have to take Name Table mirroring into consideration as well.

The process is exactly how tepples explained. Create a camera that follows the main character, and by watching the coordinates of this camera (how much it moves) you will know when a new row or column of tiles or meta-tiles is necessary. You can tell where the row/column will come from (in the level map) and where it will go to (in the Name Tables) from its coordinates and direction.

Since everything I programmed so far used this kind of dynamic Name Table manipulation, I never needed to draw a full Name Table. A tool for arranging Name Tables is useful when you are making title screens, cut scenes and things like that, or when your game has a very limited number of screens.

Scrollers shouldn't be made with these tools, because the data needed to represent a full Name Table (plus the Attribute Table) is too much, even if compressed with generic algorithms like RLE or LZ. Games with large maps need a compact level map format, and a system to decode it to the screen.

by on (#53408)
It really helps to be able to program your own tools to make game data. You don't have to know any specific programming language so long as you can make a program to build data for your game/program. Making just a big name table in a program can be ok for a few static screens but as tokumaru said for most actual game backgrounds you're going to need a level editor to create data in a compact format that can represent both the appearance of the background as well as physical game properties.

I'd really avoid trying to make data "by hand". Creating an editor isn't that hard and makes it alot easier to see what you are doing. If you are doing more than a simple demo and intend for a fairly complex or lengthy game you definitely should have editor tools for game data.

by on (#53428)
Building an interactive editor can be a pain in the behind: you have to learn a GUI toolkit, a graphics toolkit, and possibly even a sound toolkit. And then you have to pray that the toolkits aren't incompatible with your combination of hardware and operating system. I used to use Allegro as my toolkit until 1. sound stopped working on my Eee PC in Ubuntu 9.04 compared to 8.04, and 2. Xcode stopped being able to compile Allegro as of Mac OS 10.6 (Snow Leopard).

Some people like to make editors that run directly on the NES, but then you run into input and storage limitations. Nintendo never made a keyboard or a precise pointing device for the NES,[1] which limits the user to four digital axes and eight buttons. Support for saved data larger than 8192 bytes is also spotty because no NES game ever used a battery-backed RAM larger than that.


[1] I didn't say Famicom.

by on (#53472)
Well to be honest, I'm currently programming a Nametable + Attribute table maker in Game Maker atm (mainly to prototype to probably later port to C/C++)

My game only requires a static screen for all the maps ( I believe it only would need to use about 8 nametables all up.)

by on (#53545)
I've said it many times before, I design my own editors for the NES. My level editor is a NES ROM that saves the level data in SRAM. It works way better than the "by hand" method, though many say they don't think it would suffice. Now for editing plain old raw name table + attribute table data for one screen, I just use tepples' editor. It works great for doing that. Sure, it could use an undo function, but I would way rather use it than type in all the data in .db statements.

EDIT: Also, the editors I make on the NES usually are made to do separate tasks. For example, I have an editor for editing metatiles, and another for laying those metatiles down to make levels. The .SAV file made from the metatile editor is .incbined into the project for the level builder. So whenever I edit metatiles with the metatile editor, I have to recompile the level editor to have those updated metatiles available to use in the level editor. This greatly reduces complexity in actually designing the editors if you don't have one editor doing too many things. It also is nice because 8k of saved data isn't very much, so with separate editors you don't have to use all of it up.

by on (#53551)
Well in all honesty, it was nice dabbling in the NES scene for a while, but I think I'm going to leave for now as I have no motivation to work on a 'random' NES project. Maybe if I plan out a NES game in the future I'll be back, but for now, it was a great learning experience seeing how older systems handle graphics and learning some NES assembly.

Thanks for the help guys.

by on (#54017)
I guess there isn't much point in responding to this thread since Doogie appears to have quit on us but I felt like throwing in my 2 cents anyway... I too have written my own editors. In fact, when I was first learning NES coding about a year ago, my first goal was to write a program where I could draw any random imaginable picture (from an appropriate NES palette) on a 256x240 sized bitmap and convert it to a pattern table, name table and attribute table. It was a great way to learn how NES graphics fit together. That project morphed into a much more complicated (but a bit messy) editor that I use for designing graphics, meta sprites, and animations. I went on to re-use a lot of the code for a level editor for my game, which I've made pluggable if I want to have it output data for additional games I may make in the future.

I write all these editors in C#. C#, in conjunction with windows forms (.net 2.0), is an absolutely wonderful way to create quick n' dirty applications. I thank my last employer for forcing me to learn a lot of C# =D

by on (#54041)
Guess I'll throw in my two cents too. I made my level editor for the PSP in C. It outputs my compressed screens, metatile sets and slope data. Attribute data is planned and I know the format I'll use for it, I just haven't bothered. Each level takes two minutes to output (and growing), but it's a console I'm very used to writing editors for.