Graphics editor for NES

Did anyone ever manage to try this? Or are you all waiting for me to implement the tile editor first?

OK, I get it. You all want a tile editor so that the tool can become self-sufficient, and you want some example pictures to play with. I'll try to have some of those done this week.

Kinda, yeah. I love the idea of editing graphics on the system that the graphics are designed for (having come from a C64 background where such editors are commonplace) and have toyed around with the idea of something similar for the Mega Drive. It sorta helps when you can do everything within the tool though

2 tepples Just a question... You said Are you sure?

I test editor.nes mostly in FCEUX, but I successfully ran it on my NES + PowerPak last night. I have a screenshot of (an earlier build of) the nametable editor part. Are you seeing breakage on your NES that's not present in an emulator? Or are you having trouble learning how to control it?

Which mappers supported?

Does it matter? Except for the MMC5, that can work around the "same palette for each 16x16 pixel area" limitation, NES graphics are always the same no matter the mapper.

Don't forget lil' VRC6!

The intended board for this program is SNROM. If by "mapper support" you mean triggering a bankswitch part of the way down the screen to get more distinct tiles or switching between the left and right nametables every 8 scanlines to get 16x8 pixel color areas, then that's not supported. Is it a necessary feature?

The tile editor is coming tonight, barring major unforeseen mishaps.

Tepples, you probably worked very hard on this, but yet I have trouble getting my CHR files in a .sav files. A tile editor is not nessarly, but something that does CHR to .sav easily would definitely help.

Also if you made a meta-sprite editor it would be awesome !


What tokumaru said - aside MMC5's ExGraphics, NES graphics are the same no matter the mapper.
Castlevania III does NOT use any special graphics from MMC5 nor the VRC6. (unless you count switching the CHR-ROM mid-frame as "special" - in that case, SMB3 is just as special).

Editor 0.02 with the tile editor is out. Get it


I've made a note in the manual that .chr (4096 bytes) + 4096 bytes of zeros = .sav (8192 bytes).


Sprites will take a while.


The title screen of Smash TV (MMC1 based) is special too.

Good

So, d'ya come up with any pictures?

Well, it's sort of hard to motivate myself to continue this project if I don't know whether I'm on the right track with respect to the user interface design. I can't know what direction to take it if I don't get any constructive criticism from others who have tried to use it. Did you miss the release announcement for version 0.02? Have you found it too hard to learn? Are you waiting for the ability to add sprites before trying even the background part? Or do you just want something that runs natively on Windows?

I think it's about as nice as an NES graphics tool can be on the platform, I suppose.

I would never use it for that, though, since it seems a little absurd to me to try and make graphics like this when I could be using a mouse and working on a PC (where I would do the coding and other development anyway). That's really the reason I didn't try this before today.

It's an okay toy though, and probably a good instructional tool for people who want to learn how NES graphics work.

I too find the idea interesting, mainly because you can instantly see the images as they will look on the final product, but I really don't use any console-specific editors, be it on the PC or any other platform. The drawing tools are usually very primitive when compared to actual image editors such as Photoshop, Gimp or even MSPaint. I'd rather use more advanced drawing software and use tools to convert the images to the final format.

Such a converter is included, but only for images with 4 colors. I guess I could make it support images with more colors, where the user supplies a palette and the program tries to find the best color set for each 16x16 pixel area among the four. For 0.03, I'll try to work on the use case of using this alongside a PC based image editor such as GIMP.

So today, a few people in #nesdev tried this. I'll summarize the feedback I got there:

