nesdev.com

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.

_________________
https://kasumi.itch.io/indivisible

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.

_________________
https://kasumi.itch.io/indivisible

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.

_________________
https://kasumi.itch.io/indivisible

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 them both 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?

_________________
https://kasumi.itch.io/indivisible

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.