doppel said "it's got pretty dang solid usability".
Gil_ said it can be a pain to set up Python in Windows to run the converters.
rane ran it on a PowerPak without loading a .sav file, which produced random-looking data. I've seen this before, and I suggested it might be bits and pieces of the FPGA fusemap.
doppel suggested letting the user tap B to change the color set associated with an individual 16x16 pixel area. (Currently B picks up the tile number and color set under the cursor.)
rane also asked for "a way to just draw attribute".
rane liked the option to zoom in on the tiles (Start) but took about a minute to figure out it was a tile editor.
doppel thought Select+Control Pad to change the tile number was clever
doppel liked the palette editor.
rane might not "have any use for it other than something to play with". I pointed out that it could be run on portable devices that run emulators.
rane wanted a box shaped cursor on the nametable editor instead of the arrow.
rane wanted a display mode that just shows solid tiles to see attributes.

Anyway, thanks for your feedback.

I would just presume it to be the randomish bits that would be present in the PowerPak's SRAM area on startup, since I don't think the PowerPak BIOS uses it or initializes it with anything unless you have a .sav file. I don't think it has anything to do with the fuse map, unless the fuse map is normally loaded into SRAM before going to the FPGA?

I use ASEPRITE to animate sprites. This editor won't beat ASEPRITE.

I use Pyxeledit when I want check tile connections and edit tiles on the fly. Your editor would actually also be pretty useful for that, since it just naturally happens that updating one tile updates all instances of it on your map. Most graphics editors don't do that, which is why Pyxeledit exists in the first place. This editor won't beat Pyxeledit, but editors that do this are rare and sorta neat.

I actually do like the idea of this editor and will use it sometimes. At the moment, my swiss army knife of editors makes it somewhat difficult to check how even a simple change in palette will look in all the various things this game will run on. (Actual NES, various emulators) I'd like it to look good on as many of those as possible.

With this tool, I can quickly create a new CHR file without worrying about making room for the new tiles in an existing file used by my editors. I paste it into the .sav of this editor with yychr. And then I can place the tiles, and use the sav+nes rom on various things to see how the palette/tiles work.

Much easier than what I have to do now which I won't even go into.

But... I don't like the interface at all. I'm used to an LSDJ style of things, which is the only native editor I can think of that I've liked.

Consider the "EDIT COLOR PALETTE" screen of your editor. To change a color, I have to navigate to it, press A to select it, d-pad to change it, then press A again to deselect it.

LSDJ make it so that while A is held, d-pad change the number, when it's let go it allows you to select a number. Being used to LSDJ, sometimes I press and hold A to change a number, and let go when I want to navigate. I end up messing up my palette before I realize I'm in the wrong mode.

If you're feeling bold, you could satisfy both camps by detecting if the user has held A more than X frames. If so, releasing will go back to navigation, if not the user must press A again to back back to navigation.

Another thing I like about LSDJ is that the screens that allows you to control various behavior are arranged in a map. The key combo is "select+d-pad" and it consistently moves around this map. (The letters of the map are also displayed so it's trickier to get lost)


Let's say I'm on S. Select+up will move me to P. +down will take me to G. +right will take me to C.

It's also arranged intelligently in that moving left-right makes the editing your doing less/more specific while moving up or down takes you to a related edit mode to the current "level of specificity"

(T)ables, are used to control (I)nstruments, which are used to play notes in (P)hrases, which are used to string together (C)hains which are used to make up the (S)ong. This also frees up select alone for other stuff.

I also mention LSDJ's select+ behavior because your interface uses three buttons (start, select and sometimes A) to navigate between editors and LSDJ uses only one.

Check your tile editor right now. A drops a pixel of the current color. B cycles through the colors. Start and select both do the same thing. The behavior of B is a little inconsistent with most graphics programs and this editor's own tile editor.

Let's say A is left click and B is right click. A places the current color. Cool. B could pick up the color underneath the cursor. Start could cycle, and select could sent you back to the HUB.

Quick note: I selected "move used tiles to top" expecting no change at all, since all the used tiles were already at the top. Instead, it cleared out everything that wasn't used as well. Maybe this is expected behavior, but I definitely did not expect it to clear my unused tiles as well. Just thought it would push those down.

Let's say I'm on the map. I now what to edit the tile I'm drawing with. To do this I must press select,start.
I am now editing a tile. I now want to place it on the map. To do this I must press select, A.
Now I'm on the map. I want to edit the palette. Select, Select, d-pad down, A.

That is why I think it's hard to navigate and inconsistent. Select+ is one way to do things. You could certainly think of another I'm sure, but currently I really don't the interface. I always have to keep in mind what part of the editor I'm in just so I know what to do to switch, editors. I also have to keep in mind where I am just to DO stuff. B cycles through colors everywhere except the map. Things like this are just irritating.

I could write a lot more, (and I will if you're interested) but really just try LSDJ and see how it manages things.



These are great ideas.

And just to say so I'd like to be able to edit a tile with the map behind it. I'm on the map screen, and I can do some button combo to edit a tile with the map still on the screen. This will allow me to see the changes immediately. I'm not sure if this would be easy or possible, but would be very cool.

Edit: While I'm suggestion editors within editors, I should also mention you should be able to see some type of graphics on the Palette editor. Even if it's something simple like just the top 16 tiles of the CHR data. Because checking what changes in palette look like on the actual tiles is a lot of back and forth right now.

Well, what first came to mind when using the arrow to edit nametables was "oh, I wasn't on the right tile, I wish there was a grid", and then I thought of ways to do a grid (e.g. drawing over one row+column of every tile in CHR RAM maybe) and then realized all I needed was something that showed me where the current tile edges actually were, and you could actually do this really well with about 4 sprites.

If I could press a button or just hold some button combination to swap to "attribute view" and back, it would be an easy way to see the tile grid at the same time. I guess you could just create a 2x2 "plaid" tile in the other CHR page and fill the entire second nametable with it (but write attribute to both nametables), then flip to these on command. I could check it quickly before I start placing a new object so that I'd know where to start (i.e. find a nice attribute boundary).

Anyhow, it's only a suggestion because it's something I would (and did) implement in an NES screen editor. I'm always checking my attribute table as I work, but maybe that's something that only I do.

Yep, 4 sprites would do it. It's the same for choosing which tile to edit. Instead of the arrow, a box would be good there too.

Also, if possible, I'd like sprites directly around the tile in the zoomed in tile editor as well. Right now if you're editing a tile that's in the middle of the screen, it's tough to visually line up the sprites that mark the edges that are several tile away at the borders.

You have a good idea for how to make the palette editor easier. The first thing I plan to do is implement the following behavior:

• If A is held longer than twice the autorepeat delay, letting go will leave modify mode.
• If a direction is pressed while A is held, letting go will leave modify mode.

And you're right that the navigation isn't perfect. Here's the current map of the program:

From most screens, Select goes back to the tile chooser.


Currently on the map editor, Select+Control Pad changes which tile is selected. If I were to implement LSDJ's behavior of Select+Control Pad changing screens, what would become the shortcut for picking another tile without going back to the tile chooser?


You're right that moving cycle from B to Start and copying the map editor's behavior of B to pick up would make more sense here.


You're right that "move used tiles to top" destroys unused tiles because it's currently implemented using copy operations. I'd have to implement it using swap operations in order to preserve unused tiles, and that'd take even more thought about the algorithm if I want to keep the unused tiles in order.


The key idea that I wanted to implement was that pressing Select at any time would go back to the tile chooser, or hub as you figured out, just like the back button in a web browser. Look at the Select button on your Xbox 360 controller: it's labeled "Back". So Select, A always goes to the map, and Select, Start always goes to the tile editor.


The Down step for editing the palette is the part that sticks out. Editing the palette is something done less often, but you're right that I should switch the palette and help items.


That can't be done without NES 2.0. The NES pattern table is divided into two banks, each 256 tiles or 4096 bytes. The 4x zoom requires a whole bank for all 256 combinations of four different 2-bit pixels. The map display likewise requires a whole bank. This leaves no room for UI graphics.

What I can do, however, is make an alternate zoom mode in which the tiles are not in tile chooser order but in map order.

I like that idea.


At this point I'm losing track of what buttons are used for how it is, and how I'd like it to be. So uh... here's a complete overview of how I might arrange this.

Program Map is like this.


Select+d-pad moves around this map. Here are what the letters mean.
M = The map view.
T = The tile viewer.
H = Help. (The H above the map view is help for that. The H above Tile view is for that.)
Z = Zoomed in view. The Z below T is the one we have now. The Z below M is the behavior you described above.
P = Palette Editor.

Controls on P:
Unchanged, except select+now works.

Controls On M:
A: Place a tile.
B: Eyedrop a tile.
Select(no direction): Cycle attributes.
Start+D-pad: (Choose tile) (The behavior you were concerned about losing in the quote above)

Controls On T:
A/B: Selects a tile to use on M. (Eyedrops it, basically)
Select(no direction): Change Color set.
If you want you can make start zoom in, but select+ does that now.

Controls on TZ/MZ:
Select (no direction): Current color+1
B: Eyedrops the color at the current pixel.
A: Places the current color at the pixel.
If you want you make start do what it does now.

This way, B always eyedrops, select always cycles colors when not pressed with the d-pad always navigates when used with the d-pad, and start/start+d-pad is free for whatever functions in ALL the editors.

Select+down/up tends to zoom.

At least, that's as good as I can do off the cuff. I'd probably come up with a different place for the palette and help pages, but there's a basic idea.

I realize that for now, I've left out the "BLANK ALL UNUSED TILES" etc. I'm not sure where those fall yet. They're actually not that important to me, so maybe that's why I'm ignoring them. Have I missed anything else?

Edit 2:

With that explanation, I get it, but... I just tried it.
I'm on the not zoomed in Tile View. Select, A always goes where?
Select, start always does what?

If the help was moved some place that didn't affect this behavior such that what you describe always was true, I could get behind that as well.

Edit: And... I know I've seemed pessimistic. Feel free to do none of this, honestly. I realize it's a tall order. Plus, some of this stuff may only suit me as an LSDJ user. I know on user on IRC said it's solid as is, so they may not like how I'm suggesting setting it up at all. I really do find the editor extremely impressive (especially the zoomed in tile view), it's just getting around is tough.

Edit 3: Found a tiny bug/inconsistency. In the palette editor, using right goes from $x0 to $xC, but doesn't wrap. Except when x is 0. In that case, pressing right on $xC goes to $x0.

Could you use chr ram and do it in real time? Even if more than one tile is displayed you only have to update the changed tile when somebody edits a pixel.

Thank you all for the feedback. I've boiled it down into 13 change requests and one tracking bug. I had hoped to have a whole bunch of pictures with which to test a slide show builder, but I guess I'll first have to define which change requests will make it into 0.03.

And with a bunch of UI niggles fixed, 0.03 is here. Get it

• More completely enables MMC1 SRAM, even on later MMC1 revisions.
• Moved palette editor to top of the tile picker's menu, above the help page for the map editor (requested by Kasumi).
• Palette editor supports "spring-loaded" editing. If the A Button is held longer than half a second, or if a color is changed while A is held, the editor leaves change mode (requested by Kasumi).
• Palette editor: Fixed wrapping of hues between $xC and $x0 (requested by Kasumi).
• Map editor: Press B repeatedly to cycle among color sets (requested by doppel).
• Map editor: Cursor is a square (requested by rane and Kasumi).
• Tile editor: Drawing a straight line doesn't freeze the top row (requested by NovaYoshi).
• Tile editor: First press of B picks up color under pencil point (requested by Kasumi).
• Converted manual to HTML and emphasized the pattern of using Select as a back button (requested by Kasumi).

I couldn't decide which of the B behaviors to keep (cycle or pickup), so I found a way to combine them by introducing a concept called eyedropper_state. The first press of B on either the map editor or the tile editor picks up the value under the cursor, and subsequent presses without moving the cursor cycle the selected color.

At this point, I need to figure out what Start on the map editor is supposed to do. I have two actions that I want to bind. I can have Start either show attributes using solid-color tiles or enter a tile editor with tiles organized as they are in the map.

I can definitely get behind how the B button works now. I like that for the map editor, it doesn't actually change the attributes until you press A with the tile in the buffer. What I planned was more guess and check, heh. This is better.

The new square cursor for the map is totally excellent. How about for the tile chooser too?

One tiny issue I've encountered are the sprites that mark tile borders in the zoomed in mode. They're tough to see against background colors like $3C, especially on the actual NES. I know the text adapts to the background color, so it'd be nice if these sprites did too.

Here's a pipe dream, but I'll throw it out there: Block copy for the map editor. Press and hold B on 00, 00. Navigate to 01, 01. Release B. The square whose top left is 00,00 and bottom right is 01, 01 is copied to RAM. (Possibly change the display that normally has "$(Tile number) (two copies of currently Selected tile)" to "BLOCK" or something like that.)

Move cursor to 05, 15. Press A.
05, 15 becomes the tile that was in 00, 00.
06, 15 becomes 01, 00.
05, 16 becomes 00, 01.
06, 16 becomes 01, 01.

I put this feature in a PSP map editor I made once, and it was pretty useful for moving stuff around/making multiples of structures. There are lots of issues with this sort of behavior. One is how to deal with attributes. The other is that it takes a lot of RAM provided it actually copies the tile numbers that are there at the time the copy is made, rather than just remembering the start and end point. Also, if you paste a huge block, you have to update a large part of the screen. Etc.

I ask for it just because I realized after I laid my map out that the tiles were a tile away from being aligned to the attribute boundaries. Other solutions for this could be ways to shift the map a tile in any direction.

Anyway, I used this for my stated purpose of checking palettes, and it's really wonderful for that.

Edit: Any chance of making emphasis bits available?

I've ended up with so many requests for the map editor that the correct action for Start is obvious: show a menu of other actions.

Yes, in a couple versions, this might end up making Start into the menu button, like Select is the back button.

I've released version 0.04. Get it
Changes:

• Left+B+Select at the title screen erases the saved data in case garbage was present.
• Tile editor: Pen color indicator (at lower right) and tile edge marks (on the border) are drawn in the same color as the status bar text, fixing contrast with light backgrounds (requested by Kasumi).
• Map editor: Press Start for the map tools menu.
• Map tools: Zoom in on the map and edit tiles in the order they appear in the map.
• Map tools: View with constant tiles to see attribute assignments (requested by rane).
• Map tools: Change the screen tint (requested by Kasumi).
• savtool: Complete overhaul of image converter.
• savtool: Extract a palette from a .sav as a 32-digit hex code.
• savtool: Convert a color PNG with a specified palette (based on a request by tokumaru).
• savtool: Remap a PNG to use a specific tile sheet.
• savtool: Combine .nam and .chr into .sav or vice versa.
• sample_savs: Cleaned up pm a bit.
• sample_savs: RPG_village has better tree highlights and some figures.

And again, I'm taking suggestions for what to add in the next version:

1. Use swap operations instead of copy operations to preserve unused tiles when moving used tiles to the top
2. Copy and paste rectangular areas of map
3. Something that you're about to describe after trying the new features in 0.04

I really want to get it to the point where I can include more than the four sample_savs that I currently include.

Has anyone had a chance to try the new savtool or in-map tile editing?

I haven't ever tried any of the included python scripts, because messing with python has always been a hassle for me. I have tried the in map tile editing and it's very, very cool.

What hassles have you run into when getting Python to work? Perhaps I could walk you through installing Python. Or what alternative to Python should I have been using?

I managed to run Python programs with a portable version of Python, that way I don't need to modify my system in any way.

Is there anything else that you especially want to see done in 0.05 other than copy and paste?

Other ideas (you might not use):

• Allow the use of keyboard and mouse (optionally; standard controllers would still work too).
• Tapedump save mode.
• Turbo File save/load.
• Data recorder save/load.

And I've released 0.05. Get it

• Map editor: Removed duplicate binary-to-decimal converter.
• Map editor: Made some UI code reusable by other map tools.
• Map tools: Added copy and paste (requested by Kasumi).
• Tile editor: Moved everything up 8 pixels to make room for another line of text in the status bar.
• Tile editor: Displays count of unused tiles.
• Tile editor: When zoomed in on a map with unused tiles, Start toggles allocation of a fresh unused tile when drawing onto a tile used more than once.

I can see how a Super NES Mouse in port 2 might be used: left button = A, right button = B, and movement generates up, down, left, or right actions for every eight mickeys. But I don't see how a keyboard would help. Nor can I test with a data recorder.

EDIT: Also attached

I think a keyboard would help two things:

• Shortcut of commands (so each command can be mapped to a separate key, instead of using menus).
• Direct text entry onto nametables, you can type in and it make the text (or other tiles, if mapped this way).

But I don't really care much if you implement this or not (since I do not use this program); it is just suggestion.

Answering an old post: I'm not sure what I ended up trying with python before deciding the ends don't justify the means. But in this case, I must install python to try some scripts for this one program. Non portable is 15 meg, then install. One of the really cool things about NESdev is downloading for less than a second, and getting a totally cool program.

I like command line apps, but I realize that's certainly not worth the trouble for you if you want to be cross platform. (Indeed, another really cool thing about NESdev is it's pretty cross platform.) Lack of python isn't even something I'd mention if it hadn't been asked about, because I realize how stubborn I am about this sort of thing. I'll probably just write a PyxelEdit to editor program when I need some conversions.

Re: Tint bits. Any chance they could make their way to the palette editor? This way one could see their effect on the entire palette without closing it and reopening it to see every change.

Re: Copy/Paste. Because the block disappears as you're moving it quickly, sprites around it would be neat. Also, because if I copy a bunch of sky tiles to "blank" an area, when I'm moving around a map that's mostly sky I can't see where I am at all until I end up overlapping something.

The A53 mapper has 32KiB bytes (4 banks) of CHR RAM, it may be a bit slow having to do round trip copies from PPU to CPU and back again, but there's the space to store stuff at.

Tracking bug reports and feature requests from this topic:

• savtool: Port to Python 3 Done
• savtool: Accept true-color PNG files
• savtool: Make sure the error message for too many tiles has the amount of tiles substituted in

The A53 mapper has 32K only if 32K is installed. That was intended for CNROM games, but every CNROM game included in a multicart so far has been mapper hacked to UNROM (along with fixes of stack overflows), so I haven't needed to use it quite yet.

I don't think I'll be able to share enough code between the present version, which has work RAM at $6000-$7FFF, and a version that uses bankswitched CHR RAM as work RAM to make them build from the same tree. If I do make a version that uses bankswitched CHR RAM as work RAM, would you prefer that the screen be turned off during operations using a lot of random access to work RAM, causing flicker? Or would you prefer that such operations be made dog-slow, as in Videomation?

Copypaste commits and tile sorting would be fine with a blanked screen, and I would just omit the live preview of copypasting. Instead maybe try having 2 displayed bounding boxes, one for source and the other for destination, kind of like in the days before window compositing when a outlined box was showed when moving windows.

Moving in the zoomed tile preview is going to be tricky, as I think it should not blink. It might just be acceptable to leave it 3 times as slow (2 frames to load the tiles for each row, and 1 frame to draw them), but if there's enough RAM for a 6x5 tile window (480 bytes) then maybe the tile fetching part can happen in idle frames while the cursor is moving around.